Bizarre custom.exe slowdown because of a hero sprite
Moderators: Bob the Hamster, marionline, SDHawk
Bizarre custom.exe slowdown because of a hero sprite
I made a sprite in hero graphics editor the other day and now the hero graphics menu moves at a snail's pace. And ONLY for this particular .RPG game. And it goes back to normal speed if I erase the sprite.
I created the .RPG file with the 6/16/14 Nightly build. I just downloaded the latest Nightly, loaded my game in it, and it behaves in the same fashion.
Was wondering if James or TMC would like me to Dropbox them the .RPG file for research and possible bug fixing.
I created the .RPG file with the 6/16/14 Nightly build. I just downloaded the latest Nightly, loaded my game in it, and it behaves in the same fashion.
Was wondering if James or TMC would like me to Dropbox them the .RPG file for research and possible bug fixing.
- Bob the Hamster
- Liquid Metal King Slime
- Posts: 7460
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Sent you a link.
I was freaking out, thinking my HDD was dying or something, since custom.exe is the last thing I'd expect my computer to experience slowness on! It did put fire under my feet to dismantle, deep clean and reassemble my whole computer this morning, though. Even if it ultimately didn't make a difference for this particular issue.
I was freaking out, thinking my HDD was dying or something, since custom.exe is the last thing I'd expect my computer to experience slowness on! It did put fire under my feet to dismantle, deep clean and reassemble my whole computer this morning, though. Even if it ultimately didn't make a difference for this particular issue.
- Bob the Hamster
- Liquid Metal King Slime
- Posts: 7460
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
It's Hero Set 0 and Attack A frame. I didn't check the CPU load, but didn't notice slowness outside of custom.exe when this issue occurred. The slowdown would happen when selecting a sprite frame to edit, it'd lag for a good 5 seconds, and it would also do the same lag when scrolling up or down to other sprite sets that were offscreen (i.e. past the fourth set). It lagged in the same way when viewing full spritesets, too.TMC wrote:This is really bizarre. What was the hero spriteset ID/number that caused the problem? Does custom.exe use 100% cpu when in the menu? Is it slow in both the top-level spriteset list and in the sprite editor itself? What happens if you press ctrl+F to view/edit full spritesets?
Spriteset 0? So by creating and erasing the sprite you mean drawing something and blanking it out again. Does the problem reoccur if you scribble something in that frame? I expect that this problem is not caused by Attack A of spriteset 0, but its involvement is a coincidence.
Could you send us c_debug.txt (which should be in the same directory as the .rpg file) after running custom.exe and experiencing the lag? Send c_debug_archive.txt instead if you didn't get any lag the last time you ran Custom.
Could you send us c_debug.txt (which should be in the same directory as the .rpg file) after running custom.exe and experiencing the lag? Send c_debug_archive.txt instead if you didn't get any lag the last time you ran Custom.
Last edited by TMC on Sat Jul 05, 2014 9:39 am, edited 1 time in total.
Yeah, here's the archive. I've since replaced and redone the problem sprite, I did encounter the same issue once more in a different frame but moved past it. It's currently not happening anymore.
https://www.dropbox.com/s/e1lya9ns49iox ... rchive.txt
https://www.dropbox.com/s/e1lya9ns49iox ... rchive.txt
Last edited by Foxley on Sat Jul 05, 2014 1:28 pm, edited 1 time in total.
Thanks. There aren't any messages related to that lag, but I investigated a number of other interesting messages (none of which were significant problems). I often see unexpected things when looking at somebody else's debug log.
I added some timing to help pin down unexpected lags such as this one, but nightly builds aren't working at the moment. Once we fix them you could download a nightly and then send us back the debug log if it happens again.
I added some timing to help pin down unexpected lags such as this one, but nightly builds aren't working at the moment. Once we fix them you could download a nightly and then send us back the debug log if it happens again.
- Bob the Hamster
- Liquid Metal King Slime
- Posts: 7460
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
I tested this rpg file on the Windows 7 box that build the Windows nightlies. I was not able to reproduce the problem.
I tried with both the directx backend and the sdl backend, and either way, I could not see any lag or slowdown or unusual processor usage.
There must be some other factor that makes Foxley's computer different from mine.
Also, I noticed a strange bug in the sprite editor when using the gfx_sdl backend. As soon as you go into the sprite editor, the window shrinks and becomes slightly smaller than 320x200. When you exit the sprite editor, it goes back to 320x200
I tried with both the directx backend and the sdl backend, and either way, I could not see any lag or slowdown or unusual processor usage.
There must be some other factor that makes Foxley's computer different from mine.
Also, I noticed a strange bug in the sprite editor when using the gfx_sdl backend. As soon as you go into the sprite editor, the window shrinks and becomes slightly smaller than 320x200. When you exit the sprite editor, it goes back to 320x200
- Bob the Hamster
- Liquid Metal King Slime
- Posts: 7460
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Does that mean that the problem does not happen at all on your new computer?Foxley wrote:I can't even think of what it might've been if it isn't reproduceable. Hmm. Well, this was on my (as of this afternoon) old computer, which I was keeping together with spit and elbow grease since 2007, could've been a side effect of a random ailing part on the motherboard, or who knows what.