Game Development Community

1 to 1 pixel mapping, and camera stuff

by Shawn LeBlanc · in Torque Game Builder · 03/05/2007 (12:15 pm) · 3 replies

I'm trying to avoid having sprites and tiles "shimmer" when moving around on screen. This is probably because the textures they use are too big for the size they're being applied on. How do I figure out the optimal object sizes and texture sizes for my sprites and tiles? I have the impression that achieving a 1-to-1 pixel mapping to the screen would be best, but I'm not sure 1) how to do it and 2) if it's actually important.

Cameras have width and height values. I believe they're in world units. How to convert those values into pixel units? Does the actual area covered by the camera change depending on the resolution the game is run in?

Thanks!
Shawn

#1
03/05/2007 (1:02 pm)
Ok ... first ...

How large are your sprites compared to how large they are on screen?

If when you drop the sprite from the Create Tab into the Level Builder Scene you have to reduce it's size dramatically, then you know right away that your size is TOO LARGE ... your sprites should be sized appropriately to what you want them.

If your games intended resolution is 800x600, then design your sprites to fit into an 800x600 area at the correct size ... this would mean that a player might be 128x64 for example ...

'Sprites' do not have 'textures', they are just images -- granted, they may be considered textures technically behind the scenes in the rendering .. but there not 'textures' (textures are applied to 3D Objects, such as Shapes in TGB/TGE -- ie; DTS Objects, or DIF Interiors) --

If you want to have your game run at 800x600 and have a pixel-to-pixel unit scale, change your Design Resolution to 800x600, and change your camera size from 150x100 to 800x600 and your game movement will be in 800x600 'pixel-to-pixel' ratio ...

Changing the camera size more or less just helps you work with smaller numbers, I guess ... but is not entirely necessary. I've read in a few places that doing this alters performance, and not for the good, but I've yet to see this occur for me.

However, if your image is 256x256 and you drop it into an 800x600 resolution with a 150x100 camera size ... your image will render at 256x256 on the screen -- the ratio between resolution and camera size does not change the actual 'real' size of the image ... now, if you resize it in the level builder, thats a different story.

The reason for the difference in Camera Size and Resolution is that TGB uses a Relative Sizing system ... so you can run the game at 1600x1200 or 800x600 and have it look the same ... no resizing necessary by you, as the engine handles all the resizing for you. However, to achieve 'maximum quality' in your sprites, you'd have to design them first to run at 1600x1200 and have your design resolution set to 1600x1200 ... then allow the end-user to lower the resolution to allow TGB to 'shrink' your sprites to reduce the quality -- for a 2D game, this is totally not necessary -- unless you have need a for a higher resolution, don't use it, and don't even offer it as an option ... 800x600 for most 2D games is suffecient ... for adventure style games with fancy artwork and what not, 1024x768 or 1280x1024 maybe ... with the option to go 'lower' ... However, I'd almost certainly do those resolution changes by using a Package and storing all your datablocks for the sprites in a Resolution_1024 package or something, so that when you activate the package at startup, you load the 1024 optimize images stored in a /data/images/medium/ structure, or something ...

#2
03/05/2007 (1:49 pm)
> How large are your sprites compared to how large they are on screen?

Most of the images I use for sprites are 128x128. They look okay to me that way, for the sprites/tiles I'm using them on, but I'm not sure if they could be improved. They might be too big. I'll have to experiment a little.


> If your games intended resolution is 800x600, then design your sprites to fit into an 800x600 area at the
> correct size ... this would mean that a player might be 128x64 for example ...

Is there any way a user can change the resolution? I can certainly intend my game to be run in a certain resolution, but what happens if they run my game fullscreen on a widescreen LCD? My own LCD is 1600 x 1050, so I have to design my game without assuming it's in a certain resolution or screen ratio.

> Sprites' do not have 'textures', they are just images -- granted, they may be considered textures technically
> behind the scenes in the rendering .. but there not 'textures' (textures are applied to 3D Objects, such as
> Shapes in TGB/TGE -- ie; DTS Objects, or DIF Interiors) --

I meant it in the "behind the scenes in the rendering" fashion. Considering Torque uses 3d rendering, sprites and tiles are just textured 2d quads mapped to screen space.
#3
03/05/2007 (2:29 pm)
@Shawn, last I checked, LCD's could be 'down sampled' and they'd "fake it" --

Also, designing your game to fit onto a widescreen LCD and be 'widescreen' vs allowing your game to be played at fullscreen without widescreen are two totally different things ...

If you want the game to have a widescreen feel to it when it's played at a widescreen resolution, you've got quite a bit of thinking to do in your level design, depending on your game, that is ...

As for the size ... 128x128 tiles seem fine ... so long as your intention is not to reduce them in size during game play --

What I do, to ensure my tiles in a tile-layer are sized 'properly' is drop a t2dStaticSprite into the level and look at it's Size X/Y values, then set my Tile Layers Tile Size X/Y to those values ... so long as the size when I drop it initially is 'good' ... if it's too big or too small, I fix it and bring it back in again ...

As for changing the resolution, look at the OptionsDlg.gui ... you do it in your game the same way TGB does it in the Level Builder ... you can even re-use the TGB Default Options Dialog (OptionsDlg) if you want too ... I actually made a modified copy of it that removed quite a few things ... like Key Mappings ... depending on the game prototype I was working on, and renamed it to OptionsDialog rather then OptionsDlg ...