Open Source Game Engines...

[Octavious]

again, what and where do I change floating point to fixed point?

~Octavious

 

[Blah]

I think floating point is anything that has to do with calculations that are more pricise than integers.

In English, that means, if the calculations deal with having to figure a number down past the decimal point (as in say, PI 3.1415926535897932384626433832795....), than its floating point.

See if you can decipher the article on Wikipedia (I cant).

 

[Squidge]

again, what and where do I change floating point to fixed point?

~Octavious

​

Have a look here:

http://www.devx.com/Intel/Article/16478

As you can see, it's a very involved task to change an entire program from floating point to fixed point, so I hope you got a lot of spare time.

 

[pea]

Fixed point library (WIP):
http://ccrma.stanford.edu/courses/250a/doc..._8c-source.html

You will need to go through the entire source code and convert all a*b to use fixedptMultiply( a,b ) etc...

addition and subtraction remain the same. If you need to work with integers as well as fixedpoint numbers, you will need to convert to fixedpoint first using fixedptConvertFromInt

I am about to use fixed point in a current project. I haven't tested this lib yet, but it seems very simple, and I will use it for reference. One thing I do recommend is defining a new type for your fixedpoint operations (rather than just using unsigned long) for example:
typedef unsigned long fixedpoint;

This way you might be able to get the compiler to warn you if you are using the functions incorrectly.

I would also precalculate some sin and cos lookup tables, and use those for trig (precalculated as fixed point numbers)

EDIT:
More sources:
http://www.egosoft.com/x2/forum/viewtopic.php?t=22983
http://www3.telus.net/public/yeh1/eng_math.htm - heaps of resources linked from here

 

[Blah]

Could other programs such as emulators benifit from this?

 

[Squidge]

It could be used in some parts of sound emulation, specially if it needs frequency calculations.

 

[pea]

Just remember that the dynamic range of the number is cut down.

For example, a long (32 bits) goes from ~ -2147483648 to 2147483648
However, a 16.16 fixed point (32 bits) only has a similar range to a short, ~ -32768 to 32768

To get a bigger range you would either need to cut down on the precision (the number of bits that represent the fractional part), or go to 64 bit numbers, which is not possible in the hardware without writing code that emulates 64bit, which will slow everything down.

 

[Octavious]

what sort of speeds do you think we could get from Quake/Quake 2 with fixed point?
I plan on working on this after/twords the end of my school year, and would love to see ( my personal ambitions for the GP32 ) Quake 2 on the GP32, so then I couls go through and make a nice game mod off of it

so, what kinds of speeds could I get, because the system requirements for Quake are:
75 mhz Proc.
8 megs of ram ( we need less due to no sound )

Quake 2:
90 mhz ( 133 recomended ) proc
16 megs required ( proly around 8, I hope, with no sound )

well, could we atleast get 30+ frames on Quake with no scaling and sound on?

would we lose any quality with fixed point rather than floating??

~Octavious

 

[woogal]

what sort of speeds do you think we could get from Quake/Quake 2 with fixed point?

Quake already uses fixed point in some of the major bottlenecks (done by the pocketquake team, not me). There are still lots of other areas that use floating point but using the latest gcc speeds those up. Converting all of Quake to fixed point would be a massive job and I'm not sure how much of an impact it would have. The best thing to do would be to slowly convert other bottlenecks to fixed, but I don't know enough about optimising to know which areas are worth looking at (if any - it's possible the pocketquake team stopped optimising in that way because there wasn't much more that could be done). The bottom line is don't expect Quake to get much faster than it is now. Any speed improvements I'm looking at involve reducing quality and removing elements and increases will only be a fraction of a fps per improvement, not the 20fps increase you're hoping for.

As for Quake2, stop dreaming . The memory requirements are 16mb and pak0.pak alone is 48mb (I'd hate to think how big pak1.pak is) so the full game may not even fit on an smc. Taking sound out will reduce the pak size, but it will have very little effect on memory requirements.

 

[devlkore]

I don't know about speed or playability, but would it be possible to reduce the size of the textures in Quake 2? Like, open up the images and scale them down to a quarter of their size.

LA!

Just an idea.