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.

[Glycocide]

With the more recent discussions in this thread dating back 4 years, and there being a major public release 4.0 in April of 2019, along with a pre-release version just 6 days ago (as of this post, 6 days ago is August 31 2021), has any of the initial downsides changed in view of GlideN64?

There's both a QT and WTL version of the plugin, with the WTL being vastly less chunky in size (pre-release WTL 2.49mb vs QT 10.3mb extracted sizes), is plugin size/bloat still an issue?
Seems to be the size comes quite a bit from the inclusion of the gui in the QT build, which has the positive of being much easier to modify settings.


Trying to gauge if the forum is still fairly active or not, or maybe this thread is redundant thanks to these future releases of GlideN64 from the initial 2017 discussions.


Thanks,
posted from someone who has a passion for high accuracy emulation (also use a raspberry pi to tinker with low spec emulation as well, don't want to be too jaded with my views of cycle perfection)

[ExtremeDude2]

Originally Posted by Glycocide

Trying to gauge if the forum is still fairly active or not, or maybe this thread is redundant thanks to these future releases of GlideN64 from the initial 2017 discussions.

I can tell you that this forum is very dead (sometimes we get bots!) I don't even know of any place that links here anymore except maybe google.