GLQuake

BlackAura · Post by **BlackAura** » Wed Aug 11, 2004 2:36 am

I'm working on getting GLQuake running on the Dreamcast. So far, a combination of factors are getting in my way.

For one, id had the great idea to completely ignore glGenerateTextures when creating new textures, and just assign some arbitrary number to each texture. Works fine on a PC, where those texture numbers are actually numbers, but doesn't work on a Dreamcast, where the texture numbers are actually pointers to texture structures. Solved that one, but it's an ugly hack.

Next, Quake needs support for triangle fans, and KGL doesn't have it. That means I need to find a version of KGL that does support them, work out what changes I need to make to KGL to support them, and copy them over. Grr...

Third, texture formats are completely different, so I have to go through and re-write all of the texture upload code. Thankfully the Dreamcast supports paletted textures, so it's not all that difficult. I've done pretty much all of it, except the single worst offender...

Lightmaps. Quake allegedly supports four formats for lightmaps, three of which don't actually work at all (only Luminance maps work), and none of which are supported by the PVR. It also wants to update parts of a texture, which KGL can't do, so I'm going to have to re-write all of the lightmap upload code. That wouldn't be too bad, but I don't understand most of it, and there's so much of it. I can't even work out how to disable the sodding things yet...

I don't suppose anyone has a tutorial-type thingy for coloured lighting, do they? The only lightmap format that comes close to something the Dreamcast can do is 32-bit RGBA, but half the code necessary to get that working is missing from standard GLQuake (it either crashes or everything's black), and is required for coloured lighting. If I can get that working, I can modify it to work with 16-bit RGBA, which does work on a Dreamcast.

Unfortunately, Bero's version of GLQuake isn't much help. I think the phrase "a mess" is about right, along with "doesn't work", and "won't compile".

I have other stuff I need to do right now (university stuff again), so that's all for the time being.

BlackAura · Post by **BlackAura** » Wed Aug 11, 2004 5:13 am

I've got it to compile (by disabling the lightmaps, and some other stuff), and it should work, but it doesn't. It just sits there, and apparently doesn't even get around to initializing the video. It just sits there with the modlist still displayed, and doesn't seem to be getting to the bit where it changes the video mode.

I would expect a crash at least. Just sitting there isn't much help for debugging, is it?

Even if this did work, everything would still be black, because it doesn't (yet) upload the colour palette to the hardware. I wanted to make sure it didn't just explode first.

If anyone has the appropriate tools to try to work out what's wrong with it (a serial cable or BBA would be nice), feel free to have a go.

http://files.frashii.com/~sp00nz/Doom/f ... ake.elf.gz
http://files.frashii.com/~sp00nz/Doom/f ... st.tar.bz2

It's compiled against an SVN version of KOS just before it switched over to newlib. I don't know if it'll work on 1.2.0 or later SVN versions.

Oh yeah - you need this version of KGL

http://files.frashii.com/~sp00nz/Doom/f ... od.tar.bz2

Post by **Tyne** » Wed Aug 11, 2004 1:31 pm

Good work so far, sounds like porting it is pretty troublesome but I'm sure you'll manage it in the end after all you're damn talented.

BlackAura · Post by **BlackAura** » Wed Aug 11, 2004 5:41 pm

If I can work out why it doesn't appear to be doing anything at all, maybe.

mankrip · Post by **mankrip** » Wed Aug 11, 2004 6:18 pm

I believe that there's a tutorial for coloured lightning here:
http://www.quakesrc.org

BlackAura rocks!

BlackAura · Post by **BlackAura** » Thu Aug 12, 2004 3:56 am

Cool. I have (non-coloured) RGBA lighting working on the PC version (although it keeps crashing for some other reason), so I'll have to see if I can get 16-bit RGBA lighting working...

chrisalm · Post by **chrisalm** » Thu Aug 12, 2004 1:46 pm

I believe the last version of KGLx had support for triangle fans. As for lighting there are several tutorials on Flipcode http://www.flipcode.com/tutorials/

Christopher

PS keep up the good work BlackAura

BlackAura · Post by **BlackAura** » Sat Aug 14, 2004 11:44 pm

I need some help. As I have no BBA and no coder's cable, I can't debug this thing. It just hangs with a black screen, no matter what I do with it. I can't even get it to make the screen change colour using vid_clear, and as far as I can tell it doesn't even get to initialising the graphics hardware. I'm stuck.

Can someone with a BBA or coder's cable please try the binary I linked to above? Put the Quake pak files (PAK0.PAK and PAK1.PAK if you have it - the shareware version with just PAK0.PAK should be enough) on a CD in /quake/id1, then run the binary and post the entire output from the debug console. That way, I might be able to find out where it's locking up...

Moi · Post by **Moi** » Sun Aug 15, 2004 5:36 pm

Unfortunatelly noone has a coders cable in here, maybe you should ask the ppl in the programming section?

mankrip · Post by **mankrip** » Sun Aug 15, 2004 7:30 pm

