I'd suggest that encoders should hold on for now, as it is quite likely that the author would hex-correct the evident flaws in menu screens and update this submission.
I'm expecting to see a sub-25-min update with just hex-edit.
EDIT: now the update is 680 frames faster with hex-edit and skipping using the invincibility jar in the last fight. It might be safe to encode this submssion now.
<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 the ceiling breaching glitch is new? Thought I hadn't seen it before in a HoD run. How does it work, anyhow?
It was an old glitch found after the Low-Grav Glitch was found. It had no use in other categories of HoD runs.
To perform it, you just have to be in the Low-Grav status, then make a High-Jump to reach a ceiling (without bumping onto it), swing your whip and keep the whip unleashed (by holding down the B button). Gradually, you'll "drift" through the ceiling.
I claimed the previous HoD submission that was also by sksk1990 as an HoD expert as well as a TASVideos Judge, but this time I'll refrain from voting for or claiming this submission as long as I am unfortunately uncertain about what to expect with this specific category as the average audience.
<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'd rather vote for Crouching Tiger, Hidden Dragon than vote for Rockin' Kats.
<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
Hi Jungon. Are you going to improve the any%? Or will you do a new revision of Master of Darkness?
Well, Master of Darkness still needs a complete reformulation of routing, but given time, I'll be working on it..
I am still inactively working on this, though I haven't beat Stage 2 yet. What do you think about it?
Jungon wrote:
EDIT: I'm a little more inclined to Mickey Mouse's Land of Illusion next, but I really need to learn this 'dance with the music' technique, how can I perform rhythm moves if frame advance has no music at all? @__@
By trial & error.
<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 think this run is fine - in my mind using the normal driller is in some sense "the way this game is meant to be played", and using the faster driller you get by beating the mission mode is kinda like a "game+" scenario. Maybe this was a repeat of what I said earlier, but to be clear: I stand by submitting this run and think this is the version that should be published (if accepted, of course). It's true that using Ataru Hori would be interesting, but I think such a run could be posted in the forum topic for those interested.
That's very reasonable. Now let's just listen to other people's opinions.
<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
Would it be better if you played through mission mode first to unlock a faster character and then use that to TAS time attack mode?
09. Ataru Hori - Clear North Pole Stage in Mission Driller.
That's true, that would be interesting, though that would require the run to play through the 4 mission courses before playing the time attack stages. Still I think there's some value to using the standard character, in particular that everyone who has played the game knows the physics of that character. Though on the other hand it would be cool to see the fastest character blaze through the time attack levels.
What are peoples' thoughts on this?
I'd like to know what the author's thought is on this.
<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 say to pick a few selected players (active or not) who aren't gonna participate in the contest and ask them to vote for the game.
The opinion of a few connoisseurs is much more valuable than the opinion of the oblivious masses.
You never disappoint me.
Let's vote for the players who will be to vote for the game!
<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
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
I've got the impression that it was possible to glitched through some of the prison walls from the right side. I haven't been able to reproduce that, though.
EDIT: And if memory serves, there were glitched warp-doors outside of the boundaries of the prision level, which could be used as shortcuts.
<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
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
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
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
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
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
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
There is another "good" GBx emulator named KiGB, but it is close-sourced AFAIK. I wonder if it could pass these tests.
KiGB official web site: http://kigb.emuunlim.com/
EDIT: I wasn't aware of that the test results with KiGB 2.05 had been included at gbdev.
<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..
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
Time length of the movie:
* In microstorage: 1min 42.167sec.
* In FCEUX 2.1.5: 1min 42.00sec.
* In submission queue: 1min 41.0sec.
* In the site database: 1min 41.999sec.
There seems to be a bug in time display: If movie subseconds are 995-999 (this one has 999), then the displayed length is almost one second shorter. Two submissions (this and another published one) are affected by this.
The question is how could Kyman have known the bugged result before the movie was actually replaced and re-parsed.
<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 am wondering whether it was the right movie submitted/updated. Doubtful points on the descriptions and forum posts:
#1: TASVideoAgent wrote:
Game Objectives
Emulator used: FCEUX 2.1.5
Aims for fastest time
Uses game-breaking glitches
The "Emulator Used" field inside the movie file reads "FCEUX 2.10.40", which indicates that the movie was created with a version of FCEUX 2.1.4. Did the authors started working with FCEUX 2.1.5 from an old movie created with older versions of FCEUX, or was it just a bug of FCEUX 2.1.5?
#2: TASVideoAgent wrote:
This is an improvement of 16.95 seconds (947 frames) over the previously published movie by Aglar. All of the improvements come from the new route that we used, I won't spoil anything here though, watch and see for yourself! :)
This updated movie is not 947, but only 882 frames shorter than the previous movie by Aglar. Meanwhile, it is 947 frames shorter than the previous movie by Aqfaq. Did the submitter just compare to the wrong movie?
#3: Kyman wrote:
Time length of the movie:
* In microstorage: 1min 42.167sec.
* In FCEUX 2.1.5: 1min 42.00sec.
* In submission queue: 1min 41.0sec.
In most situations, the authors can only tell the time length of the movie from the readings of the first two available sources before they have it submitted to the queue. Did the authors calculated the length according to the specific frame rate of NES adopted by this site this time?
<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 don't think there is a point to continue on the 7.24 branch (aka. "v20 branch").
EDIT: But I keep updating all of the three v20 descendants nonetheless.
<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
<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 guess you may compile res.rc (was it?) to res.o manually using windres.exe.
<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
Front Page?t=1313213672708
This page does not yet exist.
<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
One suggestion... As of now, when you set the sound to "Mute" and load a save state where you didn't have the sound set to mute, it will come back. If that could be changed to still have the sound muted, would make me glad.
Sorry for keeping you waiting. This should be easily fixible. Sooner or later.
Tompa wrote:
Edit: Another thing, more serious this time. I was TASing some Drill Dozer with v24 before, everything was working fine with no issues.
But now when I opened it up again, tried to make a save state (Shift+F3 in this case) a window appeared that said "GDB connection" appeared, something I had never seen before. I tried to close it, but it didn't work. Only thing I could do was to shut down the emulator through the task manager.
I then tried to find out what made the window appear. So I browsed through all the hotkeys and found the GDB thing under the debug section. And for some weird reason it had many many many hotkets set for it, something I have never touched.
These includes SEVERAL of: Alt, alt+, CtrlShift, Ctrl+Shift and many more. I was able to delete all of the "Alt" ones, I think (As you can't even view all hotkeys set for it) but most of these weren't even possible to remove as hotkeys.
The conclusion is that everytime I want to use shift or ctrl, the GDB Connection window appears and I have to restart the emulator. Explanation, please?
It might be the INI file that got corrupted, though I can't say for sure. You may toy with vba.ini by yourself and see if the problem will be reproduced while you are using the emulator in normal ways.
<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
Did you waste time on Pirate level on the two squids while you were excavating the CD near them?
<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
