• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
chrisendymion

About fixed points

12 posts in this topic

Hello,
 
I'm in an optimization step for my little procedural engine.
For now, I worked with floats for a full planet coordinates. So, there was some artifacts in very high LOD, caused by float precision.
After reading a lot of threads and articles on the net, I came to think about using fixed points (fractional integer) instead of float.
I never worked with fixed points, and so, there are some (lot of) concepts I didn't understand !
 
Where to start using them and.. when to stop ?
 
1- I want to choose freely the planet's radius, let say 5629 kilometers 194 meters 29 centimeters. 
Using a 16 bits whole part and 16 bits fractional part, the fixed radius number will be 368914876 (5629.19429 * 65536), right ?
But in the first place, it will be a float => 5629.19429 in the code (much readable), so I must convert it before sending it to the shader ?
 
2- My planet is quadtree based LOD (cube with 6 grids). Does the grids have integer coordinates ? How to scale them on the radius ?
I imagine I must choose a power of 2 radius for quadtree divisions ?
 
3- If the coordinates of point.x is 368914876, it's a big number in the shader (with far/near frustum, Z buffer, etc.), so what to do ? Convert it to float again ?
I must scale somewhere... ? Buf if 1 equals 1 centimeter.. It will be very very big ?!
 
4- In the shaders, what happens when I use the world, view, projection matrices ? Is there a moment when fixed points are no more working ?
 
It must be something I didn't see/understand.. 
Hope I was readable because it's very coufuse to me and my poor english did not help ;)
 
Thank you,
 
Chris
Edited by chrisendymion
0

Share this post


Link to post
Share on other sites

Thank you all for your answers !

 

Frob, you talk about mixing numbers. It's one of my doubts, do I need to convert the fixed point back to float ? Float to Integer => no loss.

If don't need to convert back, how will work the shaders, as the numbers will be to much big... 

I read, a lot of engine are using fixed points, there must be a solution.. 

 

Stainless, thank you for the links, I will read them now.

 

Vortez, I read that it's a bad solution to use double, I tried to get my idea about. There was too much loss of performances.

0

Share this post


Link to post
Share on other sites

I'm not aware of any space game that uses real life scales for planets, stars, and other objects. Space is mind-boggling huge.

 

SIMSpace 8.0 of course! <g>  

 

Leave it to Rockland to do the insane!

 

Chris:

 

i just finished working out the world coordinate system for SIMSpace 8.0

 

you might want to try using an _int64 for decimeters. 

 

when its time to draw, pretend the camera is a 0,0,0.  so you subtract camera x,y,z from the x,y,z of all other objects, put the result in a float, then send it off to directx.

 

for objects past say 1 million d3d units, you do a multi-pass method. first you set your planes far, and draw everything farther than 1 million, but you draw them 1000 times smaller and closer (for example). then you reset your planes and zbuf to normal, and draw everything that's closer. 

 

this will get you accuracy of 0.1 meters, and a range of values from about -992 to 992 quadrillion meters. the diameter of the galaxy is about 100K light years ( 946,000 quadrillion meters).   

 

SIMSpace 8 doesn't map the entire galaxy, only a cube which is 200 quadrillion meters across. 

 

for truly intergalactic distances, you'll want to go with something like an _int64 decimeters, and an _int64 of Quadrilion meters. conversion to float for drawing remains similar to the single _int64 case.

 

as frob said, space is truly huge.   a light year is 9.46 quadrillion meters.     a parsec is  3.2616 light years.   and astronomers use units of kilo parsecs and mega parsecs for measuring the most distant heavenly bodies.

 

approximating the galaxy as a 100 light year diameter disc 200 light years thick, and using 200 billion for the number of stars, you get an average distance between stars of 18.8 quadrillion meters in all 3 dimensions.

 

figuring out an appropriate world coordinate system and how to draw very distant objects is the only really unusual part of building a space sim. from then on, its more or less like any other sim, just convert everything to camera relative coordinates before drawing.

 

you'll also want to code up some routines to add and subtract distances if you use two _int64s or something like that.

 

Note that _int64 decimeters is fixed point: IE  meters with 1 digit of fixed point accuracy.

 

fun fact: 1 warp number apparently equals 100 times the speed of light.

Edited by Norman Barrows
2

Share this post


Link to post
Share on other sites

 

space is truly huge. a light year is 9.46 quadrillion meters. a parsec is 3.2616 light years. and astronomers use units of kilo parsecs and mega parsecs for measuring the most distant heavenly bodies.

Luckily, these huge distances don't matter much.

 

If you look at a nearby stellar object (let's say Proxima Centauri, which is a mere 4.2 lightyears), it doesn't matter whether you measure the distance with micrometer or kilometer precision because you can't tell the difference. If you travel at "normal" speeds, then travelling for the entire duration of your life will bring you none closer to Proxima Centauri than about 4.2 light years. It is exactly the same in every respect.

 

On the other hand, if you have some form of "hyperdrive" (or any other fictional faster-than-light travel. wormholes or whatever) then you can reach Proxima Centauri no problem, but you still cannot tell the difference between a micrometer or a hundred thousand kilometers. There's no way you could hit the "stop starship" button fast enough to travel less than a hundred thousand kilometers, and there is nothing interesting but ... empty space... anyway. There is also no way of telling, after travelling 4.2 lightyears, whether that was really 4.2 lightyears or 4.2 lightyears, 33.7 kilometers and 20.0052 meters. Our sun is the same tiny spot when looked at from over 4 lightyears away whether or not it's a few kilometers off or not.

 

In other words, you can conveniently use a coarse coordinate system with a resolution of thousands (ten thousands, if you will) of kilometers to model the huge empty space between interesting things, which is convenient for modelling entire galaxies. And then again, use a different coordinate system at planet or solar-system scale (say, 64bit integers, micrometer precision) to model the "interesting stuff". Switch between them whenever you swich hyperdrive on/off.

 

 

This.  Sometimes, your relative distances look like this*:

union distance
{
  int parsecs;
  int lightyears;
  int meters;
};

Rather than This:

UnGodlyHugeArbitraryPrecisionType distance;

Embrace the fact that not all scales of distance ever matter at the exact same time.  Treat units the same way scientists do; don't try to convert everything to a uniform metric.

 

*I'm not actually sure I'd use a union in this kind of situation.  That's just an example.

Edited by SeraphLance
2

Share this post


Link to post
Share on other sites


In other words, you can conveniently use a coarse coordinate system with a resolution of thousands (ten thousands, if you will) of kilometers to model the huge empty space between interesting things, which is convenient for modelling entire galaxies. And then again, use a different coordinate system at planet or solar-system scale (say, 64bit integers, micrometer precision) to model the "interesting stuff". Switch between them whenever you swich hyperdrive on/off.

 

This is exactly the approach used in all previous versions of SIMTrek / SIMSpace. as you say it works just fine.

 

now the _int64 makes it possible to use world coordinate systems of light years and decimeters and cover the size of about 3 galaxies. this allows huge game worlds with high precision, and little muss and fuss about multiple coordinate systems, sector/quadrant stuff etc. just a simple "draw whats around the camera, relative to the camera" approach to things, with a little LOD thrown in. SIMSpace 8 will be the 6th title i've done with a game world so large it required world coordinates. and at last, i almost have data types big enough to store the positions etc without a lot of hassle.

1

Share this post


Link to post
Share on other sites


The problem was solved by having multiple coordinate systems -- One that was used to describe the location solar systems themselves, and one local space for every solar system -- basically the suns/stars were in the 'universal' coordinate system, and each sun/star was also the center of its own local coordinate system.

 

this is the precise method used by previous versions of SIMTrek / SIMSpace.

1

Share this post


Link to post
Share on other sites
Whoah ! Thank you all so much for all your help !
I start to understand. There is just some things to learn more...
 
For the moment, I will concentrate myself on only a planet, I will see later for solar system, galaxies, etc.
 
For very high precision, you say it's better to use int64. I think I need to create a class for converting it to better readable numbers (for coding) ?
If not, with micrometers precision, I will deal with very very big numbers (without digits as it's integer), not very convenient.. ? Some tips ?
 
I understand the concept of  using camera position as the center, for more precision when converting to float.
But subtracting the vertices x,y,z from the camera position in the CPU will be huge ?! There is lot of vertices in the node's grid (x 6 faces)...
Better to do that in the vertex shader, no ? But if I do that, how to send the coordinates to the shader ? 
As the max input is R32B32G32 and I will use 3 x int64... ?
 
My grids are allways the same, they are offseting and scaling in vertex shader based on node position and LOD.
 
In conclusion, when to convert to float and where ? What format to send to the shaders ? 
 
Again, thank you for all your help ;)
 
PS : I know it's a hard concept for a beginner, but I'm here for learning and not affraid to spend hours on that.
Edited by chrisendymion
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0