Maybe a cache coherency issue, where data written by the CPU is not visible to the GPU, without some kind of explicit cache line invalidation, maybe on both sides? Caveat, I don't know much about the memory system on the XBox but this is a typical issue with homebrew code on consoles.
Well, it is what is done on several tiler architectures, and it generally works just fine. Normally your computations of the position aren't really intertwined with the computation of the other outputs, so dead code elimination does a good job.
What about implementations? libpng seems pretty dead, 1.7 has been in development forever but 1.6 is still considered the stable version. Is there a current "canonical" png C/C++ library?
Small UX thing: Make it so you can just click a word to fill in the next empty spot, instead of having to drag, similar to when building sentences in Duolingo. Especially when not on a touchscreen, having to drag is pretty painful and reduces accessibility.
Function calls are very fast (unless there's really a lot of parameter copying/saving-to-stack) and if you can re-use a chunk of code from multiple places, you'll reduce pressure on the instruction cache. Inlining is not always ideal.
Not sure if you care at this point, given that you stopped working on project, but there's a better way to find the ray direction for each column than using sin/cos for every one, which will also get rid of the slightly warped look:
Calculate the two vectors from the camera at the very left and right of the screen (using your fov angles and sin/cos, that's fine). Then, to find the ray direction vectors for each column, interpolate linearly between your left and right direction vectors, and possibly normalize the resulting vectors if your ray walking algorithm requires it.
This will create a perspective that integrates tightly with sprites that you 3D project the usual way, and lines will stay straight lines.
Pack Z and 32-bit color together into a 64-bit integer, then do an atomic min (or max with reversed Z) to effectively do a Z-query and a write really, really fast.
Could save a couple of cycles per iteration by preloading the shift amounts into several GPRs before entering the loop, instead of initializing them just before use.
I think "cover shooter mechanic" refers to ducking behind cover and a system for smoothly shooting from behind it like in Gears of War - or in Winback. This mechanic was not there in Wolfenstein 3D.
Only the user mode part of the driver is replaced, the kernel interface is actually shared between the closed source and the open source driver. So it's just loaded like a DLL/.so and hooked up to the API.