drawrect?

[Hemlos]

i used fillrect in my old 2d gravity simulation.
the pixels were placed to the screen very smoothly, using floating point numbers for x/y coords.

I tried to recompile with the latest editor, and it seems the drawrect is placing pixels at integer steps now.
This makes the animations look rough and "choppy".

What has happened??

[Kitty Hello]

Oh. I'm sorry, it uses integers now, since you usually want to draw rectangles on integer base.
Is it really that bad?

[Hemlos]

Yes, bad, it is very much "commodore 64 ugly".

Being floating point made it look very nice....the difference is significatant...i can upload a before and after affect if you want?

Did you make everything integer? polyvectoring too?

All the 2d should really be left as floating, IMO....when i use these things i make the "size" of a rect integer, but to move it around i would use floating points...for smoothness, and more "perfect" lines of tradjectories...hence sin() and cos()

[Kitty Hello]

ok, so implement a float version for win32/linux/pc and integer for mobiles, or implement a DRAWRECTF and POLYEVCTORF instead?

[Hemlos]

ok, so implement a float version for win32/linux/pc and integer for mobiles, or implement a DRAWRECTF and POLYEVCTORF instead?

DRAWRECTF and POLYEVCTORF, and any other drawing operations should also have Float options if they are integer driven. All drawing operators, should have a brother floating operation, if you converted it to integer for mobiles.

Are these converted to integer too? (I have not tested these recently, but, these should also have float ability) :
DRAWANIM
DRAWLINE
DRAWSPRITE
SETPIXEL
ZOOMSPRITE
And ALL 3d operators should be FLoating too.