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]

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.

Is the RMQ engine all shader-based now? If so, that'd be really interesting.

[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]

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.

Is the RMQ engine all shader-based now? If so, that'd be really interesting.

Yup, there's no fixed left in it.

I ended up using GL_ARB_vertex_program and GL_ARB_fragment_program (yayy assembly shaders) because GLSL consistently choked on the ATI one of the mappers was using and I didn't have one at the time to troubleshoot with. Aside from that, the brush model lighting shader is fun (lightstyle animations are done entirely on the GPU with no texture uploads needed), and there's some nice motion blur too.

I'd like to jump up to GLSL at a future date but it means another bump in the hardware requirements (and I've already pushed my luck quite far enough with that --- for now) and GLSL versioning is a nightmare compared to nice clean HLSL.

[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]

Yup, there's no fixed left in it.

I'm starting to see some of the advantages and reasons behind the "manual matrix calculations" in everything after OpenGL 1.2 (and I'm not trying to do anything super-fancy). I'm having to use gluUnproject to reverse out from the model view matrix. And to get that, I have to use a "slow" glGet____ for each model. And then possibly re-project it. Kind of silly. On the plus side, after spending some time working out what I am trying to do on paper, some of the past infos from LordHavoc and a few other DP features start to make sense. I think if I set my mind to it, I could probably understand his shadow code now (I'm not thinking of the RT stuff, but the actual nice traditional shadows that render on multiple brushes).

I think the only thing that is intimidating about the non-fixed pipeline is the shader language stuff and a lot of the technical jargon. I'm not concerned with losing "quads" for 2D rendering, a simple "quad" vertex array solves that real quick.

[Looks like I'll be spending some time reading the RMQ engine source, heh. I'm really interested in learning how animation interpolation works with the fixed-pipeline. Although I'll probably wait until the new RMQ release so I can see the engine in action correctly.]

[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]

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.

I was under the mistaken impression that glGets were slow mistakenly thinking they operated in a similar manner to glReadPixels. Problems -1.

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++).

As of lately, I've actually been using Direct3D documentation in place of OpenGL documentation (LOL) to solve some of my OpenGL puzzles. OpenGL documentation is special form of terrible.

I find it rather interesting that great ideas can die on the rocks of crap documentation. Linux comes to mind (although I'm sure it is better and easier to find infos now).

[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.