![]() A very helpful guy from valve then crunched through it, and found that an alarming amount of time was spent in the sound library, and in Heapvalidate(), called from it. Then, finally we found some helpful players who not only had the bug, but were happy to run diagnostic code on their PC for valve to analyze. I also changed a callback to run every 100 frames rather than every frame, and again, no difference. I ended up moving the code that initialised steams systems from one point in my code to another, as they recommended, but there was no change. So that resulted in a ton of going through it with a fine tooth comb and checking every parameter, asking valve if I was doing it right, checking with other devs how I was doing it compared with them etc. Initially, I assumed it must be something about the steam integration code. This was followed by weeks, maybe even months of me investigating what on earth it could be. A good workaround, but not actually a fix. exe, outside of steam, enabled it to run perfectly. Happily, this was confirmed by the realisation that running the game from the. Not given the specs of the users reporting it, which was a wide cross-section of hardware types. Right from the start I doubted that this was actually the games graphics engine or core gameplay code running slow. Regular blog readers will know I am a bit obsessive about optimisation, so naturally this seemed weird to me. The bug was basically that the game ran horribly slowly, with stuttering and skipping music. Right from it’s initial launch on steam, there was a bug reported in Gratuitous Tank Battles for a tiny subset of steam players.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |