Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your feedback on a survey! Each completed response supports our community and gives you a chance to win a $25 Amazon gift card!


Why is the first spritesheet laid out like this? Seems harder to read the sprite by a sprite reader system


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
21 replies to this topic

#1 warnexus   Prime Members   -  Reputation: 1505

Like
0Likes
Like

Posted 19 April 2014 - 10:10 AM

I'm not sure if this was the actual spritesheet from the NES title, Metroid. But if it is why are all the sprites from the first sprite sheet laid out this way? Would it not be harder for a spritesheet reader to read through this spritesheet because the sprites you want to read are not linearly laid out like the second spritesheet is?

 

metroid_zps0a136337.gif

 

metroidsnes_zps90477a4b.gif

 

Would the best spritesheet be the one like the second sprite sheet where everything is tiled correctly(same width and height for each sprite) and laid out in a linear fashion?


Edited by warnexus, 19 April 2014 - 10:12 AM.


Sponsor:

#2 ApochPiQ   Moderators   -  Reputation: 16423

Like
0Likes
Like

Posted 19 April 2014 - 10:15 AM

I'm not sure it really makes much difference. The regions are just rectangles either way. I could see a tiny advantage in the second approach where you don't have to store each rectangle separately (since you can compute them all from known dimensions)... but that doesn't help much if you only have memory for so many pixels and you need different-sized sprites to fit onto a single bitmap.



#3 DiegoSLTS   Members   -  Reputation: 1940

Like
7Likes
Like

Posted 19 April 2014 - 11:23 AM

NES games didn't have a spritesheet, there's no image stored from where to read the sprites. Sprites (or tiles) where either 8x8, 8x16 or 16x16 pixels, and those sprites are combined (if one sprite is not enough) to draw the character, or enemy or whatever is not the background. For a door for example, there's probably one sprite for the square, one for the rounded corner and one for the door center, and those are used to draw the full door.

 

Also, the sprites are not the final images, only some information is stored, and the final color you see is computed using the "pattern table". In the door example, there's only one square, and the final color is read or blue when needed.

 

This is how sprite data is stored and used: http://hackipedia.org/Platform/Nintendo/NES/tutorial,%20NES%20programming%20101/NES101.html#sprite

 

For SNES games this is similar, old games where too hardware dependant and the hardware had lots of limitations and "hacks", so things like drawing, moving, collision detection and almost everything else was more complex than today.


Edited by DiegoSLTS, 19 April 2014 - 11:28 AM.


#4 Icebone1000   Members   -  Reputation: 1156

Like
4Likes
Like

Posted 19 April 2014 - 11:30 AM

The second one arent even rects, its insane, as each sprite would need to be a different mesh.

 

I have my own texture tool where I can pack a bunch of sprites into a single atlas, it saves each 'frame' uv rect to a file. So the order they show up are random.

 

Note that for animated sprites theres a problem with trimming transparent spaces, as you need to keep the frames from a single animation relative, so if in a frame the character is with arms opened and in the other closed, the frame would bounce as the position of the character wouldnt change, but the frames have different sizes. (generally ppl let transparent areas untouched, with no trimming. In my engine each animation frame have an offset to compensate, so my texture tool do the trimming and computes this offset needed to keep the animation correct, based on the amount removed from each side).


Edited by Icebone1000, 19 April 2014 - 11:34 AM.


#5 warnexus   Prime Members   -  Reputation: 1505

Like
0Likes
Like

Posted 19 April 2014 - 11:47 AM


'frame' uv rect to a file.

 

What is a uv? 

 

Also, what do you mean by atlas? Do you mean a map?


Edited by warnexus, 19 April 2014 - 11:47 AM.


#6 Icebone1000   Members   -  Reputation: 1156

Like
3Likes
Like

Posted 19 April 2014 - 11:54 AM

 

'frame' uv rect to a file.

What is a uv? 

 

Also, what do you mean by atlas? Do you mean a map?

UVs are the texture coordinates, from 0.0 (top left) to 1.1 (bottom right). Is how you get a portion of the texture.

An uv is specified for each vertex of the mesh you want to draw. Is how you map a texture to a mesh.

In the case of a sprite, you have a quad (or 2 triangles), means 4 points, so you have 4 points and 4 uv coords.

 

