Pages: 1
  Print  
Author Topic: Half Pixel Alignment, OpenGL and DirectX  (Read 809 times)
Offline (Male) Goombert
Posted on: August 01, 2013, 02:27:16 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
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.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #1 Posted on: August 01, 2013, 02:40:22 AM

Developer
Joined: Apr 2008
Posts: 1872

View Profile
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.
Logged
Offline (Male) Josh @ Dreamland
Reply #2 Posted on: August 01, 2013, 07:10:28 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2957

View Profile Email
This isn't a problem. Sprite dimensions are integral. If you pass integer coordinates, you'll have half-integer final coordinates for all vertices. If you pass random coordinates, you'll have random coordinates. We can't do anything about that without breaking small-scale games (think 8-bit 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.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Goombert
Reply #3 Posted on: August 02, 2013, 08:12:31 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 3110

View Profile
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.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Pages: 1
  Print