Spritesheets with objects?

W

Waylander

Guest
Still getting used to Game Maker and I have a question. Using spritesheets for backgrounds is great, but is it a good idea to use them with non-animated objects? Is it a bad idea to create, say, a number of floor objects and have all of them point to the same spritesheet and have the step event for that object hold the code "image_index = WHATEVER_SPRITE_INDEX_I_NEED"? Or for non-animated sprites should I just have them separate in my tree? Is it simply a judgement call on my part or are there any pros or cons for either route?

Any help is greatly appreciated :).
 
F

Fuzenrad

Guest
Honestly i dont understand completely what you want. Note: image_index dont work that way, sprite_index is that you choose a sprite resource and assign to the object. To non-animated sprites (in the same sprite resource), you can change with image_single (the number corresponds to each image in sprite, to run continuously set to -1).
 
W

Waylander

Guest
Right now, the way I am using "image_index" is working. And by working, I mean the program runs and all seems to be well. I'm just not sure if that is how I should be going about it. I don't know if this is a bad thing "under the hood."

I've used sprite_index before, but I don't think that'll work in this situation. And I found nothing on image_single.
 
F

Fuzenrad

Guest
The GM sprite editor shows each image numbered from 0 to n-1,

eg in sp_items i have 4 images:


When you have multiple images in the same sprite and want to display only one on the screen, you use the image_single. For example, if i want to draw only the shield, I write:
Code:
sprite_index = sp_items;
image_single = 2;
 
Last edited by a moderator:

TsukaYuriko

☄️
Forum Staff
Moderator
Moving to the Programming forum since this is not a technical issue.


image_single is obsolete. The following code snippets are identical in function, though:
Code:
image_single = n;
Code:
image_index = n;
image_speed = 0;
When you say "floor objects", I assume you are talking about an object that only serves as an obstacle to collide with and stop gravity? If that is the case, the approach you have chosen is suboptimal in more than one way.

Primarily, I suggest reading the tech blog article about programming fast platform collisions without using instances.
I also suggest using tiles instead of instances of objects that draw a static sprite.

If you want to take things even further (but this might not be necessary unless you have immense amounts of tiles and/or incredibly large rooms), that's possible as well by using surfaces.
 
L

leonfook29

Guest
With my understanding with what you're asking, other than the optimization issue that i might not know, I think it's all up to you, whether you like to have 10 sprite index with each holding only 1 index or having 1 sprite index with each holding. What works for me is that i bundle all the variation of the same sprite(let say a grassy platform), then upon object creation then i can randomize the floor sprite by changing the image_index.

Of course, using tiles would be much more optimal than this.
 
W

Waylander

Guest
My perhaps inefficient intent was to create objects for everything that I would need a collision for...floor, walls, etc. The idea I had was to create a separate object for each item and that object would pull its sprite from a spritesheet rather than a standalone image. That was the plan. And my question, which was answered (thanks, everyone!) tells me that it isn't optimal. I feared it was, but I wanted to see if I could get away with it LOL. Looks like technically I can, but at the same time, I need to learn some good habits, so I'll look into the fast platform collisions and go with tiles and save spritesheets for animated sprites. My main motivation for this was to have one big spritesheet that I could draw from via image_index rather than having a bunch of little ones clogging up my tree. But it looks like my problem might be solved via tiles. What I'd planned to do was use tiles in conjunction with these other spritesheets. So I'll just go with tiles and see what the other options are :).

Again, thanks, guys!
 
T

Tirous

Guest
When dealing with sprite sheets, it boils down to a balance between how big a memory foot-print the sprite sheet is, and minimizing how often you switch between sprite sheets.

The common method is to ether use one sheet if your not using to many sprites, or to make the rendering stage based, with things like props being drawn first, followed by things like enemies, followed by the player character(if its customizable), followed by things like ui, with each stage switching to its own sprite sheet and maximizing how much that sprite sheet gets used before going to the next, thus optimizing the rendering pipeline used by the game in a sense.

Just be sure to not overdo it, if you dont need a lot of sprite sheets, then dont use a lot, no reason to waste processor resources like that.
 
W

Waylander

Guest
Yea, that is the tricky part for me at this stage...I don't know enough about "resources" to know when something is efficient or not. Thanks for the input!
 
Top