Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Ilari wrote:
MESHUGGAH wrote:
Using tas-editor I sync them perfectly. #2076832347595676 btoads_shortestinput.fm2 (last link above your post) gets a game over and shows the glitchy plane and ending credits.
AFAIK, checking in tas-editor is not a valid way to test.
He means that he used TAS Editor for quick resyncing.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
TheZlomuS, please confirm if I'm right that this situation should be handled like this:
1. Replace the submission file with this file (http://tasvideos.org/userfiles/info/2034290379878874) which is made from the aforementioned movie by TheZlomuS. It syncs with old versions and makes the final screen appear faster than currently submitted file (although still showing the GAME OVER).
2. Restore original list of the movie authors to "DJtZ & DyLaX" (TheZlomuS & DyLaX).
3. Then you can accept and publish it.
4. Next month, when the FCEUX 2.1.6 (in fact 2.2.0, because seriously) is released, TheZlomuS will make a submission with this file (http://tasvideos.org/userfiles/info/1802319023889578), including MESHUGGAH as a co-author.
Nach wrote:
Some of the versions suggested also have a broken rerecord count.
The rerecord counter doesn't apply in this case anyway, because most of work is done by lua bots.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Ugh, it's probably better to publish the longer version for now, and submit the new version (with MESHUGGAH as co-author) laterrrrr... that is, when the new FCEUX is released.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
feos wrote:
We would anyway have to draw them somewhere, I suggest it to be level border.
That's still rather arbitrary way to draw a line. Can you explain why skipping a whole level is different category from skipping the whole game?
feos wrote:
So I think the "same glitch" clarification has too many pitfalls for actual TASers, while the opposite has lesser pitfalls for judges.
Indeed, I don't quite understand the recently imposed urge to make judges' life easier at all costs. The priority should be to make players' life easier, and judges have to spend more effort on thinking/investigating/foreseeing instead of just applying common rules (such straightforward work doesn't even require humans).
Players are content suppliers. They can exist without other groups, while other groups cannot exist without them. Limiting the freedom of TASers' creativity in favor of more comfortable management is... is something that can only exist in commercial structures.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Compiling FCEUX is extremely easy. You just download the source, install the Miscrosoft Visual Studio 2010 Express Edition, load vc10_fceux.sln and hit F5.
Scumtron wrote:
Does this even matter to anybody else?
Dunno. So let's leave the Courier New until someone else bugs about it.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
That's strange, none of my Windows installations had the "Courier" font. Maybe you've got it after installing some printer drivers or Adobe Reader software.
So, if current font is still a problem, I'm open to suggestions. E.g. another common fixed-width font is "Lucida Console":
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Marx wrote:
Right now two battletoad submission is being compete.
I really can't improve beyond 58 seconds so I'm about to cancel it but what do you guys think, should I wait or cancel it?
Marx, can you describe the process how you TASed this game? How you managed to beat previous run without learning the deep stuff on the game engine?
That does indeed remedy the 0/D confusion, though your use of "bigger" gave me pause, as I see an 'F' as 7x9 in the old example and 6x7 in the new (ignoring white space) on my 1600x1200 display.
I see, it's Windows98. But in WindowsXP the it looks like this:
And it's the same in Win7. As far as I understand, all Windows versions starting from XP don't have the "Courier" font anymore, and this font was specified in old FCEUX Hexeditor, so when ran in Windows XP it always substitutes the font with the "Courier New" which has lots of whitespace. So I changed the CreateFont() to specify exactly "Courier New" which is available in all versions of Windows.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Scumtron wrote:
I was going to suggest an option to "un-greenzone" past a selected frame or a range of selected frames, but feos rightly pointed out that option already exists by simply changing input (and changing it back if needed). But it's possible that such a feature might have some other use that I haven't thought of, so I'm posting this anyway.
Taseditor is fairly extendable with Lua scripting. In this case you can write a script like this:
Language: lua
function ungreenzone()
selection_table = taseditor.getselection();
if (selection_table ~= nil) then
frame_of_ungreenzoning = selection_table[1];
-- 1. Save old Input of the frame
old_input = taseditor.getinput(frame_of_ungreenzoning, 1);
-- 2. Invert the Input on the frame
new_input = XOR(old_input, 0xFF);
taseditor.clearinputchanges();
taseditor.submitinputchange(frame_of_ungreenzoning, 1, new_input);
taseditor.applyinputchanges("UnGreenzone1");
-- 3. Restore the Input on the frame
taseditor.submitinputchange(frame_of_ungreenzoning, 1, old_input);
taseditor.applyinputchanges("UnGreenzone2");
end
end
taseditor.registermanual(ungreenzone, "UnGreenzone");
Scumtron wrote:
The reason I thought of this is I trying to figure out what value a RNG needed to be manipulated to by poking it with hex editor, and kept expecting it not to be restored when I clicked or held the '>' button, like with "normal" TASing.
Ah, in this case you may want to de-greenzone right after the Playback cursor (because in Hexeditor you're editing the current frame state), so you won't need to select the frame before pressing the "DeGreenzone" button.
Language: lua
function ungreenzone()
playback_position = movie.framecount();
-- 1. Save old Input of the frame
old_input = taseditor.getinput(playback_position, 1);
-- 2. Invert the Input on the frame
new_input = XOR(old_input, 0xFF);
taseditor.clearinputchanges();
taseditor.submitinputchange(playback_position, 1, new_input);
taseditor.applyinputchanges("UnGreenzone1");
-- 3. Restore the Input on the frame
taseditor.submitinputchange(playback_position, 1, old_input);
taseditor.applyinputchanges("UnGreenzone2");
end
taseditor.registermanual(ungreenzone, "UnGreenzone");
BTW, you may also want to automate the process of poking and regreenzoning.
Scumtron wrote:
Speaking of the hex editor, I'm not sure at what point it was changed, but I preferred the old display. 'D' and '0' can be hard to distinguish when I'm leaning back in my chair with the newer, smaller text, particularly when the character to the left of a 'D' is selected.
Hm, good point. Although the new font is actually bigger (height=14 instead of 13), OK, is this better?
http://fceux.com/zip
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
sack_bot wrote:
also, reprogram the universe
You're confusing TASing with hacking.
feos wrote:
TAS is about testing actual choices.
Indeed, it is about comparing actually accomplished choices. But until the choice is only in your mind, you cannot test it, because you lack the information and processing power to emulate it for certain.
On topic: If I had TAS tools in RL I would use them to research and develop more advanced TAS tools, and repeat the cycle until I get the powers to provide these tools to other sentinent beings.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
mqduck wrote:
I tried following your directions as best I could, but there's some issues... For one, there's an "Eject Disk" but no "Inset Disk" option.
It's one and the same button. The first time you press the button, it opens the disk drive, 2nd time it closes it. So you are expected to do it exactly like this:
1) choose NES -> Eject/Insert Disk, the message "Disk 0 Side A Ejected" will appear
2) NES -> Switch Disk Side, the message "Disk 0 Side B Selected" will appear
3) NES -> Eject/Insert Disk, the message "Disk 0 Side B Inserted" will appear, and the game will change from title screen to player select screen
I just tried it with Zelda and it works.
mqduck wrote:
EDIT: Am I to take it this is a problem most people haven't faced? In my own, very limited, experience, it's been pretty universal. I should mention that I've also tried it both on my laptop and desktop computers.
FDS games aren't well known outside Japan, so most people didn't even bother to check how they are emulated.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
mqduck wrote:
FCEUX doesn't seem to read any input when I load an FDS game. I tried mapping to my gamepad and keyboard, and running it in GNU/Linux and Windows. No matter what, it never sees any of my button presses (but it works fine with cartridge ROMs). What's the deal with that?
Many FDS games ask you to switch disk side before you can proceed from the title screen. To do that, use FCEUX main menu:
1) NES -> Eject/Insert Disk
2) NES -> Switch Disk Side
3) NES -> Eject/Insert Disk
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Pasky13, that's because FCEUX Lua draws images using NES palette, while Bizhawk Lua uses RGB (platform-independent). So it's not a bug, only a limitation.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
feos wrote:
[*] Game jums to arbitrary address $75BD. $6000-$7FFF = Battery Backed Save or Work RAM. It is all filled with $6F and is an undefined code. So the game just rolls through all this area and then gets to $8000.
The scary thing is, Battletoads don't have any Battery Backed Save or Work RAM. So what's happening there is called "reading from open bus", and is not a regular situation. Usually it returns the last bits that were on the bus due to the capacitance of the bus, in this case it's the high byte of the address (0x75) and then the last byte read from $75 (at zero page), which is fortunately not a #00 (BRK) at the moment, but some undefined opcode (#6F) which lets the CPU eventually proceed to a sane code.
The more we dig into the bug, the less we are aware of the range of its possibilities.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
SmashManiac wrote:
AnS wrote:
To make the movie sync with any other FCEUX (except 2.1.5), authors of the movie should add 1 blank frame at the end of the movie, and then ask admins to replace the file.
Wait what? Why would the authors need to artificially add an extra input frame when it's just a matter of fixing a simple emulator bug?
Well, until the bug was revealed, people had to do it without even knowing, and I'm not sure the conditions should change mid-frame war. Also, the fixed emulator will only be released in a month or so, and I thought it's important for a submission to sync with some released version, not just with SVN revision. If it's not necessary then I don't object.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
CoolKirby wrote:
I can't figure TASEditor out. No matter what I change, it won't play back the run without recording new frames starting from the beginning of the movie. And the run desyncs without it.
Oh, that's because the "Auto-adjust Input according to lag" is checked by default. Damn, I need to think whether to make it enabled or disabled by default... The feature itself is very useful, but it implies that you're editing the movie, not just watching.
hegyak wrote:
Ok, what the heck? Why is this complicated? I got it to work. But why all the extra work? No other TAS made me do this.
As I said above, this all is because of the old bug in FCEUX! TAS Editor simply uses different branch of code, thus not having the bug.
To make the movie sync with any other FCEUX (except 2.1.5), authors of the movie should add 1 blank frame at the end of the movie, and then ask admins to replace the file.
CoolKirby wrote:
And what is TAS Editor doing anyway? Is it playing back the movie as well? Is it doing anything after the end of the movie file?
Up to the last frame it plays the movie exactly like FCEUX does (because it's actually FCEUX replaying the movie while TAS Editor is simply an interface).
But at the very first frame after the end of the movie it replays "no more input", while FCEUX replays input of the the last frame of the movie once again (because of the bug).
CoolKirby wrote:
Instructions:
Open FCEUX 2.1.6
Open Battletoads ROM
Open Movie File
Check the box "Pause Movie at Frame"
Play the TAS back
When the movie Auto Pauses, open TAS Editor
Resume playback.
Watch Glitch work.
Better instructions:
Open FCEUX 2.1.6
Open Battletoads ROM
Open Movie File
Open TAS Editor
Switch off "Config->Auto-adjust Input according to Lag"
Unpause and play
CoolKirby wrote:
If you don't follow those instructions then it will desync. The run will not play the first level properly, or the glitch will crash the game.
No, the first level plays normally, it's just that a lot of the movie happend after the Input ends, and the glitch is determined by the Input of several last frames, thus it works differently when FCEUX duplicates the very last frame.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Man, this movie revealed the oldest bug of FCEUX replay engine!
At the frame when FinishPlayback() is called, joyports don't update, because they're still working in Playback mode (which means reading Input from movie file, not from keyboard).
I've fixed this bug, but now I wonder how many old TASes rely on the fact that the very last input gets doubled. Since it wasn't noticed before, I presume, not many. Of course in case of memory corruption every smallest move changes everything...
Adelikat, you should check for same bug in Bizhawk, since you were the main author of this code.
The problem with this run of Battletoads can be solved by adding 1 blank frame to the end of the movie, then it will sync with old versions of FCEUX, where the bug wasn't fixed.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
jlun2 wrote:
How does that work?
Faster run = new category?
What?
The point is not that it's just faster, but that it skips entire game.
MrTickles wrote:
What's going on, from a technical standpoint? Was one of the objects loaded a checkpoint from Rat Race or something, which would explain the weird pallete?
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
That's interesting, let's hope the record time soon crosses the 1 minute line, so it becomes especially obvious this run needs its own category.
Yes vote.
mklip2001 wrote:
If half the starting input is copied from the previous movie, should the old authors be added as coauthors?
This Input was copied from 1920M anyway.
Edit: ok, checked the diff in Taseditor and it appears to be different, although you can't tell it by the game Output.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Aglar wrote:
Ok, I just thought that since the value of $CA-CB increases as you go down a vertical room it would make most sense that the value 0xFE for $CA would mean 254 screens below the top.
Note that it only increases when the camera is moving down (and at the same time all sprites move up), so it's the opposite to objects' coordinates. When it increases, Toad's onscreen Y decreases and vice versa - when it decreased by 2, Toad's Y increased by 2.
And it's the same in Win7. As far as I understand, all Windows versions starting from XP don't have the "Courier" font anymore, and this font was specified in old FCEUX Hexeditor, so when ran in Windows XP it always substitutes the font with the "Courier New" which has lots of whitespace. So I changed the CreateFont() to specify exactly "Courier New" which is available in all versions of Windows.