https://files.tasvideos.org/bisqwit/vba-demo4.avi
Looks quite good.
There's one problem that bothers me.
Occassionally, VBA fails something with the sound. Remember, when I said wine outputs "err:dsound:DSOUND_MixOne underrun on sound buffer 0x77c51270".
During the recording of this clip, it outputted that line about 90 times.
Sometimes, wine suddenly hogs all the CPU power and VBA goes into a ultra slow motion mode, looping the same miniscule sample of sound very fast, until by some unknown reason it eventually continues with normal speed. During that time, those lines are outputted several times.
Is there a way to force VBA to output the sound in a non-blocking mode, so that even if there's a problem with talking to DirectSound, the emulator won't bother itself with it and just continues emulating?
It's not a problem that prevents recording those AVI files (I think), but it's annoying because wastes real life time to something completely unproductive.
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.
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)
No, that's not it - during the delay parts, MEncoder is idle, obviously waiting to receive more data.
It's not disk IO either, because it happens even if I specify the videolog as "cat >/dev/null", which means discarding the output entirely (it will never be written to disk or filesystem of any kind).
And it's not a interprocess delay either, because if VBA was waiting for the pipe, Wine wouldn't use any CPU power at all. Programs that are waiting in a syscall (such as fifo write) are idle - they don't count in CPU usage.
nitsuja wrote:
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.
Try finding out how FCEU does it.
Admittely, it doesn't use MFC...
But I find the locale-dependent encoding an unfavorable case of bad design.
Fixing it is clearly not a requirement for me (Famtasia does the same, and I have no choice but to accept it), but I feel the right thing to do is to use some variant of unicode, so as to not shun any users, no matter what alphabet they use.
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.
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.
I agree. I was talking about this in IRC earlier. Samus seems to run a little bit too fast in MZM now. I'd rather have it laggy than playing too quickly.
You should come on IRC again ;o
I agree that the games being too fast. In Circle of The Moon sliding among other things feel too fast. I haven't even seen a trace of lag yet. I'm gonna put my run on hold till we have everything settled.
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.
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.
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.
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.)
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.)
Yeah, BoltR still thinks the timing's inaccurate, although it's closer. GSGold thinks we need to bring in more developers. :)
What I ment when I said that was:
It is more logically inaccurate rather than phsyically inaccurate. Arbitrarily changing values in a table may solve to problem to our eyes, but doesn't mean the timing is correct, or even close to correct. Does that mean that when the game "randomly" generates the behaviour of an enemy, or the contents of a room that it is the same as on the console? While what you have done may be very close to what is proper we cannot say it's perfect, and there might be future problems. It is possible to get more favourable monster spawnings just by changing that memory access table.
The main point of me saying that:
To fix the problem I beleive the core of the emulator might need a rewrite, as that might be easier than breaking down and attempting to actually fix the [almost completely] uncommented code which is already there.
Not that i'm expecting or even asking you to do this, as that's not really fair. Although I think this might be what needs to be done in the end to fix the problem.
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.
I took a peek at the GBA hardware, and I see the problems the developers are having. There are different sorts of memory (ROM, IRAM and ERAM) which are accessed at different speeds and at different bitwidths... I can see that can cause problems during emulation.
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).
Anyway, thats my $0.03
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.
It seems that this emulator is in flux and will always be.
I'm ready to open the site for VBA submissions as soon as Nitsuja is satisfied with his changes and it's not expected that a new version is coming soon.
Edit: See updated rules.
I'm already having trouble handling two versions of snes9x...
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.
Well, I've kept with the laggier version of circle then the one that plays too fast. People have said they would rather see a slightly laggier version then the one that plays too fast. The lag really isn't a problem in circle..it definately doesn't detract from the watching experiance.
So I believe we should accept the slightly more laggier versions then the ones that play too fast for now. My 2 cents.
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.
