Question about the Debug Console

Hi,

can anybody tell me what the three values in the upper left corner mean, when you open the debug console with TAB?

I looked up the manual and tried the forum search, but I somehow did not find anything, although I am sure this is already explained elsewhere, so pardon me.

... ms - no clue

... M - is this Memory used, or is it VRAM used?

... % - is this CPU time?

Any help appreciated, as I have currently around 3500 - 3900 M standing there, and I wonder if this is VRAM, if my game might have to high system specs

2. estimation of the vram (adding texture memory)

3. cpu time in percent

3500M is definitly too much, stay under 500M for most system, if you have high-end requirements you can aim for 1000M.

Thank you very much for the fast answer, Simon.

So I can start to optimize, I somehow knew it

I don't think the VRAM usage is especially important, but it's definitely better to aim for less so that more people will be able to play your game. I think the most common dedicated gpu vram these days is 2GB, though plenty of people have much more than that these days.

For optmization, try to use less animation frames, less animations playing at the same time, don't use animations that have a background canvas size that is the same size as the default game resolution, don't use duplicated images to control the length of animation frames that should display for x amount of frames - instead set a custom pause value on those frames, & if you use the preload animation system... always & I mean always make sure you manually unload those animations when you no longer need them otherwise your VRAM usage will just keep filling up & up as you preload more animations & your game will eventually start running slow (lagging).

I rack up around 500mb or so with ALLD which is running @ 1080p. I don't preload & I utilize the various methods I mentioned above to keep animation file size, frame amount & canvas sizes down. I even create some animations smaller than the width/height we need them to be & scale them up using Lua script. For example some ripples on this pond which didn't require super sharp details...

@atrus, of course this is not justified, in no way I fear

The game is in 1920 x 1080, One scene is 3500 x 1080 and another one currently 5000 x 1080, intended to be about the double in width later, so I thought this might be the problem.

But it really is only about the main character and his animations, I fear.

I use rendered scenes and characters, so I thought it might be good to make the char quite big to have a good quality when she's close to the camera. So I used 1024 x 1024 frames, and with a smooth walking animation including start and stop (which currently are just part of the walking cycle), I have a count of nearly 120 frames per direction. So I guess this is a little bit overkill, although it runs very well on my personal rig

Currently, a one frame standing animation takes 4 MB and a walk cycle 445 MB for each direction...

I think I will try to go down to 512 x 512 at maximum, and I will see what I can do with the walk cycle... I just looked up for fun Daedalics Pillars of the Earth, which needs 512 MB and recommends 1024 MB, so I have some way to go there

I always thought that only the textures currently displayed were part of the VRAM, not all the animations at once

Just for information, if a users graphics card has only, say, 512 MB VRAM, what would happen with the game? Will there be "only" stuttering or might there occur some crashes, if it needs 4000 MB like now? I tested the game on my dad's Notebook, which I doubt has as much VRAM (what I will have to check next time I visit him), and it was working well there, too.

You don't need 100's of frames to create a smooth looking walk animation or animations in general when it comes to 2D games. It's not a 2D animated video so ultra smoothness is not needed, instead limit your frames & try messing about with the global pause value for the animation & custom pause values for certain frames. With a bit of messing about you should have a fairly smooth looking animation - there's no need for duplicate frames or frames containing microscopic movement because it's really overkill.

As for the size of your characters you should consider something around 50% of the height of your default game resolution - give or take (because not all characters will be the same height). Also you should crop all animations per character to the highest one & widest one - it's not as optimized as cropping each animation but it saves time of you having to mess around aligning each animation.

I think on average your animation frames should be approx 50-200kb each. Will be even smaller if you convert your png to webp, but that doesn't reduce VRAM usage.

Thank you for the explanation, Simon. This makes things much clearer.

ARFLme, the webp conversion will be the last step when the animations are in their final shape. I tested it with XnConvert already, and the results were satisfying, but it is a process I don't want to do everytime I change something, but one time in the end. After all, it's "only" optimisation of disk space

Currently, one walking animation (direction) takes about 42 MB disk space, with 115 frames that include a walk start and a walk end, which adds up to about 450 MB in VRAM

I tried the integrated webp conversion you can use while building, but the result was awful and it messed up the graphics too much. Maybe this is something that could be enhanced in a future update

As you say that the char should be about half of the height of the resolution, I think I will first try 512 px and severly limit the frame numbers

Simon, would you say technically that cropping the images left and right would be helpful or not?

Thank you both for your help

I work directly with webp in the editor because it gives me a better idea of how the game will run from the get-go. I keep the png in case I need to edit them, but I don't mind having to delete & reconvert the edited png to webp again as I just drag them into XnConvert & press the convert button & it's done in less than a minute (lossless webp) & it automatically names the files with the same name as png & puts them in the same location.

WebP isn't just hdd usage optimization, the smaller file sizes = faster loading times for images & animations, which means that lower spec pc players can play your game much smoother.

& yeah, the webp export option as well as the scaling export options aren't really recommended. Best to convert yourself - as for scaling... :shrug: