Can the Lessons of Qbism be Applied to the GX chip of a Nintendo Wii?

Post Reply
kaisersozeh
Posts: 1
Joined: Thu Jul 16, 2020 6:04 pm

Can the Lessons of Qbism be Applied to the GX chip of a Nintendo Wii?

Post by kaisersozeh » Thu Jul 16, 2020 9:27 pm

If a member has any thoughts, comments, or suggestions, please, please comment below - is this a bad idea? where would I start with converting the gl implementation to gx ? is there an engine that works as a standard for a GL '+'?

Hi!

I'm curating* a suite of configs, art, and Wii homebrew around 'QuakeGX' - a Quake Wii engine that exploits Nintendo's GX chip -
This allowed the devs access to memory and processing beyond that typically available to homebrewers (so I'm told),
GX code is written in a form very similar to openGL, and the software rendering was replaced with code derived from quakeGL. With 'GX' came vis patched file support, experiments in .lit support, and they began to implement the more esoteric quakeGL functionality before development stalled.
Still. With an interface loaned from the Wii's CoD ports, it represented an astronomicalLovecraftian leap forward in the quality of experience available via homebrew. And it's...fun.

Why am I telling you this?

The engine is limited. I am interested in dropping the memory and processor requirements in rendering, so the engine can play content it would otherwise have zero chance of approaching. For example, I found Qbism because was mulling around for the method that replaces every texture with one of 4 or 5 colours on each face of a polygon - that is, at least, functional - a browse around with "What could doing that make playable ...? " on my mind.
It's my hope Qbism's aesthetic approach, even actual code, would be a much, much better solution.

So, why am I telling you this?

I haven't got a clue*, I'm essentially hoping to provoke your curiosity in the intellectual pursuit of applying code written with one intention (pseudo-retro rendering and a broad access to content) to another, emerging purpose (giving a sub powered machine access to classic content).
You might not care, but the Wii is pretty much ubiquitous - dime stores use them as door stops - has, by far, the highest population of homebrew-capable units, numbering in the millions, and the QuakeGX engine is an emulation arguably more immersive, more fun, than the original release. The Wii and GameCube Emulator 'Dolphin' is a popular addition to emulation suites in many distributions for different hardware. My point is, people will play it. I hope.

Much of the leg-work has already been done

https://github.com/izhido/qrevpak includes 'q1' - Izhido continued to work on shunting the workload onto the GX chip - his engine can host games, unlike GX, and has .lit support and further openGL enhancements. It doesn't however, have the CoD-like gameplay of GX, an essential aspect, and I can't compile it!
Izhido is no longer working on Wii code, but he is active on Quake discord and I get the impression he's a good guy, happy to talk to a competent coder. And me.

Fixer-upper

While QuakeGX represents many hours of coding and testing, it is immature as a user-developed quake engine, there are no qol improvements to recording demos, naming saves etc. that modern engines have, but don't constitute processor heavy functionality.
I'm trying to say it might be a project for someone who knows how a quake engine is put together, but has never done it themselves...or someone who has done it before, but is interested on a new take.

I am very, very new to coding, and haven't learned to upload the, largely cosmetic**, changes I've made to the engine, but it's based on this - I am told it represents a lot of work since the last days of GX, he replaced most of the C## with C, but Oibaf66 didn't touch the rendering...

https://github.com/Oibaf66/quakeGX_mod

A friend helped add support for arguments sent from a loader, but it's essentially unchanged.

*What is 'curating' , who are you, what are you planning on doing while I fix up your engine?

No one is looking after quakeGX, I'm a consumer-grade tinkerer trying to get it to work with wiiflow, an apple-like "coverflow" front end for loading emulated games. It can display cover art, metadata, screencaptures. Catagorising maps, mods, TC's, maps for TCs and movies. Hopefully, this will eventually be able to download content from quaddicted (and other) servers directly, either by passing arguments to other, freshly minted, homebrew or repurposing the code that downloads coverart. In the short term, it's functioning as a wiiflow 'plugin', accepting arguments to load mods, maps and movies from a title cover you click on.
Regardless of the progs.dat loaded, you can select cheats and 'hotkeys' via a .cfg based menu, so little need to use an on screen keyboard. There's enhanced wiimote support, animated reticles and an integration of FOV functionality, and further interface functionality borrowed from CoD and a nod to Tomb Raider.
The Wii custom progs.dat currently has rumble support, the capacity to return to the last non explosive, non-melle after hotkeying such a weapon, and a further interface functionality from CoD. I hope to add Frikbot10++ and multiskkins to one progs.dat, my focus has been entirely on single player, and a 'small mods compilation' with a Wii focus, a rolling project, to another.

**What 'changes'?!?!

I increased the zone memory, by changing one number - huge amounts of effort had been made to clear to way for this change, but apparently no one had got round to doing it...I even left some of the space made - It might be doing something...
I've done a lot to the wiimote code that Piko opened up - it doesn't touch the wider codebase
Added freezenonclients, a couple of 'narrative' flashes copied from the bonus flash, changed notices etc...

Addendum

If anyone fancies helping me out by adding hit location, or stops me reinventing the wheel, please let me know.

Post Reply