Fixed Point Math

[RwGast]

    I would like to do the fixed point math conversions for PQ so it will run faster since thats what we all want. My problem is that i dont know how i am a beginner level c programmer(i know dos programming, just a bit of windows programming using api, and ive done work with the q2 and q3 dll's for modding). So if someone is willing enough to walk me through how to do this proccess i am willing to do it for quake. We all gain everyone gets faster quake and i get to learn how to do all this conversion stuff.

[Dan East]

I don't have time at the moment to go through the details. However, over the last several months I (and others I think) have posted very specific info on fixed point math. Try searching this forum for "fixed point".<br><br>Dan East

[Matt Keys]

Robert, if you want to undertake this project, that would be cool. I wish you luck on finding the right info to get you rolling. Perhaps once you do Dan or someone else could tell you which areas need the conversion the most.

[Digby]

To implement this correctly you're probably going to need to write it in assembly language.  This is so that you can handle the conditions when values overflow 32 bits.  <br><br>Since the current crop of compilers doesn't support inline assembly language then you'll need to put this code in a separate function.  Unfortunately if you do this the compiler won't inline them so you'll have function call overhead for every math operation (bad).  <br><br>There's a way around this, you write the entire routine that relies on floating point math in hand-coded assembly language.  You'd need to do this for each CPU you plan to support.<br><br>You obviously don't want to do this all over the entire Quake codebase, rather only in the places that matter.  How do you find this?  By profiling the code.  That's where you should start.  Profile the code and find the one or two slow spots, then start hammering on them.  Post code bits here if you want and I can tell you how to speed them up.  Dan or Jacco is familiar with the codebase so they can point you in the direction of where to start looking, however you really need to understand profiling so that when you make a change you can measure the results in a meaningful way.<br><br>

[RwGast]

Thanks for the info. Im going to start on this as soon as i can. Does eVC have a built in profiler if not where can i get a free one?

[Dan East]

To my knowledge, it does not. The easiest way to profile would be to procure the original Quake source code from id Software, build WinQuake with Visual C++, and profile it from there.<br><br>Dan East

[RwGast]

That will help? Wouldnt the code not be slow on the pc version in the same places its slow in the ppc version. Since pc has math-co.

[Moose or Chuck]

Robert, if you don't understand that much just quit now.

[RwGast]

erhhh that was the whole point of this, to learn somthing new, im not just going to becuase you think i should, no way. Ill quit when i really dont understand, heh j/k.

[Paul]

yeah, james 'pocketcoder' sonne is a real expert.

[Moose or Chuck]

Yup... just do it on the PC. It's faster and easier to do everything. Like Dan said.

[R0B]

Gee, that's a first.  Moose is telling someone not to try.  Ha, sure, give the Fixed point math a shot.  Do you have an arm processor in you device?  I think that that would be the best processor to optimize, because most things will be using it soon, and it makes my job of porting the new source so much easier, if I don't have to learn yet another form of asm.  Lets see, I know 9 different ones now, and it is anoying to learn more.  Good luck, and if you think I can help you in any wy, feel free to ask.

[R0B]

My last post was supposed to go before the one moose just posted.  I really doesn't make much sense where it is now.

[Moose or Chuck]

LOL! LMAO... what a moron

[suchiaruzu]

ssd<br>screw stupid developers (who dont even think about mips).anyway, the new processors will be fast enough to handle a floating point quake