Moddable Game Sprites

Kezarus

Endless Game Maker
Is there a way to import custom made images (user-side) into the game? I am planning to make it on a new game, but whenever you use sprite_add it create an entire new texture page for it and can potentially tanks the game performance.

Is there a way to do it on Game Maker?
 

CloseRange

Member
Nope, gotta create that clean new texture page. But you also shouldn't worry about it. Unless you are making a AAA game it won't tank performance.
If it does appear it's hurting performance it's not a cause of that.
Just remember to delete sprites after they are no longer needed.

If somehow you are doing something crazy with these sprites and are finding yourself still killing performance, one thing worth trying would be to create a temporary packed texture page. By this I mean create a surface, draw the required sprites in the surface as a texture page via code, then draw parts of the surface as needed. Though I doubt it will have to come to that.
 

Kezarus

Endless Game Maker
Well, I am not making AAA games, but texture swaps goes through the roof if I am not careful with texture pages. I get 215 texture swaps one time and manage to get it down to 20-40. I wonder if I use sprite_add. o_Ô

I get it that GM have a lot of functionalities that you have to make from scratch, but I will only use surface to make sprites as a last LAST resource.

Is there any other way to make it simple for a player to add their own sprites as a mod like thing? o.Ô?
 
R

robproctor83

Guest
Maybe try packing the sprites together into a single texture page and then split them back up in the game with draw_sprite_part. So rather than one image pee page you store 30 or however many can fit. This will however be a lot more work because you will have to unwrap the UV coords manually and keep track of them somehow. It would however be possible and be a way to potentially increase fps.
 

Kezarus

Endless Game Maker
So, yeah. It's an ugly lot of work just to allow sprite mods. Something that is common place nowadays.

I wonder if someone else stumbled into this problem too.
 

JeffJ

Member
It's one of the things I want the most from GM, since it's the last major piece of the puzzle to make a game that is completely moddable, which is something I really want to do. What I would like is some built in tools from GM's side to more easily create and manage dynamic texturepages - basically what robproctor83 describes, but with actual purpose specific functions for it, such as sprite_add_ext() where you could define a dynamic texturepage and then add certain sprites to it, and then read from there.

Short of that, as far as I know, managing your own dynamic texturepages as suggested is pretty much the only way.

You may want to check this one out - I haven't actually used it myself, but it may help you out:
https://marketplace.yoyogames.com/assets/4543/custom-sprite-framework
 

Kezarus

Endless Game Maker
Hi @JeffJ! Nice that we are seeking the same thing. If you find something in the future about it let me know. =]

I find it daunting (and strange) to add some extensions to do something so close to the core engine. Game Maker should have something to manage this. The <choose other engine> do and sometimes I wonder why am I still using GM. =/

Well, are they planning to make something about it on the road map?
 

kupo15

Member
I don't understand the issue entirely, I mean I do but don't understand what the problem is. You said your game is not big, one external texture page is not going to do anything to your game, not even several of them considering your scope. So why don't you just do that? I don't know what the worry is about atm. You also haven't described what kind of moddable stuff you want. You are going to require players to drop images outside of the game into a folder? Animations? Full levels? Static image? Need more information.

And unless you are on mobile, texture swaps tanking performance is the least of your worries to an extent. Memory space is a more pressing concern since they create their own texture pages and if that isn't a concern, performance hits from swaps is not a concern either....really
 

JeffJ

Member
Hi @JeffJ! Nice that we are seeking the same thing. If you find something in the future about it let me know. =]

I find it daunting (and strange) to add some extensions to do something so close to the core engine. Game Maker should have something to manage this. The <choose other engine> do and sometimes I wonder why am I still using GM. =/

Well, are they planning to make something about it on the road map?
As far as I know, it's not planned or on any roadmap (would love it if someone corrected me here and told me I'm wrong).

