Just found this while cruising around. Good to see that Canadians can make useful contributions to the world of Arachnology :P
http://www.youtube.com/watch?v=sHzdsFiBbFc
EDIT: Fixed punctuation (hopefully).
All the screenshots look good... but I still can't run it. :( I can offer my opinion anyway. I know all these are low priority, but anyway:
Your system's .NET framework needs to be up to date to use this (you can get it here)
If no other formats are really necessary though (for the moment) I guess I'll just focus on tightening up the one's that are there already. I'd like to add zsnes support, simply because I like the emulator and the format. It's a shame more people don't use it (i know there are difficulties right now) because the chapter functionality is pretty cool and would be perfect for longer TAS' (especially RPG runs)
Looking good so far. I'm assuming asteroid belt will be done in 3rd person view? 1st person might be boring (just watching the crosshairs zip around and all)
Started planning and testing some additions to the next version. The next release may take a tad longer than the last couple (got another project on the go so can't release something new every couple of days =P)
Now that the form can be sized, I don't like the input editor being anchored all the way at the bottom, so in the next release, it'll be hotkey toggle-able and can be positioned anywhere on the screen while editing.
Also, I should FINALLY have metadata editing included into the saveAs logic.
I've decided I'll finally increase the major revision to 1.0 when 2 things have been accomplished:
1) mupen editing is fully functional
2) input display/editing is more convenient.
The first, I've got under control. The second however, I'd like to get some ideas on. The idea to display graphical representation's of the input has been kicked around in the past (still testing for speed), but how should editing be handled?
I've almost hit 250 downloads on sourceforge since I started hosting the project there (granted it's across all releases so the user base here could be like 6 people), but I'm writing this for everyone so I'd like to hear what you think.
Any suggestions are welcome. If you've got a far out, crazy idea, even better :)
The final-ish, todo list, as it stands today is below:
// high priority
TODO::Add exception handlers to format loads (in case headers check out but input is corrupt)
TODO::Add metadata editing support
TODO::Add internal Help options
TODO::Finish mupen support (will have to be controller inputs ... not frame inputs :(
TODO::Track recent files (file->open history)
(this could be done through a config file so no need for registry entries,
also, this would allow toggled options to be stored and loaded at runtime)
// medium priority
TODO::FCM doesn't track control updates (figure out best way to implement)
TODO::Add block overwrite on paste (as opposed to just inserting the block)
TODO::Add controller muxing/demuxing (add/remove controllers)
TODO::Add ZSNES support
TODO::Overhaul frame input editing
// low priority
TODO::Line up input (fake columns of data, so if <>A, < AB, v BS, ... etc)
(This prolly won't happen until I figure out how I want to display input)
TODO::Add FinalBurnAlpha support?
TODO::Add GMV2 support? (not sure if the format is completely defined yet)
TODO::Add Nestopia, VirtuaNES support? (not sure if it's even necessary)
It'd be neat to be able to select another submission that you are obsoleting when you submit (and then have an automatic link on the new submission page), but this feature would no doubt be abused to the point that we wouldn't be allowed to have it in the first place.
Amazingly, I can't think of any serious way to abuse this. What do you think?
Someone could swap an accepted submission with something stupid I guess, but I don't really see why anyone would go to the trouble.
I want to ask Maximus while he's here, any chance you could include multiplex/demultiplex functionality to your editor? I inadvertently had P1 controls overlapping with P2-4 and it would be nice to demux and clear the unnecessary data.
I'll add it to the list. Try to keep posts relevant to the thread though, derailment seems to piss people off ;)
Well that has got to be one of the most anticlimactic endings to an rpg i've ever seen :P The planning and execution were spot on, even though this isn't really the most entertaining run.
However, if storybook-style games have been accepted and published , such as Deja-vu, Shadowgate, or The Uninvited, you can't really hold the fact that this is menu based against the run.
Let me be the first to vote yes on this.
Cool, I really like this idea, though I think you could add a few nicer GUI touches to it. I was thinking along the lines of a movie timeline, where you can drag and drop the various movies into the splicer, and drag them into place. That way, it would be possible to introduce say 500 frames of no input before the next portion or the movie starts to play. That way, it would also be easier to insert a movie within an already existing movie. And just make sure you remember to put some checks in place to make sure that only movies of the same format can be loaded onto the timeline, which I assume you know but just have not been implemented into the demo.
The format checks exist for splicing. I just wanted to show off :P I like your idea though, it's just a matter of farting around with an interface.
v0-9-2
- UI::Drag and drop of a movie onto the main Frames listview now loads a file also
- UI::Paste or remove now ensures that the position where the action was initiated remains visible
(as opposed to the list resetting to the top position each time)
- UI::Added option to toggle editing prompts (Options -> Confirm Editing Actions)
- UI::Updating frames doesn't cause the input to scroll back to the top
- UI::Main form is now sizable :)
- UI::Adding/Removing now no longer repositions the position within the list unless a large remove
is performed
- UI::Pasted blocks are now inserted AFTER the target frame
(who'd a thought that adding 1 to an index would be so complicated :P)
- UI::Added undo functionality
- UI::SaveAs now defaults a filename ("new-" prepended to existing filename)
- ETC::Application messages now written out to the Message History (CTRL+M)
- M64::Input now parses (ControlInput though, there's no way to match it up directly to the frames)
Just so no one thinks I don't listen ;) (no help yet ... but soon)
Preliminary mupen input support. I don't really like how it displays (and I'm not even sure its accurate).
EDIT: The undo buffer doesn't have any growth restrictions, so this may bog down the program eventually. If I were to clip it at say, 10 generations of input, would that be enough?
Good update, but I still see 2 or 3 more bugs still in there. You haven't read my PM?
I did read your message (not ignoring you, i swear :P)
* Crash - Why does it say "Add Frame(s)" when it only add 1 frame? (And this one causing crash on saving as well)
* Bug / Glitch - When you have a bunch of frames on screen, click arrow down (not click and hold). They start to crossing lines on the words.
* Bug / Glitch - Pasting doesn't paste "after".
* Feature - Header information doesn't seem to update when you add/remove/splice.. etc... Would be nice if it does.
* Feature - Ability to stretch window, I feel that only viewing 17 frames is very limited, it would be nice if it stretch to be able to view 30 frames at once.
* Feature - Toggle to remove "Are you sure?" for pasting and remove, they gets annoy after a while.
* Feature - Undo, for the purpose above.
* Feature - It would be nicer if pasting cause cursor (or window) scroll down last portion of entire paste, for example:
Good ideas. I'm working on most of them (this was just a minor update release). What bugs are you referring to though? (not the paste thing ... i'm working on that as we speak)
EDIT: Sorry, forgot to put it in the release notes, but pasting now scrolls the edit window to the point where the past was initiated (if you paste at position 100, it ensures that 100 is visible after the paste)
About f***ing time eh? :P
I finally broke down and started writing a manual for this. Next version should come bundled with a brand spanking new chm file to describe how to ues this bad boy :)
It gets out of synch here in both movies (one later than in the other, but always on the same spot), I have tried different configurations of FCEU with no luck (the ROM is the correct one). The first one looked impressively, the second one desynchs on the first wall glitch.
Ok. I managed to actually crank out the new splicer in about 3 hours, so I figured I'll release an update.
v0-9-1
- UI::Fixed a bug where autoFire updates wouldn't set alternating frames properly (oops)
- UI::Fixed a bug where removing frames would throw an ArguementOutOfRangeException
- UI::Added elipses to the Open/SaveAs menu options to denote that they make a dialog call
- UI::Sorted formats alphabetically in Open/SaveAs filter dropdown
- UI::Added message if input pattern not found
- UI::Double-buffered listviews (probably should have done that from the start :P)
- scrolling through the input list doesn't "flash" anymore
- UI::Edit text fields weren't clearing after a file was closed (oops)
- ETC::Re-wrote splicing logic and interface
- M64::Fixed movie start flag read (was interpreting wrong byte pair)
Mostly bugfixes, but I think the new splicer is pretty sexy :) Just drag and drop files from explorer to the list, edit the ranges for each movie, and hit splice.
FODA's idea just keeps coming back :P
I like the idea, though (in my editor at least) it likely won't be appearing for a while. Zefiris' has input displayed horizontally (audio sequencer-esque). Since he's done a pretty good job of it, unless people really dislike the way i'm handling input (not input editing, i know that sucks right now) i'm not likely to change it (for the moment at least).
I see the fields are edited below. Why won't make them editable right where they are?
It's a ListView, not a GridView, so it's not directly editable (without subclassing the control). Since this is the first generation of the new feature, I just want to make sure it works ;) After that, I'll see if i can improve the interface.
Nothing really to report yet, but I have fixed up the errors I said I would.
I was going to release a fix, but adelikat gave me a really good idea for handling the splicer.
Drag-and-drop functionality, and no more being limited to only two movies. It's not 100% done yet, but just figured I'd show everyone I'm still working on this ;)
Also, it seems with that dynamic wall glitch of yours, you might be able to skip Matic too and go straight to the tree. I'm sure you looked into this already, but just a thought.
I can glitch to Matic in the first corridor in the Red Dragon. I tested this, but the problem is, if you glitch through the left side of the wall instead of the right side, even though you fight matic, the spark won't knock the cypher out of his hand, so it's impossible to beat him.
The final tree is a couple screens below the initial position you start at in the Red Dragon, and there's no left wall to abuse :(
As for the additional hit in Kazakh, i couldn't take enough damage :P If I wait around to take more by the guys prior to getting Disk 2, it's actually slower than taking an additional hit. I think i can get the shooting guy to hit me after the second wall glitch, but it didn't happen this time around :(
Howdy all. I'm not as experienced with C as I'd like to be, and I'm working on merging the updated mappers with 0.98.17. I figure this is good practice, but I need a hand deciphering make errors.
What I'm essentially doing is merging changes from fceu-mm-june16-2006 to the existing source one file at a time (this way I can see what's changed and how).
I've currently updated all the mappers/boards, and am making changes to the main source files that reference these changes, but when I build, I get the following error:
$ make
Making all in src
make[1]: Entering directory `/home/Maximus/fceu-0.98.17-wip/src'
source='general.c' object='general.o' libtool=no \
depfile='.deps/general.Po' tmpdepfile='.deps/general.TPo' \
depmode=gcc3 /bin/sh ../depcomp \
gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"fceu\" -DVERSION=\"0.98.17\" -D_GNU_SOURCE=1 -DHAVE_LIBZ=1 -DNETWORK=1 -DPSS_STYLE=2 -DWIN32=1 -DC80x86=1 -DLSB_FIRST=1 -DFCEU_VERSION=\"0.98.17\" -DFCEU_VERSION_NUMERIC=9817 -DFRAMESKIP=1 -g -O2 -c -o general.o `test -f 'general.c' || echo './'`general.c
In file included from general.c:37:
driver.h:196: error: conflicting types for 'MOVIE_INFO'
driver.h:196: error: previous declaration of 'MOVIE_INFO' was here
driver.h:203: error: conflicting types for 'FCEUI_MovieGetInfo'
driver.h:203: error: previous declaration of 'FCEUI_MovieGetInfo' was here
driver.h:203: error: conflicting types for 'FCEUI_MovieGetInfo'
driver.h:203: error: previous declaration of 'FCEUI_MovieGetInfo' was here
driver.h:290: error: redefinition of typedef 'TestCommandState'
driver.h:290: error: previous declaration of 'TestCommandState' was here
driver.h:296: error: redeclaration of `enum EMUSPEED_SET'
driver.h:297: error: conflicting types for 'EMUSPEED_SLOWEST'
driver.h:297: error: previous definition of 'EMUSPEED_SLOWEST' was here
driver.h:298: error: conflicting types for 'EMUSPEED_SLOWER'
driver.h:298: error: previous definition of 'EMUSPEED_SLOWER' was here
driver.h:299: error: conflicting types for 'EMUSPEED_NORMAL'
driver.h:299: error: previous definition of 'EMUSPEED_NORMAL' was here
driver.h:300: error: conflicting types for 'EMUSPEED_FASTER'
driver.h:300: error: previous definition of 'EMUSPEED_FASTER' was here
driver.h:302: error: conflicting types for 'EMUSPEED_FASTEST'
driver.h:302: error: previous definition of 'EMUSPEED_FASTEST' was here
make[1]: *** [general.o] Error 1
Any pointers as to what I should be looking for would be appreciated (may have bit off more than I can chew with this one)
Well, I decided that I'm not done with this run yet. As opposed to cancelling the current submission, I'm just going to see if Bisqwit can replace the fcm for me.
I went back through this and, surprise surprise, it can be improved quite a bit more.
This time around, I skip the glitch fight completely and opt for using death-as-a-shortcut. This kicks me back to the blue dragon, where I analyze disk 2 to open up Australia on the map. This accomplishes three things:
1) Save time on the getting to the glitched tree and fighting
2) Extra text interruptions due to Level up and disk 5 aquisition
3) Disk 2 is quicker to analyze than disk 5
I glitch past ALL the boss (re)fights this time around and go straight to Matic. By glitching through the walls to him, I can get him stuck in the door and just slash away till he dies.
This puts me closer to my goal (less time spent navigating horizontally), however, I get stuck with an extra NPC conversation (GRRRRRRRRRRRRRRR).
All in all, 34 second improvement over the current (un-accepted) run. I think this is pretty much as good as it's going to get. If I could skip the last NPC, I'd save about 5-8 seconds, but I think that's about all I can think up.
I also exit out of the walls a lot sooner, since falling vertically is actually a lot faster than cycling through the wall until it spits you out.
Enjoy :)
EDIT: I'll update the submission text when the movie's replaced.
EDIT2: Removed link to FCM since the submission's been updated.
Drag-and-drop functionality, and no more being limited to only two movies. It's not 100% done yet, but just figured I'd show everyone I'm still working on this ;)