A texture atlas is a texture inception ;D. When you take a lots of texture and merge into a single texture (like a tileset or sprite sheet). This is good for performance as changing texture is expensive, so if you manage to have all images possible into a single texture, you will never remove the texture from the GPU memory, win \o/.



#7 Strewya   Members   -  Reputation: 1589

Like
3Likes
Like

Posted 19 April 2014 - 01:04 PM

The second one is not a (usable) spritesheet. It's probably just frames of the character ripped out from the game and stored in a single texture.

Note the first row, frames 2 and 5: clearly of different widths. This is not a big problem, as you can just store each individual frames width in a descriptor file.

Note the last row, how frames 2-4 overlap each other, so you cannot take a AABB rect of just one frame without having something leftover from the other frame. This is what gives it away as not being an actual spritesheet for use in a game.


Edited by Strewya, 19 April 2014 - 01:04 PM.

devstropo.blogspot.com - Random stuff about my gamedev hobby


#8 warnexus   Prime Members   -  Reputation: 1505

Like
0Likes
Like

Posted 19 April 2014 - 07:17 PM

 

What is a uv?


Also, what do you mean by atlas? Do you mean a map?
UVs are the texture coordinates, from 0.0 (top left) to 1.1 (bottom right). Is how you get a portion of the texture.
An uv is specified for each vertex of the mesh you want to draw. Is how you map a texture to a mesh.
In the case of a sprite, you have a quad (or 2 triangles), means 4 points, so you have 4 points and 4 uv coords.

Are the uv coordinates necessarily required for 2D game programming or is it mainly used for 3D game programming? Because when I programmed my 2D rpg I never needed to worry about uv coordinates. So uv coordinates are specified to save memory?



#9 Icebone1000   Members   -  Reputation: 1156

Like
1Likes
Like

Posted 19 April 2014 - 07:36 PM

UVs are necessary for "sampling" (grabbing texture pixels on shaders) textures on both direct3D and openGL.

 

Theres no way around it, its not to save memory, its for accessing the texture pixels (more correctly, texels, as pixels are on the screen).

 

So if the software/lib you used where using one of those apis,  they are handling this for you.

 

Note that theres no "2D" concept on those apis, GPUs are rasterizers that read vertex data to shaders, shaders will work on that data and output to render targets (textures displayed on the screen).

 

The "3D" or "2D" is all on the api users responsibility, its all about transforming points with matrices. Those points are rasterized to the screen accordingly with the topology specified on the api (lines, triangles lists, etc.).

 

So, if theyr necessary for 2D game programming depends on what level* you are, if you using those apis directly you certainly need it. If not, dont worry, its being handle for you.

(*level as in low-level / high-level, not as in beginner / advanced )

 

--

 

Now, to draw things without those apis these days, I dont know if its even possible..Even windows GDI uses direcX underlying. So I dont know...Im curious, how Flash applications are drawn?? o.o anyone knows? Where are the vectors translated to pixels?

 

-edit-

http://help.adobe.com/en_US/as3/mobile/WS08cf58784027fd117735d34612d0a8759d1-8000.html

 

Crazy, flash is pretty damn fast considering the rendering madness it have to go trough


Edited by Icebone1000, 20 April 2014 - 07:15 AM.


#10 Alpha_ProgDes   Crossbones+   -  Reputation: 4692

Like
0Likes
Like

Posted 19 April 2014 - 08:17 PM

The second one is not a (usable) spritesheet. It's probably just frames of the character ripped out from the game and stored in a single texture.

Note the first row, frames 2 and 5: clearly of different widths. This is not a big problem, as you can just store each individual frames width in a descriptor file.

Note the last row, how frames 2-4 overlap each other, so you cannot take a AABB rect of just one frame without having something leftover from the other frame. This is what gives it away as not being an actual spritesheet for use in a game.

 

Thank you. I've seen sheets like this before (the 2nd one) and have always wondered how games even pull the sprites from there.


Beginner in Game Development? Read here.
 
Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
 
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts Posted Image
 
Spoiler

#11 L. Spiro   Crossbones+   -  Reputation: 14447

Like
1Likes
Like

Posted 20 April 2014 - 03:13 AM

As Strewya mentioned the bottom one has no purpose since almost all the images overlap. Whoever made that seems to enjoy wasting time making things no one can use.

As ApochPiQ mentioned it makes no difference since they are just texture coordinates. Why does a computer care if they are laid out horizontally? Humans care about that, not computers.
However the second one (if it was valid) is laid out randomly (as apposed to systematically as in the first one). A computer does actually care about numbers, and numbers that round off to powers of 2 are healthy for a computer, so the first one would be better. All the coordinates are divisible by 8, 16, 32, etc. Floating-point numbers are not always precise in computing so you have to care about the UV coordinates in any texture atlas.

DiegoSLTS is incorrect in saying that texture atlases did not exist in old days. Since the dawn of time texture swaps were expensive so texture-atlasing was one of the earliest and most primitive optimizations there was. Yes, they only read 8×8 blocks from them, so drawing Mario took 2 calls, but the calls read from the same texture. Mario’s head would only be in 1 8×8 block, then a bunch of different lower 8×8 body parts. It would all still be part of the same texture atlas.


L. Spiro


Edited by L. Spiro, 20 April 2014 - 03:46 PM.

It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#12 Satharis   Members   -  Reputation: 1307

Like
3Likes
Like

Posted 20 April 2014 - 03:59 AM

DiegoSLTS is incorrect in saying that texture atlases (did I mention that “sprite-sheet” is a term reserved for the uninformed?) did not exist in old days. Since the dawn of time texture swaps were expensive so texture-atlasing was one of the earliest and most primitive optimizations there was. Yes, they only read 8×8 blocks from them, so drawing Mario took 2 calls, but the calls read from the same texture. When newbies take screenshots and put together texture atlases (or as monkeys call them, “sprite sheets”) they may use whole characters in each sprite (that is why they are monkeys amateurs)

I must be a monkey then because I much prefer the term sprite sheet to texture atlas, not to mention texture wasn't(as far as I know) a term even used until about the time they invented the first primitive texture mapping to 3D geometry.
 

but professionals are much more efficient. Mario’s head would only be in 1 8×8 block, then a bunch of different lower 8×8 body parts. It would all still be part of the same texture atlas.

I'd have to call you insane here, there was nothing "professional" about the folks who developed mario, in fact mario was developed at a time where software(games in particular) was in such infancy that a lot of basement hackers had the same or better knowledge and skills than people working in offices with others. Really, Mario Bros came out, what, 9 years after Nintendo even got into video games at all? Heck it was Miyamato's like, 7th game he even worked on.

Not to mention the need to take such minimalistic approach to blitting had nothing to do with them wanting to be efficient it was because space was such a commodity that it made way more sense to split up characters into fragments instead of copying entire sprites for each pose.

These days there isn't much practical reason to not having entire character poses as a single sprite on a sheet. A lot of things done in early games were either to save work or for practical efficiency. There's a reason that almost every 2d game has side views of characters being mirrored(amazing how Link always holds his sword facing you!)
 

Did I mention that “sprite sheet” is a term that apes use to refer to inefficient texture atlases?
We are not apes on this site. We range from enthusiastic to authoritative, and we know better than to use child terminology.

My what amazingly aggressive and insulting wording for no real reason. You're also completely wrong there are a large number of people here that are either complete amateurs, indies, develop rarely or even are just people that stumbled in here from Google. I wouldn't even hold all the moderators to the standards of an AAA developer or something, because it just isn't true.

That said there are a lot of talented people on here and at the least quite a number that have decent knowledge on coding/general game development subjects.

Edited by Satharis, 20 April 2014 - 04:05 AM.


#13 haegarr   Crossbones+   -  Reputation: 4608

Like
2Likes
Like

Posted 20 April 2014 - 05:15 AM

It should be mentioned that "sprite" nowadays does not necessarily mean the old school image rectangle. Advanced sprite techniques exist that allow for lighting effects, for example. There is also a technique that allows for animation by mesh morphing. The game made by using this is one about zoo animals; I currently do not remember its name. This technique is actually based on irregular meshes and hence would principally allow for an "overlapping" packing like in the 2nd atlas. However, that technique also requires a higher texel resolution than those shown in the OP to look good. (In other words, the 2nd atlas is probably not an example of this technique.)

 

Using irregular bounding boxes is also not exotic these days. Texture packers usually export a file besides the texture, wherein the clips are stored by name/index and texel co-ordinates. However, the usual texture packers still deal with AABB only, even if they support bin packing.

 