My best suggestion (other than trying out Braffolk's extension or making a system yourself) is to make an official feature request / suggestion via the bugreporting system using the appropriate category. As long as no one is officially asking for it, they have plenty of grounds to say it's not a priority, since there's no or little demand. If you want to go in a bit more prepared, it wouldn't hurt to do a few searches (such as search the forums for stuff like "sprite_add_ext", "mod graphics", "external graphics" etc.), that will without a doubt show you several topics over the years where people are asking for this, just like you have. You find every topic you can, every member who's expressed interest in this over the years, and use every link as an addendum to your request, showing that there are more people than just you and me (which is definitely the case).

While they may flat out decline, I wouldn't rule out them actually accepting it, but even in that case, I'd wager it will be years before we see anything like it (heck, I've waited several years at this point for much simpler requests that were accepted and put on the roadmap).

I don't understand the issue entirely, I mean I do but don't understand what the problem is. You said your game is not big, one external texture page is not going to do anything to your game, not even several of them considering your scope. So why don't you just do that? I don't know what the worry is about atm. You also haven't described what kind of moddable stuff you want. You are going to require players to drop images outside of the game into a folder? Animations? Full levels? Static image? Need more information.

And unless you are on mobile, texture swaps tanking performance is the least of your worries to an extent. Memory space is a more pressing concern since they create their own texture pages and if that isn't a concern, performance hits from swaps is not a concern either....really
I can't speak for Kezarus' specific situation, but external graphics handling to any serious degree will never be scalable this way. There's a reason why it's generally advised against using sprite_add() a whole lot, and if you'd actually want your game to be basically 100% moddable (exchanging all graphics for custom assets), it's going to be a performance nightmare where it really shouldn't have to be. Not only will it affect the amounts of various resources you could support swapping at a reasonable level of performance, but it will also hinder your ability to support lower end hardware (where, again, this shouldn't have to be a problem, and only becomes one because this is a really, really bad way to handle it).

It's much harder than it needs to be to support graphics modding for GM games, and I think it's a shame that YYG doesn't seem to have shown much interest in changing this, because for a lot of games, modding is what has kept them alive for decades. Not saying it can't be done, but the hoops you need to jump through really doesn't need to be this big.
 

Kezarus

Endless Game Maker
(would love it if someone corrected me here and told me I'm wrong).
That makes two of us, my friend.

As long as no one is officially asking for it
Ouch, ok. That killed it for me. I will not beg GM to make something that only I am asking for. Despite have loads of direct and pratical reasons for it. In the future, whenever I put engines in a balance again, I will remember to scale this issue too.

it's going to be a performance nightmare
For a prototype or a simple game... not so much. For any real Indie commercial game, well... you don't expect to need a powerful machine to run an Indie Game, do you? And this we agree with Jeff. That will happen if you span about 100 or so images in a entire texture sheet for swap on top of your actual game.

modding is what has kept them alive for decades
And this is the whole point of my post, thanks @JeffJ. I manage to create archives to command behaviors and status of Skills and Items in a game of mine. Completely moddable in that regard. But when a player asked for sprite mods I stumble into this big rock of an issue. Shame. =/

Thank you all, you good people for your ideas and insights about it. If anyone does know something about it, feel free to add to the conversation.


Cheers! =]
 

Lukan

Gay Wizard Freak
I might be wrong here, but if you got creative with surfaces, you might be able to avoid a noticeable tank in performance.
Put all the new images on one png and load that, then cut it into surfaces for use.
Still a bit taxing but Ithink it would be better than having 100 texture pages?
 
Ouch, ok. That killed it for me. I will not beg GM to make something that only I am asking for. Despite have loads of direct and pratical reasons for it.
If you have good reasons for it, then it is the perfect thing to raise as a feature request. What Jeff is getting at is that if nobody in the community bothers to raise feature requests then YYG will probably never think that this is something which needs changing.

If you were to raise the feature request, perhaps even ask if something could be included for some sort of texture page batching so that any subsequent sprite_add calls would go into that one batch/texture page until you call the batch end, something like the batch blending(? can't remember if that is a thing but definitely know that there is something that you can batch together) that exists so that you could do something like:
Code:
texturepage_batch_start();
sprite_add(....);
sprite_add(....);
...
texturepage_batch_end();
So texturepage_batch_start() would create the new texturepage, and all the sprite_add calls after that would load them into the texture page that is in the batch (provided that they will fit - and if they don't then they default to creating a new texture page as usual), and then the texturepage_batch_end() just switches everything back to the normal functionality.
 

Kezarus

Endless Game Maker
I might be wrong here, but if you got creative with surfaces, you might be able to avoid a noticeable tank in performance.
Put all the new images on one png and load that, then cut it into surfaces for use.
Still a bit taxing but Ithink it would be better than having 100 texture pages?
Well, the thing with this solution is that you will have to fiddle with surfaces and positions in it and never use sprite_add or the likes of it. You get a bunch of functionalities left out. Imagine if you have to rotate a sprite pivoted at the center this way.

What Jeff is getting at is that if nobody in the community bothers to raise feature requests then YYG will probably never think that this is something which needs changing.
Hm, I didn't mean to offend, sorry if that was the case. But I see how people asks for things for Yoyo and they very rarely comply. And, when they do, it takes a life time. So... I am wondering if it is really worth it. Change engines is a much less complicated than this.

So texturepage_batch_start() would create the new texturepage, and all the sprite_add calls after that would load them into the texture page that is in the batch (provided that they will fit - and if they don't then they default to creating a new texture page as usual), and then the texturepage_batch_end() just switches everything back to the normal functionality.
Yeah, if that actually exists it will be an awesome solution. I thought about sprite_add and point for the texture group, but your solution seems more reasonable.

Maybe I ask them to add this feature. As @JeffJ said, modding is what make games alive for longer, so everybody wins.
 

Lukan

Gay Wizard Freak
Limited, for sure. But if you're willing to reinvent the wheel for features, it is a way to do it.
 

Kezarus

Endless Game Maker
Limited, for sure. But if you're willing to reinvent the wheel for features, it is a way to do it.
Well, seems to be an awful lot of work just for a basic feature, don't you think, mate? =]

I deem myself a little bit too lazy for confort. But even I got fed up about the lack of GM features and made a Framework full of things that is at the marketplace (it's free, check it out, Monastery Framework).

But remake the entire sprite engine makes me feel... uncomfortable.
 
R

robproctor83

Guest
Yea it would be nice if yoyo gave us a script for adding multiple external sprites and have them auto pack into a single texture page and it be that simple, but I wouldn't count on it, mainly because you can already achieve such a thing with writing your own code.

Like kupo was saying though for a couple of sprites it should not be a problem and if it is causing a problem there is a good chance that something else is messed up unless you are adding a lot of sprites accidentally.

If you really need a scalable system that can handle a large number of sprites then you have to pack and unwrap them manually. It's not that difficult to store some uv coords and use draw sprite part and such. Like you mentioned you will run into some issue with the Sprite origin, but it's not overly difficult to reposition your movement to be offset by the origin, and if I remember correctly there may even be a simple trick but you'll have to do some searches.
 

CloseRange

Member
omg.
GUYS
YOU. ARE. NOT. MAKING. AN. AAA. GAME

Stop making a big fricken deal of this I don't wanna sound mean but your game is not as big as you think!!!
If you are having performance misuse that is on YOU and is not related to the game.

But fine I will fricken show you guys.
@Kezarus
215 texture swaps one time and manage to get it down to 20-40.
Fine I will use 200 as a baseline.
I opened up a project that I have runs perfectly fine nothing wrong and I throw this in the create event:
Code:
for(var i=0; i<200; i++)
    SPR[i] = sprite_add("SadKind.png", 1, false, false, 0, 0);
and in the draw event:
Code:
for(var i=0; i<200; i++)
    draw_sprite(SPR[i], 0, 0, 0);
hmmm what wow I'm drawing 200 sprites. Mind you SadKind.png is 512x512 image. I get 205 texture swaps BUT MY GAME RUNS FINE
with show_deub_overlay I see oh hey it's running at a nice 2700fps still

Now I know at least one of you will start talkin to me about instance rendering so I'll do ya one better.
I have a folder full of the entire 151 first gen pokemon.
Because of how they are layed out each pokemon is a file size of 3762x38 give or take 1000 for each. So yes BIG FILES SO NO EXCUSES
Code:
for(var i=0; i<200; i++)
    SPR[i] = sprite_add("SadKind.png", 1, false, false, 0, 0);
for(var i=0; i<151; i++) {
    var t = string(i+1);
    while(string_length(t) < 3) t = "0" + t;
    POK[i] = sprite_add(t+".png", 1, false, false, 0, 0);
}
create event to load all files:
Code:
for(var i=0; i<200; i++)
    draw_sprite(SPR[i], 0, 0, 0);
for(var i=0; i<151; i++)
    draw_sprite(POK[i], 0, 0, 0);
draw event to draw all 351 sprites and 355 texture swaps.

hey look. I'm running fine at a smooth 2300fps now dang I guess I did drop.
Sure there are now pokemon blocking a chunk of my screen and I had a much longer startup (about 10 sec maybe less. Still way better then 99% of actual AAA games) but that's because sprite_add is a slow but that doesn't mean don't use it.....
And this is not directly at the OP or anyone in particular I'm just seriously sick of everyone trying to micro manager performance on 2D indi games in places that they shouldn't need to be.
If you are getting performance problems it's not Game Makers fault for not including this, frankly it's not a feature because it's not as big of a problem as you'd think.
The only time I've had performace problems with Game Maker is when I do something really stupid in my code and frankly I've done some extreamly stupid things in my time on Game Maker
 

Kezarus

Endless Game Maker
Hi @CloseRange,

Just about code and performance. Yes, you are running a prototype on a developer machine. But nonetheless, it's interesting that you got numbers that are that good. I wonder why noone else is advocating for sprite_add then. Most of the source material that I researched before posting (from people that have publised indie games and tutorials) said otherwise or point out for an extension (like @JeffJ did). If you do a quick search you will find that too.

About AAA, well, do you consider Forager a AAA? Have a look at this article from Game Maker blog itself: https://www.yoyogames.com/blog/517/forager-optimization-in-gamemaker

And yes, it's easy to mess up a game and make something stupid. I am against overengineering, but just wait for a problem to happen to discover that you have to redo all your code is not that smart, is it? I am just trying to discover what's the best course of action before start doing things. That's what is this forum for, I guess.

And finally, please, no need to be rude or angry. This forum is full of nice and helpful people. Let's leave it like that, shall we.
 

CloseRange

Member
@Kezarus sorry. I was tired and probably did not explain this well.
And finally, please, no need to be rude or angry. This forum is full of nice and helpful people. Let's leave it like that, shall we.
As I said I don't mean to be rude, sorry it came out that way. I took a nap maybe this will be a better post.
Here is some advice to anyone reading this. Sometimes, even with myself included, we give out wrong advice.
Sometimes it's because we don't know any better, and sometimes it's because we don't trust anyone.

Here are the 2 (hmm maybe 3?) problems with sprite_add
1: it's slow to run because it needs to create a new texture page. Note here. sprite_add is slow to run. Not drawing sprites with sprite_add.
This is why for me it caused a long load time, I was loading 351 sprites all at the start, that's why AAA games have load screens, because they are loading a booty ton full if sprites into memory.

2: if done wrong it causes memory leaks. This is why some people don't want you using sprite_add because too many people end up screwing it up and breaking everything and then others have to re-explain why they are creating memory leaks.
It's easier to just say "don't use sprite_add" then to explain an advanced concept like memory leaks and then to have them remember to use sprite_delete and then expect them to actually know when is right to delete them. Of course it takes a lot (and I truly mean a lot) of sprites to make a memory leak.
I mean you saw my project, 351 still wasn't enough to cause one and if you are loading 351 sprites into memory at the same time there might be other problems (ok maybe that's a lie I've had projects load more than that at once)

3: ? They say this is a problem but until I ever see the problem I will hold my ground. It's texture pages. People complain because sprite_add creates its own texture page this is what causes huge numbers of texture swaps. This is why this thread is here and what everyone says is the problem.
I've seen people obsess over so much about reducing texture swaps by just a few in order to "maximize performance"
If you are doing it for practice and to learn more about it then 100% do it. I've done it many times in order to practice and learn. But if you are spending days to reduce a couple texture swaps on an actual project then they are wasting time that they could be using making the actual project.
That's not to say you are doing this but I have seen people become like that and I feel it's a tad obsessive. If you use general common sense and have a basic solid understanding of when you are drawing things / doing things when you shouldn't be then you'll be fine.
If you are a beginner and trying out a big project with lots of sprites like this, then I'll just say don't. Do small projects to try out. But I don't think you're a begging Kezarus so I think you can do this just fine.

Alright let's answer some questions. Kinda.
About AAA, well, do you consider Forager a AAA? Have a look at this article from Game Maker blog itself: https://www.yoyogames.com/blog/517/forager-optimization-in-gamemaker
AAA usually means a company with a fork ton of money, resources, and history. It has nothing to do with the complexity of the game really. But the fact is any indi studio without a fork ton of money and resources will never be able to create a WoW size game before we die.
So when I say make a AAA game take it with a grain of salt, but know that AAA games have to worry wayyyy more on performance than any of us for a handful of reasons.
As for the blog I've seen it before but only skimmed it.
It is important to optimize code. Yes. But knowing where to optimize code without wasting time and possible end up never finishing is another story.
No that was not a AAA game as it wasn't made by a AAA company. Though it does look like a really fun game.
I don't know when he used included files or if he did at all so I can't talk about his meathod for that.
But It's understandable to worry a little about batch calls and breaking a batch in game maker is worse. Though again don't stress over it unless you plan to be breaking the batch thousands of times.
Game Maker uses a batch rendering system that's why using 100 different shades is no good. This is the opposite with something like Unreal that using instance rendering so it's fine to have 1000 different shavers running at once.

I am against overengineering, but just wait for a problem to happen to discover that you have to redo all your code is not that smart, is it?
Hard to say I suppose. I rewrite code all the time so I've gotten in the habit of writing code in ways that makes it a lot easier to rewrite. That's why I advocate using functions anywhere and everywhere possible.
If I have a script that takes in an x and y and shoots out a number then later realize it's breaking everything I only have to rewrite that one script, ensuring that it still at least takes in that x and y and shoots out a number.
If you get better at writing code that can be easily changed or scale well in the future then if you break something or realize something is wrong or wanna add something later, well then you can start skipping most of the planning phase with insurance that it's ok if it's not 100% perfect.

I am just trying to discover what's the best course of action before start doing things. That's what is this forum for, I guess.
Yeah, that's understandable. Here is the thing, nobody wants to reinvent the wheel that's why you and others want a way to pack sprite_add calls into texture pages. And while that would be nice to have, I also don't think you have to worry about it as much as you think.
Game Maker has a really good 2D rendering system. Better than unreal's and probably Unity's. Optimization is good when it needs to be there. Obsessing over it is bad when you need to release that game.
 

Kezarus

Endless Game Maker
Hi @CloseRange, thanks for the explanation. =]

Yeah, I see how people could mess up with this kind of resources. Maybe that's why so many people advise against sprite_add. If that's the only reason it's kinda silly and we should experiment with the engine on our own like you did. I really expected something far worse, but your test clearly show that maybe it's an option.

Tell you what, I will make a simple project like you did and upload it to git. Images don't need to be that big ('cause it's an entire texture page for its lonesome hahaha), so a bunch of 128x128 sprites added many times over (10 sprites added 10 or 100 times) should do the trick. I will try to run that in a potato an post the link here for the git.

About the amount, I don't know exactly 'cause I am planning for mod on the user side. They can add as many things as a folder can hold. I bet around 100 to 1000 (upper limit) is reasonable.

Will get back here with the git repo and my findings in the potato pc. Wish me luck. =]
 

YanBG

Member
@Kezarus i'm already using background as included_files for my base game graphics, then load it with background_add and draw background_part. Since every frame has fixed width/height and is placed on spritesheet, it's pretty simple to know where exactly say image 5 of aniamtion 3 is. This all can be edited and replaced for mods and you could either add a few blank/dummy spritesheets for additional custom content or code the game to accept more images in the included folder. Modders need to know the correct dimensions or you could use text files that specify the size of the frames for each spritesheet.
 

Kezarus

Endless Game Maker
Hi @YanBG! Long time no see, mate! =]

So, this is kind of what I am trying to do, give the player the power to add new sprites and mod the game.

As I encountered so many people advising against sprite_add I post my doubt here. But, as @CloseRange point out, maybe it's not well grounded in evidence. Gonna make a project when I get home and share the results with you guys. I will try to run it on a laptop that my wife uses only for internet and Word. If it runs smoothly there, well, problem solved! =]
 

JeffJ

Member
But if you are spending days to reduce a couple texture swaps on an actual project then they are wasting time that they could be using making the actual project.
This, in a nutshell, is where we seem to have a lack of communication.

There's a big difference between "a couple texture swaps" and literal hundreds. If you are making a big game, with a vast open world (still 2d, still "indie") where there would be literal thousands of sprites in the IDE using the "intended" way of developing, here's the major difference:
Using the IDE, you can organize everything with the texture groups, so it doesn't have to matter a lot whether you have 10 sprites or 10000 sprites - what matters is the organization of them.
Now, with sprite_add(), you lose that control, and will literally have as many swaps as you have sprites. If you only use sprite_add(), this actually puts a hard limit on how many sprites you can have in your game, which is what makes it not scalable. On top of that, there's also the issue of what kind of interface you want your user base to interact with in order to add sprites to the game - with actual managed texture groups, you could make a system that would let the user put several sprites onto a single sheet and preview (like what we do in the IDE), but with sprite_add() it's just fire and forget, complete texture chaos. And this problem will increase exponentially the more sprites that are added.
 

CloseRange

Member
There's a big difference between "a couple texture swaps" and literal hundreds.
Nonono sorry the "couple texture swaps" wasn't in refrence to any of you guys I was giving an example of a few people I had seen in the past and was warning going down this path.

Also did you not read anything else I put? I litterly tried with 500 texture pages. Running 500 texture swaps every frame no problem. Unless someone else comes over and wants to show me different results because I will be genuinely curious but I hear all talk but no proof. In fact someone please come PROVE me wrong. If I'm wrong I wanna know. But don't just say "you wrong you bad" actually show me what you did and how you proved it. I have yet to see anyone prove how much of a problem it really is so why should I trust them when I do the test myself and never get lag?
If you're getting lag due to sprites it's more than likely because you're drawing too many sprites, not because of texture swaps.

Now to this end I am fully sure that this can become a problem on mobile targets. But good luck getting modding to work on mobile anyway....
Personally I don't care if they make sprite_add apply the sprite to a texture page. This way I have more control.
Now, sprite add takes way longer as it has to go into the texture page, calculate where the sprite can fit most effectively, then remake the entire texture page with this new sprite in mind.
Then when it needs to delete the sprite, same process.
I'd rather it just say create the sprite as is, and when I delete toss the whole thing with the small caviot of 1 extra texture swap.
And, because I have full control, I can, by hand, go in make that functionality myself but delete the whole texture page when needed instead of on a sprite to sprite basis. And you can't complain that you don't want to make this yourself because it takes like a half hour to make yourself maybe an hour depending on how distracted you are.
 

Kezarus

Endless Game Maker
In fact someone please come PROVE me wrong.
In fact I want to prove you RIGHT! I just created a new project and start deving a stress test. If that works it's a win scenario for all. Also I dig a little deeper and get a post of Russel himself stating that "I do not think you should be as concerned with the texture swaps as we were on GMS1". Post link.

I got my fair share of problems with GM1 and textures swaps, true story, but not in GM2 yet. If that statement is true.. boy, oh, boy. =]

If you're getting lag due to sprites it's more than likely because you're drawing too many sprites
Weeeeeeeell............ if you have pieces combining together to, let's say, a customizeable character you have about 10 to 20 pieces per character. If you have 50 of them on screen... do you see where it's heading? This is an real life example that I made into a comercial game. Not anyone else. A indie game that I dev. =]

