![]() ![]() ![]() That, assuming that Jabo will still come bundled with Project64 in the future. EDIT: Or enter the emulator configuration and manually set Jabo's D3D8 or Glide64 or other plugin that works with their hardware. Aka, how Dolphin currently approaches this. If you really insist in rising the requirements to that level, I guess most of the userbase of the Dolphin emulator (which is not small) would be able to use Project64, and would motivate users with older computers to upgrade, or resign to use an older version of the emulator that works with their computer. On the other hand I agree that in an ideal world where most users have a gfx video card compatible with at least OGL 3.3, GLideN64 would be the ideal plugin since it actually has progress. But don't go to the other extreme either, excluding most of the userbase from using the emulator with GLideN64. So summarizing what I said above, let's not be so afraid of rising the requirements for people with older processors, it's simply not possible to decently emulate the N64 using old APIs like Direct3D8. Wouldn't that make the plugin work significantly faster, since it wouldn't spend time translating the GLIDE calls into OGL calls?Īt least, even though it's not as accurate as GLideN64, compatibility with game effects increases a lot using Glide64 instead of Jabo's video, which has overstayed its welcome for a while already. I read somewhere time ago that a developer was working on a wrapper-less version of Glide64, I think it was for RetroArch or something. I guess there's a way to make GLideN64 compatible with even older hardware, so only some FB effects work, but I'm not sure how feasible is that. Sure, it's actually more optimized than Glide64 for Frame Buffer based effects, but the compatibility with the broad hardware is a huge turn off. I'd say Glide64 would be the best as the default plugin, with the trade-off of rising the requirements a bit, but unlike with GLideN64 it will not only be limited to like 5% of the user base the hardware requirements for GLideN64 are quite high (not in raw power, but compatibility with a high version of the OGL spec 3.3 as the minimum with depth-based effects not working (like coronas, etc.) and the ideal 4.4 to get all the effects to work IIRC). (same type of thing applies to azimer's audio plugin). so the other question is if we use gliden64 how do we maintain where the master is for working on it. Also work needs to be done to be able to get and use Gliden64 in the main code branch, glide64 is already forked and in the tree. I would much prefer to look at and use GLideN64 since it has more attention, but the compatibility with older hardware worries me. So it would be nice to get rid of jabo d3d since it is closed source and have a plugin that can be fixed/improved. Open source, best cfb handling, according to is much faster, have developers actively developing it. Open source, good gfx, no one really doing any work, performance is worse than Jabo d3d, also meant to have issues with certain intel gfx cards. There are 3 plugins possible options that I am considering Jabo's D3d, glide64, and gliden64.Ĭlosed source, can not be fixed changed improved, would like to be off it but seems like the best compatibility still.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |