I'm curious, why is GLFW preferred over SDL? Looks like an uncommon choice for an emulator. I'm asking this because I was looking for input parts to make input mapping for my Wii U Controller Pro and I noticed that GLFW handles input too. But, then, isn't better to use SDL for these thing, including the audio? I mean, a lot of games use SDL for easily managing graphic, audio, and input parts together and at same time making them portable in every OS. We could say SDL is the standard de facto for games.

I once attempted a SDL backport of angrylion's original DirectDraw, pixel-accurate plugin off which some of the RDP and VI rendering driver now in CEN64 is based.

It was generally slower at blitting the pixels to the full screen in the surmounted result due to SDL abstraction layer calls being slower than the native Microsoft DirectX calls on Win32.
Still, I would much rather use SDL over DirectX.
At the same time, I would much rather use OpenGL/OpenAL over SDL, where possible.

I hate nothing more than tying myself to bloated, monstrous libraries.

If I wanted to drop GLFW support tomorrow, I could do so in a heartbeat because the only purpose it serves is creating a window and gathering user input. Likewise, OpenAL and OpenGL are the most open-sourced, cross-compatible libraries out there for what they do, and as such I want to use them as much as possible.

SDL, on the other hand, forces you to write an SDL application, instead of writing an application which uses SDL. It's the SDL way, or the highway.

It was generally slower at blitting the pixels to the full screen in the surmounted result due to SDL abstraction layer calls being slower than the native Microsoft DirectX calls on Win32.

Didn't the SDL scaling also make the output look all garbled (at least in Super Mario 64)?

Nah, that was a defect in the SDL port because I could never understand what angrylion was trying to convey in DirectDraw.
It was a problem with the pitch scaling via pixels per line (and that SDL had no automatic stretching like DirectDraw did).

Fortunately, however, by the time anyone decided to betray my work by publishing it prematurely, it was already in that unstable state, so the source code at that point was quite hard to make do with.

Also, too bad there's no controller input open library. (OpenCL and OpenIL names are used on other things.)
Maybe there should have been an OpenJL (joystick)?

CEN64 does have a software renderer. However, even though the output image is rendered is software, it still needs a graphics library of some sort to raster the image to the client's window. It uses OpenGL to do this in a hardware-accelerated manner (and it also uses OpenGL to perform the scaling from 320p/etc. resolutions to the 640p or that of the window in hardware).

MarathonMan wrote:GLFW doesn't support any kind of force feedback to my knowledge.

Well, this is disappointing. So it means that force feedback support is completely cut by CEN64 atm? Or do you intend to push GFLW's authors to implement force feedback in a short time?

MarathonMan wrote:
CEN64 does have a software renderer. However, even though the output image is rendered is software, it still needs a graphics library of some sort to raster the image to the client's window. It uses OpenGL to do this in a hardware-accelerated manner (and it also uses OpenGL to perform the scaling from 320p/etc. resolutions to the 640p or that of the window in hardware).

Interesting. So theorically it should be easy to manipulate pixels with, e.g., GLSL shaders too, am I wrong?

Snowstorm64 wrote:Well, this is disappointing. So it means that force feedback support is completely cut by CEN64 atm? Or do you intend to push GFLW's authors to implement force feedback in a short time?

Right now, I've been pushing off any promises of features until the emulator becomes more stable and the show-stopping bugs are fixed.

Snowstorm64 wrote:Interesting. So theorically it should be easy to manipulate pixels with, e.g., GLSL shaders too, am I wrong?

You'd need a GLSL library to do this, but yes. There are actually some filters that MAME and others use out in the wild to make it look more like the actual image (and require only OpenGL). I've stripped them out for the time being as I was pulling from angrylion's code and they had Windows-specific things embedded into them that I didn't feel like reversing at the time.

MarathonMan wrote:
Right now, I've been pushing off any promises of features until the emulator becomes more stable and the show-stopping bugs are fixed.

Well, I should have known that. I'm hoping force feedback will be added to CEN64 someday, too.

MarathonMan wrote:
You'd need a GLSL library to do this, but yes. There are actually some filters that MAME and others use out in the wild to make it look more like the actual image (and require only OpenGL). I've stripped them out for the time being as I was pulling from angrylion's code and they had Windows-specific things embedded into them that I didn't feel like reversing at the time.

Correct. Whenever I see TYPES THAT ARE IN ALL CAPITAL LETTERS AND OBNOXIOUSLY LONG, I just nope.avi my way out.

Yeah, I know it appears as if there is something Windows-specific. (In fact you can see some WIN32 defines for "conditional" things which actually turn out to be redundant. I safely removed such things such that there was nothing Windows-specific, just blitting using the language of DirectX.)