Posts for Luke

Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Check out the Famtasia movies in the thread here (in General). Most of these are pretty easy to obsolete with FCEU. Some games needing runs are Paperboy, Klax, and Dr. Mario. If you're not worried about getting your run published, you could try doing a different category run. Like, playing Tetris in B-type, level 19 height 5. Or, a Mario run without getting any powerups. For making the TAS, you should allocate about 1 hour per minute of gametime. Although some games take even more time than this.
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Fabianx wrote:
How do you locate the random number generator? I have located a variable, which changes each frame and looks kind of random, but using a "cheat" to set it to a fixed value does not make the game more deterministically in regards to certain events. So there must be something else.
First, the Cheat function (if I'm not mistaken) only updates the value at the beginning of every frame. So, the value can still change WITHIN the frame, which would explain the lack of non-randomness you experienced. FCEU has something called "read substitution" which is supposed to take care of this, but it slows down the emulation considerably. FCEU also has a disassembly window in the debugger, which can help you figure out exactly how the game works. Given that snes98xw doesn't have a debugger, the way to determine if you've found the random number generator would be to save a state, then try putting different values in the memory address, and compare results when you enter the same input. In general you can usually figure out what most memory addresses are for by comparing the game's behavior before and after you've changed the memory. If you're using an emulator with a debugger, there's lots of ways to figure out how the random numbers are used. First, you can set a breakpoint whenever the memory address is being written or read. This can give some insight into what it's being used for and how it changes. If you are trying to find the code for a certain event (say, how much damage you are going to do), first try to find a RAM address that changes when the event occurs. Then set a breakpoint when this RAM address is accessed. This will get you to the general spot in the code where the event happens.
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Phil wrote:
Luke wrote:
How can we compile this source with MinGW?
Go to the actual source directory that has files like cart.c, cheat.c, etc. Type "make". Configure no longer works, in fact if you run it, it might corrupt the makefile. If you want to change the compiling options you can edit the makefile manually. If you have automake, you could try that. That should update the configure file. The reason for this is, I added the memory mapper files, but you need automake (which I don't have) to add new files to the configure script.
You should make it clean. Btw, you don't give the root directory with files like config and makefile. The makefile you give doesn't compile FCEU.
$ make            
Makefile:1083: .deps/x6502.Po: No such file or directory
Makefile:1084: .deps/fceustr.Po: No such file or directory
Makefile:1085: .deps/cart.Po: No such file or directory
Makefile:1086: .deps/cheat.Po: No such file or directory
Makefile:1087: .deps/crc32.Po: No such file or directory
Makefile:1088: .deps/debug.Po: No such file or directory
Makefile:1089: .deps/endian.Po: No such file or directory
Makefile:1090: .deps/fceu.Po: No such file or directory
Makefile:1091: .deps/fds.Po: No such file or directory
Makefile:1092: .deps/file.Po: No such file or directory
Makefile:1093: .deps/filter.Po: No such file or directory
etc.....
make: *** No rule to make target `drivers/win/.deps/aviout.Po'.  Stop.
Oh I see. Hmm this is why make is dumb. You will need to create these files. Probably the easiest way is to put a # before the include lines that are causing the errors. Run make once, and then you will have these files.
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Swedishmartin wrote:
FODA wrote:
it is not taking background input from my gamepad, only keyboard. not that i need it, but is it supposed to be like this?
I have problems with this too. I need a gamepad, I just can't use the keyboard.
Try downloading it now. I'd don't have a joystick so I didn't even think of this :) I can't test this, but it's a simple fix so I hope this will work now.
How can we compile this source with MinGW?
Go to the actual source directory that has files like cart.c, cheat.c, etc. Type "make". Configure no longer works, in fact if you run it, it might corrupt the makefile. If you want to change the compiling options you can edit the makefile manually. If you have automake, you could try that. That should update the configure file. The reason for this is, I added the memory mapper files, but you need automake (which I don't have) to add new files to the configure script.
And your way of using savestates is rather strange.
I actually do exactly what FODA does, so I've already found this useful. Making it visible all the time is possible, but this method was exetremely simple to program.
From what I can read in your changes, there's still remain many bugs that haven't been fixed.
FCEU is a seriously hack-job IMO. A lot of bugs are there because it's not particularly well-thought out programming (and being in C doesn't make it any nicer). So I really only plan to fix bugs that are critical or that I introduced.
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
I did the first track, but it wasn't quite so exciting since your speed is capped. I'm working on a Super Turrican run now, which might take another week. I'll probably come back to Excitebike later.
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Ok I think a 98.16 is ready for release: http://lukeg.50webs.com/fceu.html I am probably done adding features. I'm pretty happy with FCEU now. So probably only minor changes or bugfixes from now on. Copied from the webpage: There are new mappers and configuration options, so the version number is now 98.16. Some games will run in 98.16 that didn't run in 98.15. You will need to reconfigure your hotkeys for 98.16. Theoretically this source should compile on Linux, but Linux people will need to update makefiles using automake or something... (sorry I can't help with that) If you just want the new mappers, you can copy the "boards" and "mappers" directory, and the ines* and unif* files. Changes Added mappers/boards from the memory-mapper FCEU project. Added a rewind feature. You must enable it manually every time because it's a little experimental: Config...Enable Rewind. All it does is save a state every few seconds to "rewindX.fcs" where X=0,1,2,3, which you can load by pressing the rewind hotkey (default "R", can be configured). Added a support for a hotkey to view the save slot you're on. New input display. Press the input display button to cycle between 0, 1, 2, and 4 controllers displayed. The "Run in Background" option now works correctly. Added an option to accept input while running in the background, which should be useful for making multi-game movies. NOTE: Holding frame advance won't necessarily advance the FCEUs at the same speed. The solution is to only tap frame advance. Compiled some parts with higher optimization settings, so you might get a small emulation speed boost. Fixed a subtle bug (introduced by the shared memory code) that made FCEU crash in some cases eg. Bio Hazard (unl). Added absolute value "abs" and "setcounter" to BasicBot. Also added "mem" which gives access to all memory locations 0-65535 (unlike "ram" which only could do 0-2047). Memory watch can now access all memory locations 0-FFFE. Memory watch is now throttle-friendly. It won't slow you down when you increase the throttle. A little more space for labels in the memory watch window. Memory watch and BasicBot remember the last directory you used, even after closing FCEU. Fixed the autofire not working 1st frame after loading a state while recording a movie. Attempted to fix the read-only toggle glitch adelikat mentioned. Maybe it will work now? More throttling speeds for people with crazy fast computers. A movie's PAL/NTSC flag is now respected. Also fixed the bug that games would always reset to the default PAL/NTSC mode when starting a movie, regardless of user or movie settings. A couple glitches no one will ever notice (unless you read the source code) have been fixed.
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Phil wrote:
FCEU crashes when I open Bio Hazard (Unl) [!]. With nitsuja and FCEU-mm version, it doesn't crash. Something is wrong in your changes.
Ohh, good catch. I'm looking into this, it's not very obvious what this could be (mapper 15 source is unchanged in all the versions). I really hope it's not related to memory leaks (yes FCEU comes with quite a few of them... not my fault!), but that's probably what it is... Btw the 98.17 I have there now is from a few days ago, I was just checking if it would fit in the 300KB limit (it's like 298KB where KB=1024bytes). It should be pretty stable though if you want to try it, I've been using it while working on a TAS. The real next release 98.16 should be ready as soon as I find this bug. Edit: Killed the bug. I'll play around with it a bit to be sure everything is OK and then update the webpage.
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Oh interesting. I've never used read-only toggle while making a movie (I've only used it when watching movies). Sounds like your problem is that the movie file is not getting flushed--in other words, FCEU isn't saving the last bit of the movie before you load a state. This is probably a "quick fix" if I can find the faulty code.
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Phil wrote:
By speed, I mean, using the turbo key and when you release it, it stills continue at turbo speed for a while. It doesn't do that with nitsuja.
Is this with Memory Watch open? I know that has some speed issues, but I think I've made it much better now. Unless you are using memory watch or BasicBot, the emulation code should run exactly as before, so I wouldn't know what to say otherwise.
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Keep up the good work!
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
adelikat wrote:
Another problem: the memory viewer really doesn't allow enough of text box for a good description of the ram address, I find my self running out of room even when abbreviating everything. Could the text space be doubled? I don't think it bloat the window size too much. If this is a pain in the ass then don't worry about it, but if it is an easy correction it would help a lot.
Yup, easy fix.
Also, could it be set up so that the tab button advances from one field to the next?
The resource compiler in MinGW seems to eat the tab orders. (along with menu hotkeys) It annoys me too :/ I don't know how to fix it though...
can the cheats menu in FCEU be set up so that it can stay open while playing the game? when finding ram addresses it is a real pain to have to open & close it so much.
I looked into this, but the cheat menu isn't programmed to update in real-time; that's why it has to stop the emulator when you open it. Actually I just thought, a possible quick solution is to add an "update" button to it, so that you manually have to update the values.... hmm.
Use the force
Post subject: NESVideos at MTV
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
I'm surprised this hasn't reached the forum yet... probably Bisqwit is being modest ) http://www.mtv.com/news/articles/1528811/20060417/index.jhtml Not such a great article, IMO, but I suppose it's good publicity nonetheless. It could have talked a lot more about the process to create the videos. Tries to stir up controversy about TAS videos by interviewing regular speedrunners (like Radix and TSA).
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Right now I'm working on a rewind feature. Once I am done testing this I will post a new version. I like the idea of displaying a controller to show the input. If it's not difficult I'll try to add that later, but don't expect it in the next release. Here's why I'm not planning on including bisqwit's stuff, if you're curious.
    - Bisqwit's custom input defaults - Bisqwit's compose mode for making 2p movies easier to create
These are redundant with the Windows input configuration. I don't really want to maintain the linux code, especially since I don't have a Linux box at the moment.
    - BisqBot (with settings last configured for Rockman 2 scrolling substitution)
BisqBot options are all in the source code, so it's really tough to integrate it with the GUI. Also BisqBot is very game-specific.
    - Warp's font for smaller HUD texts (fits more text on screen)
Could do this, but not a high priority since FCEU can open separate windows when it needs to show extra stuff (for example, the debugger or memory watcher)
    - Bisqwit's tile tracker -- the engine used to make GIF animations. (A #define from source code needs to be changed to activate).
I don't fully understand what's going on with the code, it's somewhat involved. Also would be tricky to integrate it into the GUI. I would love to see this, but it's not a high priority and would be a lot of work.
    - Bisqwit's dual game daemon support (Needs a separate program to work, and to be enabled from drivers/pc/sdl.c.)
I've already added this :) Background input can be enabled. You will be able to compose multi-game movies in the next version. Start planning your SMB1/2j/2/3 and Megaman 1/2/3/4/5/6 runs. :D (actually I've already found this feature to be useful so you can frame-advance through 2 movies at the same time, making comparisions very easy)
    - Disables debugger (not implemented for Linux anyway, makes emulation faster)
As far as I can tell, the debugger code doesn't run unless you're in debug mode. So your emulation should be just as fast as Bisqwit's. In any case many people make use of the debugger.
    - Rockman 1&2 RAM analysis with frame display (displays X&Y position&speed and magnet beam positions) - Magnet beam solidifier (a visual enhancement filter for Rockman 1, has to be manually disabled for all other games)
Game-specific. I don't really want to bloat FCEU with mods for every game. Someone else certainly could add it, though.
    - Now actually says it's 0.98.15; Nitsuja's source code had still "0.98.13" somewhere
I've also made sure the version number is correct everywhere :)
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
It's interlaced, so you don't get the full resolution every frame. But to say it's only 30 fps wouldn't be 100% correct :)
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Yeah I looked at Bisqwit's source and I don't think I'll put the things in the Windows version for various reasons. Too bad, because the tile-tracker thing seems pretty useful (making maps or animations). But I think you will be pretty happy with the features in the next FCEU. I should have it ready in a day or two, depending on how busy I am. I think viewing 4-player input is a little tricky because there isn't enough room to display it properly. I guess if you don't mind it not being nicely aligned, I could make a quick change to show 4 controllers. I suppose for makeing 4-player movies this would be important so you can actually see if you have all the keys down...
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Bladegash wrote:
You get a different ending in DuckTales if you can perform the (impossible) task finishing the game with no money.
Maybe it would be possible to make your money value overflow, so that the game thinks you have 0 even though you've actually gotten a lot?
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
OmnipotentEntity wrote:
And also, prove that using quarter face turns only, a Rubik's Cube scrambled with an even number of moves can only be solved with an even number of moves. Same for odd.
You can check that a 1/4-turn is an odd permutation of the faces (observe that 2n-cycles are odd permutations, and a 1/4 turn is five 4-cycles). Then even number of moves <=> even permutation <=> even number of moves required to solve it. PS I'm a math major :D
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Also had a desync in Ifrit. I really enjoyed the movie and lol'ed when Kupan comes out of the dressing room looking like Maria. Keep at it! Even if it's not perfect, a FF3 TAS is high on everyone's Most Wanted list D
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Swedishmartin wrote:
FODA wrote:
Bisqwit wrote:
Swedishmartin wrote:
If you press reset while watching a movie the game resets but the input continues. Is it supposed to be like that?
Yes, it's supposed to work like that, because you can include reset(s) in a movie. This is used in a few of the Nesvideos movies already.
but if he's watching the movie, then this reset should work as a different command that resets the movie as well
Exactly.
Right now, if you're in read only, a reset or power will reset the movie. I realize this is a confusing feature...
Highness wrote:
So how about adding *.7z so one doesn't need to extract roms? =D
That might be a lot of work... someone else wanna give this a shot? 7z code is easily available, it's just a rather big thing to add to a program.
adelikat wrote:
yeah, someone compile all this stuff together and make a kickass fceu with it. Call it 98.16 while you are at it.
I will be upping the version number, since there are new/revised mappers which change the emulation. I'll include as many features as I can get working :)
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
I started a TAS on difficulty 2 in NTSC. I thought maybe I would try beating the first boss on difficulty 2 and 4, and see how it compares... but I've already invested a ton of work and still have a level left before the first boss! So I think I will just stick with the run I've started. 2 levels done, 4027 frames, ~281 frames saved. So I'm expecting 30 seconds or so improvement.
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Being far from an expert in SMB2, I still noticed missing tricks in this run, and so I was disappointed. Voted no... Regardless, I'm not such a big fan of a Princess-only run anyway. Doesn't seem to be any more interesting than the regular run.
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Ah, yeah the description I give is just a symtom in Windows. The text rendering wrong isn't the actual problem; what happens is FCEU is in (for example) PAL mode internally, but the graphics are showing NTSC. Since PAL has more scanlines this makes the text cut off. It's possible on Linux it would display correctly, i.e. it'd show PAL if you're in PAL. But the movie-loading does have a bug (98.15 does, 98.12 doesn't so maybe you don't even have it actually), such that the PAL/NTSC mode resets to the default when it loads the movie.[/code]
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
I found a significant bug in FCEU regarding PAL/NTSC settings. Right now FCEU screws up the PAL settings when you start recording a movie. (All is fine if you record in the default mode, which is determined by whether the ROM name has "(E)" in it or not.) I'm not exactly sure what happens if you try to play a movie in the non-default mode. You can tell if this bug is happening the text at the bottom of the screen (e.g. "Playing frame 11034") will be in the wrong position, either too high or too low. In any case, you can hack around this right now by changing the ROM name include an (E) if and only if you want PAL mode. Also sort of dumb, but not a bug, is that FCEU saves whether the movie is PAL or not, but doesn't check this when you open it. I'll put fixes to these problems in the next update. However it appears that changing PAL/NTSC mode is driver-dependent, so I don't know if I can give a whole Linux fix.
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Looks good!
Use the force
Experienced Forum User, Published Author, Player (84)
Joined: 2/10/2006
Posts: 113
Location: US
Phil wrote:
Can you just use nitsuja's source without your previous changes?
Yeah I realize it could be a problem having revised mappers on Win32 but not other platforms. Actually patching the code is pretty easy, so it's not hard to update nitsuja's source. My problem is I lack some makefile programs (automake specifically) needed to update the compiling instructions-- so I couldn't make something that "just works," and someone else would have to update the makefiles. For those interested: To put in the new mappers, just copy the /boards and /mappers directory. Also copy the ines* and unif* files in the main source directory.
Use the force