Can't decide...

OK, in my 2D vector graphics lib, everything (vertex coords, scale, etc.) is expressed in world units, not pixels, of course.

Now, when transforming everything from world to screen (pixels), there's some loss of accuracy. For example, if I have a box with one edge very close to the edge of another box, my calculations correctly determine that the boxes aren't colliding. However, when actually drawing the boxes, they look as if the two edges are actually overlapping.

I can't decide whether to just live with this or tweak things so collisions are only reported if the visual representation shows a collision.

However, there's a problem if I go with the onscreen representation: a low-res screen mode might show the box edges overlapping, but when switching to a higher res, there may be a visible gap.

Suggestions?

I'd say go with what the player sees on screen, so if it visually shows a collision, then it's a collision.

But... Couldn't you tweak the on screen stuff so if there's no *real* collision, but on screen shows there would be then reduce the on screen dimensions accordingly so it shows no visible collision?

Qube, the trouble with that is that the actual-to-screen inaccuracy increases, the lower the screen res gets.

For example, a player could pause a game with their ship right next to a bullet, change to a lower screen res only to find there ship is now hit by the bullet. Boom!

Difficult to say, can you post some visuals? I'm assuming you're using 2d in 3d? Could you use a scaling factor in your collisions depending on the screen res? Is it likely for someone to want to change screen res mid game - or are you talking about windowed mode?

It means your translation from pixel coords to screen coords is screwed up. There should be no inaccuracy.

Here's what I mean. This is pure 2D BTW, not 2D in 3D. The output is screen res independant.


As you can see, the lower res screen shows a collision, the higher res one doesn't.

Leadwerks: I don't know what you mean. There's bound to be inaccuracy when the screen doesn't have sufficient res to accurately represent the data's resolution. It'd be like saying an angled line drawn on the screen shouldn't be any less jaggy when drawn in a lower res.

Are you sending the same coords regardless of resolution?

I'm basically doing this:

vert_x# = (mesh\vert_x[i] * global_scale_x) * vl_unit_size_pixels

Where global_scale_x is the entity's global X scale, and vl_unit_size_pixels# is the size of a world unit, in pixels.

basically it seems you lose accuracy with lower resolutions. Ie the higher resolution screen can display the scene accurately but because each pixel on the lower res screen each pixel is more than one line you get overlap.

TBH, that could get really messy and I'm not sure I could get it to work meaningfully, anyway.

EdzUp: Yeah, that's the problem. It's unavoidable.

I basically need to decide:
a) Use world coords representation which is consistent regardless of screen mode, but the screen representation may not be 100% accurate.
b) Use the screen representation which is visually accurate, but may not be consistent between different screen modes.

I don't think the low res picture looks too bad. Sure, is shows a visual collision even though mathematically there isn't one. Unless your talking about a really noticible amount of penetration .. i.e > 1 or 2 pixels then I personally wouldn't worry about it.

That said, would it not be easy enough for you to allow the use of both coordinate systems, with option (b) done by setting the vl_unit_size_pixels to 1.0?

Stevie

I'd go with B for a single player game and A for a multiplayer game.

Only thing worse then not being able to do something that looks obvious is having someone else able to do something that looks impossible.

I don't see the problem frankly. If those boxes were filled with graphics - unless the graphics are filled boxes - the overlap will not be noticeable anyway. I would use A in all situations.

I do actually have that option in now - there's two functions; one to transform to pixel coords (for rendering), and another to tranform to world coords. I'm currently just transforming to world coords for line-to-line intersection checks etc. - it's a tad faster as it removes the multiplication by vl_unit_size_pixels. This is where the error creeps in but, as I've said, using the screen transformation instead still isn't perfect. :)

Whichever way I handle this, it'll be consistent so I shouldn't have any problems in that regard. :)

I'm beginning to think that. There doesn't seem a way to get the best of both worlds so I think I should just stick with what I have now. I'm just having trouble making decisions today. :P

Thanks all for the input!

Set your basic coordinates at a 1 to 1 ration with the smallest resolution you allow. Then zoom from there.

Not sure I understand what you mean, TaskMaster. Besides, there is no smallest res I allow - windowed mode can be set to any res. The number of world units that span the screen horizontally can be set to anything which remains constant whatever the res, to maintain a res independant display.

Is it because you're drawing to integer coordinates and not antialiasing your lines? If the boxes are not actually overlapping, as in hires, then even the lowres presumably should show some trace of the white of the larger box blended in with the red of the smaller box, all within one pixel. That you have total overlap of red replacing white suggests you aren't drawing properly.

I absolutely would not do this as you're essentially allowing users with different screen resolutions to inhabit different worlds -- it will bite you on the ass eventually.

Assuming that collisions are bad for the player (as they usually are), there visually appearing to be a collision where there actually isn't one will do nothing more harmful than give the impression of squeezing past something by a hair's breadth. Every shooter with hotspots does this and I wouldn't worry about it.

Everything is modelled with floats, of course, but they have to be converted to integers at render time (i.e. pixel coords). Anti-aliasing doesn't come into it as there isn't any - this is pure 2D.

Indeed - some good points. I have decided to stick with using the mathematical representation and just leave it to the renderer to display the world as accurately as it can. I have yet to see a visual error of > 1 pixel so it should be fine.

Thanks.

Well theoretically, unless your maths is wrong, it should be impossible to see an error >1 pixel in any screen resolution.