• entries
222
606
• views
592229

# QTEST

1516 views

Quote:
 Original post by ScetLooks nice, I could never figure out Quakes lightmaps.
The unofficial Quake specs are a bit confusing on this matter. To get the size of the texture, find the bounding rectangle for the face (using the horizontal and vertical vectors to convert the 3D vertices to 2D in the same way as it's done for the texture coordinates). Then divide by 16 and add one, like this:

Width  = (Ceiling(Max.X / 16) - Floor(Min.X / 16)) + 1Height = (Ceiling(Max.Y / 16) - Floor(Min.Y / 16)) + 1

Quote:
 It was meant to make it look like the Doom software renderer but with Direct3D. Plus I could use L8A8 textures which prevented it from eating up my RAM. All you'd have to do is switch the shader technique when using 24-bit textures, although you'd have to implement your own fading system since the colour maps are just palettes and you lose palette support.
It'd certainly work, but it'd probably look a bit odd (mixing and matching, that is - emulating the appearance of the software renderer on its own is very cool). [smile]

Quake II appears to contain a lump that maps 16-bit colour values to values in the palette. I don't know what that was used for, but you could probably use something similar to convert the truecolour textures to 8-bit textures.

The rest of this journal post goes off on a bit of a historical tangent.

Before Quake was released, ID released a deathmatch test program, QTEST. This featured the basic engine, three deathmatch levels and not a whole lot else.

However, the PAK files contained some rather interesting files, including a variety of models - some of which were later dropped from Quake entirely!

The model version is type 3, and I've made a guess at the differences between type 3 and type 6 (6 is the version of the models in retail Quake). Type 6 has 8 more bytes after the frame count in the model header. I skip the "sync type" and "flags" fields, as I don't know what these do anyway. [rolleyes] Type 3 files don't have a 16 byte frame name, either (between the frame bounding box information and vertices in type 6).

The most impressive extra model is progs/dragon.mdl. It appears in this early screenshot:

One character which changed design considerably was progs/shalrath.mdl.

Appearing in registered Quake, it became the following (QPed seems to mangle the palette, sorry):

The charmingly-named progs/vomitus.mdl is likewise untextured:

The frame data appears to be corrupted here, so I don't think my model loader is working properly. However, you can still get the rough idea of what progs/serpent.mdl might have looked like:

The fish model is quite different, but like the above its last few frames appear corrupted.

A number of textures changed in the final release. Some model textures, such as the grenade and nail textures, were originally much larger.

The Ogre before and after his makeover

The original 'gib' textures, eventually unidentifiable meat, were also toned down quite a lot from the rather more graphic ones in the QTEST PAKs.

The screenshots (taken directly from QTEST - I can't load those BSPs myself) show a few other changes - billboarded sprites for torches and flames were replaced with 3D models, the teleporter texture was changed and the particle effects for explosions were beefed up with billboarded sprites.

Yeah, I remember seeing some stuff about the Vomitus in the Quake progs.dat source. Some death string ("%s was vomited on by a vomitus" I think). I always wondered what they were, I assumed they'd been dropped from Quake for some reason.

Very interesting work, Ben. I've been following your journal for ages now, but I don't think I stop to say, "awesome work" nearly often enough. I'd really like to hear some more juicy details on Cogwheel and how things were put together -- hopefully in a manner that a fellow that knows little about console emulation would understand [smile].

I've likely missed an earlier post that said so, but is the plan for this Quake renderer simply to have a Quake renderer, or to develop it into an original Quake-like game?

Keep trekkin' on!

Quote:
 Original post by HopeDagger Very interesting work, Ben. I've been following your journal for ages now, but I don't think I stop to say, "awesome work" nearly often enough.
Thank you. [smile] I'm very bad at commenting on people's journals, though I try to read all of them. [sad]

Quote:
 I'd really like to hear some more juicy details on Cogwheel and how things were put together -- hopefully in a manner that a fellow that knows little about console emulation would understand [smile].
Ah, yet another old project that's 90% finished that returns to haunt me occasionally. [grin] There isn't really much to say, but I'll prepare a journal entry on how I designed the emulator in C#.

Quote:
 I've likely missed an earlier post that said so, but is the plan for this Quake renderer simply to have a Quake renderer, or to develop it into an original Quake-like game?
I don't have any specific plans, really. A generic BSP loader/renderer (Quake 1-3) would be a decent learning project for me. As has been pointed out by Evil Steve, the game code is (mostly) implemented in QuakeC (some of the internal functions are native, for speed or convenience reasons).

I now have the QuakeC compiler source code, so I can work out what each instruction in the compiled bytecode is meant to do and write an interpreter for it (which, in a roundabout manner, takes us back around to C# emulators - it's the same principle).

Congratulations on your ability to actually finish and release projects. It's not something I've ever got the hang of. [smile]

Oh man, I remember the old Quake screenshots.

Especially remember all of the stuff they were rambling on about linked portals. Good fun.

## Create an account

Register a new account