But good luck getting modding to work on mobile anyway
True that =]
 

CloseRange

Member
if you have pieces combining together to, let's say, a customizeable character you have about 10 to 20 pieces per character. If you have 50 of them on screen
yeah but reducing texture swaps / packing included files would not have fixed that problem.
Depending on the complexity of the pieces though you might want to do what Stardew Valley did and provide the modder with a big texture page full of all "peices" and then allow them to add pices to that big texture page and upload just that. If you think this would be a problem. For Stardew valley it was easy because each style had to fit in a grid anyway (I think they used 24x24 for things like hair and clothing and items but I could be wrong)
Not even this is really necessary. Stardew Valley was created in c# using it's own custom engine. It didn't have a huge experienced team (YoYo games in this case) to create an optimized engine to work with.

I want you to think about this example though. Swords and Magic and Stuff
It's a 3d online(4-8 player) rpg currently in development. The developer, an indi, streams all the time and talks about the development. So I can tell you that the entire world as it currently stands is always rendered, every texture is a separate image, there is little to no sprite packing. Because every tree is always being rendered, every weapon, every particle, every enemy, every model, I am fully sure there are plenty of texture swaps taking place.
I've had the honor of beta testing the game and I can promise you, there is no lag. The developer, Kindred, is an artist fully and would have no idea what we are talking about in this forums because he has stated many times he's not a programmer, in fact he uses blueprints (the equiv lent of drag and drop for game maker) to make this game.

Game Engines hold games up so we don't have to worry as much about things like this. That's why they are here. So let game maker do its job.
 

Kezarus

Endless Game Maker
Oooook, I did some tests here...

Short Answer: IT WORKS!! =D

Long Answer:
Got 10 Kenney sprites 136x136px and added them 100 times with sprite_add. So I have 1000 different sprites.

Then I get 1000 objects in a room randomizing their sprite_index at start. I got literally 1000 texture swaps!

On my developer machine I got 300fps. On the potato machine... not so lucky, around 30-50fps. But the potato is a five years old i5 laptop that was never formated with serious performances issues. It lags to open a web page. And I am really stressing things out with this amount of instances and sprites on the screen.

My humble conclusion:
It works for the intended purposes. Players could add images and the game will run even in a potato pc. Of course one should not be that crazy to add so many instances or more than 1000 simultaneous sprites, but it's safe to say that GM 2 can handle this kind of operation without so much of an issue.

If any of you want to test it on your side here is my Project Link. Please share your results. =]
 
Last edited:

CloseRange

Member
So how do you know if it's because of sprite swaps or just you drawing all those sprites?
Well I downloaded the code I also got 300 fps.
I tried a small modification, Instead I set every single object to use the same sprite. This left me with 4 texture swaps. I still got 300fps (though I think it may have hovered slightly closer to 400)
So the lag is caused simply by drawing a lot of sprites at once, not because of texture swaps. That means it doesn't matter if you use sprite_add or import straight into the IDE or pack them into the same texture page. Either way it's the number of draw calls that is scary.
 

