Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

I'm curious how people are planning on handling fixed point overruns in their applications.

1. How is it detected. Right now I'm using some xor logic and checking signs but it seems like there might be a better way.

2. What do you do once an overrun has occured? Constantly recenter world about camera? Not render once something has overrun?

It seems to me that fixed point is the biggest issue with opengl es. It also seems to me that most of these issues have probably already been solved before. If anyone knows a standardized fixed point solutions please let me know.

Hmm. I've done 3 PS1 titles (33mz cpu), they all used fixed point (12.4 and 1.19.12 vectors). Never really had that much of a problem. Just use sensible units for the situation you're in. Eg 32 bit vectors for translation, 16 bit vectors for vertices. There's not enough time to go checking fixed point calculations every time you do them. You could do that in DEBUG I suppose.
Regards,
Steve.

Hmm. I've done 3 PS1 titles (33mz cpu), they all used fixed point (12.4 and 1.19.12 vectors). Never really had that much of a problem. Just use sensible units for the situation you're in. Eg 32 bit vectors for translation, 16 bit vectors for vertices. There's not enough time to go checking fixed point calculations every time you do them. You could do that in DEBUG I suppose.
Regards,
Steve.

What do you do when you have an overrun? with 16.16 fixed point it seems overruns would happen relatively often. Right now I get some overruns when my bilboards are too far from the camera. The vec.normalize function seems to cause it the most.
Since my overrun checks are only going to happen on my math and not the opengl rasterizer is the overhead still going to be prohibitive?
Did overruns simply not happen in your ps1 games?
Did you cast to longs for multiplication and division?
I've never heard of 1.19.12? is this common practice? How are you going to implement this with 16.16 opengl?

What do you do when you have an overrun? with 16.16 fixed point it seems overruns would happen relatively often. Right now I get some overruns when my bilboards are too far from the camera. The vec.normalize function seems to cause it the most.
Since my overrun checks are only going to happen on my math and not the opengl rasterizer is the overhead still going to be prohibitive?
Did overruns simply not happen in your ps1 games?
Did you cast to longs for multiplication and division?
I've never heard of 1.19.12? is this common practice? How are you going to implement this with 16.16 opengl?

It's a matter of getting your units correct.
If you have 1 unit = 1 meter then your billboards can be 32Km away before they over run, so unless your billboards are massive they should be culled by then. I assume your culling right? This would allow 1/65535th of a meter accuracy, which is plenty.
Overuns only happened when we were converting from a PC floating point game. On a native PS1 game you make descisions that avoid these situations.
1.19.12 is just another variation of fixed point. 1 sign bit, 19 unit bits, 12 fractional bits. You can use whatever format you like, as long as you give OpenGl what it expects (16.16) by shifting down. You shouldn't need to do this kind of messing around for rendering billboards though.
On PS1 multiplying 2 32 bit values gives you a 64 bit result, which you can extract.
Gareth wrote:What do you do when you have an overrun? with 16.16 fixed point it seems overruns would happen relatively often. Right now I get some overruns when my bilboards are too far from the camera. The vec.normalize function seems to cause it the most.
Since my overrun checks are only going to happen on my math and not the opengl rasterizer is the overhead still going to be prohibitive?
Did overruns simply not happen in your ps1 games?
Did you cast to longs for multiplication and division?
I've never heard of 1.19.12? is this common practice? How are you going to implement this with 16.16 opengl?

It's a matter of getting your units correct.
If you have 1 unit = 1 meter then your billboards can be 32Km away before they over run, so unless your billboards are massive they should be culled by then. I assume your culling right? This would allow 1/65535th of a meter accuracy, which is plenty.
Overuns only happened when we were converting from a PC floating point game. On a native PS1 game you make descisions that avoid these situations.
1.19.12 is just another variation of fixed point. 1 sign bit, 19 unit bits, 12 fractional bits. You can use whatever format you like, as long as you give OpenGl what it expects (16.16) by shifting down. You shouldn't need to do this kind of messing around for rendering billboards though.
On PS1 multiplying 2 32 bit values gives you a 64 bit result, which you can extract.
Gareth wrote:What do you do when you have an overrun? with 16.16 fixed point it seems overruns would happen relatively often. Right now I get some overruns when my bilboards are too far from the camera. The vec.normalize function seems to cause it the most.
Since my overrun checks are only going to happen on my math and not the opengl rasterizer is the overhead still going to be prohibitive?
Did overruns simply not happen in your ps1 games?
Did you cast to longs for multiplication and division?
I've never heard of 1.19.12? is this common practice? How are you going to implement this with 16.16 opengl?