I have writen a small program in C# 2.0/.NET which, when associated with the .fcm extentions, allows you to view the movies simply by double clicking on them in explorer.
Download [This version is old. Please find the post with the most recent version]
The basics of how the program works:
Setup an ini. The ini belongs in the same directory as the executable, and is named config.ini. To give an example, mine is:
[config]
dirs=G:\NES\US;G:\NES\Jap
fcm=E:\NES\fceu-0.98.12-blip.win\fceu.exe
Of course change for your own situation. The program will warn you if there is a problem with it.
When the program runs, it gets the md5 checksum from the movie file. It then checks against it's database (sqlite) to see if that file is known. If not, it updates the database (the first time, if you have a lot of roms, it will take a bit), and rechecks the db for the rom.
To associate this with your fcm's. Just double click a fcm in explorer. Ask to find the program, and pick emuMovFront. And you're all set.
You will need a semi-special version of FCEU. I believe nitsuja intends to keep this in the main releases. Download semi-special FCEU. A big deal fo thanks to nitsuja for helping me out.
The source code will be released with my second release (it's dirty atm). With the second release I hope to support additional systems.
Comments, mud slinging, bugs, feature requests, etc, are overly welcome.
Edit---
Any one who downloaded it prior to 8:15EST may want to consider redownloading- assuming they want the program to work :P
I accidentally uploaded the wrong executable.
I just wrote a program which generates a md5 for every rom (zipped or uncompressed) in the directories you give it (stored in a SQLite db), and matches the checksum stored in the video file to the file that way... but... um, now I realize that FCEU does not support command line movie playing!
Some one mind helping, I'm hoping I didn't write 300 lines for nothing :)
It's writen in C#, so even you linux nuts may be able to use it via mono :P
Does anyone have a link to a website with the memory address of things like "link gets damage", "link dies", "link falls down a hole" etc.? I've got an idea I want to test out.
Plasmo;
I'll redescribe what I wrote on my page, but more casualy.
Note, when ducking out side of the grating of a vent, you can walk through it one way. I believe this was intentional,and I believe this is what causes these glitches.
Now note that some thing odd happens while kneeling and going forward on any tiny ledge that has a full wall infront of it. I believe this is an unintended glitch due to the above intentional programming.
It seems the game allows Duke to slighly move into the structure. Since it's not tiny, as a grate is, it pushes you back out. This causes a 'jittering' effect. Any wall where you can jitter, you can push into.
Raw meat is highly glitchable. The basic idea is you need enough push to be able to survive the trip through the wall. If you're going to slow... pop, you're done.
I've yet to be able to push my self through any wall aside from the sign (not through the sign then through the wall) in raw sushi using the RPG. I believe with slow down I would be able to, because it would allow me to get running speed, jump, turn around, and fire- a skill I don't have otherwise.
Space port is a funny one. Getting in follows the above mentioned logic. In this case, the wall is the forcefield, and the ledge is the outer rim going around the forcefield. But getting out is differnt. I'm not fully sure how it even works, but I've managed to do it several times.
I suppose you could try doing some steroid&explosion push out, but mine have only used steroids, jumping franticaly, and a lot of luck.
I left you a message via icq's web service thing. I have no idea if/how it works. Feel free to contact me via AIM at fizzbinx or through the email in my signature if you need any more help.
On a some what off note, any one here interested in making a TAS version of Duke for the PC? :)
Rick;
I was dicking around with the n64 version to see if any of the glitches transend. I couldn't get the controls to be acceptable enough, but I did manage to note that the way to avoid the blue key card in level 2 does work.
Daedolon
Thanks for that bit of info. The strange problem is is that some times I can switch through walls, and other times I can't, often in places were the wall is even thinner. If you have any idea, I'd appreciate it if you could contact me through email.
I'd hate there to be two similair projects in existance. No reason to tred water against one another. I have created a pretty flexable frame work intended on reading emulator's memory. It also has coded support to support bots, it's just that the key commands are empty, due to not having a valid way to comunicate. If you want an example, though very immature, look at the Tetris class in GameGeneric.cs.
One of the main things my approach lacks is being able to hook an instruction address. Aside from that, it seemlessly switches between games and emulators, and should have enough features on the programmers and users end of it all.
http://www.red-stars.net/EmuRead/EmuRead-110205.rarhttp://www.red-stars.net/content/EmuRead
I've watched the VCR based speed runs, though very impressed, I do believe this game could heavly benefit from tool assistance.
I'd like to see bountys for videos. I'd toss 5 bucks at Blast Corps.
If I recall properly, the only time the potential outcome will change is if the int32 at 0x02000008 changes. So watch that in the memory viewer.
That changes every single frame... Are you sure you don't mean 0x02000010?
I do mean 0x02000008 as an int32, so it includes 0x02000010.
It depends upon the room's needs. For example, the room to the left of the first mermen room, and then to the right of that room, you'll see that it dosn't change unless (I believe) a fish causes it to change, or your weapon.
If I recall properly, the only time the potential outcome will change is if the int32 at 0x02000008 changes. So watch that in the memory viewer.
I have not stopped working on it, I have just split my efforts across very broad grounds and I'm not progressing much in AoS at the moment.
EmuRead is currently extreamly stable and in a very release worthy state. The only problem is the lack of use it has with little to no read ahead prediction. One thing I have been putting my interest into is Tetris, and creating a bot for it. The problem being, I have no valid way to send key strokes to the emulator.
It was a little while ago that I bothered to work on the random attacks in this game. But the following are my notes on the subject:
//f5 == pointer to table index at 0x3F900, which relates to random attack.
/*PRNG? $80=(($27+#07) << 4) & #07
$80=(($28+#07)>> 2) & #38 | $80
x=$6012 & #40 | $80*/
It's rather odd. $F5 seems to dec on each step, which is then used as the index into the table at 0x3F900, and some how $80 mixes into it all.
I need visual boy save states in battles against several differnt bad guy types if any one could possibly provide them.
I have updated the features in my program and released the current source and binarys. If some one wishes to help test this out for/with me, that would be awsome.
Information and downloads can be found at: http://red-stars.net/content/EmuReadScreen shot
Please note, the bottom 3 menu items in the "Informations" tool strip do not currently function.
I have finished most of my transitional steps from the last beta to the new one. I just hope that I can get some actual value behind the information provided before I release binaries and source again.
As you can see, I moved over to a tree view. Sadly, this is a third party control and it's slow as shit. Since the code adds items via a named path, I even have a collections class caching the path to node lookups. The problem is in the third party control. It apears to not properly impliment BeingUpdate and EndUpdate since that seems to cause it to redraw even more. I'm going to have a look at his code and see if I can fix up at least that problem, if not, any one know any decent tree list views?
The only game specific code for the above output is:
public class MarioLuigi : GameGeneric {
public MarioLuigi(EmuClient vba, MainForm mainform)
: base(vba, mainform) {
Title = "Mario and Luigi: Super Star Saga (USA)";
}
public override void UpdateDisplay() {
AddItem("Mario\\HP", Emu.Short(0x02004866) + "\\" + Emu.Short(0x0200486A));
AddItem("Mario\\BP", Emu.Short(0x0200486C) + "\\" + Emu.Short(0x02004870));
AddItem("Luigi\\HP", Emu.Short(0x020048A2) + "\\" + Emu.Short(0x020048A6));
AddItem("Luigi\\BP", Emu.Short(0x020048A8) + "\\" + Emu.Short(0x020048AC));
AddItem("Luigi\\Level", Emu.Byte(0x020048C4));
AddItem("Misc\\Coins", Emu.Short(0x020048E0));
}
}
I'm rather pleased at how simple I was able to keep it. The Emu class will translate the provided GBA address into an internaly stored list of views and return what you desire from there. The AddItem member dosn't actualy add an item unless it's not found inside of the cache, otherwise it just updates the current.
Should be simple and flexable enough for any one with mild {}; language knowledge to get what they want working.
Once again, thanks Ike :)
Is there any thing for this game that could be included in EmuRead to assist in the speed running of this game?
I tossed in detection and some basic reads for this game as my first supported game simply to test the software out, but I'm rather lost if there are any valid uses for this software for this game.
I played through the Japanese version, so I'm rather shitty with names and story line events, so stuff a bit more specific then english names would be nice.
I'm still mainly waiting on the hacked VBA for soul collection.
I got some stuff done just as proof of concept to my self. I'm currently implimenting tons of new stuff into the code base, but havn't had too much time to work on it at the moment. I should be able to make some progress this week.
I'm moving the output over to a TreeListView with an abstraction layer for updating, and I'm moving the main VBARead class over to a child of the abstract EmuRead. Thouse things are what are taking up most of the development time at the moment. I'm putting in a lot of effort to make sure that expanding the software for additional games and emulators is as simple as possible. Hopefuly soon I'll be able to go back to working on adding in game specific features opposed to program features, as I wish to do.
Do you think it's a good idea to put these changes (when completely done on the VBA side) into the supported VBA rerecording version, or will they necessarily impact performance or something? At some point I'll be putting up a minor update to VBA, and I haven't had a chance to look at what changes you've been making yet, I'm just wondering what you think about it.
To my knowledge, there is no performance inpact. I, being a fan of this, would appreciate this being in the standard VBA-rerecording release.
As a side note, I cleaned up the source a good deal, added in some new stuff and started working on Castlevania: AOS a bit, but it's difficult debugging to make sure my interpitation of the formulas are proper given the lack of break points in the non-sdl vba. I should have some thing else posted around 2pm (GMT-05) tomorrow.
I currently have very preliminary support for damn near any thing in my program at the moment. I'm attempting to get the code base as flexable and useable as possible before I go ahead and impliment a million things.
The source and binaries can be downloaded from http://red-stars.net/content/VBARead
The source code needs more cleaning up and commenting, a timer included for refreshing, fixing up the generic game class, possibly other display options.
To use as is, run Ike's VBA, load up Mario and Luigi's Super Star Saga, get into a saved or new game, then run \VBARead\bin\debug\VBARead.exe, and you'll see some basic stats displayed.
This, as is, is not useful. I wanted to get the code base out there to allow people to start tinkering with it and not need to wait for me to release a full blown application/cleaned source before they get a chance to have a bit of fun.
All in all, it should be simple enough for any one with some fundamental C#/.net experience to be able to impliment what they so desire. To build it, using microsoft's Visual Studio C# Express Beta2 should work just fine.
The only games I can stand are new games in new series (Golden Sun, MM Zero, MM EXE, Boktai, WarioWare, Advance Wars and FE in the US), I can't think of a single remake that was even on par with the original, and even games that everyone else and their mother thinks are great (Mario and Luigi, FFTA, Sword of Mana, etc) I think are awful.
Klonoa, Mr. Driller, Rampage, Metroid, Castlevania, Bomberman, and Mario and Luigi (Mario RPG), all, in my opinion of course, had their best title(s) on the GBA.
Excellent everyone involved, this hopefully will lead to people attempting this for other games. (FF6 US with this for snes? ...)
I fully intend to help every one out to the best of my abilities, given enough free time, for any GBA game that I have interest in that others are planning on speed running. I also fully intend to do the same for NES if any one decides to release a version of FCEU with the same feature.
I am glad others are taking interest in such matters, since this truly is a higher level of tool assisted speed running.
Edit---
Some thing that could be made from this is what I was working on for Doom a while ago- Speed running bots :)
Edit 2---
Ike; I am woundering if you could compile it to share all of the gba's memory? Including rom, iram, wram, etc. I wish to read the rom's header to switch my programs functionality based upon what game is loaded. This way I can keep a single code base for all games and allow it to autodetect.
Also, this should probly be split to a seperate thread.
Ike;
Thank you very much for your effects, would it be possible for you to email me a copy of your build (email: jlennox[at]gmail[dt]com)?
I will begin work on making an AOS tool as soon as I recieve the new binaries.
As you can see, I moved over to a tree view. Sadly, this is a third party control and it's slow as shit. Since the code adds items via a named path, I even have a collections class caching the path to node lookups. The problem is in the third party control. It apears to not properly impliment BeingUpdate and EndUpdate since that seems to cause it to redraw even more. I'm going to have a look at his code and see if I can fix up at least that problem, if not, any one know any decent tree list views?
The only game specific code for the above output is:
I got some stuff done just as proof of concept to my self. I'm currently implimenting tons of new stuff into the code base, but havn't had too much time to work on it at the moment. I should be able to make some progress this week.
I'm moving the output over to a TreeListView with an abstraction layer for updating, and I'm moving the main VBARead class over to a child of the abstract EmuRead. Thouse things are what are taking up most of the development time at the moment. I'm putting in a lot of effort to make sure that expanding the software for additional games and emulators is as simple as possible. Hopefuly soon I'll be able to go back to working on adding in game specific features opposed to program features, as I wish to do.