Divorce Glide64.ini from Project64.rdb about project64 HOT 20 CLOSED

I would love to drop it for GLideN64.

The aim of the settings is to make every install of pj64 portable. now it would not be that hard to move them off to there own file.

but what in particular are you finding is major hassle with them both in the same file?

from project64.

The fact that if I'm working on improving game settings, I also have to work on improving Glide64 settings. If I ignore the Glide64 portion, it won't be possible to update the plugin's settings without replacing the RDB. It ties 2 different settings to a single file.

And also, the mashup of PJ64 and Glide64 settings looks rather cluttered. I makes it a bit hard to tell which parameters are for PJ64 and which belong to Glide64. If Glide64 is eventually going to be dropped, we may as well sanitize the RDB already to make it easier to work with. I'm willing to edit it myself to remove the Glide64 settings, you would just need to readd Glide64.ini from the official version (it's settings have not been changed so far).

from project64.

what is wrong with replacing the RDB file?

all glide64 settings should start with glide64-

i do not see having an extra file will help make things easier. I know your editing the RDB file and there are a few other people who do, but in general it is not something that an end user will ever do, actually 99.9999% of people I assume never even open the rdb file.

from project64.

I never open the RDB file either. I'm one of those 99.9999%, but I'm inclined to agree with Fanatic-64.

Maybe splitting Glide64 settings out of Project64.rdb really does do nothing more than "having an extra file", but I still think it's a matter of logical concept. If we're going to start merging Glide64's, other plugins' settings with Project64 RDB settings for fewer files, we may as well kill the plugin system and just statically link plugins within Project64 rather than use a plugin system to begin with.

Plugins should have all the power to do things to their own capable knowledge in their own way and their own techniques, and mixing their tactics and opinions with those of Project64.rdb is mixing things that multiple people know separate things about into a file that neither know both about. Maybe having one file could sometimes be more efficient than having two files, but it seems rather counterproductive to maintenance and collaboration. It would be more organized to divide a solution into steps that different people are best at, not collide it all to a heap. I have a similar opinion about this entire repository including plugins to go with it, but that's a separate argument which I know will not be won.

from project64.

...Anyway that all being said, I don't feel like it's an "issue" since I don't care about RDB file anyway. I like the idea that an emulator can be perfectly accurate without one...the RDB should really just be for speed techniques and tricks like recompilers.

So it's up to Fanatic64 why he interprets it to be an issue, since unlike me he works on that file. I think it's a design flaw, but not an issue.

from project64.

I agree with both Fanatic-64 and cxd4 points of view, and think that PJGlide64 settings should be separated from the main RDB. Also, it would be more appropriate now that GLideN64 is approaching an official release.

from project64.

maybe jabo's gfx plugin default settings should be removed out of the rdb as well .. the rdb was meant to be the default settings for different roms, but it can be the default for just the core and have different ones for different plugins.

GLideN64 will have a higher requirement I think it what is needed functionality wise on the gfx card, do you think we should have GLideN64 and PJGlide64, or just GLideN64? Or Should users have to download it them self.

from project64.

Yeah, I also agree with the above opinions. Let the RDB be dedicated to the core (I'd also say move out the Jabo plugin settings, but I know that's not feasible), and let plugins work independently.

EDIT: Ninja'ed, the problem with the Jabo plugins is that since they cannot be edited, removing their settings from the RDB would be removing them altogether. Unless we remove those plugins completely.

I'd say we ship Jabo (DX8) for lower end machines, GLideN64 (OGL3.0/4.2) for higher end, and maybe Rice (DX9) as an alternative too. I can't see GLideN64 being much slower than Glide64 anyway.

from project64.

actually all jabo setting should be removable, it all should go though the settings api and should not go directly read/write to the file any more .. at least for the 1.7 ones .. the 1.6 plugins tho would still directly read the file tho.

from project64.

I think we should keep PJ64Glide (for mid end) and just Jabo's D3D8 1.7 plugin (for low end) and ideally GLideN64 should be the default but too bad it has a high OpenGL support requirement.

Rice is fast but too hackish and is no more accurate than Jabo's plugin, not to mention the UI is somewhat confusing, so I disagree about including it.

from project64.

need to wait till it is released and we can test it more, it would be nice to have another function to test if the gfx card is capable of supporting GLideN64. If it is then set it as the default if it does not the set jabo's as the default.

from project64.

Even the pro-deprecation OpenGL zealots like mudlord hate that GLideN64 is going to require OpenGL 4.1. I personally am very serious about backwards-compatibiliy and minimizing the OpenGL requirement, and that's something Khronos screwed up starting in OpenGL 3.1. (Personally my OpenGL fork of angrylion's plugin only needs OpenGL 1.1 but does dynamic, messy extension stuff to detect pixel transfer optimizations up to OpenGL 1.5.) I would hope that GLideN64 is someday able to work out a solution that doesn't require beyond OpenGL 3.0.

Even that laptop MarathonMan shipped me has a NVIDIA 9600M GT, which has OpenGL 3.3 support, not OpenGL 4, not enough for the plugin. I doubt I would ever be able to run Gonetz's newer plugin on any computer I have easy access to.

Yes I would think it's logical to if at all possible, allocate Jabo plugin settings outside the PJ64 RDB as well. However maybe this isn't best to invest time into if the 1.6 plugins still force accessing the RDB anyway and if 1.6[.1?] plugins are included, because then it compromises consistency, legacy backwards-compatibility and possibly the nostalgia of the times where Jabo worked on pj64 (a relationship not shared with the developers of other graphics plugins like Glide64, which I think is even more logical to move out of the RDB).

from project64.

I guess once the source is out of Gliden64 we could look if there is any way to reduce the requirements of OpenGL 4 .. like maybe disable certain functionality .. have to wait till it is out to see.

from project64.

According to this: http://www.emutalk.net/threads/55166-The-creator-of-Glide64-is-crowdfunding-it-s-next-generation-N64-Graphic-plugin!?p=453724 OpenGL 4 is only required for Depth Buffer Emulation: http://gliden64.blogspot.mx/2014/07/depth-buffer-emulation.html Which means maybe the Glide64 method of Software Depth Buffer Emulation could be retrofitted. The rest of the plugin should work with OpenGL 3.0.

from project64.

Ok added a pull request for splitting the settings, #54

have a look and tell me if that is what you wanted?

from project64.

Yeah, that's perfect. One minimal suggestion would be naming the file Glide64.rdb (to make clear it's about the plugin and not the Glide API).

from project64.

Glide64.ini doesn't really sound too bad either.

don't think file name constitutes an issue though...far as I'd ever see, glide.rdb works fine

from project64.

@Fanatic-64 if your happy with this I can close it

from project64.

Is the Glide64 UCODE section no longer needed in Project64.rdb?

If so, you can close this.

from project64.

Glide64 should not be using Project64.rdb for anything

from project64.