Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (429)
Games in Android Showcase (89)
games submitted by our members
Games in WIP (466)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Why floating point in drawing code?  (Read 3916 times)
0 Members and 1 Guest are viewing this topic.
zahl2001
Guest
« Posted 2003-11-15 12:39:21 »

Since pixels come in 'whole numbers' why do programmers always write code using floating point numbers for positions on the screen?

My point is why say new Ellipse2D.Float(100.0f, 100.0f, 100.0f, 100.0f) when it HAS to end up being drawn at a whole number point on the screen...we'll at least it seems that way to me Wink  I must be wrong or else everyone would use integers and save memory!
Offline kevglass

JGO Kernel


Medals: 85
Projects: 22


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2003-11-15 13:16:04 »

I suspect theres lots of reason but the first that jumps to mind is transformation (scaling/rotating etc..)

Kev

Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #2 - Posted 2003-11-15 13:54:06 »

Its also important for smooth movement, if you use ints then you can only move whole pixels at a time. This might not seem like too much of a problem, but then you realise something simple like a jump isn't going to look right if you use int speeds only. Obviously you need to snap to nearest pixel when drawing, but the 'true' float value will accumulate the fractions over time.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline tom
« Reply #3 - Posted 2003-11-15 15:48:18 »

Pixels come in 'whole numbers', but the shapes that you draw do not. Moving a sircle by 0.1 will probably change how it will look on screen. Because some pixels will go outside, and others inside the sircle. It's called sub pixel accuracy.

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #4 - Posted 2003-11-15 15:52:28 »

I think the main reason in fact is the transform stuff. There might be a 100x scale, to 0.1 difference in the coordinates do 10 pixel on screen.

Printing (where the res is much higher) might be another reason

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #5 - Posted 2003-11-15 19:32:07 »

In addition you can draw in fractions (with antialiasing and the fraction thingy hint). Eg if you draw a black line from 0.1/0 to 0.1/100 it isn't 1 pixel wide and black - instead it's two pixels wide. The left line is almost black and the right line is almost white (if your background is white).

弾幕 ☆ @mahonnaiseblog
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #6 - Posted 2003-11-15 20:33:58 »

Quote
if you draw a black line from 0.1/0 to 0.1/100 it isn't 1 pixel wide and black - instead it's two pixels wide. The left line is almost black and the right line is almost white (if your background is white).


I think the infinity of 0.1/0 will likely cause problems before the line is drawn Smiley.

But yeah - the whole point is image quality, sub-pixel rendering with antialiasing yields really nice results.  Specially good for slow moving things in games.  Though games usually don't go to the trouble.

Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #7 - Posted 2003-11-15 23:04:48 »

Heh that was ment to be a pair of coords not a division :>

弾幕 ☆ @mahonnaiseblog
Offline Jeff

JGO Coder




Got any cats?


« Reply #8 - Posted 2003-11-16 01:23:07 »

Also, ever since Pentium, floating point has actually been nominally faster then integer in the x86 world (and on similar processors.)

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline crystalsquid

Junior Member




... Boing ...


« Reply #9 - Posted 2003-11-16 10:47:38 »

Yep, the integer multiplies and divides are actually performed as:
Int->Double convert, FPU operation, double->int convert
Unsurprisingly, this is a fair bit slower than using floats. Additions & subtractions are 1 cycle for ints though, and slightly slower for floats.

- Dom
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sma

Junior Member





« Reply #10 - Posted 2003-11-16 14:39:38 »

...and last not least, with Java floats need 4 bytes as ints do so you don't save memory by using ints instead of floats.

.: Truth Until Paradox!
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #11 - Posted 2003-11-16 20:10:20 »

Quote
Yep, the integer multiplies and divides are actually performed as:
Int->Double convert, FPU operation, double->int convert
Unsurprisingly, this is a fair bit slower than using floats. Additions & subtractions are 1 cycle for ints though, and slightly slower for floats.

- Dom


Are you sure about that?  That means that integer multiplies and divides don't use the integer ALU.. that seems like a waste, since an integer multiply is easier to do that a floating point multiply.  It COULD be done faster if the integer ALU supported the operation.  And the fact that integer operations are generally more common.. since they are needed to calculate array offsets etc.. it just doesn't seem to make sense to go through all those hoops.

I know in many cases you can get better performance if you convert floating point ops to integer ops with fixed point math... maybe that was only if you could avoid division..  For example to divide by a constant multiply be the reciprocal.. if possible use power of two fractions so it ends up being an integer multiply followed by a shift.  Sometimes with a little extra fudging you can get the exact same answer as if you did the math with floats, yet the result is computed in half the time.  I know of someone that used this technique to get dramatic speedups with a video codec and that was using at least a Pentium 3.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #12 - Posted 2003-11-16 20:41:38 »

Quote
Also, ever since Pentium, floating point has actually been nominally faster then integer in the x86 world (and on similar processors.)


I've not checked since Java 1.1.8 and 1.2.x (that's the last time I had a real app that spent nearly all of it's time in ALU-limited calculations), but in Sun's JVMs IME int mul and div were much faster than float mul/div, on Pentium 2 upwards.

OTOH, float add/sub were (effectively) the same speed as int add/sub.

This was when I was writing 3d fractal renderers where it's pretty easy to see the effects on performance of changing your datatypes. However, it's long enough ago that I cannot recall what differences there were with/without hotspot, and perhaps 1.1.x just wasn't utilising the P2 fully? (PS I was only ever working with basic datatypes)

<fx: prepares to be told he did something stupid with his app design Smiley >

malloc will be first against the wall when the revolution comes...
Offline Jeff

JGO Coder




Got any cats?


« Reply #13 - Posted 2003-11-17 01:48:27 »

Quote


I've not checked since Java 1.1.8 and 1.2.x (that's the last time I had a real app that spent nearly all of it's time in ALU-limited calculations), but in Sun's JVMs IME int mul and div were much faster than float mul/div, on Pentium 2 upwards.


Likely limits in the VM.  These days Im pretty sure you are getting platform speed in the Intel environment.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2003-11-17 11:10:10 »

The server VM in 1.4.2 absolutely flies for floating point maths now. Client, and prior, VMs are not nearly so good.

I still got a considerable performance boost moving to fixed-point math but that's probably going to be irrelevant in about 6-8 months' time as the typical desktop will be approximately 2x as fast.

Cas Smiley

Offline crystalsquid

Junior Member




... Boing ...


« Reply #15 - Posted 2003-11-18 13:16:54 »

Quote


Are you sure about that?  That means that integer multiplies and divides don't use the integer ALU.. that seems like a waste, since an integer multiply is easier to do that a floating point multiply.  It COULD be done faster if the integer ALU supported the operation.  And the fact that integer operations are generally more common.. since they are needed to calculate array offsets etc.. it just doesn't seem to make sense to go through all those hoops.

It makes more sense to save silicon and only have a single divide unit. Int & float divides take the same time on PII+ (39 cycles, double precision, 23 single), and cannot be done in parallel (like they could on plain Pentium, as that had 2 units). The int conversion is done 'transparently' in these cases, and the FPU can perform multiplication & additions while waiting for the result. However, only the last 2 cycles of the divide can overlap with integer instructions, so by trying to use integer math you would lose 36 cycles worth of computation - thats 36 multiplies!

Int multiplies are 4 cycles (PII+, 9 cycles before) and 3 cycles for a float. The float instructions can also be pielined to allow 3 multiplies to be in flight at any one time. Int*float is even worse - 6 cycles with no concurrency.

Quote
I know in many cases you can get better performance if you convert floating point ops to integer ops with fixed point math... maybe that was only if you could avoid division..  For example to divide by a constant multiply be the reciprocal.. if possible use power of two fractions so it ends up being an integer multiply followed by a shift.  Sometimes with a little extra fudging you can get the exact same answer as if you did the math with floats, yet the result is computed in half the time.  I know of someone that used this technique to get dramatic speedups with a video codec and that was using at least a Pentium 3.


Multiplying/dividing by simple powers of 2 is a great speed up. Not something easily achieved in Java except for small cases. In C++, we use a union between an int and a float (called a floint) that lets you do some great speed ups:
Clamp to zero:
Float:
if(f < 0.0f)
   f = 0.0f;
Looks easy enough, but in fact it takes 15-30 cycles to work out

instead:

floint fl;
fl.f = f;
int m = fl.i>>31; // If f was negative, this is 0xffffffff, else it is 0
fl.i = fl.i & (~m); // either 'f' or '0'

This takes around 5 cycles to compute with no chance of a Branch Predict error - 3 to 6 times faster. You can use this when doing clamping operations on colours, so it is a good thing for video codecs & software renderers.

Avoiding division is good to always aim for, e.g:
   a/b + c/d
is faster if you do:
   (a*d + c*b) / (b*d)

And avoiding multiplies:
  a * f + b * (1-f)
is faster as:
  b + (a-b)*f

If you want to know more, I reccomend googling for 'Agner Fog', the godfather of pentium optimisation.

- Dom
Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2003-11-18 15:34:15 »

Those kinds of optimisations are the kinds that javac should actually be performing. And others like the floint one should be performed by the JVM. Really. But I bet they aren't.

Cas Smiley

Offline Jeff

JGO Coder




Got any cats?


« Reply #17 - Posted 2003-11-18 23:02:09 »

Actually, I suspect it is, at least in cases where it makes sense (like math with constants.)

But hey, you can always dig into the compiled code and find out.

(better you then me, I'm happy to be past that s-it Tongue )

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #18 - Posted 2003-11-18 23:03:44 »

Btw,

As a side note.  Even for addition and subtraction, at least on the Pentium (don't know about later processors) floating point was *slightly* faster then integer.  

The reason was that the integer adder was also used for incrementing the PC thus there was some *slight* contention for it that wasn't present on the FPU Wink

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (81 views)
2014-04-15 18:08:23

BurntPizza (73 views)
2014-04-15 03:46:01

UprightPath (84 views)
2014-04-14 17:39:50

UprightPath (67 views)
2014-04-14 17:35:47

Porlus (83 views)
2014-04-14 15:48:38

tom_mai78101 (107 views)
2014-04-10 04:04:31

BurntPizza (167 views)
2014-04-08 23:06:04

tom_mai78101 (263 views)
2014-04-05 13:34:39

trollwarrior1 (213 views)
2014-04-04 12:06:45

CJLetsGame (223 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!