Kezarus

Endless Game Maker
So how do you know if it's because of sprite swaps or just you drawing all those sprites?
Well I downloaded the code I also got 300 fps.
I tried a small modification, Instead I set every single object to use the same sprite. This left me with 4 texture swaps. I still got 300fps (though I think it may have hovered slightly closer to 400)
So the lag is caused simply by drawing a lot of sprites at once, not because of texture swaps. That means it doesn't matter if you use sprite_add or import straight into the IDE or pack them into the same texture page. Either way it's the number of draw calls that is scary.
Well, it works! Who would have thought? And the fact that, no mattter how many texture swaps happen, it still holds the FPS make it even better in my humble opinion. =]

I had soooo many issues with texture swaps and GM 1.4. I manage to fix them all, one way or another at the end. But it's a real relif that this is no longer a big (or... any...?) concern.

I am really curious to know the opinion of other people about this. See, this is a recurring theme and people usually avoid sprite_add entirely. I was until I saw proof that this maybe not the case and performance on GM 2 is safe I guess.
 

GMWolf

aka fel666
Yep texture swaps are much less of an issue in gms2 desktop (dx11).
But might still give you a headache with other platforms.
I think it's still worth avoiding them
 

TsukaYuriko

☄️
Forum Staff
Moderator
Desktop platforms have historically had less issues with massive amounts of swaps than others. This doesn't mean they're not an issue, though, so I wouldn't say that "performance on GMS 2 is safe". Try assigning the same sprite to all 1000 instances, see whether it makes a difference. If it doesn't, scale it up to 10000 or something and try again - it doesn't even have to be 10000 different sprites, it can be just two, with every odd instance having sprite 1 and every even instance having sprite 2.

