GLQuake

[q_006]

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.

why not just use that new programmer's only forum someone just put up?
and i thought someone was working on a PVR accelerated Quake?

[Moi]

It's history now.... because of a little misunderstanding....

[speud]

It's history now.... because of a little misunderstanding....

not sure which project you mention here, if you mean RADquake then its not history, though i never planed to use hardware acceleration. and the reason why its update won't be posted here has nothing to do with a "little missunderstanding".

and i thought someone was working on a PVR accelerated Quake?

i know someone that planed to work on something similar to what blackaura tried here, i won't post his name cause i'm not sure he wants it to be public yet. he's new to dc devving and if someone as experimented as blackaura failed there are little chances he successes, but hopefully if everybody who wants this to happen collaborate it could happen someday.

[mankrip]

Hey BlackAura, did you see this?
http://www.quakesrc.org/?Page=tutorials ... memfix.txt

I'm downloading all these tutorials now (I don't know why I didn't did it before...).

[BlackAura]

Ah, interesting. I don't know if it'll fix anything, but it might be worth a try.

[Tyne]

I just talked to LordHavoc on IRC, and here goes:

<LordHavoc> 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.
....
<LordHavoc> just make an array
<LordHavoc> (array of texture structures)
<LordHavoc> 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...
<LordHavoc> just use the *software quake* model data instead of the glquake model data
<LordHavoc> 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
<LordHavoc> things yet...
<LordHavoc> 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.
<LordHavoc> litsupport.zip anyone?
<LordHavoc> it changed the partial update method too, much more efficient
<LordHavoc> I'd just fix KGL to support partial updates
<LordHavoc> and I wouldn't bother with KGL, I'd just use KOS directly
<LordHavoc> (accelerated quake on KOS would be easier than glquake)
* LordHavoc sleeps

Well, that's that.

[BlackAura]

<LordHavoc> just make an array
<LordHavoc> (array of texture structures)

That doesn't work quite right on the Dreamcast, because you really need to manage the textures properly. While it worked fine on a PC (and that was the ugly hack I mentioned), it completely failed on a Dreamcast (ran out of VRAM, if I remember correctly).

just use the *software quake* model data instead of the glquake model data

Or, even better, just remove the code that generates trifans, which I already did.

I'd just fix KGL to support partial updates

Easier said than done. Even a partial update would probably require re-uploading the entire texture anyway, because there is no efficient way to upload parts of a texture. In that case, we may as well not bother with partial updates, and just use DMA transfers to copy all of the modified textures over. Of course, then we start having all kinds of other problems, such as uploading a lightmap over the top of a copy that's still being used (the same thing that cause the sprite corruption bugs in Genesis Plus), and the fact that unless you twiddle the textures (which is very slow) the rendering speed will drop quite a lot. As if it's not slow enough anyway.

and I wouldn't bother with KGL, I'd just use KOS directly

In other words, re-write the entire renderer using an API that was designed for sending data to the graphics hardware at the lowest possible level. Ouch...