BlackAura, is it possible to write the log file to the VMU, so you could make a small DC app to read it later?

BlackAura · Post by **BlackAura** » Sun Aug 15, 2004 10:02 pm

Unfortunatelly noone has a coders cable in here, maybe you should ask the ppl in the programming section?

Not to worry - someone saw it (two people, actually) so it's all good. Turns out it was running out of main memory, which is why I couldn't get it to do anything. All I need to do now is work out how to make it use less memory...

Logging to the VMU would work, but not for this kind of error. I currently have error handlers for two types of error - a Quake Sys_Error call (which would normally pop up as a message box in Windows), an the KOS assert() error handler. I currently just draw the error message to the screen and halt the system, but I could log those to a VMU if I really wanted to. I can't log a KOS kernel panic though, becuase when that happens KOS might not be in a usable state.

mankrip · Post by **mankrip** » Sun Aug 15, 2004 10:13 pm

The only thing I remember that could cause this is that GLQuake converts the pallette from 8 to 16 bits before running. GLQuake also generates .ms2(?) meshes for each model, but only when loading a map or during the gameplay.

Maybe the default heapsize for GLQuake is bigger than for WinQuake?

BlackAura · Post by **BlackAura** » Sun Aug 15, 2004 10:25 pm

It's actually not running out of heap memory - it's running out of main memory when I try to allocate the heap. Basically, it breaks as soon as you do the first malloc(). The heap size is the same as the software rendered version, and it's allocated in the system driver before any code from Quake is called. It's the very first thing that happens after the modlist is called.

Since it hasn't run any GLQuake-specific code, I assume that GLQuake just uses a lot more main memory than Quake does. I'll have to check the binaries and see how far up the main memory pointer is. However, we shouldn't need quite as much heap memory as we would with software Quake, because the textures are being kept in VRAM instead of main RAM.

BlackAura · Post by **BlackAura** » Sun Aug 15, 2004 11:06 pm

I just tried it with a heap size of 8MB instead of 10. It runs, but only just. Having mucked around with the GL library a little more, I got it displaying the console. The text is corrupted quite badly, and the game itself doesn't actually work. You get a mostly black screen, with a few tiny bits of garbage textures, and then the game appears to crash.

So, once again, I have no idea what's wrong with it. I'll try it again with texturing disabled (gl_bind set to 0, and disable GL_TEXTURE_2D) and see if it's just the textures that are corrupted, or if it's just not drawing any geometry correctly. I suspect that both are happening, unfortunately.

I suppose I could try it with Bero's GL library. It's very, very different to KGL, but it might work. It'll probably have the same issues Bero's port had, but I might be able to fix them.

TheDumbAss · Post by **TheDumbAss** » Mon Aug 16, 2004 12:14 am

Somewhat good news there. Sounds like things are progressing a bit.

Now why wasnt this here a year and a half ago when I expected it BA? hehe
Seriously though... good work on getting this far.

BlackAura · Post by **BlackAura** » Mon Aug 16, 2004 1:56 am

I don't think I can get any further, actually. Using Bero's GL library, I can get it working well enough to display some graphics on the screen. However, these graphics are also completely screwed up. It looks like it's just rendering everything in one big blob in the upper-left corner of the screen. Then, after a few seconds, it slows down to around 1FPS. Then, a few seconds after that, it runs out of memory again (or comes up with another cryptic memory-related error) and crashes.

Something similar happens when using KGL instead of Bero's GL library. I get mass corrupted graphics all over the screen (it looks like transformations are going the wrong way, and the vertices are being drawn in the wrong order), lots of corrupted textures, then it slows down to a crawl, and then it crashes having run out of texture memory.

Unless I were to re-write most of the renderer (and I really do not want to do that), I don't think I'm going to be able to get anything useful out of this.

mankrip · Post by **mankrip** » Mon Aug 16, 2004 3:11 am

I'd like to ask some engine modders to help. There are people who are working on the Quake engine for years, so maybe they could take a look at your source and try to find a solution.

BlackAura · Post by **BlackAura** » Mon Aug 16, 2004 3:23 am

Feel free. I think most of the problems are with the GL library and the Dreamcast, not the Quake stuff. When I get it working properly again (in software mode), I'll post the source code somewhere.

TheDumbAss · Post by **TheDumbAss** » Mon Aug 16, 2004 11:49 pm

Tyne would probibly agree that LordHavoc would be the best person to talk to about quake engine related things. Tomaz and several others that hang out in #qc are also well versed in things Quake engine related too and can be very helpful.

so go to #qc on irc.gamesurge.net (or is it .com?... hmm)

It'd be interesting to really talk to Rand about this stuff too... with his DC hardware knowledge and considering he did a Quake engine clone that runs on really low end hardware.

Mr. Jones · Post by **Mr. Jones** » Tue Aug 17, 2004 12:02 am

As long as the information given isn't publically posted in the forums (conflicts of interest and all that), I wouldn't see any harm in giving Rand a PM.

Speaking of PMs, BA, you've got one.

GLQuake

GLQuake

Fans and lighting