That'll get you up to the same amount of texture swaps without blowing up your RAM with thousands of texture pages... which is the other problem of sprite_add: It creates a new texture page for every sprite, no matter how big it is, which then needs to be a power of 2 in each dimension and takes up more RAM than if it had been placed on a texture page alongside others, etc. Like this, you can test the impact of swaps vs. no swaps at just about any capacity.

Once you think your project's frame rate is dying from swaps, test it on HTML5 or Android. You'll start counting in SPF (seconds per frame) instead. :p
 

Kezarus

Endless Game Maker
I think it's still worth avoiding them
Why avoid sprite_add or texture swaps if it doesn't hurt performance? =]

@TsukaYuriko I'm gonna do the tests that you said, but anyone can see for themselves as I provided the source files for the project. At the end of the day, it scales well and, unless there is another reason, it seems that "performance is safe on GM" regarding sprite_add.
 

TsukaYuriko

☄️
Forum Staff
Moderator
Why avoid sprite_add or texture swaps if it doesn't hurt performance? =]
Because it does hurt performance, to different extents on different target platforms, and on different hardware. Just because it doesn't cause noticeable lag on your system doesn't mean it will work well on others', and if your game eats a bowl of texture swaps for breakfast, you can probably forget about porting it to non-desktop platforms as they are way more sensitive to swaps than desktop platforms. There's a good reason why manual texture group management is a feature and the manual keeps warning users about the pitfalls of swaps - if it wasn't an issue, those wouldn't have been added.

