Models

Published July 25, 2007
Advertisement
Quote:Original post by Evil Steve
Do you intend to parse the progs.dat file (I think that's what it was called) - the QuakeC compiled code? I've no idea what's actually involved in that, however...
I'm not sure either (I haven't looked into it). As the source code for Quake and the QuakeC compiler have been released I might be able to do something. I have a hunch that said code is responsible for level events (switches, bridges, lifts, doors and so on) so it would seem pretty important.

Quote:Original post by Scet
You might want to check the version of your BSP files versus the one used in the Unofficial Quake Specs.

...

Also here's some API independent code for loading Quake MDL models.
So far I've had one minor problem that was resolved with a hex editor (something simple like a short becoming an int or vice-versa). I'll take a look at your MDL code - thank you! [smile]


I've made progress with the Alias model loader and written a ModelRenderer class to go with it.


zombie.mdl before and after texturing support.

Animation isn't handled very well just yet - the frames aren't grouped by action (such as the 'attack' animation, 'walk' animation and so on) and the Draw call just takes a frame number.



It'll do for the moment as a test. [smile]

I'm still having problems with textures not wrapping correctly.



As you can see the texture above the hand is distorted. I was pointed in the direction of a solution via the texture wrapping options, and have added these lines:

graphics.GraphicsDevice.SamplerStates[0].AddressU = TextureAddressMode.Wrap;graphics.GraphicsDevice.SamplerStates[0].AddressV = TextureAddressMode.Wrap;


This, unfortunately, hasn't helped. Experimentation has shown that this does change something, and by using the TextureAddressMode.Mirror I get the following -


Note the orientation of the red symbols

I still can't get decent looking light maps out of the level - they all have the "diagonal stripes" effect that usually is caused by an erroneous width. I think I'll have to start trawling through Quake's source code.
0 likes 1 comments

Comments

Evil Steve
Quote:Original post by benryves
Quote:Original post by Evil Steve
Do you intend to parse the progs.dat file (I think that's what it was called) - the QuakeC compiled code? I've no idea what's actually involved in that, however...
I'm not sure either (I haven't looked into it). As the source code for Quake and the QuakeC compiler have been released I might be able to do something. I have a hunch that said code is responsible for level events (switches, bridges, lifts, doors and so on) so it would seem pretty important.
Yup, I've done soem QuakeC modding before. The progs.dat is basically all the game code, and quake.exe is all the engine code. if you can load progs.dat properly, you should be able to get behaviour exactly like the original Quake.
Progs.dat is responsible for all monster types AI, and I think you're right about triggers and bridges and stuff.

I looked at this aaagggeeesss ago when the Quake source code came out, but I really can't remember for the life of me how progs.dat is laid out (If it's executable code, bytecode, or something else).
July 26, 2007 04:05 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement