• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

[SOLVED]Application stopped working...

AriesGames

Member
Hello everyone,

I am using GM 8.0 by the way.
I know most of my titles are click-bait, but this time that's the issue indeed.
So like less then 25% of times I get application stopped working. The game freezes.
All this happens at launch, it either launches or it freezes.

This issue appeared only after I created this code...
I know it's not a good thing to use with function so much and in this way...
But just look at what I am trying to do and tell me how I could improve that.

It uses all directions, N,E,S,W. (W,D,S,A) I am just showing you one of them here...
-sht_col = shooting collision, like a ray but made of actual pixels to determine collision
-e2 = enemy 2
-p1 = player 1
-choice is what I use to determine the behaviour of the enemy
choice 1-4 are the movement directions decided by a choose function (will become randomize() later)
choice 7 for example is not even put in that choose function, it's declared.

I am over trying here I know...
Code:
with obj_p1 if place_meeting(x,y,obj_e2_sht_colW)
{
    with obj_e2
    {
        choice = 007;
        if choice = 007
        {
            vspeed = 0;
            hspeed = 0;
            if shoot_cooldown <= 0
            {
                sprite_index = spr_e2_shootW;
                instance_create(x,y,obj_e2_bullet_W);
                shoot_cooldown = 60;
            }else{
                shoot_cooldown -= 1;
            }
        }
    }
}

Maybe it has nothing to do with this code, maybe it's just because I have 1500x1500 sprites which need to get cropped and optimized. But I am just asking...maybe there's something clear why this is happening.
 
L

Lonewolff

Guest
Can't see anything there that might cause an issue. Not even an endless while loop there, which can be the source of some of these issues.
 

AriesGames

Member
Great that you replied so I can post again.
When I alt tabbed to check the memory it consumes (still at 1gb and almost 20% of vram, that's cause I got a lot of free unused space in sprites) I got this error which multiplied on top of eachother...
System error code:5
Access is denied.
Any idea why this happened? If that's a shoot in the dark, which it is...

Can't see anything there that might cause an issue. Not even an endless while loop there, which can be the source of some of these issues.
I know right?

Why might the original problem then occur?
 
L

Lonewolff

Guest
Could be an out of memory issue. 32 bit applications will crash if the exceed ~1.5 GB.

How much is 20% of your VRAM? does your 1GB plus this figure go anywhere close to 1.5 GB?

If you are creating additional surfaces when you are close to the edge, it might tip you over.
 

AriesGames

Member
32 bit applications will crash if the exceed ~1.5 GB
How do I change it to 64? Does GM 8.0 build on 32 bit? You mean RAM or VRAM?

This only raises more questions on my part...excuse me.

How much is 20% of your VRAM? does your 1GB plus this figure go anywhere close to 1.5 GB?
20% would be around 1.5 GB since it has 8GB flat.
It consumes 1000-1200 MB of RAM...task manager doesn't show values on VRAM.
And VRAM gets to 20% after I let the instances it created of that bullet obj get to 200...
I noticed I am never destroying those bullet instances, but that can't be the problem at launch, right?
 
L

Lonewolff

Guest
Sadly GM doesn't do 64 bit. And I mean RAM + VRAM.

Sounds like you are using anywhere up to 2.5 GB in total. Which would put you in the 'lap of the gods' type figures.
 

AriesGames

Member
Which would put you in the 'lap of the gods' type figures.
Nah, not really...
I am just gonna crop the extra not used space in each sprite and move the ones I am not using at all...
And at a fresh start the game currently consumes 3% of the VRAM, which is 400MB if it was let's say 5%.

But wait a second, it just hit me like a thunder struck, you're saying anything that surpass 1.5GB RAM+VRAM in 32 bit is not doable?
If that's true, something I am thinking a lot lately, will port to GMS2 fix that? Or at least increase that cap?

Don't tell me I can't build a The Binding of Isaac on GM. :(
 
L

Lonewolff

Guest
Nah, not really...
I meant with regards to the whether the game crashes or not. :D


But wait a second, it just hit me like a thunder struck, you're saying anything that surpass 1.5GB RAM+VRAM in 32 bit is not doable?
If that's true, something I am thinking a lot lately, will port to GMS2 fix that? Or at least increase that cap?

Don't tell me I can't build a The Binding of Isaac on GM. :(
GMS2 has the has issue as it creates a 32 bit executable too (with the exception of a few of the exporters such as UWP, Android, iOS, PS4, and XBox One - In these cases you are limited only by the total RAM available).
 

AriesGames

Member
Even UWP? This is ridiculous...something like...
The earth is flat and therefore consoles are better. ROFL

Wow, now on a more serious side, this will be more of a challenge then I ever imagined.
Technically I can't build a game like that with GM, technically.
I already have some ideas how to handle that and still have hundred of items.

This is really getting interesting the more deep I get into it and the more deep I get into it the more I can't turn back.

Now I really understand why games like that, aren't supposed to be high resolution.

O.O
 
L

Lonewolff

Guest
Hehe, Yep. You need to really plan out what you want to do.

Think back to the dark ages when coders only had 192 bytes of RAM to play with on the Atari 2600.
 
L

Lonewolff

Guest
Got any example screenshots of your game? We might be able to work out a solution if we see your style.
 

AriesGames

Member
Think back to the dark ages when coders only had 192 bytes of RAM to play with on the Atari 2600.
They were actually shifting pixels somehow, so movement of a said character was not even independent, it was the same background but with it's pixel changing color based on said speed.

Yea sure here's an ss, the problem is there is not much too see...I am working on everything that goes to the mechanic part of it.
One issue I am quickly getting at, I am using sprites for each "room" layout...
Example, open doors north, closed each other direction. That's one sprite.
Open north and east, closed the rest. Another sprite image.

At this scale I need to have only one sprite for the room and then draw the changes depending on desired seed.
Also remove corridors from each sprite, keep them rectangular. Draw corridors again when needed, based on the respective seed.

Yea...
 
L

Lonewolff

Guest
Quite a few different approaches you could take here going by the screenshot. All ranging from various levels of complexity.

Firstly, are you deactivating instances outside of the view? That might be of tremendous value to you right there.
 

rIKmAN

Member
They were actually shifting pixels somehow, so movement of a said character was not even independent, it was the same background but with it's pixel changing color based on said speed.

Yea sure here's an ss, the problem is there is not much too see...I am working on everything that goes to the mechanic part of it.
One issue I am quickly getting at, I am using sprites for each "room" layout...
Example, open doors north, closed each other direction. That's one sprite.
Open north and east, closed the rest. Another sprite image.

At this scale I need to have only one sprite for the room and then draw the changes depending on desired seed.
Also remove corridors from each sprite, keep them rectangular. Draw corridors again when needed, based on the respective seed.

Yea...
You are doing something very wrong if you are hitting 1.5GB RAM based off that screenshot.
I can't help as I've never used GM8, but you should check that you are freeing things like datastructures, surfaces and not creating objects etc every frame by mistake.

Try printing instance_count to the screen to see how many things are being created.
 

AriesGames

Member
First of all, to be very clear, I didn't even knew about the 1.5GB cap until five minutes ago, which will mess and shift my design road a lot.

@Ghost in the IDE No, not for now. In the future (after I managed to set a proper very alpha version, very, very beta prototype) that random generation algorithm I have would have turned into a procedural one.
That means they are not even drawn, not deactivated. But it's a nice tip for now. Yeap...

@rlKmAN That's because you don't see the other 80 instances. I can't believe I just said that, haha.
There are invisible wall that act as collision masks. There are a bunch of them.
And you're not seeing the next "rooms", because my pc likes to now draw some sprites for some reason. They work fine on other PC's...I try to ignore that problem, if bugs will occur on that seed in those rooms. I will just debug and test on other PCs.

The point is there are rooms generated that each come with their own invisible walls collision masks. Those invisible walls sprites have huge empty spaces, they need to get cropped.
On that side it's still a freakin' mess.
 
L

Lonewolff

Guest
Still, from the screenie, it is hard to see how you'd be getting that high in RAM usage. Even with an 80 additional hidden instances.
 

AriesGames

Member
Indeed.

I just disabled the "room" generation system, even exported the script and deleted it. Same results...RAM at 1200 and VRAM at 7%. For some reason it runs, I am close to the edge.

I calculated all my big sprites in the resource tree... Not even 200 MB...55 sprites x 2.14 MB each...that if each pixel consumes 4 bytes.
This makes no sense.

Yea...the resource tree for some reason which is beyond me takes up 1200 of RAM.
I have an obj_moderator which does all the stuff in the game. I /* */ all the code in it, even removed it from the room. Since it was the only instance I put in the room. Same result.

Someone suggested to move everything to a new clear project step by step and check if this occurs again and where.
 

AriesGames

Member
Excuse me for so many posts one after the other moderators.

@Ghost in the IDE
but you should check that you are freeing things like datastructures, surfaces and not creating objects etc every frame by mistake.
How do I do that, I mean with datastructures and surfaces?
And isn't the debug supposed to tell me how many instances I create? It doesn't increase above an expected number.
 
L

Lonewolff

Guest
surface_free() to get rid of a surface.

Not sure with data structures, I don't use them.
 

rIKmAN

Member
Excuse me for so many posts one after the other moderators.

@Ghost in the IDE

How do I do that, I mean with datastructures and surfaces?
And isn't the debug supposed to tell me how many instances I create? It doesn't increase above an expected number.
I'm not sure if the commands are the same in GM8, but for datastructures you want to be looking at the ds_*_destroy() functions.
Whenever you use lists, maps, grids etc make sure you are destroying them so they don't hang around in memory if you lose a handle to them - that's a memory leak.

Surfaces are the same thing - make sure you are destroying them with surface_free() when you are done with them, just creating a new surface using the same handle (variable) means the old one is still is memory but you now have no way to access it to use it, destroy it etc.

How big are your sprites in pixels (width x height)?
You said each sprite is 2mb - that's quite a lot for a sprite.
 
L

Lonewolff

Guest
You said each sprite is 2mb - that's quite a lot for a sprite.
Pretty sure he meant when decompressed in RAM (as he mentioned 4 bytes per pixel).

But yes, still pretty big. That equates to 1204 x 512.
 

rIKmAN

Member
Pretty sure he meant when decompressed in RAM (as he mentioned 4 bytes per pixel).

But yes, still pretty big. That equates to 1204 x 512.
Probably, but I find it's always best to double check even the obvious :)
If he means 2mb filesize then we may have found the issue.
 

AriesGames

Member
I am not using data structures or surfaces, excuse me for that question. I thought they are things they get created without your concern.

Well the big sprites are 1500x1500 with only one image each.
A lot of their space is free and unused, needs to be cropped. After that step I need to reinvent the random generation alg, maybe even turn it procedural as of this stage in dev.
I didn't expected this 1.5GB cap at all...

But since I deleted everything and the application still consumes 1200 MB isn't this irrelevant in a way?
I said days ago I will format my hard-drive, because I need too anyway, reinstall windows and then re-create the project step by step.

Edit:By delete I mean keep it resource tree only.
 
L

Lonewolff

Guest
I am not using data structures or surfaces, excuse me for that question. I thought they are things they get created without your concern.

Well the big sprites are 1500x1500 with only one image each.
A lot of their space is free and unused, needs to be cropped. After that step I need to reinvent the random generation alg, maybe even turn it procedural as of this stage in dev.
I didn't expected this 1.5GB cap at all...

But since I deleted everything and the application still consumes 1200 MB isn't this irrelevant in a way?
I said days ago I will format my hard-drive, because I need too anyway, reinstall windows and then re-create the project step by step.

Edit:By delete I mean keep it resource tree only.
Not sure how GM8 works. It might still be loading these sprites into memory regardless.

1500x1500 is pretty large. That's 9 Meg per sprite once loaded in to RAM.

Most of the time you will have a copy both in RAM and VRAM (due to GM's internals). So there is 18 MB for one sprite right there.
 

rIKmAN

Member
I am not using data structures or surfaces, excuse me for that question. I thought they are things they get created without your concern.

Well the big sprites are 1500x1500 with only one image each.
A lot of their space is free and unused, needs to be cropped. After that step I need to reinvent the random generation alg, maybe even turn it procedural as of this stage in dev.
I didn't expected this 1.5GB cap at all...

But since I deleted everything and the application still consumes 1200 MB isn't this irrelevant in a way?
I said days ago I will format my hard-drive, because I need too anyway, reinstall windows and then re-create the project step by step.

Edit:By delete I mean keep it resource tree only.
A 1500x1500 sprite when loaded into VRAM will take about 9-10mb (without doing exact maths) - not sure where you got 2mb from?
It sounds like you might need to optimise your assets and how you use them, but without knowing the exact details of what you are using asset-wise it's hard to tell.

edit: ninja'd :p
 

AriesGames

Member
1500x1500 means 2.250.000 pixels. If you multiple that by 4 bytes...that's the only thing I knew about this...
I guess it's not only 4 bytes...

I guess all that is irrelevant and I will mark this thread as solved. Let me explain...

A guy told me that GM (not sure if only 8) counts everything from the resource tree even if never used.
If what you say is true 9 MB on average, I have 55 big sprites (1500x1500).
18 MB x 55 that alone is 990 MB...
Now if this two theories are true, it makes perfect sense.
But that means GM 8.0 "reads" sprites both in RAM and VRAM even when they are not used at all, just by being in the resource tree.
Interesting...

A wise thing to do before I go format mode on this is to go "crop" (optimize) mode on each sprite and see if there are differences.
 
L

Lonewolff

Guest
New ninja game. You like? :p

@LoadingDevelopment - Do your backgrounds typically repeat like in your earlier image? If so, you should be able to knock this down to a 32 x 32 or something and set the background to repeat. That would save you a ton of memory.
 

AriesGames

Member
I was clearly not doing some basic math right...like forgetting one step of the equation, for some reason....
Now I can't trace my steps back to that 2.14 MB....>.<

What background? I have no background. You mean that "room" thing? That sprite behind the robots?
Someone suggested to go grid based, but algorithm complexion go a little to far for me at that point, taking in consideration what I "dream" of doing.
 
L

Lonewolff

Guest
What sprites are 1500 x 1500 then? Surely that is a bit excessive isn't it?

I have an $850 display that doesn't even go to 1500 on the vertical.

(I probably got ripped off :p)
 

AriesGames

Member
Surely that is a bit excessive isn't it?
That's an elegant way to put it. ROFL

The 1500x1500 sprites are supposed to be the "rooms", that thing the robots walk within, imagine it as Isaac rooms.
I have so many because I drew each one with unique entries. North door exist or it's a wall, east one the same, then all variants in which two of them exist and so on...
Four directions, it comes to 15 unique variants, minus the one where all the directions are walls...because well...
On top of that, but wait there is more, each such room comes with collision sprites, which are 1500x1500 each, 15 of them...
The point is there are 55 such sprites of 1500x1500. 1GB of RAM right there.

This was way before I knew about the memory cap, excuse me. I liked to think I will solve that later during the dev pipe-line. >.<

Don't laugh yet, there's more...

I did some fast experiments and this are the results...each of those 55 sprites can be reduced to 1000x1000, just by cropping. Yea...this deep I am.
Around 4 MB for each sprite, that's 220 MB just by cropping.
But wait there's more, no sprite is cropped how it should, but those are the big ones. I also have around 50MB of garbage that I keep as a reminder how my graphics are evolving.
An very large average of 400MB are purely wasted by no cropping.
Yea, it goes deep...

I didn't even get into programming optimization, like creating a solid generation system.
I didn't even get into actually optimizing those collision huge 1000x1000 sprites into something more workable.
A pseudo-collision system. (No sprites, just pure code collision.) A dream you might think of mine.

Thanks a lot for your help, that memory cap was the most important thing I learned in a long time about GM and this project.
 

rIKmAN

Member
Don't laugh yet, there's more...
LOL! :D
I did some fast experiments and this are the results...each of those 55 sprites can be reduced to 1000x1000, just by cropping. Yea...this deep I am.
Around 4 MB for each sprite, that's 220 MB just by cropping.
GMS already trims any excess space from the sprites when it packs them into texture pages, so it's already been done.
You are reducing the size of the sprites, but not saving any memory as GMS is already using cropped sprites (on a texture page) so your memory usage is still that once cropped.

Honestly - there are much better ways to do what you are doing without having 1000x1000 sprites.
Look into tiles - with a little planning it's just as easy to use them to do this exact thing and will completely remove any of the problems you are having with memory.
 
L

Lonewolff

Guest
GMS already trims any excess space from the sprites when it packs them into texture pages, so it's already been done.
Doesn't it only crop transparent areas? If the wasted area is solid white (or something) it would likely remain.
 

AriesGames

Member
This memory cap is messing with my logic now, why does android and consoles get full memory usage and we PC users dont...FREAKIN' PC USERS ! GODS ! Grrrr....
(Keep calm, keep calm...)

I am not using GMS, I am using GM 8.0. I doubt it trims anything...since I left only the resource tree standing and the game still consumed 1200 MB.
I will try the cropping thing and if doesn't change anything then I will think of real alternatives.
Grids, tiles...the like...
 

rIKmAN

Member
Doesn't it only crop transparent areas? If the wasted area is solid white (or something) it would likely remain.
Well yeah, if it's white it's not classed as "excess" as it doesn't know that the white bit isn't part of the sprite.
But why would someone load a sprite with a white background as the unused part of the image? :D

If there are no transparent area on his bgs then yeah, no cropping - but he said he managed to crop them himself so I assumed there were some unused areas.
 
L

Lonewolff

Guest
True, it has certainly opened the OP's eyes. Which is a great learning experience for him. :)
 

AriesGames

Member
I am going to sleep after this, I don't want to break my sleeping hours because it will take me weeks to recover it back.

Wow, wow...
Don't confuse laziness
Maybe the same reason they are using 50x 1500²px images :D
for stupidity
But why would someone load a sprite with a white background as the unused part of the image? :D
xD
True, it has certainly opened the OP's eyes. Which is a great learning experience for him. :)
You have no idea, I am starting to understand why such complex systems are being used in programming all over the world. My "it shouldn't be so hard" conception is slowly falling to pieces.

Thank you a lot and good night to both.
 

AriesGames

Member
One of the best communities I have ever heard of, one of the most user-friendly and easy to get in but hard to master engines on the market.

Why I didn't thought that all this comes at a cost, a 1.5GB more exactly cost. >.<
 

rIKmAN

Member
I am going to sleep after this, I don't want to break my sleeping hours because it will take me weeks to recover it back.

Wow, wow...
Don't confuse laziness

for stupidity

xD

You have no idea, I am starting to understand why such complex systems are being used in programming all over the world. My "it shouldn't be so hard" conception is slowly falling to pieces.

Thank you a lot and good night to both.
It's not too hard - like I said you just need to spend a little time planning (a) what you want to do, and (b) the best way to do it.
Once you have done that and have a formed a plan post back in here and people will help advise you the best way to go about things and keep you on the right track.

Don't give up, keep at it! :)
 
Top