Please stop calling them “sprite sheets”. It’s an insult to the industry.

Well, this is interesting. In the world of perhaps not exactly professional 2D game makers there are many examples of tools and libraries that actually use the term "sprite sheet". There are for example Texture Packer, Zwoptex, cocos2d, and perhaps most noticeable Flash (at least in CS6). So the term is effectively introduced in the pre-industrial phase.



#14 jbadams   Senior Staff   -  Reputation: 19453

Like
11Likes
Like

Posted 20 April 2014 - 06:12 AM


By the way, it’s a texture atlas, not a sprite-sheet.

[...] (did I mention that “sprite-sheet” is a term reserved for the uninformed?) [...]

Did I mention that “sprite sheet” is a term that apes use to refer to inefficient texture atlases?
We are not apes on this site. We range from enthusiastic to authoritative, and we know better than to use child terminology.

Please stop calling them “sprite sheets”. It’s an insult to the industry.

 

Don't you think that's a bit of an extreme reaction?  Not everyone here is an industry professional, and the term "sprite sheet" is common and well understood.  The use of a common (if perhaps less technically correct) term is hardly "insulting" enough to warrant four separate mentions in your post.



#15 stupid_programmer   Members   -  Reputation: 1242

Like
1Likes
Like

Posted 20 April 2014 - 11:04 AM

I must work with a bunch of monkeys as I've heard sprite sheet and texture atlas used interchangeably for my entire career.

 

The Samus sheet might be an TexturePacker output image.  As I recall it can trim transparency from source images and give you an offset to place the trimmed image inside the full sized frame.



#16 Oberon_Command   Crossbones+   -  Reputation: 1975

Like
2Likes
Like

Posted 20 April 2014 - 11:55 AM

I've actually heard the terms "sprite sheet" and "texture atlas" used to refer to different things. A "texture atlas" is simply a collection of textures packaged into a single image. A "sprite sheet" is a texture atlas which is specifically used to store sprite assets for a game object (like a character) and has the additional restrictions that each of the sub-images are the same size and are laid out in some regular fashion to improve the efficiency of animation frame lookup. For what it's worth, I didn't hear the term "texture atlas" until my first industry job, where they were used for packaging custom GUI element textures together. I've never heard "texture atlas" used in the context of sprite animation.



#17 L. Spiro   Crossbones+   -  Reputation: 14447

Like
5Likes
Like

Posted 20 April 2014 - 01:27 PM

Don't you think that's a bit of an extreme reaction?

Yes.
I’m not even sure why I got so up-tight about it.
A bit of a bad mood at the time yes but I don’t tend to fly off my rocker just for that. “Sprite sheet” is a term I also tend to use sometimes, so I am not sure how calling people apes ever came out of me. My day was bad but not that bad.


My apologies.


L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#18 Kryzon   Prime Members   -  Reputation: 3314

Like
0Likes
Like

Posted 20 April 2014 - 11:42 PM

can i call it sprite atlas

#19 jbadams   Senior Staff   -  Reputation: 19453

Like
3Likes
Like

Posted 21 April 2014 - 12:25 AM

blocker.gif

Alright, I think the mostly off-topic "Sprite Sheet" vs. "Texture Atlas" discussion has gone on long enough, all further replies back to the original topic (sprite sheet/texture atlas layout) please! smile.png



#20 dejaime   Crossbones+   -  Reputation: 4119

Like
1Likes
Like

Posted 21 April 2014 - 10:55 AM

The second image is impossible to use. Ok, maybe not impossible, but a pain to do so. All the frames overlap each other, and it is not just a matter of copying a rectangle.

 

If you tried to copy the rectangle for the second frame of the "running animation" it would also render the foot from the first frame and the gun from the third one. So you'd need to create a mechanism that ignored these parts at runtime or erased them by actually removing the overlaps when loaded or something like that.

 

About the first image, it does have arbitrary positioning, but that can be easy to solve simply by storing the information you'll need, in this case the offset and size of each frame, for example:

PlayerRunning		#The Animation Name
3			#The total number of frames
(306, 234)(350, 278)	#The first frame, start and end coords of the rectangle
(394, 234)(430, 290)	#Second Frame
(354, 233)(385, 291)	#Third Frame





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS