ENIGMA Forums
General fluff => General ENIGMA => Topic started by: Goombert on August 01, 2013, 02:27:16 AM

As some of you may not be aware, vector graphics require a half pixel align or else there are edge artifacts, anybody who has worked with SVG's knows about this. Anyway, DX and OGL require you do the half pixel alignment yourself for 2D rendering. Now Josh's original proposal to me was to just shift the ortho projection function by (0.5,0.5) and that appeared to work because I was using draw_rectangle. Now this does not fix it for every draw function, as x and y are by default float because of gs_scalar and what both graphics API's use internally. This means if you call say draw_sprite(random(room_width), random(room_height)); you'll end up with half the sprites half pixel aligned and the other half of them not. The only way I could resolve it locally was to cast to integer before passing the coordinates to the draw functions and then letting the projection matrix shift (0.5, 0.5)
The only solution to this I can think of is to either explicitly require integer for x and y with 2D drawing functions (which breaks them for transforming say a sprite into a 3D billboard as float is still the highest precision allowed). We could create a separate scalar for 2D x and y drawing functions so people can easily choose their cast. Or we can manually enter (0.5, 0.5) to every single 2D drawing function. Looking for input on this you guys, specifically you, Josh Dreamyland.

I haven't seen this problem in sprites. I only saw it in line drawing and such. Also, transformations are done AFTER the cast. That means if you pass x and y as integers, it shouldn't in any way impact 3D transformations.

This isn't a problem. Sprite dimensions are integral. If you pass integer coordinates, you'll have halfinteger final coordinates for all vertices. If you pass random coordinates, you'll have random coordinates. We can't do anything about that without breaking smallscale games (think 8bit games with a resolution of 240x160). In those games, rounding coordinates would mean choppy movement when they're blown up to 640x480, or full screen.
It's fine how it is.

Actually, just to update on this, this problem is specific to D3D 9. It looks awful Josh, we have to do something about it, the solution does work for OpenGL 1, but D3D 9 is notorious for this problem.