Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Major slowdowns #21

Open
IlDucci opened this issue Mar 2, 2018 · 11 comments
Open

Major slowdowns #21

IlDucci opened this issue Mar 2, 2018 · 11 comments

Comments

@IlDucci
Copy link

IlDucci commented Mar 2, 2018

I just want to leave a place so you know where you can find the largest slowdowns in the game.

So far, the most obvious one I've seen is during the resonance cascade in Unforseen Consequences. With the HD models, I've managed to get to 9 FPS with Release 2. There's other slowdowns but they are just going from 60 to 20-30 FPS, so I don't think they're that relevant.

@spacebruce
Copy link

spacebruce commented Mar 2, 2018

I've had it go under 1 fps shortly after the cascade (Around the area where you first meet headcrabs), but was unable to reproduce the problem, and reloading fixed it.
I think it may have been triggered by putting the vita to sleep mode during an autosave but I can't be sure.

I was quite amused to see the framerate counter flip to seconds per frame mode when slower than 1fps.

@fgsfdsfgs
Copy link
Owner

fgsfdsfgs commented Mar 2, 2018

@bakagamedev, I had that happen to me during testing. This is caused by the game running out of memory. It tries to load something (was a decal texture in my case), but fails due to insufficient memory, so it keeps retrying every frame until you shut it off. There's no fix for this except restarting the whole thing.

The easiest way to trigger an out of memory situation in Release 2 is to complete Hazard Course and then start a new game. It will happen exactly after the first mapchange in Unforeseen Consequences.

Since 3d56e23 it's more difficult but still possible to run out of memory in such a way.

@a1batross
Copy link

@fgsfdsfgs Sadly, you can't do so much about memory consumption. Engine doesn't have too much places that can't be reduced to allocate smaller memory. You may enter "memlist" in console to get allocated memory for exact zones, it may help in debugging.

And I thought, Vita has 512M RAM? How much you can allocate? Engine shouldn't run OoM on 256M.

@a1batross
Copy link

Meanwhile vitaQuake allocates 192M heap and some ports even use 240M.

@fgsfdsfgs
Copy link
Owner

fgsfdsfgs commented Mar 3, 2018

@a1batross 282 MB RAM and 112 MB VRAM is available to user apps. In Release 2, 128 MB of the 282 are allocated for the malloc heap, I decreased it to 96 later, because having a smaller heap size leaves more memory for vitaGL.

vitaGL seems to dynamically allocate a lot of RAM for internal purposes. It also doesn't do this through malloc, but by directly calling kernel memory allocation and mapping routines. Also, a 32 MB scratch buffer is preallocated for it on startup to store vertices and other temporary data.

It seems that because Xash is more graphically intensive than, for example, vitaQuake, vitaGL requires more non-heap memory, and so increasing heap size beyond 128 MB leads to crashes in vitaGL. Decreasing the scratch buffer size also leads to crashes, but I'll have to confirm this because I've not tried decreasing it in a while. The vitaGL dev is currently carrying out major refactoring and optimization of its code, so its memory consumption could probably improve. I'm not sure how correct I am about this.

There is an expanded memory mode that gives you access to 109 more megabytes of RAM, but it seems that I either can't get it to work or it's enabled by default.

vitaGL also has a hard limit of 1024 textures by default, which I increased to 2000 for Release 2, but that limit can't be increased any further because of the way it allocates texture memory. This also was the source of multiple crashes, so it still might be causing some.

@a1batross
Copy link

I don't know so much about rendering on Vita, so I didn't knew that vitaGL is so memory heavy.

Ah, I know. You can try to decrease max edicts, max tents(temp entities) and max particles. These are appended to gameinfo.txt after converting it from liblist.gam. HL1 doesn't relies too much on temp entities, so you can decrease it safely. Be careful with max edicts, if you will run out of edicts, you will see a Host_Error.

@spacebruce
Copy link

spacebruce commented Mar 3, 2018

You'd know if expanded memory was working, you'd be unable to launch any other app while this was running, even basic things like the system settings app or user manuals.

@fgsfdsfgs
Copy link
Owner

@a1batross Decreasing max edicts and such isn't probably going to help, since they are heap-allocated, and the game seems to be running out of non-heap memory. You can run CAGED on the latest commit without much trouble, for example, and that requires a max edicts of 4096, yet on latest commit the heap size is 96MB. I'm probably just leaking memory somewhere in my code and blaming it on vitaGL, but it's not as simple anyway.

@bakagamedev I know that, and that's actually what's happening in the latest version, where I tried to enable the expanded memory mode, yet it still crashes if I increase heap size beyond 128MB like before. So it either doesn't work or there are memory issues somewhere else. Could also be related to the fact that I have two executables. Maybe expanded memory mode turns off after I exec the game executable from the launcher.

@fgsfdsfgs
Copy link
Owner

Switching to custom shaders (ddf0c6e) seems to have increased rendering performance, but not as much as I'd hoped. Yet, HL rarely dips below 30 FPS now.

@Damin72
Copy link

Damin72 commented Mar 9, 2018

Slowdowns is not so annoying as these freezes (I think because game trying load some sound effect/something different)... =/

@IlDucci
Copy link
Author

IlDucci commented Mar 10, 2018

Good job! Now the resonance cascade only dips to about 20 FPS plus loading spikes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants