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.

Yes, I would like to see the rpg file

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 just tested the rpg file you sent me, and I am unable to reproduce the problem on my Linux box. That makes me think it might be a Windows-specific problem. I won't have access to a Windows box until next week, but I'll test it again then.

Nice pixel art, by the way! :)

Thanks!

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?

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.

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.

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/e1lya9ns49ioxvi/c_debug_archive.txt

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.

Well the default nightly builds (the ones linked from the Download page) are working and have been built. (Some problems with the others)

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 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.

My guess is that it was a file IO problem, such as due to a harddisk problem.

Does that mean that the problem does not happen at all on your new computer?