Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1681  
Old 11th March 2015, 10:42 PM
fallaha56 fallaha56 is offline
Project Supporter
Member
 
Join Date: Apr 2006
Posts: 34
Default

Quote:
Originally Posted by V1del View Post
Doubtful that a website would magically fix things. Dolphin's actually a good example here. The unofficial website over which the team has no control over which contains outdated builds and isn't supported, still has the top google spot in some countries. And it would be additional work, for not really all that much of a purpose. Having it on Github when he feels he has improved it enough to have it there available for all is a much more cost efficient option

And if there is a binary it has to be accompanied by the current source at the time of a binary, so the situation wouldn't at all be different from that aspect.

And he doesn't want any money from it (and in this particular case it might even be against the license)
Take your point but have to say love the Dolphin web presence -effectively a detailed blog with a build-bot plus links to an issue tracker and games wiki

It is a little fragmented tho definitely esp the issue tracker!
Reply With Quote
  #1682  
Old 11th March 2015, 11:37 PM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

Well...

Dolphin web has a bunch of people working together.

Pixel-Accurate N64 Software Video Plugin only has one guy.
Reply With Quote
  #1683  
Old 11th March 2015, 11:40 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Quote:
Originally Posted by V1del View Post
You may also look at the controversy shunyuan's soft graphic thread caused, as what transpired there is likely to be part of hatcats reason to keep the source under wraps right now (although I can't say it is THE reason, it likely plays some part)
Related-ish, but yeah it's not exactly to do with suanyuan or Shunyuan at this point.
If my angrylion fork being compiled by somebody else to take all the credit for it was all I had to think about, I think I would have put it back on GitHub by now already. So that's not really it. I don't care that much about people taking credit for "my work" since this itself is a fork of angrylion's research. I didn't even care when Shunyuan used my RSP code in his plugins. I cared what he used it for and how he stole everyone else's code which unlike mine was not public domain.

I'm not good at explaining my own feelings or senses, and even if I was, all the logic, illogic and/or credibility in the world wouldn't really convey what I have learned about this external force of dishonesty, lies and evil through my own experiences. So I am better off not attempting to explain it here, as no explanation would really change much of anything, whether or not anyone believed it.

Important thing is that it should be ready for a new update soon. And yeah, making money off of this plugin is a violation of the MAME license. I have never made any money off of programming in my life except some summer job I had when I was 14.

Last edited by HatCat; 11th March 2015 at 11:43 PM.
Reply With Quote
  #1684  
Old 12th March 2015, 12:20 AM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

Yes I meant the whole way he went about things and not respecting the license and stuff not necessarily what he leeched directly off of you. For someone uninvolved the whole thing provides a good nutshell example of why one would be reluctant give access to stuff as freely as github allows.

I'm sure you have other reasons which don't really need to be elaborated on. It was to point out with a practical example that there WILL be people that abuse the general availability of sourcecode.

Another note on the whole website thing: Dolphin is a complete emulator, making a website just for two parts of one will not attract that much of an audience outside of enthusiasts who are already here.

Quote:
Originally Posted by ReyVGM View Post
Pixel-Accurate N64 Software Video Plugin only has one guy.
There surely are more, he's just the only one frequenting here (ofc angrylion comes to mind first as without him this particular plugin here wouldn't exist and by extension MooglyGuy and other people of the MESS team)

Last edited by V1del; 12th March 2015 at 12:27 AM.
Reply With Quote
  #1685  
Old 12th March 2015, 08:41 PM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

Quote:
Originally Posted by V1del View Post

There surely are more, he's just the only one frequenting here (ofc angrylion comes to mind first as without him this particular plugin here wouldn't exist and by extension MooglyGuy and other people of the MESS team)
Maybe so, but for the last year it has only been one guy: HatCat.


Quote:
Originally Posted by HatCat View Post
Important thing is that it should be ready for a new update soon.
Ooo yeaaah. Goldeneye here I come! :P

Last edited by ReyVGM; 12th March 2015 at 09:43 PM.
Reply With Quote
  #1686  
Old 13th March 2015, 02:09 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Okay. So as not to leave anyone under the assumption that I'm letting this project go dark again, here is what I've accomplished today.

