Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Scet

SDL Quake

Recommended Posts

After reading the "quake ports" threads and seeing that there was no "Chocolate Quake", I thought it would be a good idea to find an SDL based port and build one. Unfortunately I didn't find anything other than this, which I had more trouble trying to build than the WinQuake source.

So I've built mine own version based off the link above and WinQuake. The only Windows reliant code is the OpenGL and WinSock stuff. I've never used SDL_Net and didn't want to mess anything up, so I left it alone.

I don't plan to keep working on this, which is why I'm posting it here. The Quake code is so awful looking, it makes the Doom code look good.

Download

Note that this is a VC2008 project, which means I'll probably get bitched at. Also there is a bug in PF_VarString. Initially I thought it was a buffer overflow caused by strcat, but it's not. Some of the pr_globals don't seem to be initialized, causing negative pointer arithmetic in the the G_STRING macro.

Share this post


Link to post
neg!ke said:


The point wasn't just to port it to SDL, but to help create a base for a purist port. Fitzquake adds to the engine and doesn't even have the software renderer.

Share this post


Link to post
Scet said:

Also there is a bug in PF_VarString. Initially I thought it was a buffer overflow caused by strcat, but it's not. Some of the pr_globals don't seem to be initialized, causing negative pointer arithmetic in the the G_STRING macro.

What are the symptoms of the bug?

PF_VarString() only loads values from the parameter area of pr_globals, and they should always be initialised (by the code doing the function call).

Share this post


Link to post
andrewj said:

they should always be initialised (by the code doing the function call).


Well they're not. It happens whenever it tries to parse a quantity, like in "You received 25 health", the 25 is the problem. The pr_globals value is set to NaN and G_STRING makes the pointer an int which results in a large negative value. I added a check so I could at least see most of the message, but now it just says "You received health".

Share this post


Link to post
Aliotroph? said:

And aside from the concept of the "purest" Quake, what do we get from keeping a software renderer?

Software rendering looks better.

Share this post


Link to post

Built and run the code under Linux.

Brief test works ok, including the health messages.

I reckon you've hit some kind of compiler weirdness. The only thing I can think to try is to mark pr_globals with volatile.

Share this post


Link to post
Aliotroph? said:

what do we get from keeping a software renderer?

A port which some people can use? Not everybody has a 3D card.

Share this post


Link to post
Aliotroph? said:

And aside from the concept of the "purest" Quake, what do we get from keeping a software renderer?

Proper, not-resampled texture sizes
Overbrights
Fullbright colors
Colormaps
Real water warp
Superior atmospheric feeling

Ideas to chocolatize Quake:
- Max 200px height skin crash
- Brown menu background tint, instead of black mesh
- The classic threatening quit messages
- "tweaked" video mode emulation (i.e. 320x400, 360x240)
- ENDOOM.LMP END1/END2.BIN display on quit
- -sspeed parameter to set the sample rate (very easy to implement)
- Adjust sound attenuation to be more like DOSQuake (Yes there's a difference of this since WinQuake/GLQuake)

Share this post


Link to post

I see no reason why those things can't be in a hardware renderer. Stuff like weird texture sizes seems to cause problems in a lot of engines but I bet there's a good way around it. The other things that end up being basically free on systems that support them (eg. AA) are just too good to leave behind.

Share this post


Link to post

Yeah well there's more than enough GLQuake ports in existence and there's 0 chocolate ports. Go play those if you must. DOS never had hardware GL.

(Though, it did have vquake)

Share this post


Link to post

Aliotroph? said:
what do we get

Just because you don't get anything, it doesn't mean we don't.

leileilol said:
Superior atmospheric feeling

Indeed, I love the gritty feel of Quake in software mode.

Share this post


Link to post
andrewj said:

Built and run the code under Linux.


Surprising, I could have sworn there was still plenty of Windows code.

andrewj said:

I reckon you've hit some kind of compiler weirdness.


I thought so to as I found one other post about the error, but the author "fixed it" by going back to VS2003. I've tried changing it to volatile and playing around with every possible compiler switch, it still doesn't work.

leileilol said:

Ideas to chocolatize Quake:


It now occurs to me that I've never played DOS Quake. I didn't think WinQuake really changed anything.

Share this post


Link to post

Another idea to try: edit pr_exec.c and change the implementation of OP_STORE_V and OP_RETURN in PR_ExecuteProgram() to use memcpy instead of normal assignment. [maybe the compiler trashes the funky value returned by ftos() by loading it into an FP register]

Share this post


Link to post

No that didn't work either, thanks for trying. Could you post your Linux project/makefile? Might help if I can get it built with GCC.

I've decided to put my Doom port on hold, and work on this instead. Hopefully I can clean up the prog code to not rely on such god awful pointer arithmetic.

Share this post


Link to post

Another idea for more chocolate behavior, is emulating 1.06, which is basically lacking the .gravity float that was added in 1.07.

Share this post


Link to post
Scet said:

Hopefully I can clean up the prog code to not rely on such god awful pointer arithmetic.

I suggest allocating an extra 128 bytes when loading the string table and make 'pr_string_temp' a pointer to that.

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  
×