Sprite sizes?

#1 Larger images take up more memory. Don't forget that you only have so much video memory and with 32-bit images they add up fast. For example 128 x 128 x 32 = 512 KB & 700 x 600 x 32 = 12.82 MB. Additionally, if you are only going to display at 32x32 pixels on the screen, you get no additional detail by shrinking a larger image. But this does mean that if you are using relatively few images and are displaying them at full resolution, there is no technical reason why you couldn't use larger images.

I hope that helps.

#2 Well my game is using 1024x768 because our statistics show that thats the resolution that 79% of people use. So we wanted to use 256x256x32 for the character sprite. ALso the 700x600 building is unanimated.

So basically every single 256x256x32 sprite would use like 4mb of ram? Is that a problem if alot of them are loaded at once...

#3 Where did you get that 79% number? Was there a survey someplace?

#4 Based on users who visit our website

#5 That's interesting. I'd like to know more about these numbers, but I haven't found much and I've been using 1280x1024 as the base resolution, but I'm concerned also about laptop screens with resolutions likes 1440x900.

#6 The thing I want to know is how to find 2d artists. It seems like noone really knows what to call art these days when your looking for it. If I say "looking for 2d artist" im going to get a very wide range of 2d art thrown my way.

http://www.youtube.com/watch?v=gI-V3Uw1b3U

What exactly is used to create modern 2d art. What exactly do you call it.. I hear lots of terms like vector, pixel, fractal or whatever else.

New to 2d art and getting hella confused trying to find artists who can create the art I need.

#7 Ok I just tried using a 128x128 sprite instead of the ninja from the platformer tutorial.

Question: The ninja was set to 5x5 pixels but obviously wasnt. Setting my sprite to 128x128 makes it really big, lags the engine and movement basically doesn't work. Whats up with this?

If someone draws me a 128x128 sprite... what size should it be in TGB? 5x5?

#8 When you say 5x5, do you mean that in terms of your game's measurements or in absolute pixel sizes?

#9 Well I assumed its pixel size...

#10 Well, a 128^2 sprite shouldn't be larger than 128^2 on the screen. Higher fidelity won't make it look any better, but will still cost memory. So if your sprite was to look 5x5 pixels, you should make it pretty small or put it on a sheet with other sprites.

#11 Well the original sprite was 32x32 but it was set to 5x5 in TGB's editor... somehow it still showed all the detail even when set to 5x5 wich leads me to believe TGB is lieing about the size of things.

#12 Torque doesn't do sizes in pixels, it does them in an internal sizing scheme using the scale and aspect ratio selected by the developer. In theory, this means you could actually make a grid of 32 pixel squares that measures just 32x24 in your internal measurements and each square could be 1x1 in size. In real measurements, it would be 1024x768. Torque itself isn't lying about the sizes, it's just a matter of which measurement system your using.

#13 Wait I dont understand this. So if everything is 1x1 then thats the real size? Whats the point of this size system or is it just for scaling? Now im really confused. This would explain why increasing the players sprite size to 128x128 from 32x32 had no effect on its scale in the game.. but still I dont really understand why I would want anything above 1x1? Is this feature there just to mess with my newbie brain xD

#14 No, it's there because it keeps things in scale despite resolution changes. Let's set up a simple scenario mimicking what we had before.

1. Our game's key resolution is 1024x768.
2. The entire game board is a tilemap made of 32x32 sprite files.
2a. We have 32 sprites horizontally.
2b. We have 24 sprites vertically.
3. Our sprite files are 32x32 pixels each.

If we were to change resolution to 1280x1024, we have to adjust our graphics.

Option A: Use more sprites: 40 horizontally and 30 vertically.
This means we'll now have more game map displayed at any one time. This actually could be bad, depending on how we've built our game. Quite simply, we're using an expanded viewport which could actually go off the levels.

Option B: Stretch (or shrink) our graphics to fit the new resolution.
We may be pushing more or fewer pixels, depending on how we resize things. Our viewport hasn't changed, which means the view presented to the gamer is fundamentally the same.

TGB prefers option B. The standard camera I believe is 100x75 units (not pixels, just arbitrary units). Regardless of my image's native size, telling TGB to draw something at 32x32 will take up roughly 1/3 of the screen horizontally and a bit under half vertically.

As a practical example, look in any .t2d file. You'll see that it creates an un-named t2dSceneGraph, sets the layer sort modes, and towards the bottom of the first paragraph you'll see what's germane to this conversation: 'CameraPosition' and 'CameraSize'. The value 'CameraSize' sets the scale for the viewport.

