Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers AppGameKit Corner / Game slows down

Author
Message
ThePict
6
Years of Service
User Offline
Joined: 6th Nov 2017
Location:
Posted: 11th Apr 2021 10:41
My game uses about 60 sprites. I set them up outside the main loop, then DrawSprite() them within the do>sync()>loop. My games last barely a minute, then repeat with a new puzzle, but after about 6 games the game runs quite slowly, after 10 it is struggling to run at all. I have a feeling it is loading new sprites over the previous ones, and getting bogged down with old data.
Maybe a clean start, deleting all sprites and loading them again from scratch, but seems a bit overkill. Any thoughts anyone?
PartTimeCoder
AGK Tool Maker
9
Years of Service
User Offline
Joined: 9th Mar 2015
Location: London UK
Posted: 12th Apr 2021 00:04
reusing sprite ID's does not reuse the sprites associated with the ID, you need to delete previous sprites and clear any arrays before generating more.

If you have generic sprites that appear in every level like a background or border then these are safe to keep just make sure they only get loaded/created once, for the puzzle pieces there are a number of ways to handle them, delete/recreate, set image, clone/instance from a master sprite or as you use drawsprite you can use a single sprite with setimage/position but for 60 sprites I would just let AppGameKit take care of the drawing and just sync()
Phaelax
DBPro Master
20
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 13th Apr 2021 14:32
Sounds like you might be reloading the images with each new game.
Tiled TMX Importer V.2
XML Parser V.2
Base64 Encoder/Decoder
Purple Token - Free online hi-score database
Legend of Zelda

"I like offending people, because I think people who get offended should be offended." - Linus Torvalds
n00bstar
20
Years of Service
User Offline
Joined: 9th Feb 2004
Location: Montreal, Canada.
Posted: 15th Apr 2021 22:14
Sounds like a sprite problem. Like you keep creating more and more sprites without ever deleting any of them.

GetManagedSpriteCount() could help you figure out if that's the case.

Some useful benchmarking commands here:
https://www.appgamekit.com/documentation/Reference/Benchmarking.htm
-----------------------------------------------------------------------------
We all got a chicken duck woman thing waiting for us
Raven
19
Years of Service
User Offline
Joined: 23rd Mar 2005
Location: Hertfordshire, England
Posted: 5th May 2021 03:01
If we assume for a moment that what you're doing is loading new images as sprites each game... then we're still only talking about 600 or so Sprites.
Now if we also assume that these are all quite "Large" Sprites... say 1024x1024 PX then we'd be looking at a grand total of 2.4GB VRAM being used.

On the surface this might sound like a big issue but actually., keep in mind that only 60 of them (240MB) is actually in-flight., and this actually ends up being important; as it's smaller than the 256MB PCIe Block Limit; this means the Drivers (or in the case of Vulkan., the Memory Management System) can swap out said Memory Block between Active and Inactive Blocks at little to no performance penalty with the System Memory.
I mean, sure there might be a few seconds of initial lower framerates; but it essentially would end up in the Video Memory; and running like normal... and given System Memory is likely to be larger than the 2.4GB required from not releasing Images / Sprites / etc. well then there shouldn't strictly be an issue at 10 "New" Instances... possibly 16 or more.

No, the issue is less likely to be that you're not cleaning things up per se... as you're almost certainly still DRAWING all of those previous Sprites.
I mean you've said you're manually calling "DrawSprite( )"., that's not strictly necessary unless you're manually controlling the whole Draw Queue., actually it's a bad idea unless you are... because in most cases you're going to be drawing the Sprites twice.



Now something to note is when you load an Image., you DO NOT have to make a Sprite out of it... just as if you create a Sprite you don't HAVE to assign an Image initially; but by default it does expect it.
If (as I assume we're talking about some Tile-Based Puzzle Game)., you KNOW how many Sprites you need to manage and draw; then a simple solution is to ONLY create the number of Sprites you need...

As far as the Images used., well these can either be Pre-Loaded all at once (when you start the Game) or on a Level-by-Level Basis., where you are Loading / Deleting based on what will be used on such.

Remember my est. above (given you provide ZERO information) are based on the assumption of Large Images being used for the Sprites; chances are you're using much smaller images., and frankly none of the memory should be an issue at all... but I almost guarantee the sheer volume of sprites is.
Yes., AppGameKit can actually handle several thousand sprites just fine; but YOU can't manage that many Drawing them Manually as AppGameKit Script is SLOW, esp. when it comes to For..Next Loops.
Believe it or not but a Repeat...Until is a noticeably faster loop (~22ms difference when we're getting up to 10,000 Loops) and when you throw in a Draw Call as well; eh., well yeah you'll definitely start to see some slowdown at say 600 of them per loop.

So, go over your code and just make sure you're ONLY drawing say the Last 60 Per Frame; rather than an entire Array

Login to post a reply

Server time is: 2024-03-29 13:59:16
Your offset time is: 2024-03-29 13:59:16