I'm in a club, basically the main guy. Problem is I'm a programmer and I'm not sure about the art stuff. I remember once when I was toying around I grabbed some ripped sprites and instead of being one big sheet they were each individual images. I was wondering if that was just the game or if that was how it's done now a days for higher res sprites.

The game was Blazblue. I'm not sure the resolution of the characters. But how are character sprites handled for higher resolution games?

So like the difference of Street Fighter 2 to Street Fighter 2 Turbo HD Remix. Are the sprites made differently?

Seeing the blazblue one made me think it actually loads all the images into an array and then plays the correct sequence in the array based on the action being taken. But then I was reading up on a simple 2D game and that a sprite sheet holds all the sprites and that the game just reads the whole thing and renders only specific part of the sprite sheet based on the pixel position.

Sorry if this is the wrong area. I thought this might belong in programming section but I think it's more art side since I need to tell my artist how to make the characters.

You can do either individual sprites or spritesheets, but a terrible amount of information says that spritesheets are generally faster.

Really? I haven't actually looked too deep into which is faster or the pros or cons of either. But I just assumed spritesheets would be faster because it's got all the animations loaded while individual sprites would have to be loaded separately.

Check out this two-part series as a fun way of learning: http://www.codeandweb.com/what-is-a-sprite-sheet.

The main difference in sprites between blazblue and sf2 is that sf2 uses hit boxes and IIRC blazblue uses pixel perfect collision. Meaning blazblue looks for actual non-alpha parts of the sprite that are designated as damage parts.

I was reading up on a simple 2D game and that a sprite sheet holds all the sprites and that the game just reads the whole thing and renders only specific part of the sprite sheet based on the pixel position.

Well, you are warm. If the source code of the game is written correctly then a game engine ( game engine is layered between game source code and hardware) will handle the memory issues involved in your hardware. The whole sprite sheet should be held in memory somewhere and therefore ready at an instant under calls from the game source code. The game engine will do the actual lower level memory management and render the sprite to screen once a call is made from the game source code to do this.

Games in the 1980s thru 1990s relied on game source code to handle memory issues and most other areas of the game. The huge difference now is that most popular and profitable games usually have a game engine layer between the game source code and the hardware, whereas more primitive games decades ago relied totally or mostly on game source code. As game source code became larger and more complex, the need for a game engine to standardize lower level coding even across many games became a stronger demand. Since art assets often have a lot of lower level coding to handle them, a game engine to standardize the methods of game development in lower level coding will free the developer to spend more time on upper level coding such as gameplay functionality. Some developers will insist that this is an over-simplification, but I drew the principles this way for the sake of clarity in explaining the boundaries which might be there. Such boundaries can be a good thing because compartmentalization or modules of coding generally make everything better for the developer, especially a team, and avoid much of the "spaghetti" coding which is so very difficult to extend, integrate, and debug.

Clinton