Software Render about omnispeak HOT 4 CLOSED

The good news is that there is already a software renderer in the code (a couple, in fact), though they're not activated at the moment in the precompiled x86 binaries (which wouldn't help for the Wii anyway).

Omnispeak can be built against SDL 1.2, which will always use a pure software renderer (and won't do any scaling, so needs resolution-switching to work properly for fullscreen support), and — with the git head version — also support for using the SDL 2.0 render API, which can be configured to use a software rendering backend with the SDL_RENDER_DRIVER=software environment variable.

Note also that the video interface (id_vl) in the code is pluggable, so you could write a backend based on a native Wii API if you prefer, and gain some of the advantages of hardware acceleration if it's appropriate (I'd guess you could do palette conversion and/or scaling with the GX API, but I'm not 100% sure). Look at the VL_Backend struct in id_vl.h if you want to see what needs implementing for a graphics backend (and at the various id_vl_*.c files for example backends, including in-progress Vulkan and DOS/EGA ones).

Personally, I've successfully played Omnispeak on the 3DS (using the SDL1.2 backend), and got the graphics working on the Switch as well, so it should be possible to port it to the Wii without too much strife.

from omnispeak.

If the framerate was nice in the 3DS then it should run good on the Wii too (I'm pretty sure it has a ever so slightly better CPU)

I'm going to try that. Getting input to work natively is going to be hard but rendering should be easy with the pre-made SDL 1.2/2.0 libs for the Wii. Thanks for the advice!

Uh, so i just use SDL_RENDER_DRIVER=software in the makefile or use "set (that command)"? I'm going to try both.

Just in case, isn't there any library to emulate keypresses with a Wiimote? If not i suppose i can just use Wii Linux + wminput (which comes conveniently preinstalled).

EDIT: Well, the 3DS CPU's likely runs at less than half of the New 3DS CPU's speed, which would be somewhere around 1.5GFLOPS, which compared to the Wii's 2.9GFLOPS should mean Omnispeak would run at least 1.5x times better than on the 3DS. Excluding any other bottleneck of course.

from omnispeak.

For the SDL_RENDER_DRIVER variable, you'll need to set it at runtime, either by setting it before running the omnispeak binary, or by using SDL_SetHint() from within the code (put it anywhere before the renderer is created, possibly in VL_Impl_GetBackend() after the SDL_Init() call (in id_vl_sdl2.c)).

As for performance, I admit that the 3DS build I experimented with really only ran smoothly with the new 3DS overclocked CPU. One of the biggest performance sinks is the Adlib emulation. If you hit problems, maybe you could lower the sampling rate, try optimizing it, or just stick to the PC speaker. The other big thing on s/w rendered devices is the scaling (if you're using SDL2) and final copy — in DOS, keen renders directly to the display, but the SDL backends for omnispeak render to an offscreen buffer, which is then copied to the display each frame. This copy (which also handles the palette conversion and scaling) is usually a timesink, particularly at high resolutions. In any case, I'd focus on getting it working before worrying about optimization. With some hackery, I've got omnispeak to be quite playable on a 66MHz 486, so it's definitely possible to run it on lower-end machines. (Also, FYI, GFLOPS is probably not a useful measure for Omnispeak, which doesn't use any floating-point operations — Keen originally ran on machines without an FPU, and Omnispeak also uses entirely integer/fixed-point arithmetic)

Finally, input indeed can be a problem. Omnispeak has basic support for the SDL Joystick API, so you may be able to use that (though you'll need to copy over a CONFIG.CKx already configured for joystick if you don't have a keyboard connected). The joystick support is pretty rudimentary, though. If you need something more advanced, the input code is pluggable just like the graphics code, so you could replace the SDL implementation in id_in_sdl.c with a Wii-specific one that talks to the Wiimote (or GameCube PAD) directly.

from omnispeak.

There's now an "sdl2sw" renderer which forces the use of SDL's software renderer.

This can be built with make RENDERER=sdl2sw, or by building with VL_SDL2_REQUEST_SOFTWARE defined. Of course, even if you use the normal SDL2 renderer, the software renderer will be used at runtime if hardware rendering is not available. (And can be forced at runtime with the SDL_RENDER_DRIVER=software environment variable.)

This was added in commit 8bba1dc.

Finally, the SDL 1.2 renderer is usually software rendered -- and I believe there's a port of SDL to the Wii -- so that may be the better option in some cases.

Feel free to file a separate bug if none of those renderers work for you.

from omnispeak.