Really, the problem is just no straightforward way of expanding the number of "QuickSave" style slots available. Rather than working with folders, it might be easier to implement "sets" of save states, with a button to cycle between them. The set just corresponds to another digit on the actual savestate files this way.
I load a state A (this is the starting point).
I advance to a certain frame*.
I load state A again.
The next frame, it shows the glitched sprites. The frame after that, it is normal again.
If I advance to a different frame, and then load state A, it doesn't happen.
I think other effects that I saw was that my character and enemies turned invisible.
I'm noticing this problem especially in the current level I'm in (The Smurfs GB, level 11 "The Cliff").
I turned off the luascript and it still happens. No memory freezing or lua memory editing is going on. Seems to be graphical only.
___
*This frame will always produce the problem. The chance of landing on such a frame is really high in The Smurfs GB, level 11.
after a while of opening, closing then reopening TAStudios over and over. Currently the only "fix" is to close and reopen the emulator.
I noticed using this gives a different result in both emulators:
VBA prints: 1.79489673697e-009 Bizhawk prints: 1.79489673696339E-09 Is this a bug?Language: Luaangle = 0 -- as read from memory when not tilting AngleDegree = angle * 1.40625 -- converting from 0-255 to 0°-360° RPD = 0.0174532925 -- radians per degree print(math.cos(-(AngleDegree+90)*RPD))
VBA prints: 1.79489673697e-009
Bizhawk prints: 1.79489673696339E-09 I added +1 and it looks like before. This is good enough for my purposes.Language: Lua-- draw line from yoshi to this destination (*80 factor is how far the line goes) des1 = math.sin(AngleDegree*RPD)*-80 des2 = math.cos(-AngleDegree*RPD)*80 des3 = math.sin((AngleDegree+90)*RPD)*-80 des4 = math.cos(-(AngleDegree+90)*RPD)*80 gui.drawLine(Xscreen,Yscreen,Xscreen+des1,Yscreen+des2,0xFFFFFFFF) -- below yoshi gui.drawLine(Xscreen,Yscreen,Xscreen-des1,Yscreen-des2,0xFFFFFFFF) -- above yoshi gui.drawLine(Xscreen,Yscreen,Xscreen+des3,Yscreen+des4,0xFFFFFFFF) -- left of yoshi gui.drawLine(Xscreen,Yscreen,Xscreen-des3,Yscreen-des4+1,0xFFFFFFFF) -- right of yoshi (this is the line that looks off, but by adding +1 it looks as before)
I'm not sure if it's just the build I'm using, or it's like this for others, but for some reason, if I opened BizHawk and do nothing, according to Task Manager, it uses like 30% CPU. As soon as I load a GBA game (not sure of others) and pause, it immediately drops to like 2% usage. So here's 2 questions: 1. Anyone have this problem? 2. How does that even work?
void gui.drawText(int x, int y, string message, [color? forecolor = null], [color? backcolor = null], [int? fontsize = null], [string fontfamily = null], [string fontstyle = null], [string horizalign = null], [string vertalign = null])
Language: Luawhile true do gui.drawText(50,60,"hillo",0xFF0000) emu.frameadvance() end
Isn't it supposed to be red text?
Isn't it supposed to be red text?
I was browsing through this file because it's a good resource for console frame rates, but noticed that it hadn't been updated with info for a few of the recently added consoles, particularly N64 and Saturn. Does anybody have info for those?