Small test...
sprite0: Texture group Test1
sprite1: Texture group Test2

obj_test Create:
Code:
repeat(n)
{
    with (instance_create_layer(0, 0, "Instances", obj_testsprite))
    {
        sprite_index = (id mod 2 == 0) ? sprite0 : sprite1;
    }
}

fpstotal = 0;
steps = 0;
obj_test Draw:
Code:
fpstotal += fps_real;
steps++;

draw_text(20, 100, string(fpstotal / steps));
obj_testsprite is an empty object.


I manually set n in the Create event until I reached an average FPS of 60 (after letting it run for a few seconds). In this example, n ended up being 35000.
I then placed sprite1 on texture group Test1 as well, so that both sprites are on the same texture group, and repeated the test.
This time, n ended up being 90000 before FPS dropped to 60. That's almost two and a half times as many sprites that can be drawn when texture swaps are not a concern.

Now, this is of course a lab experiment and in a real world scenario, such as an actual game, will have a lesser impact on performance because drawing isn't the only thing going on. However, this was just to illustrate that texture swaps do have an effect on performance - however big that may be.
 

Kezarus

Endless Game Maker
Hi @TsukaYuriko

Because it does hurt performance, to different extents on different target platforms, and on different hardware.
Yes, I agree, but this only happens if you go burlesque with the amount of texture swaps. And yes I tested it on my machine and on a potato machine as dev rigs are usually much more powerfull than standard ones. I got a noticeable difference when I did a stress test, but not on a standard reasonable test.

non-desktop platforms
Right! I will not target these. I just want to allow modders to mod my steam games. =]

There's a good reason why manual texture group management is a feature
I think you are right when it's about GM 1.4, video-games and mobile. PC hold it's own pretty healthly, isn't it?

