0
\$\begingroup\$

I am embarking on a massive (image quality, file size, high frame count) project. I am still working on the basic engine, but have a big question that I would like answered before I begin testing. (It requires a lot of work to test, and possibly fail and have to recreate all sprite sheets, so an answer can help me save weeks of work if I'm wrong.)

The game is entirely in 2D, with 2.5D view. I want to eventually have 40 animations, which all have to be animated in 8 directions. I want each direction/animation to have its own sprite sheet. This equates to hundreds of spritesheets and thousands of files.

Before the obvious solution "Degrade quality for file size!" I would like to take every step possible to prevent degradation of quality, animation frame count, and image size.

Before my solution, one character was 350MB in ram (LOL!) but that was fixed quickly down to 10-20MB per whole character. That is...if I were to load ALL (40) animations in ALL directions (8). So if I were to load 320 sprite sheets into memory, it was going to be a ridiculously large amount per character in ram.

MY QUESTION IS THIS:

How much (of total sprite sheets) should I have loaded into memory at any given point?

Can I get away with loading ONLY the CURRENT spritesheet (Direction + Animation) into memory? Is modern hardware fast enough to constantly swap textures on the fly?

Players could, at any moment, change direction. This would change the entire spritesheet. Same for animation. So within a split second, the game would have to load a specific new spritesheet, unload the old one (or unload it eventually), and render all within a split second. This would have to be done once for every character, anytime they animate or change directions in a real time game.

Fortunately, the amount of characters on screen at once will be limited by the fact the game is 2D, but I'd prefer to be able to cram in the maximum amount without performance issues on a mediocre computer.

Is texture swapping, file loading, instant rendering from HDD and memory-- all so fast with modern hardware that I wont even need to worry about ANY of this?

I just dont want to work on all of these spritesheets (from thousands of images I already have) only to find out my performance will be horrible and have to redo all spritesheets. Even to test, since I have a layering equipment system, is a time consuming task for spritesheet creation. That is, until I find a solution to process those faster (automation, i do it manually currently, using a program)

Improve this question
\$\endgroup\$
8
  • 3
    \$\begingroup\$ You're talking about using gigs of ram to hold the animations of one 2D character? Yes your performance will be horrible. Even a modern bleeding edge computer is going to choke. I'm not sure what the point is either, you're going to be loading pixel information for far more pixels than a user could even display. Why load 10,000 pixels for a sprite that is only going to be displayed on 50 pixels of screen space? Beyond that, this question is overly broad and depends on far too many variables to be accurately answered. \$\endgroup\$
    – House ♦
    Apr 30, 2012 at 17:39
  • \$\begingroup\$ If you really wanted to go hog wild with it you can look into sparse virtual texturing (sometimes also called megatexturing) silverspaceship.com/src/svt But it's likely that you don't need to go that far. \$\endgroup\$
    – Tetrad
    Apr 30, 2012 at 20:05
  • 1
    \$\begingroup\$ No, I am NOT talking about using gigs of ram to hold aniamtions of one 2D character. I am talking about what created my concern (gigs of ram) before finding a possible solution (cutting it down to only 10-20MB per whole character) but with it comes some drawbacks (depending on how fast computations can calculate spritesheet creation). My first question is in a 2D game, such as Diablo 2 or Baldurs Gate 2, or a 2D or 2.5D game, how many spritesheets or animations are typically loaded into memory per character? All of them? Only the current? Only a few (Current + Last few)? \$\endgroup\$
    – user15858
    May 1, 2012 at 2:27
  • 1
    \$\begingroup\$ Individual parts is actually the biggest problem in memory. A single part (a single character sprite) is about 1-3MB in memory with all my animations it cannot possibly exceed 20MB for a single character. If I were to NOT compound all the paperdoll technique (layers of images for equipables) and do them in pieces, that is what would exceed 350MB per character. I have to either not load so much in memory, or have the game create compounded spritesheets on load from a series of layered images. My only fear is that this will be too slow to allow fast equip/unequip actions. \$\endgroup\$
    – user15858
    May 6, 2012 at 13:03
  • 1
    \$\begingroup\$ A single equip requires it to compound thousands of images again to form the new character sprite. I think though this isn't a problem because texture swapping is handled quick enough to allow for only required spritesheets to be loaded in memory. The rest stay on the HDD. \$\endgroup\$
    – user15858
    May 6, 2012 at 13:03

4 Answers 4

Reset to default
5
\$\begingroup\$

Swapping textures will kill your performance. Modern hardware has only gotten more susceptible to this problem, not less, as the speed and power of the shader units and video RAM are growing much faster than the speed increases of the bus between system RAM and the GPU.

The only sane approach is to cut down your texture sizes, or generate procedural sprites (using vector art). As another reply stated, there is absolutely zero reason to have huge textures for sprites that will only be a few dozen pixels tall on the output. It sounds like you're looking for a solution to a problem that you're imposing on yourself for no reason.

Also, you will usually have better looking art if you design for the target pixel size than if you downscale a high-res texture.

Improve this answer
\$\endgroup\$
20
  • 4
    \$\begingroup\$ Indeed - "It sounds like you're looking for a solution to a problem that you're imposing on yourself for no reason" \$\endgroup\$
    – House ♦
    May 1, 2012 at 1:20
  • 1
    \$\begingroup\$ "As another reply stated, there is absolutely zero reason to have huge textures for sprites that will only be a few dozen pixels tall on the output." Zero reason to have spritesheets as opposed to tiny single images? This is contrary to what I read on here about spritesheets vs single images. (Always load a huge image than to load a lot of tiny ones). \$\endgroup\$
    – user15858
    May 1, 2012 at 2:29
  • 1
    \$\begingroup\$ Any "problem" I impose on myself is obviously for a reason, such as a game feature or quality. If there was no reason, there wouldn't be a problem lol. \$\endgroup\$
    – user15858
    May 1, 2012 at 3:31
  • 2
    \$\begingroup\$ Older games didn't use OpenGL or modern D3D, didn't store textures in VRAM, and were basically just accelerated blitting engines; this is not at all how modern hardware works. The acceleration methods used by old games are literally not even in new hardware anymore. Your question was whether there's be a performance hit doing things the way you describe - the answer is yes, a big one. Also rememer that modern GPUs do allow compressed textures, which can help a lot. Look into trying DDS textures instead of JPGs (no game uses JPGs - worst possible texture format for a game). \$\endgroup\$
    – Sean Middleditch
    May 6, 2012 at 19:08
  • 2
    \$\begingroup\$ "It works" proves nothing. Swapping textures means transferring things over the bus. This is slow; you're just lucky and not stressing it much; common for little hobbyist games. Doing this in general is bad juju, and that is plain fact. Modern hardware is plenty "powerful", so longed as it's not abused too hard. You're only abusing it a little. :) and yes, disk transfer is a major problem, disk is much slower than anything else; finding the balance between disk and runtime speeds is part of what we get paid to do. \$\endgroup\$
    – Sean Middleditch
    Jan 28, 2013 at 22:10
2
\$\begingroup\$

You need to prototype this, with placeholder data.

Create a simple program that outputs a sprite sheet where each frame consists of text describing what it should be (e.g. "Sprite 7 frame 5"). Use that to create the final number of sprite sheets you're going to end up with, and see how well that runs a test scene with everything loaded into memory.

If it runs ok on your target hardware then go ahead and create your sprites, otherwise you'll need to adjust your plans or optimize the code to make it work.

Improve this answer
\$\endgroup\$
0
0
\$\begingroup\$

Consider making the graphics quality configurable in the game. For example you could set a target for the "high end" of hardware you want your game to work on, and design your graphics and animations around that target. Then provide graphics quality settings that let you, say, use 50% scaled versions of the sprites, or use every other frame of animation.

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

If you're only targetting Windows/Mac/Linux, I wouldn't worry about HDD space.

Some of the most popular AAA titles are 20GB+ or larger.

If it's an online game, a singleplayer RPG, or a MMORPG, you could easily introduce a small client with less content (6-8GB max) and then introduce "expansion packs".

What people don't realize is that some games have a large client of 6+GB, and the expansions grow it to over 20GB.

The key though is to allow accessibility without having to download all 20GB of content. Example, WoW's streaming client vs Vanguard: Saga of Heroes. WoW is actually larger than the 20GB beast of Vanguard, but the former can be played in an hour of downloading on Cable, while the latter can take days for people to download.

Your problem is definitely going to be memory, as HDD space isn't a real requirement, nor are the draw calls for 2D graphics. Your memory problem will occur long, long, long before any HDD space (a virtually non-existent problem in modern streaming tech) or Rendering problems.

Keep the number of characters loaded small. Refrain from excessively large spritesheets. It is better to have a Dragon composed of 4+ sprites (chopped up dragon pieces) or stream single images (no sprite sheet at all for Dragons) than to load massive sheets.

Trying to animate a 4000x4000 sprite sheet dragon will make your game slow. Animating 10, 400x400 sprites will not. As long as your memory usage doesn't explode, your game should have no problem. As a 2D game, I can't imagine that many characters being on screen at any given moment unless the camera is zoomed out. If the camera is zoomed out, perhaps having smaller sprite images for that viewpoint would be better. It would create a ton more HDD space, but would help with memory dramatically.

Also, see about loading RGBA4444 instead of RGBA8888 to keep memory even lower. The former can still result in beautiful sprites.

Improve this answer
\$\endgroup\$

You must log in to answer this question.