Posts for nitsuja


Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Hmm, well all of this works fine for me, but I can only test on WinXP. I haven't changed the Open ROM dialog or unzip code at all. I'll see if I can get it to compile with a different compiler, maybe VS.NET is adding some stupid stuff in the build process. VBA seems to do a lot of special-case things with visual themes in dialogs, but none of that has been touched.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Bag of Magic Food: Would you rather have them cancel out? I thought having it choose one of the two was more user-friendly and standard, but maybe it isn't. julianch: You'll have to explain more, but I'm guessing you just have a corrupted ROM. ventuz: Sometimes loading the state is slow and it thinks it needs to adjust for the lost time by rendering the next frames quickly. This shouldn't be a problem if you load the state while the game is paused or going very slowly. Vatchern: Re-recording is the same as on Snes9x. You have to uncheck "read-only" to re-record instead of rewinding. If you open a movie in read-only mode, you can change it to non-read-only from the menu. There is another option, you can choose "continue recording from here" from the menu if you don't want to save+load to do it (hopefully that works, will test more). Also, if you want to re-record from the end of the movie or a specific frame, check "pause at frame" and when it pauses, hit save, load, unpause. TheAxeMan: Currently VBA isn't capable of drawing messages while paused, just like Snes9x, and adding that kind of functionality is a lot harder than it seems like it should be. Although it should be easier than adding it to Snes9x would be, so I'll give it a try. What about the save/load interface is different, is it that there are no prev/next slot commands? I can't figure out how to remove the dependency on MFC71.DLL, anyone know anything about this? I'm not loading or using that DLL anywhere, only the compiler itself uses it to compile... Should that file just be included with the emulator? I just realized that Rewind works pretty weirdly when lots of save states are used (it rewinds into all of your attempts that have already been undone), and the "watch from start" action somehow stopped working, both of these are non-essential extra features anyway but they should get fixed sometime...
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Arg, how can you not have that file? I mean, OK I'll try switching the build type and re-upload. In the meantime, try looking someplace like here.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
It's finally done! http://nvdata.pilif.ch/VBA-rerecording-new5.zip Or at least, I think it's done. I haven't been able to test it very extensively, so you'll probably still find problems with it, but it's certainly better than before. Please try it out and let me know how it goes. (I thought I'd make this a new topic since the other one was getting a little large and frequently off-topic.) To Bisqwit: This should meet all of your requirements for a VBA re-recording emulator. Let me know if it doesn't. The zip file should contain more than enough info, along with the full diff of the source changes.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
I'm importing and adapting the recording code of Snes9x which handles Read Only correctly, so yes. I think all I have left to do is plug some things into the GUI. Well, VBA is highly win32 dependent and I haven't done much to fix that, but I'm pretty sure it should run to Bisqwit's requirements in Wine once I make some commandline argument flags.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
McBAIN: About VBA lagging, it probably has to do with settings in the frame skip menu. I've found the best settings are to turn automatic OFF, set frame skip to either 1 or 2, and very importantly, set throttle to "No Throttle"; for some reason it's not the same as "100%" throttle! (I'm working on fixing the throttle and frame skip somewhat, by the way...) When VBA doesn't get enough CPU to pay proper attention to the sound, the sound quality goes to hell. This can also happen if you open any other applications that can play sound before you open VBA. NrgSpoon: Are you watching it with the same version as before? I think some timing things changed between versions. If you are watching it with the same version, it would help me if you can think of what settings you changed between when it worked and now, if any.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Bag of Magic Food wrote:
I was going to say renaming was a good idea... But wait a minute... If all the save data the movie needs will be saved in the movie file itself, couldn't you just have the emulator ignore the current SRAM file completely for making "no previous save" movies, and for savedata-based movies, have it read the SRAM file once to save it into the movie file, then ignore it completely from that point onward? That seems like a more natural way to protect people's save files, and then you probably won't have to put in nagging notices about losing or renaming files (like what VBA has now).
I think I'll just remove the nagging notice, or at least make it a text label inside a dialog instead of a pop-up. Personally, I think that anyone who knows enough to play back one of these movies won't be stupid enough to have unrecoverable data they want in the SRAM and not in any of their emulator save states. When you play a movie in Snes9x, from snapshot or from reset, that overwrites your SRAM too, and I haven't heard any complaints about it. (VBA is really aggressive about keeping SRAM btw, I actually had a pretty hard time figuring our how to not use it (even deleting the file is not enough, it keeps backups in RAM and writes it back out to file at every opportunity.) The problem with just ignoring the SRAM is that even if I could get it to, it would just overwrite it the next time the game resets or closes or does anything, or if not, it might accidentally load whatever SRAM you have if the run contains a reset later in it, causing a desync. Getting rid of or moving the SRAM and nuking the internal backup, and then allowing things to proceed as normal, is the only reliable way I've found so far.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Bag of Magic Food wrote:
Does 020 store whether the game is GB, SGB, GBC, or SGB2 (SGB + GBC)? I noticed that 016 only stores whether or not it's GBA, so I was a little confused.
That flag is more intended so that when someone makes a submission it can be detected which system it was for. (Which mode you have set when you made the run is stored at 020.) I wasn't sure if making the further distinction between GB, SGB, etc. was necessary, but I guess I might as well put that in as well, that's why I reserved so much space in the header. By the way, the variables for this seem to be a little hidden, but I think all GBA games run at 60 FPS, and all GB games run at either 60 or 64 FPS (I can't tell which from the code, will have to test, unless someone here knows it offhand.)
Bag of Magic Food wrote:
Do you think the options for left+right and up+down should be separated in case people want one and not the other, or does that seem unnecessary?
Seems unnecessary to me, not sure if it'd ever be useful to turn on only one of the two.
Bag of Magic Food wrote:
So controller data is 2 bytes per frame instead of 4 bytes now, right?
Yeah, I'm not sure why shanedudddy thought that 4 bytes were needed, unless there are some extra controls I'm not aware of. GBX has less buttons than SNES and Snes9x also uses 2 bytes.
Bag of Magic Food wrote:
Does this mean I could potentially stuff the necessary information into the beginning of my Rockman World movie and set it to 2 controllers to make it work? Would I need to use one of your "use old sync" options? Or would 2 controllers not work anyway because it's not SGB? (Speaking of multiple controllers/players, is there any potential for linked games in VisualBoyAdvance, or is that a bit too far-fetched right now?)
I briefly tried to write a VBV-to-VBM converter, but gave up when I realized that VBV encompasses several formats, the earlier variants of which I don't understand. The "old sync" is actually an existing emulator option for sound which requires an emulator restart to change and I'm not sure what exactly it does. However, the scanline timing thing change I made changes the frame timing, for the better I think but I will be making it optional just in case. I believe all existing movies will be able to play in this version IF someone (maybe me sometime later) is willing to write a file format converter. VBA doesn't support GBA links, and I'm guessing it's not trivial to add that support or it would've been added already. It looks like it might support GB links though, I'm not sure how but I keep seeing active link-handling code in the GB emulator core.
Bag of Magic Food wrote:
Being able to record resets in-game is cool, but I'm sure that purists will argue that you should only be able to reset games by the A+B+Select+Start code and nothing else. What do you think?
I think there's no problem if a run hits reset partway through the run, after all you can reset a real GBX, and there is no possibility of cheating because the only save data you'll be able to load is the data you've created within the run up to that point (if it's a "from power-on" movie, it will actually erase (maybe rename would be better?) your SRAM file before starting the movie).
Bag of Magic Food wrote:
I don't really know anything about motion sensors. Were they used for Kirby's Tilt 'n' Tumble? I haven't played the game, but supposedly you have to tilt the actual Game Boy Color to play it. That sounds like something you would need motion sensors for.
Yep, OK, that's one game that uses it...
Bag of Magic Food wrote:
And this is a bit unrelated, but have you given any thought to the clock in the second-generation Pokemon games that keeps track of the current time, even when you're not playing? How does that work? How is it generally handled in an emulator?
As far as I can tell this is the only feature that uses the system clock. It appears to get the time you start with it system clock, and then use the system clock to add to that time as you play, and it saves the last time it was played in the SRAM. The time updating can be replaced with using the emulator clock when a movie is active, but I'm not sure what the start time should be. The easiest thing to do would probably be to use the time stored at 008, the downside is you might have to start your run at a certain time of day. I could instead make a configurable "start time" field in the GUI, but that's a lot of work considering how few games use it. Oh, I forgot to mention this in the above, but there was a section of code in the GB core that requests input outside of the main loop, causing frames to be recorded/played at a non-constant rate that depended on how often it decided to return to the GUI, and that input wasn't even used for anything after it was requested, so I just disabled that code. Despite the fact that I don't think it would have been put in without reason, it's caused literally nothing but trouble as far as I can tell. (I was suspicious of it for a while, but when I noticed the frame counter hit 500,000 once just from starting up Rockman World and exiting the title screen, I decided it had to go .)
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
It's been my experience that Volume Envelope Height Reading causes random desyncs - only in some games, but it seems that this is very likely one of those games because the setting changed the timing on playback, and timing changes from having the setting on tend to be sort of random. But if you want to know the real answer to your question, you'll just have to try it out; try making a sample movie with VEHR on, something less than 10 minutes long that isn't perfect at all would work fine, then you could play it back once at normal speed and once at fast-forward to see if it still works. (Note that if a "Fake Volume Envelope Height Reading Off" workaround is ever made, you won't need to start over to get the better sound, I haven't tried anything with it yet though.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
OK, I've been secretly working on this all day... I wasn't sure if anything would come of it, but I've made some major progress so I thought I should probably make a status report. 1- I finally found out what was causing the weird desyncs in GB games, it's because a variable called gbJoymask wasn't being saved in the save state, causing input that's already been recorded to the movie file to change (without being recorded) upon loading a save state 1 frame after it. 2- Frame advance was being done by holding an internal emulator timer variable at 0, which screwed up the behaviour of the game sometimes. I made the simple change to set theApp.paused true instead and frame advance no longer messes up. 3- I also found an easy way to improve the timing with the GB screen (simply don't break out of the main emulation loop during mid-scan) to avoid the partially-drawn transitions that used to be all over the place. Keep in mind that all of these were pre-existing problems with the GB emulator core, it's not shanedudddy's fault it was so screwed up. Anyway, a lot of the changes/disablements shanedudddy made now seem to be unnecessary. Oh, and here's the movie format I've decided on, so far at least, so let me know if you see anything wrong with or likely to cause trouble in it: Movie File Format: (currently going with .VBM (visual boy movie) extension to avoid confusion with existing .VBV/.VMV files) Header Info Start Data Controller Data Header (64 bytes): 000 4-byte signature: 56 42 4D 1A "VBM\x1A" 004 4-byte little-endian unsigned int: version number, must be 1 (for now) 008 4-byte little-endian integer: movie "uid" - identifies the movie-savestate relationship, also used as the recording time in Unix epoch format (obviously this stuff is based on the Snes9x movie format) 00C 4-byte little-endian unsigned int: number of frames 010 4-byte little-endian unsigned int: rerecord count 014 1-byte flags: - bit 0: if "1", movie starts from an embedded "quicksave" snapshot; if "0", it doesn't - bit 1: if "1", movie starts from reset with an embedded SRAM; if "0", it doesn't - (NOTE: If both bits 0 and 1 are "0", then movie begins from power on with no SRAM or save state. If both bits 0 and 1 are "1", the movie file is invalid.) - other: reserved, set to 0 015 1-byte flags: - bit 0: controller 1 in use - bit 1: controller 2 in use (SGB games can be 2-player multiplayer) - bit 2: controller 3 in use (SGB games can be 3- or 4-player multiplayer with multitap) - bit 3: controller 4 in use (SGB games can be 3- or 4-player multiplayer with multitap) - other: reserved, set to 0 016 1-byte flags: - bit 0: if "1", movie is of a GBA game; if "0", movie is of a GB or GBC or SGB game - other: reserved, set to 0 017 1-byte flags: values of some boolean emulator options0 - bit 0: synchronize - bit 1: theApp.useOldSync - bit 2: theApp.useBiosFile - bit 3: theApp.skipBiosFile - bit 4: theApp.removeIntros - bit 5: theApp.winRtcEnable - bit 6: left+right / up+down - other: reserved, set to 0 018 4-byte little-endian unsigned int: theApp.winSaveType (value of that emulator option) 01C 4-byte little-endian unsigned int: theApp.winFlashSize (value of that emulator option) 020 4-byte little-endian unsigned int: gbEmulatorType (value of that emulator option) 024 4-byte: reserved, set to 0 028 4-byte: reserved, set to 0 02C 4-byte: reserved, set to 0 030 1-byte: reserved, set to 0 031 1-byte unsigned char: the CRC of the ROM used while recording 032 2-byte little-endian unsigned short: the Checksum of the ROM used while recording, or 00 if GBA 034 4-byte little-endian unsigned int: the Game Code of the ROM used while recording, or "\0\0\0\0" if not GBA 038 4-byte little-endian unsigned int: offset to the savestate or SRAM inside file, set to 0 if unused 03C 4-byte little-endian unsigned int: offset to the controller data inside file Info (192 bytes): After the header is 192 bytes of text for the author to put some information in. The size is fixed to both to simplify code and to make it a lot easier to hex edit author info in after the fact. Start Data: Located somewhere after the Info, as determined by the 4-byte save offset value at 0x038 in the Header. It MUST be BEFORE the controller data, however, and obviously must not overlap the controller data. Can be either a save state snapshot or SRAM, as determined by the 1-byte flags at 0x014 in the header. Also has the possibility of not existing at all, which is the same as containing SRAM all cleared to 0. Controller Data: Located somewhere after the Info, as determined by the 4-byte controller offset value at 0x03C in the Header. A stream of 2-byte bitvectors which indicate which buttons are pressed at each point in time. (They will come in groups of however many controllers are active, in increasing order.) Each value is determined by OR-ing together values for whichever of the following are pressed: 0x0001 A 0x0002 B 0x0004 Select 0x0008 Start 0x0010 Right 0x0020 Left 0x0040 Up 0x0080 Down 0x0100 R 0x0200 L 0x0400 Reset 0x0800 (unused/reserved) 0x1000 Left motion sensor 0x2000 Right motion sensor 0x4000 Down motion sensor 0x8000 Up motion sensor Reset is recordable input because some games require reset to do certain things, such as loading up an unlocked feature. It is not used to make any of the recording modes work, for example, start from reset does not put "reset" as the first input. Also, note that in real life the motion sensors are analog, but VBA already uses digital input for them and simulates their analog-ness internally. (Anybody know of games that use the motion sensor that would be good for testing? I've already implemented recording of it, along with most of the above, but I'm guessing it won't work right with re-records until I test it out and find some more bugs.) I've uploaded the code to pilif's FTP (http://nvdata.pilif.ch/new-vba-rerecording-src.zip) if anyone wants to look, but there's still a lot to left to do, on the interface side of things especially (which is to say, I have to figure out how to prevent Visual Studio from having a cow and giving mysterious linker errors whenever I alter the resource file).
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Tilus wrote:
Do you plan on using the Defend formula (or the Speed formula, which you pick up in the Volcano in the same way) sometime later in the run?
Saturn already explained that this is supposed to be a 100% completion run of the game, which means every formula must be acquired even if it's useless.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Whoa, that's pretty weird/funny. Have you tried setting the buttons one at a time, starting from the right side then the left side, going from bottom to top, and hitting OK after each one is set? Actually, here's a better workaround for now: Set up your joypad in an older version of Snes9x where it works. Then you can open up the newer version and those settings will be imported.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
About starting over with VEHR on, it's likely that's not even an option, because a lot of times VEHR behaves unpredictably meaning the movie will randomly desync with it on, even if it was recorded with it on. I wouldn't know how to fix a timing issue as deep as that, but perhaps there's a way to fool it into thinking it's off for timing-critical APU things while leaving it on for sound generation... I'll look into this sometime.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
ventuz wrote:
I have never had problem configurating control to joypad, but this new version, but in this version 7, im having trouble adding joypad control. (I dont know when was introducted, i was jumped from version 4 to 7) I dont know how to explain it, but it's doing weird screw up. It's not joypad problem (other emu doing fine).
From 4 to 7 I think includes the leap from 1.43 WIP to 1.43 Final, so my guess is your problem has to do with this thread. (EDIT: or maybe it was one of those other threads, I know some of them are about other people experiencing problems configuring their joypad.) Could you try explaining it even though it's hard to explain? It might help.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Fabianx wrote:
I assume you are using Fake Mute Workaround as the video was recorded with it on. At least in linux if Saturn picks up a item (like some oil or ashes) I have the feeling the sound is "longer" then it should be ... Overall sound quality "feels" quite bad under linux, but I have not checked if it would be much better without Fake Mute Workaround... Or is ist just, because I'm using v1 of the Fake-Mute Patch? ...
Well this game is supposed to sound a little weird. But actually, maybe I'm just imagining it, but I think Fake Mute is causing some sounds to get cut off before they finish, they're actually supposed to be even longer, with a fade-out time at the end. Saturn, you should turn off Fake Mute the next time you play back to re-record and continue working on this video (the change will get saved into the movie when you re-record while the setting is changed), because Fake Mute doesn't affect this game at all except maybe to make it sound a little worse. EDIT: Oops, actually fake mute has nothing to do with it. It's because Volume Envelope Height Reading is off. It sounds a lot better with it on, but it also desyncs with it on so we might just have to live with the weirdness.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
suraimu wrote:
Having problems with this one - it desyncs during the final battle with Bowser.
You must have "Allow Left+Right / Up+Down" on for it to be desyncing there (and the author must have accidentally pressed left and right at the same time during the final battle). Turn that option OFF (and keep it off most of the time) and it should playback fine, with WIP timing on.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Is there anything wrong with just leaving the emulator setting on "Automatic" and border on "automatic border" instead?
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Oh, right I forgot to comment on this newest update here. It's looking great, I can't think of any improvements to suggest either, and I'm really looking forward to seeing how you manage the next part of the game (not to mention the rest of it).
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
VIPer7 wrote:
Very nice, I didn't think that Zurreco's movie could still be improved by 74 seconds. To be honest, I didn't really notice that many obvious improvements, it must have been lots of small details
There were a lot of improvements, maybe I should list them:
  • jumping past the auto-walk part of 1-1
  • not losing forward momentum on a block later in 1-1
  • not getting hit in 1-2
  • killing the 1-2 miniboss faster with more throw attack
  • running to the exit of 1-2
  • killing the 1-4 snake boss a little faster
  • keeping momentum and not waiting for an enemy in 2-1
  • running across the leaves to the exit in 2-1
  • swimming faster in 2-2
  • killing the 2-2 miniboss faster by using the much stronger fully-charged shots
  • running instead of walking throughout 2-3
  • killing the 2-4 spider boss a little faster
  • running instead of walking to the miniboss in 3-1
  • running instead of walking when going up the platforms and hill in 3-2
  • not waiting for a platform in 3-2
  • clearing blocks faster in 3-3
  • making it under the fire wall when it comes down the second time instead of waiting for it
  • faster climbing and grappling in 4-1
  • going under the mountain in 4-2
  • killing the 4-3 bird boss a LOT faster
  • killing the 5-3 walrus boss a little faster
  • not using the slower-than-running magic carpet in 6-1 or wasting time changing into the magic suit
  • riding up a block in 6-3 (this is actually near-impossible to do)
  • pushing block in 6-3 other direction and somehow getting an invisible foothold to jump on it
  • killed the 6-4 final boss a decent amount faster
VIPer7 wrote:
What I did not like were those upward jumps (e.g. at 16300 / 18900 /22000), but I guess they can't be shortened
Right, the game does not give any control of how much vertical height those branches give, either you go up a lot or you barely go up at all.
VIPer7 wrote:
The wait at 21000 was needed to not get hit by those hammer stompers?
It was the minimum time I had to wait in order to both not get hit AND be able to continue running throughout the rest of the level. It more than made up for the time lost waiting.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
The main difficulty is that if you miss a single arrow, you can't fire another arrow until it hits the wall, and the chance of getting even 2 arrows in is pretty low. The other problem is that unless they're heading straight toward you they move too fast to get many shots in. I think the best that could be done in a human run is to: 1- stand near where one is about to appear, on the side of it that's closest to the center of the room, and fire an arrow at just the right time so it'll hit it when it pops out (this the only part that doesn't rely on luck, mostly just timing practice) 2- if it hit, keep firing until an arrow misses 3- when an arrow doesn't hit, rush in and start swinging the sword. It may help to keep the sword charged during all the previous arrow-firing to get off a spin slash, if spin slashes do more damage than a regular slash to lanmolas 4- switch targets and repeat, starting from step 3 if you're either not lined up right or not able to fire an arrow I think killing them in less than 6 "pop outs" with this (or any) strategy would require an unbelievable amount of luck as well as LOTS of practice.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
I'm starting to believe you're right that a lot of leveling is needed in Terranigma, though, but not so much that it wouldn't be worth doing to get through the rest of the game. Actually I think maybe I'd rather see a Seiken Detsetsu 3 run at this point, after seeing how well the other Secret of Mana/Evermore runs are coming along.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
DeHackEd wrote:
Okay, I botched up applying the patch from v6 to v7. I did it again more carefully and it worked better this time. Sorry, that was my fault and not yours.
Actually, this is probably a stupid question, but how do you apply these patches? I assume there's a program that can apply them that I just haven't found, but if it has to be done manually, maybe I should just put up the full source since that's a lot of changes to be applying manually...
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
asteron wrote:
How possible is it to hexedit this thing together in stages? ... to splice different runs together with only a few frames of luck manipulation in between sections to sync things up.
This is possible, I've done it before (very briefly) with similarly random games, but it's actually WAY more work than just starting over from the point of the mistake, and it's also less optimized because it misses out on more favorable random conditions that might have opened up. (It would become more possible if we knew something about how this game determines its random numbers (for instance if it just depended on the frame and it wrapped around every some number of frames), but I don't think anything like that is known...)
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
suraimu wrote:
If the steps in the castle are slower than jumping off a ledge, you can save a couple frames in the room to the left of the boomerang - if you move over to the corner you can jump down instead of taking the steps.
Have you really tried this? I don't believe it's possible to jump there, the corner isn't far enough away from the stairs.
OmnipotentEntity wrote:
I'll decide whenever I get the new snes9x compiled under Linux.
Oops, am I holding this up? (I thought you were either using windows or wine, I don't really know what improvements can carry across into a Linux build.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
First of all, I'm not aware of any changes I made that would benefit the Unix version, they're mostly Windows-specific, except the desync fixes which I haven't added commandline switches for yet. At the very least I can try to keep the Unix code compiling with the rest of it, though.
DeHackEd wrote:
What's broken with v6 ... So it comes down to some header file errors, something funny with the unzip code, and changing the parameters of S9xMovieCreate. I had to do some ripping, but I got it.
These are mostly problems with me not realizing there was unix-specific code (which I can't test) that calls any functions I changed. Shouldn't be hard to fix... What do you think are "header file errors", though (and which header files)? (About the unzip code, the file it was looking for is zLib\crc32.c, I don't know why it didn't find it for you. But then again, I think you shouldn't need to include that file, but for some reason I need to for it to compile (otherwise it says crc32() is undefined).)
DeHackEd wrote:
I'm not going to put per-frame data on the image (ie Frame counter); I'm sending it to stdout instead. That chunk of your patch I'm removing.
The frame counter already output per-frame data on the image even before I changed it...
DeHackEd wrote:
And now the problems from v7's source:
snapshot.cpp:602: error: `FREEZE_ERR_WRONG_VERSION' undeclared (first use this function)
(And a whole lot like it.)
This is defined in language.h. It's included by snapshot.cpp (snapshot.cpp->movie.h->snes9x.h->language.h), so I don't know why it isn't being included for you.
DeHackEd wrote:
i386/cpuexec.o(.text+0x45e): In function `.noOAMreset':
: undefined reference to `S9xUpdateJoypads'
And I am NOT touching the assembly core.
This looks like a regular out-of-date-header problem. It's defined in snes9x\i386\sa1struc.h for me, what other file are you using instead of that?