RadQuake

[Hola]

I was wondering since Ians improved his skill constantly and so had the rest of the RadQuake team if we'd be likly to see a new RQ with some improvements.

These are some of the things I was wondering apon.

*HighReso( 640x480 )
*Zlib compressed saving
*AntiAlasing
*Menu resizing for HighReso ( No small text like on the test version. Text like titiniums port)
*Even more speed up to acomedate these new features which will surly slow it down.

[Christuserloeser]

Hm, I won't say anything beside that there will be a new version.
MetaFox asked BlackAura (nxDoom, GenesisplusDC) so he revives his nxQuake project (that merged into RADQuake some time ago) or better: reports GLQuake.
Beside that Fragger adds his Mods (compressed Saving routines, JoyMenu & JoyConsole etc) to the project.
But speud & Ian are also still active on the RADQuake project.

I guess we'll see something great coming along these days...

Chris

[Hola]

Saving would be the most important next I guess but, high reso is the one thing making me cling on to titiniums port still.

[MetaFox]

MetaFox asked BlackAura (nxDoom, GenesisplusDC) so he revives his nxQuake project (that merged into RADQuake some time ago) or better: reports GLQuake.BlackAura is really the person who should be getting credit for this. He's been doing a lot since I contacted him about nxQuake.

[Christuserloeser]

Sure, my wording wasn't perfect. :-/ I know BlackAura does all the work on it...
..but also thanx for asking him :)

[MetaFox]

Sure, my wording wasn't perfect. :-/ I know BlackAura does all the work on it...
..but also thanx for asking him :)I'm planning to do some on it too, but I haven't managed to get anything that I've tried to actually work yet. ;)

BlackAura has gotten a lot done though. BA rocks. :)

[BlackAura]

Still haven't gotten GLQuake working yet. At the moment, it seems to hang just before it gets around to changing the video mode, which means none of the OpenGL code is even being executed. I have a large list of things that aren't wrong with it, but that doesn't help much. I'll find it eventually.

On the plus side, the software rendered version works a lot better than it used to. You can't change screen resolutions on the fly (yet), but you can use any video mode the Dreamcast can output, and it'll run just fine. Perhaps a little slowly if you try 768x576 PAL or 800x608 VGA, but it works.

Other than that, music works perfectly (Ogg Vorbis streams), sound works partially (it's being generated, but it's not being sent to the sound hardware yet), both mission packs run correctly, the modlist is a little less broken than it used to be, there are a few other internal fixes, and the PC-based SDL version no longer works properly.

[wraggster]

Nice to hear of some progress :)

[BlackAura]

Not much progress still...

I worked out what was wrong with it, but it's still not working properly. Now it loads and seems to be working fine until you get to the game. In game, it just shows a load of garbage all over the screen (running at a very high framerate, ), then it slows down to a crawl, then it runs out of texture memory and crashes.

I've just tried using Bero's GL library instead of KGL, and I have a similar problem. The screen is filled with a completely different kind of garbage, which looks like everything's been stuck to the upper-left corner of the screen and then drawn in 2D, then it slows down, then it crashes with some problem related to main memory (instead of texture memory).

At least with Bero's GL library, I think I know what's causing the graphical corruption - it looks like it's not applying the transformation matrices correctly. However, I don't know who, nor do I know how to fix it.

I don't have any idea why it slows down so much, and then crashes either. I think it might be the texture scaling code causing it, because that's the only bit which keeps allocating and freeing memory while the game's running. The problem is that code has to be there, or we'd run out of memory before we get started.

I think I'm just going to work on the software rendered version for the time being. The hardware rendered version is just too much hassle right now.

[Ian_micheal]

Yeah still active any news is posted on teh offical radquake forum . Compressed saving is working fine.

Just have to wait.

[BlackAura]

I have quick saves working. They don't require a VMU, and they aren't permenant. As soon as you turn the Dreamcast off, you lose the save. However, they save pretty much instantly, and load no slower than starting a new level. I still need to add compression to those, probably using zlib.

Personally, I don't think using the standard Quake save system is a very good idea, because we're saving the position and state of every entity in the level. No other console game does that, and that's what quick saves are for anyway. A better approach would be to save the level, the player state, anything else that's persistent between levels, and any console variables which have been marked to save. The save games will get much smaller, possibly down to only a couple of blocks with compression, and you can change the interface a bit to make it more like a console game. For example, you could tie the game save system into the intermission, so it saves the game just before you enter a level, just like a commercial game.

[Hola]

So is actual saving and quick saving both working?

[BlackAura]

VMU saving is working in RADQuake by the sound of it. Quick saving is working in nxQuake, but I've not started on VMU saving. I really need to modify the saving code to use zlib first. Once I've done that, all I need to do is save to the ramdisk, then write it out to the VMU with a VMU header attached to it.

[Mental2k]

IS there co-op mode on RADquake? its the only way to play fpss on a console. Or will it never be possible, due to having to draw 2 screens at once?

[BlackAura]

No, there isn't. It's possible, but requires quite a lot of modification to Quake itself. In theory, you can just connect multiple clients to the same server, and render each client's display in a different part of the screen. In practice, Quake was written with the assumption that each copy of Quake can only have one client running in it at a time, so you'd have to change a hell of a lot.

It'd be easier on a PC, actually. You just start two/three/four separate processes and connect them all to the same server.