• 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
pressgreen

Double to Float

10 posts in this topic

Ok so i am using the PhysX 2.8 engine with my program but i have my entire program using doubles. so i am having to cast the values that physX is handing me because it only works with floats. I read there is a way to set up physx to use doubles but i was unable the little info i could find on the subject. Well the problem i am having is that i am sure info is being lost in the process of casting and i was wondering if there is some kind of awesome CS casting trick that i am over looking from CS101 that can fix or help in the matter. I am getting smooth rotations and translation until these little moments when it gets a little jumpy or jittery other then that it actually works fin but i would like to smooth out these little bugs if i can. thanks

also if any one knows of the procedure or a white sheets on setting up physX to work with doubles that too would be totally awesome as well :)
0

Share this post


Link to post
Share on other sites
well thats a good question. well i would have to say that I have been building off of a program i developed for a class and i started out using doubles and now its turned into a beast before i started trying to used physx. i am using openGL by the way. any how at this point I i guess just been lazy about converting everything to floats although in retrospect it might not be as much as a hassle as it might trying to retrofit physX. I know there is a way to get physX to work with doubles i just have not found documentation that i understand on how to do it.
0

Share this post


Link to post
Share on other sites
frob is right! Doubles have longer range than floats which takes up more memory. However, conversion from float to double isn't that hard to say at least just impacts the performance. If you wanted to convert a float to a double just put the:

[code]

float PI = 3.14;
float ConvertFloat = (double)PI;

-- or --

double AnotherPie = PI;
[/code]

However, floats are used in most 3D Applications instead of doubles. But if you insist - go ahead and try and see what your results are. If you feel the performance is getting a punch then this would be the reason behind using floats instead of doubles. I forgot how many bytes doubles use but they're way different than floats.
1

Share this post


Link to post
Share on other sites
It's been awhile, but I think there are possible ramifications with having DirectX use float rather than double. I seem to remember having an issue once when I was playing with Ogre3D, where I was suddenly, seemingly out of the blue, getting weird and intractable errors with my embedded Lua. Spent days trying to figure it out; it only happened when I would switch to a Direct3D renderer from OpenGL. I believe it was DirectX changing the FPU mode to float, whereas Lua wanted doubles. Things could be different now, though.
1

Share this post


Link to post
Share on other sites
Just wanted to chime in, probably a bit late but anyway. Floating point variables have a range of something like 12345[sup]10[/sup]. Although this is difficult to place actual range of numbers to it is important to remember that floating point variables are normally used for positions, velocities and other 3D calculations. It is very rare that you will ever encounter a level map, model, mesh or really any 3D asset that even comes close to peaking out the maximum allowable values of a float.

With all of that said I understand that many coders think bigger is better and that using a double in place of a float will give you the ability to have larger maps, worlds, more precision in game and all that jazz. However that is simply untrue, video cards themselves fall flat on their face when you get anywhere near those sizes. So I guess in short, I would suggest coders just be in the habit of using floats unless there is some extenuating circumstance wherein you actually do need the extra range.
-1

Share this post


Link to post
Share on other sites
Why use doubles at all? I mean what requires such precision if most of the time it is unnecessary. The only reason I am using doubles in this program is because the graphic programing class i took had us set up this entire engine using doubles. I figured there was a reason for this but i don't believe it was ever explained. I mean all literature on the subject out side of this class talks about and uses floats. what are some examples of when doubles are beneficiary in graphic programing?
0

Share this post


Link to post
Share on other sites
[quote name='Dan Mayor' timestamp='1349936871' post='4988981']
Just wanted to chime in, probably a bit late but anyway. Floating point variables have a range of something like 12345[sup]10[/sup]. Although this is difficult to place actual range of numbers to it is important to remember that floating point variables are normally used for positions, velocities and other 3D calculations. It is very rare that you will ever encounter a level map, model, mesh or really any 3D asset that even comes close to peaking out the maximum allowable values of a float.

With all of that said I understand that many coders think bigger is better and that using a double in place of a float will give you the ability to have larger maps, worlds, more precision in game and all that jazz. However that is simply untrue, video cards themselves fall flat on their face when you get anywhere near those sizes. So I guess in short, I would suggest coders just be in the habit of using floats unless there is some extenuating circumstance wherein you actually do need the extra range.
[/quote]

I believe that the developers on the original Dungeon Siege encountered precision problems while building their [url="http://floatingorigin.com/mirror/continuous-world.htm"]continuous world[/url], hence their switch to a hybrid system using chained local coordinate spaces. It really isn't as hard as you might think to start encountering precision problems using single-precision floats. Awhile back, I built a quick and dirty little streaming system for my isometric game, and it really only took me about 20 min to hit the "end of the world", where precision problems started cropping up. You can have large floats and you can have precise floats, but large precise floats are a different story.
1

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1349933896' post='4988970']
@OP, simply casting your doubles to floats in the standard manner shown by SIC Games should be all you need. There's no trick to it. This will generate CPU assembly to read your 64-bit double from RAM into an FPU register ([i]expanding the value to register precision, e.g. 80-bit[/i]), then write the contents of that register to a 32-bit float RAM address ([i]rounding the value to 32-bit precision[/i])
[quote name='JTippetts' timestamp='1349930650' post='4988957']I believe it was DirectX changing the FPU mode to float, whereas Lua wanted doubles. Things could be different now, though.[/quote]Yeah, when creating a D3D9 device, it sets some flags in the CPU to tell it to round all it's results to 32-bit precision. You've got to set the D3DCREATE_FPU_PRESERVE flag when creating your D3D9 device to avoid this.
[/quote]

Thanks bro for agreeing. I also like to add that when I tried to convert my mesh file from float to double - it didn't draw correctly until I switched it back to float. Though a XMVECTOR willt ake a double just it's less nessary. Hope this forum has helped out. It doesn't hurt to try and see for yourself though.
0

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