I've moved all of the OpenGL stuff that was fundamental to the context and maintaining it (something like 80% of the total OpenGL code throughout the whole thing) to its own module (context.c and context.h, which will be two new source files). This should make concentrating on the RDP easier for people who aren't familiar with graphics APIs. Plus the OpenGL code is totally overflowing with my compatibility attempts...check for OpenGL 1.5 extensions, if not present use fixed-function whatever. Makes a few functions pretty complicated...so that is in a separate module now.

One reason I needed to do this is I am going to be looking at, unfortunately, falling back on a macro switch to link in SDL for GL context initialization. The reason for this is because Mupen64 0.5 uses SDL to handle windows rather than low-level X11 calls, and I have not yet worked out enough of the SDL 1.2 source code's functions written on top of X11 to see what my angrylion plugin is missing to fix this window event messaging issue (causes the controller plugin functions to never respond...you still get pixel-accurate graphics, just no response from your keyboard ). So since it has taken me quite a long enough time already to solve this, I'm going to have a macro to temporarily include SDL fallback instead to get around this.

That is what I am doing tomorrow.

Another thing I want to do is rename the RDRAM dumps (new feature in this unreleased plugin, either 4 or 8 MB depending on emulator settings). Currently they're just named "DRAM.bin", but I thought it would be more productive to name them after the value of VI_ORIGIN_REG ... so that you know the hexadecimal offset into the RDRAM dump that the frame buffer is stored. This way you can copy paste the hexadecimal into this other program I wrote, which reads any binary file as a raster pixel map and lets you scroll through it for texture memory, color/depth/frame buffers and other goodies.

Quote:
Originally Posted by ReyVGM View Post
Maybe so, but for the last year it has only been one guy: HatCat.
And RPGMaster has contributed virtually the entire GUI that you guys have now. And that will be improved in the next release as well, though only for Windows. I did not do a GUI of any sort in the Linux build; I am bad with windowing code. I moved most of the GUI's purpose to various other accessible communications of the plugin to minimize the need for a DllConfig in the Linux port, but configuring the plugin through linux mupen64 will XOR switch the config bit on whether to use bi-linear video upscale or point-sampled NN screen filtering.

Not to mention I've had to talk with angrylion quite a bit for a few pointers on a few RDP details here and there. He has done all the main development to the plugin; I am doing just some conventional things with it, like implementing SIMD for speed, features, a technical rewrite of the RDP interpreter core though that shouldn't really be noticeable to many people.
Reply With Quote
  #1687  
Old 13th March 2015, 05:12 AM
ReyVGM ReyVGM is offline
Project Supporter
Senior Member
 
Join Date: Mar 2014
Posts: 212
Default

Ah. I didn't know there were other people involved since only you seem to talk about the development of the plugin.

This current plugin doesn't have a GUI (unless you mean the three popups at the config option?), so I didn't know RPGmaster was working on that still.
Reply With Quote
  #1688  
Old 13th March 2015, 08:43 AM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

Nice progress, is there still as big of a perf hit when compiling with GCC or did you get that hammered out? Anyway keep up the good work. Can't wait to give this a whirl on linux

@ReyVGM
It should if you use the latest nocomment5, you do have the rdp_config.bin in PJ64's root directory? It should error out telling you that it's missing though.

Last edited by V1del; 13th March 2015 at 09:02 AM.
Reply With Quote
  #1689  
Old 13th March 2015, 09:08 AM
DaMan69 DaMan69 is offline
Member
 
Join Date: Feb 2015
Posts: 77
Default

Quote:
Originally Posted by HatCat View Post
Plus the OpenGL code is totally overflowing with my compatibility attempts...check for OpenGL 1.5 extensions, if not present use fixed-function whatever. Makes a few functions pretty complicated...so that is in a separate module now.
Given the CPU requirements I don't think you need to worry about GMA support.
Reply With Quote
  #1690  
Old 13th March 2015, 09:15 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,029
Default

Quote:
Originally Posted by V1del View Post
Nice progress, is there still as big of a perf hit when compiling with GCC or did you get that hammered out?
Well, I know that Clang certainly gives better performance than MSVC for this plugin. Never tried compiling with GCC yet.
Quote:
Originally Posted by V1del View Post
@ReyVGM
It should if you use the latest nocomment5, you do have the rdp_config.bin in PJ64's root directory? It should error out telling you that it's missing though.
Doesn't sound like he's using the latest version .
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 01:18 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.