GameSalad

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Is there a way to dump graphic memory?

owen_dennisowen_dennis Just a guy, you know.Member, PRO Posts: 236
edited May 2015 in Working with GS (Mac)

I have an endless runner that spawns new and different kinds of enemies as the game progresses. When I look at the memory usage of my game, the game slowly uses up more and more ram until it reaches a certain point and crashes. It coincides with more enemies having existed, not necessarily how many are on screen at a time. It also seems to happen after I've played a couple rounds, but not after the first time I've played.

This is leading me believe there is a memory issue and it's basically causing my game to become unplayable. When I found this was a problem a month ago, I switched all my graphics from being retina to non-retina, and that helped a lot. It then would only crash after an even more extended period of time, sort of delaying the inevitable. However, I've since had to add more graphics and it's back to crashing a little earlier. I've cleaned up my code considerably but it still isn't helping.

So this feels like it's pretty clearly pointing to a memory dumping issue. Is there any way to dump memory?

Comments

  • BlackCloakGSBlackCloakGS Key Master, Head Chef, Member, PRO Posts: 2,250 GameSalad Employee

    0.14 should do that for you automatically

  • owen_dennisowen_dennis Just a guy, you know. Member, PRO Posts: 236

    Great! I haven't tried the nightly builds yet. I'll give it a shot and see what happens.

  • owen_dennisowen_dennis Just a guy, you know. Member, PRO Posts: 236
    edited May 2015

    Whoa... new graphics engine is right. This issue might be fixed, but now my game is super blurry? It looks almost like all the images are a quarter the size they used to be and were then scaled up within the engine or something? I guess I'll have to wait until the stable build of 0.14.

    EDIT: Whoops, that's a known bug. No reason to continue pointing it out. Sorry!

  • ToymanToyman Key Master, Head Chef, Member Posts: 11 GameSalad Employee

    Thanks for your input on 0.14! I worked hard on making it a totally streaming based solution for delivering graphics to the video card. It takes your PNGs, rips them into 64x64 tiles, and downloads them to a single large "mega" texture to use Id Software's parlance. If you run out of tiles because you want to draw something new then the oldest tiles will be evicted from memory and make enough space for the new image. Then it'll start rendering like usual. There will be a stutter when this eviction happens because it has to load from disk but it's better than crashing! :) I'll take a look at the blurry issue. If it's blurry it usually means that we're scaling the image some how. There's talk of adding a point sampling option to the engine, which would give you a pixelated look when scaling (which is sometimes desirable for pixel-art styles) and never blurs. Let me know if there's anything else I can do to help.

    Toyman

  • owen_dennisowen_dennis Just a guy, you know. Member, PRO Posts: 236

    @Toyman said:
    Thanks for your input on 0.14! I worked hard on making it a totally streaming based solution for delivering graphics to the video card. It takes your PNGs, rips them into 64x64 tiles, and downloads them to a single large "mega" texture to use Id Software's parlance. If you run out of tiles because you want to draw something new then the oldest tiles will be evicted from memory and make enough space for the new image. Then it'll start rendering like usual. There will be a stutter when this eviction happens because it has to load from disk but it's better than crashing! :) I'll take a look at the blurry issue. If it's blurry it usually means that we're scaling the image some how. There's talk of adding a point sampling option to the engine, which would give you a pixelated look when scaling (which is sometimes desirable for pixel-art styles) and never blurs. Let me know if there's anything else I can do to help.

    Toyman

    That is very interesting. Should I take my "divisible by 4" image scaling a bit more seriously? I've been making images this whole time to be divisible by 2, which I would think wouldn't be a huge difference, but what do I know.

    Point sampling (I've always referred to it as "nearest neighbor" because of photoshop) would be great so we could make truly pixelated looking graphics and make the actual images themselves keep a tiny footprint. I would love to be able to keep my images at their real pixel size, then just scale it up within the game engine.

    Out of curiosity, how big is that mega texture? Just to make it so we can sort of predict when that stutter might occur? Or does it not work that way? I'm looking forward to seeing this engine get all streamlined over the next few months.

  • RabidParrotRabidParrot Formally RabidParrot. Member Posts: 956

    Are you destroying actor when they are off the screen?

  • owen_dennisowen_dennis Just a guy, you know. Member, PRO Posts: 236
    edited May 2015

    @RabidParrot said:
    Are you destroying actor when they are off the screen?

    Yes. As soon as it is fully outside of the camera's view the actor is destroyed. I feel like this may be one of those things where I wait awhile for a more stable version of 0.14 to be out, then check out what happens.

  • RabidParrotRabidParrot Formally RabidParrot. Member Posts: 956
    edited May 2015

    @octopus1138 said:

    Are you using a lot of timers?

    Timers won't affect the blurry images but having less of them (timers) running at once will improve performance.

  • owen_dennisowen_dennis Just a guy, you know. Member, PRO Posts: 236
    edited May 2015

    @RabidParrot said:

    No, I've switched about 90% of my timers to the self.timer%(time) method which also streamlined things a lot. I also cut down on how often tables are updated (tables that I use to measure randomly spawned characters' hitboxes) to try and get away from the issue I read about with lots of table updating causing slowdowns. I also made sure that at the end of levels tables are cleared and replaced so there isn't any excess info just sitting around taking up space.

  • supafly129supafly129 Member, PRO Posts: 453

    Is deleting all actors before scene changes supposed to be an effective solution to dumping memory in 0.13?

  • SocksSocks London, UK.Member Posts: 12,822

    @Toyman said:
    Thanks for your input on 0.14! I worked hard on making it a totally streaming based solution for delivering graphics to the video card. It takes your PNGs, rips them into 64x64 tiles, and downloads them to a single large "mega" texture to use Id Software's parlance. If you run out of tiles because you want to draw something new then the oldest tiles will be evicted from memory and make enough space for the new image. Then it'll start rendering like usual. There will be a stutter when this eviction happens because it has to load from disk but it's better than crashing! :)

    I realise this is a difficult question to answer with any kind of precision (given that each project has its own set of circumstances) but generally speaking what do you think the main advantageous of the new rendering system are going to be ? And do you have any broadly applicable figures illustrating the improvements (i.e. loading times are cut by X% or a game can have XX more actors in a scene before frame rates suffer) ? Cheers in advance for any input.

    @Toyman said:
    I'll take a look at the blurry issue. If it's blurry it usually means that we're scaling the image some how. There's talk of adding a point sampling option to the engine, which would give you a pixelated look when scaling (which is sometimes desirable for pixel-art styles) and never blurs.

    This is enormous news for all the 8-bit folk out there !! This would be brilliant !! :smile:

    A quick question, would this option be on a global (game-wide) basis or per-asset ? If it were per-asset then its utility could be extended way beyond the needs of the 8-bit folk, I can imagine lots of (non-8-bit game) uses for this.

  • SocksSocks London, UK.Member Posts: 12,822
    edited May 2015

    @octopus1138 said:
    That is very interesting. Should I take my "divisible by 4" image scaling a bit more seriously? I've been making images this whole time to be divisible by 2, which I would think wouldn't be a huge difference, but what do I know.

    Any blurring from an image not sat on a whole pixel value (especially on a high resolution Retina device like an iPhone) will be fractional, I am going to go out on a limb and say (without having tested this) that an image asset not sat on a whole pixel value (not divisible by 4) would be indistinguishable from an image asset sat on a whole pixel value (divisible by 4) on high resolution devices - and in the case of the iPhone 6 plus this imperceivable blurring will be much less than the default blurring that happens as the project goes through the internal scaling process (1242p > 1080p).

    The Retina branding is sold on the idea that individual pixels are indistinguishable by the human eye - even at the Retina iPad's 264ppi it's pretty unlikely that anyone could see an individual pixel, and when we get to the even more pixel dense iPhones (401ppi on a 6 plus !) it's pretty much impossible - and many Android screens even surpass these insane resolutions !!

    The divide by 4 recommendation, at least to some extent, relies on the idea that we see individual pixels (or at least the effect of placing them on sub pixel values) - I think this made a lot more sense in the pre-Retina days.

    tl;dr "[shouldn't] be a huge difference" - agreed.

  • owen_dennisowen_dennis Just a guy, you know. Member, PRO Posts: 236
    edited May 2015

    @Socks said:
    tl;dr "[shouldn't] be a huge difference" - agreed.

    Hah! Well okay then, I'm glad I don't have to go redo everything.

    I hope we get to see a stronger version of this new rendering engine within a month or two. My game is probably 80% done (but hey, it's a game, it'll be 80% done forever) and the main thing holding it back at this point is this memory issue. It's very frustrating to play a game and get super far with a very high score and then have it just crash. I don't want to release the game if it does that all the time, that'll just cause angry customers and bad ratings. I can't tell them "If you've been playing for about 5 minutes, restart the game so the memory gets cleared out"

  • SocksSocks London, UK.Member Posts: 12,822
    edited May 2015

    @octopus1138 said:
    Hah! Well okay then, I'm glad I don't have to go redo everything.

    Obviously in this particular situation the issue is a bug in the work-in-process that is 14.1 . . . but . . . even if there was pronounced aliasing (blurring) issues due to image assets not sat on whole pixel values or/and not divisible by 2 (they are essentially the same issue) then you can solve the issue without having to redo any of your artwork by compensating for their indivisibility - for example if you had a 101 pixel wide image asset that was very slightly blurring/aliasing (and you could see it with your off-the-scale-super-eyes on an iPhone !!) you can simply offset the actor horizontally by 0.5 pixels - and Boom! Your image is back to being optimally sharp (whilst still not being evenly divisible).

    @octopus1138 said:
    I hope we get to see a stronger version of this new rendering engine within a month or two.

    Me too, really looking forward to seeing what it's capable of ! The schedule was 14.1 being released around a month after 13, so with 13 now out in the wild we should in theory see something in the next month or so . . .

    @octopus1138 said:
    My game is probably 80% done (but hey, it's a game, it'll be 80% done forever) . . .

    :smile:

Sign In or Register to comment.