90000 before FPS dropped to 60
Wow, 35000 to 90000 instances making swaps. It's a lot!! O_O If one have to go as far as this to make the system buckle, the conclusion could be: "Yes, it hurts performance, but only with ludricous amounts of instances".

For moding purpouses on PC it seems safe enough as I thinks it will be really hard for one in his/her right mind to put this many instances being draw on the screen at the same time.


Cheers! =]
 

GMWolf

aka fel666
I would still try to reduce those texture swaps. It's just a little sloppy not to.
But if you game performs ok without it... Eh?

Just make sure you leave enough flexibility to switch to better texture management.
For instance, use a custom draw sprite script rather than the build in draw sprite. That way you can change it if you decide to do texture packing, or some other scheme.
 

TsukaYuriko

☄️
Forum Staff
Moderator
Who said sprites can't be both moddable and not messing up swaps? ;)

@Braffolk's Custom Sprite Framework is essentially a custom texture page packer to be used at run time. Essentially, it's a sprite_add that doesn't create separate pages for every sprite added, but rather stuffs a few of them on a page and then internally maps the sprites correctly. Performance is not-fully-but-almost on par with native resources. It's for GMS 1.x, so I'm unsure how much adaptation would be needed for it to work in 2.x, but it's essentially the best of both worlds.

Otherwise, just make sure you'll have a way to refactor your game's drawing pipeline further down the line, should the need for more proper texture page management from external sprites ever arise, or it may come back to bite you from behind in the future.
 

Kezarus

Endless Game Maker
use a custom draw sprite script rather than the build in draw sprite
Otherwise, just make sure you'll have a way to refactor your game's drawing pipeline further down the line, should the need for more proper texture page management from external sprites ever arise, or it may come back to bite you from behind in the future.
This is actualy a good advice. Will plan and do this. Whenever I get lazy and don't plan things it really comes back to bite me. That's why I posted here, to prevent this. =]

@Braffolk's Custom Sprite Framework
Yeah, this is the same framework that @JeffJ suggested too.

It's for GMS 1.x, so I'm unsure how much adaptation would be needed for it to work in 2.x
The thing is, it doesn't seem to be the case to make it for GM 2.0. I got loads of problems with texture swaps on GM 1.4 and it makes a lot of sense there; On GM 2... ¯\_(ツ)_/¯
 

rIKmAN

Member
Nocturne said in another thread recently that it’s actually every frame of a sprite that creates a new texture page, so a 10 frame walk cycle is 10 new texture pages, not 1.

However if performance is decent then keep it in mind as low hanging fruit for optimisation later.

I don’t see an issue with providing template texture sheets for modders to add their own graphics to and then loading those in your game though, seems to be the best of both worlds in the current situation.
 

Kezarus

Endless Game Maker
I don’t see an issue with providing template texture sheets for modders to add their own graphics to and then loading those in your game though, seems to be the best of both worlds in the current situation.
Hi @rIKmAN! How would you do that exactly?
 

rIKmAN

Member
Hi @rIKmAN! How would you do that exactly?
Not sure it needs more explanation that "template texture sheets", but it's similar to the method used in Braffolks extension where you would provide an image/images which were templates for the user to fill in their own sprites (characters, weapons, vehicles, whatever) at whatever size you deem acceptable, have predefined locations for walk, run, jump frames etc and then you simply load that 1 single sprite using sprite_add() and draw the required part from that single new sprite.

It's basically what texture packers do when they provide a json file with the packed image which contains the images x, y, w, h, name etc so they know how and where to locate that image from the full texture page, and I assume is similar to what GMS2 does under the hood to keep track of each sprite once stripped of whitespace and packed into texture pages.

So essentially (depending on the sprite sizes in your game and the texture page size) you could have an entire character with all animations added with a single sprite_add() call and draw whatever you need from it.

You should give Braffolks extension a try, I believe it's free and would be worth importing into GMS2 to see if it works as the sprite functions haven't changed that much between 1.4 and 2.x.
 
Last edited:

Joe Ellis

Member
I use a dll that loads each image into memory completely bypassing gm's texture handling, so the image loaded takes up exactly how much that single texture will. https://forum.yoyogames.com/index.php?threads/gm-community-dll-collection-discussion.70032/
You have to use a shader with a custom sampler, but you can just write one which is the same as gm's standard default one and make it read from "texture" instead of gm_base_texture

EDIT- actually it's not that simple, you won't be able to draw sprites in the normal way, you'd have to draw quads with the texture on them. But that isn't really that bad anyway, you just have to do it a bit more manually. If the amount of texture pages generated from sprite_add is a problem, this is probably the only viable option, until gm stops making whole texture pages for single sprites
 
Last edited:
Top