In a game with a resolution of 800x600, in an actual file, there is a level with the following attributes:
cameraPosition = "0 0";
cameraSize = "200 150";

This tells the engine that our viewport is 200 units wide and 150 high; it extends from -100 to 100 on the horizontal and -75 to 75 on the vertical. The center of the screen is 0,0. You could, if you wanted, put the cameraPosition in another location so that the origin is at the top left of the screen. That would result in only using positive numbers for your on-screen coordinates.

Although really, the window is 800x600. This means that every units in our game is 4 pixels wide and 4 pixels high. Since TGB can handle decimals, things can move 1 pixel by being moved 0.25 units. When we declare a new object and present its size to the engine, we'll use the internal scaling. Since we've established that our resolution is 800x600 and our viewport is 200x150, if we were to put an object at 0,0 and give it a size of 100x75, it would be 400 pixels wide and 300 pixels high.

That's really the best explanation I can give without graphics. If you need more help, feel free to IM or post your questions.

#15 Looking at another thread gave me a capital idea. Use the setscreenmode function to see it in action.

Set up a simple level with a few thing, then use:
setScreenmode(640, 480, 32, 0);

Then:
setScreenmode(1024, 768, 32, 0);

You'll be able tell that you're changing since those are windowed modes. The basic view will remain the same. You can also stretch out things, but since your CameraSize hasn't changed, you'll end up with a stretched view because your camera aspect ratio will still be 4:3. Playing around with that should help anybody understand how this all fits together.

#16 Ok so

1. Why don't I just make everything 1x1 so that its in scale. None of the art needs to be scaled because it was all made to work together.

2. What about backgrounds for the stage. What effect would a 8192 by 768 background have?
EDIT: Crashes TGB...

3. Whats the best way to create a level using handdrawn art. Should I use a background and then scatter smaller object (buildings, rocks, fence's, Tree's) around overtop the background?

#17 If everything is exactly the same size, you could make it 1x1 if you really wanted to do that. If the art is different sizes, you'll obviously have a big problem.

A background that big would be about 25MB in RAM. That doesn't sound like much, but it's actually a pretty big picture. Probably not a good idea. For what it's worth, and you can believe me or not, your not just crashing TGB with a texture that big. If you throw in anti-aliasing of any sort, you're going make things worse. Very few video cards can handle a texture that size. Nvidia's 8800GTX, which I use, can go up to 8192x8192 according to some sites, but I haven't even gotten around to actually testing it.

A level with hand-drawn art would best be done like a level with sprite-based art since you'd essentially convert the hand-drawn artwork into sprites.

#18 So how would I make a background that shows diffrent stuff as you move through the level?

#19 If you want to make games, you'll have to do some research on your own. So far, all of your questions are discussed in the tutorials and the documentation.

You'll have to learn how to make a picture move and probably how to use tilemaps if you hope to do it in an efficient manner. Honestly, your questions are bordering on ridiculous. The term "shows diffrent stuff" is unhelpful. Do you want it to scroll by at a fixed rate or move along with the player? Either way, a little research will make the answer quite clear. An auto-scrolling background is just a picture or tilemap that moves, one that moves with the player is only a little more complicated. If you want to use parallax scrolling, that's something a bit different. Either way, "shows diffrent stuff" is not descriptive enough to warrant spending time explaining it.

You say you have information from users visiting your site, that's really great. At this point though, you shouldn't be concerned with making your game. Focus on the fundamentals. If you wander off into making some game before understanding what you're, it'll be an unmaintainable disaster. Rather than trying to slap together some background and put it in some game, just make a little project or two with backgrounds so you can isolate the task and understand it well. Making games isn't supposed to be easy, it's a confusing amalgamation of individually complicated tasks. If you haven't taken the time to master things like properly displaying sprites, you're not ready to wander off to new things.

#20 Actually the only thing im having a problem understanding is 2d art. Nothing about scripting or programming confuses me much.

Its a vague question because my knowledge of 2d art is very vague. Also the tutorial does not explain anything related to backgrounds other than mounting a big image to your character and that just looks stupid anyways (a non moving background through the entire level).

All im doing is messing around and slowly learning. When I complete something I add the finished scripts into the a backup folder. For every one question I post here I complete many other things. Sofar I have finished dashing, double jumping, wall climbing, wall jumping, basic attacking with collision.

Now im just trying to get a handle on how 2d art works. I'm not using tile's, Im just trying to figure out exactly what to ask the artists to create. Basically none of the tutorials touch on the actual art side of things.