bryanedds

I implemented a virtual pixel system in Buttermilk to try and keep all the graphics of a game the same size no matter what the preferred back buffer resolution was.

Unfortunately, due to accuracy problems with SpriteBatch.Draw's int-based coordinate parameters, cracks keep appearing between my tiles, and tiles sizes shrink / grow depending on how the float coordinate value of the tile translates to the int-based coordinate parameters. I've tried all different kinds of Math routines (Floor on the pos, Ceiling on the Size, Round on everything, etc etc etc) but nothing work as well as it needs to.

So, I'm probably going to completely abandon the virtual pixel system. It's just not working at all. But, I still need some way to keep game graphics the same size across different resolutions. What is the best way to go about this with XNA

Thanks for reading!




Re: XNA Game Studio Express Keeping game graphics the same size over different resolutions

Joel Martinez

you could forget about the built-in sprite system and build your own using textures on quads ... of course, then you have to rebuild a lot of the stuff that the built in sprite system gives you (like batching)





Re: XNA Game Studio Express Keeping game graphics the same size over different resolutions

Johnnylightbulb

I've been thinking about this myself and I am considering rendering to one of three fixed resolution/aspect buffers.

One for 16x10 (PC Widescreen), one for 16x9 (HDTV) and one for 4x3 (PC/SDTV). I would then scale that (high resolution) buffer to whatever resolution the screen was in by rendering it on a full-screen quad. I'm pretty sure it would work, and I know there will be waste if say the 4x3 buffer is 1280x1024 and is down-sampled to a 1024x768 screen, but it's also a simple solution.

There's alot to be said for simple. That way you can have three, or just, two, natural resolutions to design to, and not worry about division fractions of some obscure screen res messing with your layout.

Another simple approach might be to design screen elements such that gaps are not obvious - soft edges





Re: XNA Game Studio Express Keeping game graphics the same size over different resolutions

Shawn Hargreaves - MSFT

SpriteBatch doesn't have to be integer based. Some of the Draw overloads take integer parameters, but there are other versions that are entirely floating point and can handle sub-pixel positioning.





Re: XNA Game Studio Express Keeping game graphics the same size over different resolutions

parlance

 Shawn Hargreaves - MSFT wrote:
SpriteBatch doesn't have to be integer based. Some of the Draw overloads take integer parameters, but there are other versions that are entirely floating point and can handle sub-pixel positioning.

For a large number of sprites this becomes inefficient because what are you actually doing is redundantly replicating the effect of modifying 2 elements of the projection matrix, and applying that transform using the CPU rather than the GPU which is bad practice where you can avoid it with any graphics card that supports hardware T&L. Depending on the overload, you would executing up to 4 redundant floating point multiplications per sprite, or O(n) complexity for the problem. The much more efficient way (O(1) )would be to add an overload to SpriteBatch.Begin that would allow you to explicitly specify the parameters that make up an off-center orthographic projection matrix, and while you're add it, save users the trouble of executing 2 redundant floating point adds per sprite for the added advantage of scrolling, and allow users to specify parameters that make up the view matrix as well (this could also include 'screen' rotation).





Re: XNA Game Studio Express Keeping game graphics the same size over different resolutions

bryanedds

Oh man... I can't believe I didn't notice this!

Thanks Shawn!






Re: XNA Game Studio Express Keeping game graphics the same size over different resolutions

bryanedds

One more thing though -

ScissorRectangle is entirely int-based. Is there a way to make it float-based If not, some tiny issues could linger when it comes to clipping things that are float-based.

Thanks!






Re: XNA Game Studio Express Keeping game graphics the same size over different resolutions

parlance

I assume ScissorRectangle works by modifying the device scissor rectangle render states, which means that it would be impossible to set sub-pixel clipping rectangle in this way since the physical device actually accepts integer coordinates to define this rectangle. Ultimately, I highly doubt you would notice any specific difference because of this. The only issue I can think of is with multi-sample enabled backbuffer formats in which for some reason it may be necessary to clip away specific sub-pixel samples rather than all or none of them. In this case your best bet would be to do away with the scissor rectangle and instead render a a quad into the stencil buffer representing your scissor rectangle, and then render your sprites using that scissor rectangle with stencil testing enabled.

Or, alternatively, and perhaps more efficiently, you could compute the screenspace transformation of the sprite quad vertices locally, and represent the scissor rectangle as 4 2D planes (nx * x + ny * y - d = 0) and clip away edges on the outside of the rectangle, and split edges that intersect it. This would also give you sub-pixel clipping accuracy but without the added fill-rate hit you might get for large scissor rectangles using the stencil buffer.





Re: XNA Game Studio Express Keeping game graphics the same size over different resolutions

Shawn Hargreaves - MSFT

The scissor rectangle clips post-transformed screen pixels, so that is inherently an integer operation. It can only either draw or not draw to a given pixel: there's no way to do that clipping on a fractional location.





Re: XNA Game Studio Express Keeping game graphics the same size over different resolutions

parlance

Shawn Hargreaves - MSFT wrote:
The scissor rectangle clips post-transformed screen pixels, so that is inherently an integer operation. It can only either draw or not draw to a given pixel: there's no way to do that clipping on a fractional location.

Except of course, the methods I just posted ;)





Re: XNA Game Studio Express Keeping game graphics the same size over different resolutions

parlance

parlance wrote:

For a large number of sprites this becomes inefficient because what are you actually doing is redundantly replicating the effect of modifying 2 elements of the projection matrix, and applying that transform using the CPU rather than the GPU which is bad practice where you can avoid it with any graphics card that supports hardware T&L. Depending on the overload, you would executing up to 4 redundant floating point multiplications per sprite, or O(n) complexity for the problem. The much more efficient way (O(1) )would be to add an overload to SpriteBatch.Begin that would allow you to explicitly specify the parameters that make up an off-center orthographic projection matrix, and while you're add it, save users the trouble of executing 2 redundant floating point adds per sprite for the added advantage of scrolling, and allow users to specify parameters that make up the view matrix as well (this could also include 'screen' rotation).

You wouldn't per chance have any plans to address this would you Shawn