"FitzQuake Plus": An Easy Engine To Compile

Baker · Post by **Baker** » Thu Jan 27, 2011 12:16 pm

For the sake of naming this, I just called it "FitzQuake Plus" so as not to confuse potential binaries with "FitzQuake proper".

I took FitzQuake and add a small handful of enhancements:

1. Half-Life Map Support (Does not support external .wad files, you can add this in rather easily via the tutorial if you choose. I don't like external WAD files.)
2. Session to session console history
3. Rotating brush model support
4. Fixed the system clock issue [causes severe problems on some machines ... Windows-only issue, usually with dual-core or quad-core]
5. Frag Machine's chase_active 2 (added a couple of extras)
6. Added 5 button mouse support + made scrollwheel scroll the console.

Easy As Hell To Compile

Download FitzQuake Plus binaries + source:
http://quake-1.com/files/engine-sources ... e_plus.zip

To compile ...

Option #1: Code::Blocks + MinGW. Code::Blocks is a light and tight IDE that combined with MinGW uses the gcc compiler. The install is a mere 74MB. Download that at http://prdownload.berlios.de/codeblocks ... -setup.exe . To compile, unzip the fitzplus.zip and then unzip the engine source zip contained within. Double click the FitzQuake_GCC.cbp file to open the project; press F9 to Build the binary and run. The End.

Option #2: Microsoft Visual C++ Express. Download that at http://www.microsoft.com/express/Downlo ... Visual-CPP .

To compile, unzip the Fitzplus zip and then unzip the engine source and double click the FitzQuake.sln file and then click Build. The End.

Samples

http://quake-1.com/files/engine-sources ... amples.zip

The above contains 2 samples:

1. A map called halflife.bsp to load as an example. The textures were compiled into the .bsp and therefore it does not use external WAD files.
2. A mini-mod in a folder called "rotate" and a map named "rotate" that is just the crappy rotating doors/drawbridge map I made in the Avirox rotation ported to NetQuake thread.

Sajt · Post by **Sajt** » Thu Jan 27, 2011 4:08 pm

I don't know, I was never able to get hell to compile without tons of errors.

ceriux · Post by **ceriux** » Fri Jan 28, 2011 5:08 pm

it compiled fine for me.

Baker · Post by **Baker** » Fri Jan 28, 2011 5:12 pm

ceriux wrote:it compiled fine for me.

It compiles with 0 errors, 0 warnings in both MSVC++ and Code::Blocks

Just out of curiousity, which did you use?

ceriux · Post by **ceriux** » Fri Jan 28, 2011 5:51 pm

me? i used express.

Baker · Post by **Baker** » Sat Jan 29, 2011 11:30 am

Coming soon ...

FitzKurok 0.85 SDL (Windows, Linux, OS X) with obviously Kurok support and HLBSP plus all the other stuff listed above and as gb calls them "fence texture" support and that means Remake Quake too.

After that, I'll probably throw in q1 model external texture support for fun.

After that I expect to go for Nehahra support and throw in Quakespasm's 64-bit fixes so this one Linux 64-bit machine can run this engine.

goldenboy · Post by **goldenboy** » Sat Feb 05, 2011 11:22 am

Baker wrote:and that means Remake Quake too.

For now. Future RMQ releases are bound to have heavier requirements.

Engines will need a) protocol 999 (or something like DP7) and b) massive performance improvements (renderer), well above the level of most engines today.

I'm willing to get example maps to engine coders, as demonstrated in the past, so they can know firsthand what engines will have to deal with soon.

RMQ is gonna require CSQC and stuff like FRIK_FILE in the future as well, plus a set of extensions and TE_ entries. The e1m6rq demo already uses these extensions, they're just not very noticeable yet (rail trail etc). Our cutscenes will probably require clientcamera for example. And so forth.

Right now I consider it RMQ support if it correctly runs the latest demo though - to my knowledge, the list of engines doing that is relatively small.

cheers.

mh · Post by mh » Sat Feb 05, 2011 12:39 pm

Until then, one reasonable test might be "can your engine handle a fully dynamically lit world?" If you can do that and still get good framerates you're one step along the way.

Baker · Post by **Baker** » Sat Feb 05, 2011 1:06 pm

One thing I am interested in is fully integrating the SDL and Windows builds of FitzQuake into a single source because I think running an SDL build on Windows at least for FitzQuake is a little silly.

I am also want to get vsync working multiplatform which likely could be transportable to, say, Quakespasm.

I know the RMQ engine specs will certainly morph as the project goes along, I'm focusing on a few little interests of mine here and there to play around and one thing I want is Kurok running on OS X. The last thing I have to do to get that working is play around with gl_fog.c (it works without this) and then do testing to get 100% on the rendering (which at this point, only fog appears to be an issue).

I think it'll be fun to see what type of CSQC features RMQ uses and other changes you guys make to the protocol and what you are implying with the client camera features.

qbism · Post by **qbism** » Sun Feb 06, 2011 6:54 am

Baker wrote:running an SDL build on Windows at least for FitzQuake is a little silly.

Only silly if there's a performance hit or feature limitation? It might actually be wise in terms of simplifying code. Usually I haven't seen differences between "native" and SDL (DP is an example) but someone with a P-II may differ.

ceriux · Post by **ceriux** » Sun Feb 06, 2011 7:40 am

P-II as in Pentium 2? i have a crappy AMD...

leileilol · Post by **leileilol** » Sun Feb 06, 2011 8:20 am

qbism wrote:
Baker wrote:running an SDL build on Windows at least for FitzQuake is a little silly.
Only silly if there's a performance hit or feature limitation? It might actually be wise in terms of simplifying code. Usually I haven't seen differences between "native" and SDL (DP is an example) but someone with a P-II may differ.

I find SDL on older computers a lot less stable and compatible, especially since SDL seems to hate secondary video devices. In other words, no Voodoo2 in FitzQuake for you.

And also in terms of 8bpp rendering, it's worse... so it's bad for software based engines as well, particularily on Win9x. but it's also bad on modern hardware when you have nvidia giving slowdown on palette changes and ATI lacking color precision for darker blues, and then there's the dreaded mouse polling if you dare to choose to use SDL input...

Baker · Post by **Baker** » Sun Feb 06, 2011 5:35 pm

I pretty much have the next stage of this wrapped up [I'm talking about the Kurok-capable addition] ... except for one annoying QuakeC issue. [Kurok has a "speed check" in the QuakeC which I suspect could be so sensitive as to hate a clock difference.]

I'll have to double check to make sure I haven't missed some obscure but important piece of the Kurok engine modification somewhere.

What I could do, but I'm not going to invest the time right now ... is convert the SDL port of OS X and Linux into native non-SDL ports.

Besides, that is getting ahead of myself ... I need to track down the issue here with the QuakeC (Kurok has a slightly modified protocol) and I did discover one other annoying issue with Kurok that I verified exists in the original engine build --- changing the video mode has a fog issue. So on video mode change some OpenGL thingy needs re-initiatied or possibly turned-off ... but since video mode switching shuts down the OpenGL rendering context it is far more likely to be the former and the odds of the problem being the latter seem slim to none.

ceriux · Post by **ceriux** » Sun Feb 06, 2011 8:21 pm

will the next release include the transparencies ? (fence textures)

Baker · Post by **Baker** » Tue Feb 08, 2011 4:59 am

ceriux wrote:will the next release include the transparencies ? (fence textures)

Yes