Zilmar refuses to adopt GLideN64 and he's extremely obtuse about why (here is why!)

[Wally123]

Originally Posted by oddMLan

GLideN64 doesn't use the Glide API at all, in any shape or form. The actual reason it is 10MB is because of Qt, which is a very bloated GUI library. Compile the plugin without GUI and it's just 1.5MB

GlideN64 wraps Voodoo3 functions (Glide3x) to OpenGL. It even says so in the mission statement on Indiegogo

https://www.indiegogo.com/projects/g...phics-plugin#/

As for the "Bloated" GUI, it is far better to have everything self contained than it is to make users install all the required components of the GUI themselves. That and it makes it more compatible with the MupenPlus core for RetroArch. I do agree with zilmar that it is a tad bloated as a plugin, but as far as being able to be used in RetroArch, IMHO it is a fair price to pay for being cross platform between Mupen and Zilmar spec plugins.

[loganmc10]

Originally Posted by Wally123

GlideN64 wraps Voodoo3 functions (Glide3x) to OpenGL. It even says so in the mission statement on Indiegogo

No, it says that Glide64 used Glide3x. Trust me, GLideN64 doesn't wrap any functions, it is written directly in OpenGL.

[HatCat]

Qt in and of its self runs OpenGL, so keeping the render API GLIDE instead of GL would be dumb as hell if you're depending on Qt already.

Similarly, Qt libraries are all heavily designed in C++, so why even bother coding in C on top of colossal dependencies.

All the fancy alpha-transparent windows and objects blending in KDE is Qt using the graphics card through OpenGL. Interesting, but it's all done in C++ with a ton of console warning messages and much higher memory usage and latency. I think just GTK (under Xfce or maybe GNOME) is still not as lightweight as I like to go but still way simpler with more than a sufficient amount of modern desktop design concepts for my purposes.

[ExtremeDude2]

It's alive

[m1t0s1s]

Originally Posted by Wally123

GlideN64 wraps Voodoo3 functions (Glide3x) to OpenGL. It even says so in the mission statement on Indiegogo



As for the "Bloated" GUI, it is far better to have everything self contained than it is to make users install all the required components of the GUI themselves. That and it makes it more compatible with the MupenPlus core for RetroArch. I do agree with zilmar that it is a tad bloated as a plugin, but as far as being able to be used in RetroArch, IMHO it is a fair price to pay for being cross platform between Mupen and Zilmar spec plugins.

?

You could easily have an automatic glideN64 plugin downloader. Let's be honest, all n64 emulators need LOTS of forum post reading, tweaking, downloading, and configuration for each game. Which is why a single plugin that everyone can contribute to is a good idea, as long as it continues to follow the zilmar plugin specification. I'm ok with 10mb for a plugin size, we have plenty of storage, even on cell phones. If the issue is RAM and code size, code size does not speed. Even the openwatcom c/c++ compiler has optimizations that balance between code size and speed.

Recent discussion from gonetz's blog:

So, now GLideN64 has a bit of audio processing code. Emulation of this microcode requires modification of N64 SP_STATUS register. That is not allowed by original zilmar's specs for graphics plugin.