<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Just wanted to note that VBA-24-m's lag counter doesn't work with GB Kung-Fu Master. Should be possible to bypass this problem by using lua to check if the character moved during a frame, but still..
EDIT:
Slowed down emulation is still present in the latest vba 24 svn version. (...).
I added an issue for it here.
The problem seems to happen if a certain unknown condition is met. Once that happens, every subsequent saving and loading of a state will result in slowdown of the emulation.
Here is a demonstration:
http://www.youtube.com/watch?v=sbLuPvgP8SM
Just wanted to note that VBA-24-m's lag counter doesn't work with GB Kung-Fu Master. Should be possible to bypass this problem by using lua to check if the character moved during a frame, but still..
I haven't tested that game though, but I don't think it is a bug. The emulator cannot tell that there is a "lagged" frame if the game does read the input but does not move the game character according to it.
MUGG wrote:
Slowed down emulation is still present in the latest vba 24 svn version. (...).
I added an issue for it here.
The problem seems to happen if a certain unknown condition is met. Once that happens, every subsequent saving and loading of a state will result in slowdown of the emulation.
Here is a demonstration:
http://www.youtube.com/watch?v=sbLuPvgP8SM
Quickly resolved. New downloads are available: http://code.google.com/p/vba-rerecording/downloads/list
EDIT: The bug is from old v20: a variable used for LCD timing is erroreously multiplied by 2 everytime a savestate is loaded in GBC if certain conditions are met, which will mess up with frame timing.
The v19-v23 branch is not affected.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Nice, but... I can't seem to be able to load any savestates with 24m svn 391. Folder "saves" is in the emulator directory, but whenever I save a state it wouldn't actually place any files in that folder and in the menu "load state" has all entries grayed out.
Was a temporary problem, it's fixed now mysteriously.
When playing back a recording in the new vba24-alpha svn392, I keep hearing this static sound about every 1400 frames. I'm not sure if this was something caused by the savestate fix, but it would be nice if you could look into it.
EDIT: Never mind, this isn't an emulator problem, just a problem with my computer. Sorry...
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
I was planning on taking a look at the timing bugs in the GB core of v8.24 today, but I cannot compile it with the VS2008 solution (rev 391) and I have been trying for hours to fix the errors to make it compile but no success...
First it complained about some 60 files that didn't exist (fixed that by re-including them)
Then it complained about some external symbols that where re-defined with another type (fixed that)
Now it is complaining that it cannot resolve external symbols (not the same as I corrected) [Linker error LNK2001 and LNK2019]
klmz, would you mind taking a look at this?
(I usually program in Linux, so I don't have a lot of skill working with Visual Studio)
You must have checked out the right branch http://vba-rerecording.googlecode.com/svn/branches/v8.24, haven't you?
The VS2008 solution has been out of date, as well as the VS2005 one has. For whatever reason, MS modified the VC++ project file format in VS2010, so you cannot simply edit the up-to-date VS2010 project files (VBA2010.vcxproj and VBA2010.vcxproj.filters) and open them with VS2008. So the best solution (no pun intended at all) would be that you fix the VS2008 one manually.
To fix the linker errors, add these Additional Dependencies (to all building configurations that you might be interested in):
directx/d3dx8.lib;wsock32.lib;directx/ddraw.lib;directx/dxguid.lib;winmm.lib;directx/dinput.lib;vfw32.lib;opengl32.lib;nafxcw.lib;libcmt.lib;lua51.lib;
and Ignore Spefic Default Libraries (to all building configurations that you might be interested in):
libci.lib;nafxcw.lib;libcmt.lib;
Note: you may delete the names of the two libs in Italic if the linker didn't complain about them.
EDIT: I almost forgot that, you should check whether the lib directories were configured correctly.
EDIT2: Hotfix for the unusual edit/record movie mode bug reported by MUGG.
v7.23.5.394 "v23.5a" (or should it be "v23.5c"?): http://code.google.com/p/vba-rerecording/downloads/detail?name=vba-rerecording-svn394-win32.7z
v8.24.0.393 "v24m": http://code.google.com/p/vba-rerecording/downloads/detail?name=vba-v24m-svn-r393.7z
v7.24.0.395 "v24-alpha": http://code.google.com/p/vba-rerecording/downloads/detail?name=vba24-alpha-svn-r395.7z
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
klmz wrote:
You must have checked out the right branch http://vba-rerecording.googlecode.com/svn/branches/v8.24, haven't you?
The VS2008 solution has been out of date, as well as the VS2005 one has. For whatever reason, MS modified the VC++ project file format in VS2010, so you cannot simply edit the up-to-date VS2010 project files (VBA2010.vcxproj and VBA2010.vcxproj.filters) and open them with VS2008. So the best solution (no pun intended at all) would be that you fix the VS2008 one manually.
To fix the linker errors, add these Additional Dependencies (to all building configurations that you might be interested in):
directx/d3dx8.lib;wsock32.lib;directx/ddraw.lib;directx/dxguid.lib;winmm.lib;directx/dinput.lib;vfw32.lib;opengl32.lib;nafxcw.lib;libcmt.lib;lua51.lib;
and Ignore Spefic Default Libraries (to all building configurations that you might be interested in):
libci.lib;nafxcw.lib;libcmt.lib;
Note: you may delete the names of the two libs in Italic if the linker didn't complain about them.
EDIT: I almost forgot that, you should check whether the lib directories were configured correctly.
EDIT2: Hotfix for the unusual edit/record movie mode bug reported by MUGG.
v7.23.5.394 "v23.5a" (or should it be "v23.5c"?): http://code.google.com/p/vba-rerecording/downloads/detail?name=vba-rerecording-svn394-win32.7z
v8.24.0.393 "v24m": http://code.google.com/p/vba-rerecording/downloads/detail?name=vba-v24m-svn-r393.7z
v7.24.0.395 "v24-alpha": http://code.google.com/p/vba-rerecording/downloads/detail?name=vba24-alpha-svn-r395.7z
I grabbed the latest rev of the ones modifying the 8.24 branch (should be rev. 391)
I will try editing those linker settings and see if it compiles for me. Thanks!
Sadly updating to VS2010 is not an option for me :(
So which version should we developing, the VBA-M based one? What's different in the VBA-M version anyway?
From what we've been seeing and will be seeing, I can tell that the old good v1.7.2.560->v7.23.5.x is the most popular and widely used. It should be maintained without becoming incompatible (or the whole point is lost).
I would suggest implement new emulation-level features on v8.24, which would not cause too many compatibility problems for players.
The legacy v20.x is supposed to be used for watching certain movies that require this particular major version. It was updated twice just to be more comfortable to use.
The v7.24 (the codename "alpha" suggests its fate) can be discontinued if the v8.24 branch works. It was there just in case the new GBA core might exposed unexpected problems - do you still remember the tale of v20.0?
Conclusion:
v7.23: Shouldn't be made any more incompatible with older versions.
v8.24: New stuff e.g. master code here!
v20 & v7.24: You may forget about these. Just leave them to me or someone else bored.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
I see, so the VBA-M version doesn't have the same timing; I assume it has better timing?
I hope so. It is less laggy in some games and much laggy in some other games. In the former situations, it seem more accurate compared with the real GBA. In the latter situations, I don't know.
Note: you may try to use an extern GBA BIOS (if you have one) with the old/new cores to see whether it makes a difference. The new core seems to be more consistent when it is with and without a BIOS.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
From what we've been seeing and will be seeing, I can tell that the old good v1.7.2.560->v7.23.5.x is the most popular and widely used. It should be maintained without becoming incompatible (or the whole point is lost).
So...there would be 2 branches of the emulator like the SNES? Wouldn't that make it hard to compare runs made in different branches and also make it annoying to maintain both branches?
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Warepire wrote:
klmz wrote:
You must have checked out the right branch http://vba-rerecording.googlecode.com/svn/branches/v8.24, haven't you?
The VS2008 solution has been out of date, as well as the VS2005 one has. For whatever reason, MS modified the VC++ project file format in VS2010, so you cannot simply edit the up-to-date VS2010 project files (VBA2010.vcxproj and VBA2010.vcxproj.filters) and open them with VS2008. So the best solution (no pun intended at all) would be that you fix the VS2008 one manually.
To fix the linker errors, add these Additional Dependencies (to all building configurations that you might be interested in):
directx/d3dx8.lib;wsock32.lib;directx/ddraw.lib;directx/dxguid.lib;winmm.lib;directx/dinput.lib;vfw32.lib;opengl32.lib;nafxcw.lib;libcmt.lib;lua51.lib;
and Ignore Spefic Default Libraries (to all building configurations that you might be interested in):
libci.lib;nafxcw.lib;libcmt.lib;
Note: you may delete the names of the two libs in Italic if the linker didn't complain about them.
EDIT: I almost forgot that, you should check whether the lib directories were configured correctly.
EDIT2: Hotfix for the unusual edit/record movie mode bug reported by MUGG.
v7.23.5.394 "v23.5a" (or should it be "v23.5c"?): http://code.google.com/p/vba-rerecording/downloads/detail?name=vba-rerecording-svn394-win32.7z
v8.24.0.393 "v24m": http://code.google.com/p/vba-rerecording/downloads/detail?name=vba-v24m-svn-r393.7z
v7.24.0.395 "v24-alpha": http://code.google.com/p/vba-rerecording/downloads/detail?name=vba24-alpha-svn-r395.7z
I grabbed the latest rev of the ones modifying the 8.24 branch (should be rev. 391)
I will try editing those linker settings and see if it compiles for me. Thanks!
Sadly updating to VS2010 is not an option for me :(
I have checked now and those are already in the linker command line. Removing the libs in italic did nothing
Here is my build log, maybe that explains the problem better:
http://www.mediafire.com/?9n5aqagmk7qa9yy
It seems that you forgot to add src/gba/GBA-arm.cpp and src/GBA/GBA-thumb.cpp into your project.
The LNK2001 errors were caused by the deifinition of int/int32/int32_t/long (do you build on a 64-bit system?). I committed some changes (SVN rev. 396) to work-around them, but I don't know if that solves the problems. The code needs cleaning, undoubtably.
Warepire wrote:
Did this fail (no 2xSaImmx.obj generated) due to nasm.exe not found? If this failed, you may do this by hand.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
So...there would be 2 branches of the emulator like the SNES? Wouldn't that make it hard to compare runs made in different branches and also make it annoying to maintain both branches?
True. True.
And I suppose people would set up "(sub-)community rules" regarding which version to use for making TASes of a specific game. Just think that Snes9x v1.43 is always used for Super Metroid TASes.
Tompa wrote:
http://www.mediafire.com/?tq9634sypq1f1ac
That's the ini file at least. I can't really spot what is wrong with it. It seems to be working fine as long as I don't use those buttons, shift and ctrl. But I can't tell for sure.
When I removed the ini file to reset it from scratch, it all worked fine. But I can't tell what caused it in the first place, as I didn't do anything out of the ordinary (As far as I know), just some normal TASing... Oh well.
I almost forgot to reply. Just as I speculated, the hotkey data stored in the ini file was corrupted. The same thing had once happened to me, but the true cause is still unknown.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
klmz wrote:
It seems that you forgot to add src/gba/GBA-arm.cpp and src/GBA/GBA-thumb.cpp into your project.
The LNK2001 errors were caused by the deifinition of int/int32/int32_t/long (do you build on a 64-bit system?). I committed some changes (SVN rev. 396) to work-around them, but I don't know if that solves the problems. The code needs cleaning, undoubtably.
Warepire wrote:
Did this fail (no 2xSaImmx.obj generated) due to nasm.exe not found? If this failed, you may do this by hand.
I am trying to build it on a 32bit Windows Vista Home installation, though the CPU has 64bit capabilities I did not install any of the x64 packages with VS2008.
Including the 2 new files to the project and updating to rev. 396 fixed all the errors I was having, and gave me 2 new ones.
LNK2001 errors about unresolved external symbols:
"int gbColorOption" and "long gbPaletteOption"
nasm is working fine, no problems building that obj.
Sorry for giving you more work instead of taking some off you :(
Sorry for giving you more work instead of taking some off you :(
No need to apologize. You've been actually helping with the development.
Rev. 397 should have got rid of the last two errors.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
The users who follow the svn closely might have already noticed that I committed some changes to the SDL version of VBA-rr (aimed at Linux users), which was failing to compile for a long time, and I intend to work on it further to increase its usability.
No binaries were provided in the repository because, as was noted, it was inactive for a long time and thus is extremely buggy and lacking the necessary features of the rerecording branch. If you want to try it, you can compile the code yourself or ask me in private. Using it for beta testing purposes will help fix the countless bugs it has now. I just encourage not to make any builds public because it could lead a lot of people to use it thinking it's stable.
EDIT: Reading the previous posts...
klmz wrote:
v7.23: Shouldn't be made any more incompatible with older versions.
v8.24: New stuff e.g. master code here!
v20 & v7.24: You may forget about these. Just leave them to me or someone else bored.
Wouldn't this lead to a fork of the project? Well, theoretically not a fork per se, since there wouldn't be two svn's, but the consequences would be the same. In that case, do you think there's enough coding potential to support this? I mean, I can't stop thinking that the existence of two snes9x versions, for example, has made its development slower.
I remember the dark days of v19 vs v20, where something would sync on both only by a miracle, and also the snes9x 1.43 vs snes9x 1.51 debate that's unlikely to ever be resolved, so I can understand being reluctant on the definitive v24 release, but I think NESbot has made it as clear as day that console verifications are possible and we should walk in the direction that'll make them more likely to happen. VBA-M v24 has got more love than v20 had for GB games and v23 has some big emulation errors that were fixed in the v24 core. Don't you think it's wiser to replace v23's GB core now and let the GBA core, which is harder to compare, in an experimental branch? In the case of backwards compatibility, anyone can download the previous versions to watch the movies, I don't see the need for regular maintenance if they are used only for the purpose of watching and not TAS making.
Don't you think it's wiser to replace v23's GB core now and let the GBA core, which is harder to compare, in an experimental branch? In the case of backwards compatibility, anyone can download the previous versions to watch the movies, I don't see the need for regular maintenance if they are used only for the purpose of watching and not TAS making.
So you suggest that it should be wiser to continue on the v7.24 branch than on the v7.23 branch. That's acceptable.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Using the pause glitch in SML2 will sometimes cause movies to desync in VBA24m.
Same thing as with Earthbound's text glitch in snes9x 1.51.
What version number of VBA24m? Was savestate used when you were recording such a desynched movie?
EDIT: I should have asked more specifically.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
