ProQuake 4.70 PSP Build

[dr_mabuse]

Any chance to get the source or an eboot of your latest ProQuake build?
My mod runs fine so far, and i have fixed the mp3 playback, but the random crashing issue is getting annoying in 4.70..

[Baker]

I have a real-life project I am in the final stages of wrapping up. Then I can work on the PSP stuff and otherwise do engine coding [for a couple of weeks, at least]

I will be at least as happy about it as some others will be (I get nagged about some of other engine stuffs). I have a lot of things I have only been able to think about, that I'd like a good high-quality block of time to play with to implement.

[One example of something that I'd like to do ... yeah this isn't PSP ... is convert Qrack over to OS X, look at QuakeForge's SDL software renderer and port Engoo to OS X. That isn't even the half of it, really, but the PSP update come first or very first-like-ish.]

What really frustrated me with the PSP about 15 months ago involved memory issues. And at the time, I wasn't deeply familiar with ... although this sounds funny to say ... "each memory allocation" and when they occurred. That changed when I started ripping apart Quake memory management, rewriting a lot of it, trying new ideas after looking at other engines, failing occasionally and understanding why I failed, etc.

[mh]

I'd personally love to see a shader-based version of Qrack. Of all engines this is the one I feel could benefit most from making the jump up.

[Baker]

[dr_mabuse]

no problem, real life goes first

It just was funny, i added a simple crate on my map, loaded it on the psp and started and then my psp crashed...
And i was like ... xD

[mh]

[Baker]

I look forward to seeing that. For me personally, it is far easier to be able to compare an apples versus oranges way of doing the same thing (RMQ versus FitzQuake 0.85) ... than .. well ... the OpenGL documentation leaves a lot to be desired.

re:Qrack shaders

Hehe .... it would be funny to see if you actually do it. What I mean is that all the FuhQuake family tree engines are chalked to the brim of really old model loading code, rendering code, input code (like to support non-existent situations, like Windows 95 scroll wheel .dll). The QMB particle code itself recursively uses #define in a lot of places. Would you be able to rewrite just the rendering?

[mh]

I personally find it easier to write new things in D3D and then port them to OpenGL these days. With some small exceptions I wouldn't touch OpenGL with a 10-foot pole for anything extensively new - a sad reflection on how things have changed.

If I was to try a full-blown shader implementation of Qrack it would have to be a native D3D port too. One further difficulty is that Quake clients tend to need to support a whole TON of special case situations, mode toggles, etc - easy with fixed, but shaders tend to increase in number exponentially. This is quite a pain in the ass.

[ceriux]

also baker earlier didnt you say you were releasing a mod with your new psp build? i'm interested in what you have to throw up =)

[Baker]

I don't want to say much, but your flying drone will be in it and all models, map files, .wav files and textures will be GPL content and the maps will be a bit of the flatish side to allow easy PSP navigation. Will feature brush model rotation, a few bobbing platforms just to use my QuakeC I wrote for that purpose. Some other stuff that I don't mention either to not give all the secrets and/or that I may need to scrap to get it out so I don't want to "say will have X" but then decide against it.

[ceriux]

awesome =D i really can't wait to test it!

[Baker]

[mh]

The shader language stuff is actually very non-intimidating, although GLSL makes things slightly more messy than they should be. There is a lot of framework and boilerplate you need up-front before you can actually start getting stuff on-screen, and different revisions of the spec have breaking changes between them. Once you get past that it's incredibly easy though.

The older assembly shaders are just a couple of glEnables, a couple of glBinds and (optionally) set some parameters. Much easier and because there was only a single revision of the extensions then they're consistent acoss all platforms and GL_VERSIONs, although they don't have full modern functionality and the language itself can seem a little daunting at first encounter.

D3D totally wipes the floor with anything GL has to offer in this regard; HLSL is very accessible and the Effects framework makes it much easier to get started.

Manual matrix management rocks. No more worrying about "did I push, did I pop, watch my stack, what if I want to retrieve this matrix, etc". Just glLoadMatrix and you've got it right straight away. A dirty little secret that some might not be aware of is that the D3D matrix functions will actually work in a GL program (which makes sense because all that they do is some calculations on the CPU). I ended up inheriting from D3DXMATRIX and adding some extra members to handle common transforms in-place in my current code, which makes things so much easier too (warning: needs C++).

A glGet from a matrix shouldn't be slow as you're just reading it from the CPU. It does have to go to the driver to do the get though, so it's not as fast as if you had the matrix locally in your own code, but it shouldn't be measurably slow.

[Baker]

[mh]

Some glGets are slow, but it depends on whether or not it has to readback from the GPU. Matrix building always took place on the CPU (it's only the final multiplication of position by MVP that's on the GPU) so it's OK for this; a readback from the GPU involves a pipeline stall though. Trouble is that it's not totally clear which ones do which so it's something you need to experiment with.

The D3D documentation is a special kind of awesome. I was hugely frustrated by it at first, but as time went on I really came to appreciate all of the useful info in it. And you're right - it does lead to a better understanding of how things work in general, which does help a lot with OpenGL too.