Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
I think I've found what was really causing the problem. The GBA can switch into a prefetch mode where the instruction fetch time of certain instructions is reduced. (The reason a game would ever not switch into this mode is that it uses battery power faster.) Games that switch into this mode rely on it at times in order to continue running at the correct speed. VBA 1.72 did not have any support whatsoever for this mode. So sometimes instructions would take just enough longer to fetch that it would overrun the time of the next screen refresh, and then the game code would assume this hadn't happened and would wait for the refresh (for correct v-sync) causing an entire extra frame to go by every time this happened.
So, I'm now detecting when this mode goes on, and then making only certain instruction fetches 1 tick faster. The memory access delay table is all back the way it was before, and games that do not enter into prefetch mode aren't even affected. VBA will now display a message whenever the mode changes so you know what's going on, and I made it so enabling/disabling lag reduction takes immediate effect (no longer requires reset) so you can easily test for yourself what it changes.
Also, I fixed some text display problems and the AVI-already-in-use crash. So, I think now it's really stable (v8), barring any stupid crash bugs or something that hopefully I didn't add any more of.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
What things still need to change in order for it to qualify as a final release?
edit: Well, I guess that crash on trying to output an AVI file to an invalid place would be good to fix. Also, I've decided that the possibility of inaccuracy is much better than definitely inaccurate behaviour, but I am going to look to see if anyone else has already worked on this before in other unofficial improvements (such as one that added GBA link system support) so I can get some verification on what exactly the change should be.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Hmm, now suddenly 2 different opinions. Well, if it's decided that the 'lagless' timing is an acceptable improvement (which I also think it is, I think the lag does actually detract and it also causes in-game timers to keep counting down during the lag possibly causing things to be impossible that should be possible on the real system), then the Ctrl trick can be used to make and view movies with that option, without requiring a version change atm. Or we can wait a while on GBA games, I think some people here would object to that but I don't know what decisions will be made on the issue of allowing GBA game movies.
Keep in mind that the next release of VBA (the beta of it so far, I mean) is making this lag even worse still and VBA currently has no official developers that I know of, so it's probably not going to get fixed in an official release in quite a while.
About the incremental timing improvements, I would prefer not to put it through that; the options flags are already a little polluted, and if movies start getting made at lots of slightly different timing levels there'd be no comparing them.
I really don't know how it's expected to behave differently than it does with the current lag reduction option, though; there's no way to even try to refine it if I can't find any cases where it goes the wrong speed.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Hmm, looks good, so I only have a few time suggestions and a few more style/points suggestions:
time:
- at frame 30590, you slow down a lot. I know you think this didn't waste time, but I'm pretty sure you have to move further to the right to generate the horizontally moving platform that is the bottleneck, then you can fool around without wasting time
- every time you shoot a fireball that bounces, you lose 1 frame compared to shooting it directly into the enemy's face (probably because of extra time calculating the fireball's trajectory compared to when it disappears instantly).
- after 3-3, the time it takes to wait 1 height change and then go down the ladder to the fireflower is almost certainly greater than the time it would have taken to finish 3-3 at a different enough frame to get a straight path to the fireflower
- on platforms moving toward you that you jump on, I'm not sure you're jumping away at the earliest possible frame every time.
- at the start of 1-3, you jump, I would check to make sure that doesn't slow you down by jumping before you're fully accelerated.
style:
- around frame 845 you can do something more fun to get the coin block and kill the enemy (still without slowing down).
- around frame 2360 you can get the coins on both sides of the block without slowing down (making the mushroom appear didn't give any points)
- at 2580, I think it's possible to get all 3 coins at once
- at formations like the one at frame 5100, you can hit all 3 coin blocks without slowing down, not just 2
- you can get an extra coin at 9850
- you can run right up to enemies and jump at the last possible frame before touching them instead of having to jump earlier to land on them, I might've seen this somewhere but more often on goombas and things would be neat
- in the autoscrolling levels, if you let yourself almost get crushed off the screen and then shoot the block(s) away at the last moment, you'll keep going but you'll be mostly off the screen further left than normally possible (maybe neat to show off)
- picking up the mushroom you don't need in 2-3 would still give you bonus points, I think
- when you have to take a hit on spikes, if you jump at just the right frame you'll cancel the "getting hit" sound effect
And one more thing: it looks like you're shaking the Game Boy quite a bit (i.e. you seem to have some of your motion sensor buttons set to your regular arrow keys)
(anti-typo edit)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
OK, it's done. Version 7b should be stable.
There are still some requests/complaints that haven't been dealt with, but... that can come sometime later.
So... lag reduction is always turned off for movies with this. You can hold Ctrl to override that, but then it has to be done on playback too or it won't even open, so there is no possibility of a run using it unless everyone agrees it can.
(Remember to update the VBM format page along with everything else - look at 017 in the new vbm-format.txt file.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
To clarify, it does not play too fast when the lag is gone, it is actually the correct speed as far as I can tell; it is only too fast in comparison with the lag which shouldn't even be like that. Normal running around or whatever is exactly the same speed as before except in areas that slow down where it shouldn't slow down.
Anyway, I'll upload a stable version with lag always in recording/playback soon. If nothing else came of this, at least that desync problem due to the memory wait values not being stored was fixed.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
My changes have not been affecting what runs will work for of any of the runs people are working on - not GB/GBC/SGB at all, and not any runs started before on GBA. And I will maintain backward compatibility with them if I do make further changes, so I think there is no reason to delay opening VBA submissions just for this.
About the changes, I was satisfied with them, but if the majority of people here are not (I'm not sure, only 2 people have said anything about, they both don't like it but I'd like to hear more opinions responding to my last post on the previous page of this thread), then I will remove the possibility of recording with lag reduction on.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
TNSe wrote:
However, ignoring the differences will definately not make emulation accurate, and until someone figures out the right values, I think we should keep on using the values in 6 (before you changed anything).
Well, ok then. I'm not ignoring the differences, though - the memory access times still depend conditionally on the type of memory and I'm not skipping any memory delays either. The change is actually quite small.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Well, I've tried several versions of VBA and it seems this timing is actually constantly in flux between even official versions. And the special case I added is right next to a bunch of other special cases they seem to have added already. I think it's not too unlikely that they just got a value wrong for this case; I'm not as bothered by the possible logical inconsistency of it as I was before.
Anyway, being physically accurate must be more important, that's what emulators are trying to do after all. As it is, the amount of extra lag with the previous timing could actually cause tool-assisted runs to be quite a bit slower than speedruns done on the real GBA - the times just would not be comparable. I think the times will be a lot more comparable with it being more physically accurate, and I think it is more accurate without the excessive lag which clearly should not be there.
And you are right we cannot say it's perfect, but I don't think any emulator has ever claimed to achieve perfection, certainly this one wasn't before and won't be anytime soon. About the randomness, that is already different from the real thing.
Also, the change I made the second time wasn't completely arbitrary, and there is so much guesswork in what is already being done that it can't make it much less correct logically. So far I have actually found problems (glitches not really in the game) caused by the lag and have not found any caused by the lack of it, so I think the argument could just as easily be reversed. But if people would really prefer to stick to the way it is... that's fine, but I feel it is an unnecessary handicap.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
IcyCool wrote:
Another quick question. My SNES9x doesn't seem to want to let me press UP and DOWN at the same time. How to I activate it so I can???
It's a modified version which for now you can get here.
I don't know why that topic's locked now, but hopefully some of it will get into one of the next actual releases of Snes9x anyway. (I've just been prioritizing VBA since it didn't even have accepted re-recording support for any games.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Any specific examples of where it's inaccurate would help. I can say for sure that Samus is running at the exact same speed as before (I've compared the footstep sound timing between in the emulator and the real thing, and also I've tried recording a movie with lag on and playing it back with lag off and it stays in sync until I hit a section of the game that used to cause slowdown.)
I also think it would be good if anyone else wants to help with this.
(And I usually can't be on IRC because often my internet connection is barely good enough to stay online for the few seconds it takes to send a post.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
I already said it can be smaller. Changing your filter will make it half the size, changing the text display mode (in the Text Options dialog which also has some other things to play with) to On Screen will make it even smaller (back to the way the text used to be), or turning on the border will make it smaller relative to the window size.
About the fixed lagless option in v7, this obviously has different timing from the previous lagless option so any movies made with the previous lagless option will no longer play (will give "invalid version" error since they would just desync). I don't plan on changing this new timing again, unless someone can find something really wrong with it soon. It was the absolute minimum-impact change I could find that would fix the inaccurately extreme lag. (I also tested quite a few games with it this time just to make sure....) So, despite what I just said before, I think that those working on GBA runs should consider switching to this again.
(EDIT: to further clarify one more thing, I shouldn't be calling it "lagless", it still lags because it's supposed to lag a little, it just isn't as extreme as before. And I'm not hard-set on keeping it this way if you think it still needs to be further refined, I just didn't want to annoy you with too many timing change updates.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Bisqwit wrote:
nitsuja wrote:
BoMF: The text is intentionally cut off if it can't fit, and I shortened most of the messages specifically so it would happen less often
You could arrange the text so that most important information comes first, such as the frame number in the frame number displayer, and so on. That way, the rest of the message chopping away isn't terribly bad.
I think I've already done this, at the very least it is done with the frame count. But if anyone points out specific messages that are losing information at the moment, I can easily shorten/rearrange them.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
OK, I've found a much better way of getting rid of the lag. Rather than pretend all memory access is infinitely fast (how did I ever think that was right?) I reduce the number of ticks of only 1 value in the delay table by 1 to specifically target the situation of extreme lag, without speeding up other things much if at all. I think it's truly closer to being accurate emulation than the old versions, now. (EDIT: and by this I mean, check the first post for version 7 and let me know if it's better, I think its timing will work well.)
(BTW, as further evidence that it was inaccurate before, look at when BoltR makes the spin-jumps onto the top of where all those bugs come out of in his MZM run, the sprite totally glitches out when there was lag, and won't anymore.)
BoMF: The text is intentionally cut off if it can't fit, and I shortened most of the messages specifically so it would happen less often on GB, but even when it does happen there are many ways around it: Change your filter mode to anything except Normal, or change the text display mode to On Screen, or (maybe a little graphically weird but) turning the border on will also make enough room.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Ugh... maybe you guys are going to kill me, but I'm starting to really have second thoughts about this lagless thing. I'm really concerned that I've gone and made it way too fast - sure, it was way too slow before, but I'd prefer more accuracy. Maybe I'm not qualified to make this type of change; I really don't understand the hardware or what most of the emulator core is actually doing. Until this is really resolved, I suggest that people who were making runs continue as they were before (dealing with the lag) - I didn't mean to interrupt and until it's a completely sure thing I don't want any more effort wasted recording in a mode that is likely to be changed.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Released another slightly fixed update, 6c, hopefully this fixes GBA lagless mode desync problems. (I'm not completely sure they really existed, but if they did they should be gone.) GBA movies made with 6b aren't supported anymore, but that wasn't out for very long.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Well, try version 6c now. It takes into account the other half of the table (oops) and also saves that stuff in the save states. It's always possible there's something else I forgot, but I'm able to at least get past the boss in MZM and past 10000 frames without desyncs now.
EDIT: err, I mean, try version 7 now. (Maybe you're right, at this rate it'll hit version 20 pretty soon.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Apparently... I think I was forgetting something from the change. Hopefully not too much has been done with the changed settings since 6b was released.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
I'm wondering, are you (and other people currently making GBA runs) planning on finishing the run before going back and redoing it? It will be a lot faster without lag, but you've gotten so far already that maybe it's better to save that for a second version, I'm not sure.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
OK, this one I did have trouble playing, and I think I know why. It has to do with VBA not storing information about the cpu memory lag amounts in the save state as they change. To play back this movie correctly, I had to choose Enable GBA Lagging, then Reset the game (and let it run for a bit), and then play the movie.
This shouldn't be a problem anymore if you make the video clips in no-lag mode, because the amount isn't changing then (unless you play a without-lag from-snapshot clip immediately after viewing a with-lag movie of the same game).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Any luck reproducing this? I think maybe you found an obscure desync bug, which would be good to fix, but I've tried fiddling with settings and loading different games or parts of the game and haven't been able to get it to happen.
Unless, did you try starting the clip by loading a save state? Loading save states out-of-order is OK when recording, but it will immediately desync if you load an invalidated save state when playing back a movie (not usually a problem, since it doesn't actually record the desync).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1300)
Joined: 12/21/2004
Posts: 2687
Hey, that does seem to be right. You may want to check to make sure that GBA games also work and encode properly, since they do run under an entirely different emulator core with a different screen size. I suspect you'll have even worse performance problems with GBA games, though, since they're so much more CPU-intensive than GB ones.
I'm not sure the occasional stopping has to do with the sound - I think it does continue emulating even when the sound buffer runs empty (which is the reason for the sound buffer underrun errors). I was under the impression it had to do with the huge amount of A/V data being written (either disk access time or AVI processing time) and the fact that no frames are being skipped. (When I set the frameskip to 1 or 2 and don't output anything, this happens much less frequently for me.) Anything that stops the emulator will cause the sound to loop, including just dragging the window around. But I could be wrong about the sound not being a cause, maybe the sound buffer is triggering waiting when it's realized to be empty, I'll check or see if I can reduce the underruns.
About changing the character format, the problem is that the MFC control I get the text from doesn't seem to be able to handle anything else. If I type "Я", it displays as a little block, so even if I write unicode to the file, it will still not display as the correct character either when entering it or when viewing the movie's description in the dialog box (and I'm probably losing what the character should actually be due to receiving it as 1 byte). I think Snes9xw also has this problem for the display (despite attempting to handle the input as multibyte). There must be a way around it, but I've found nothing helpful about it on MSDN or anywhere else.
