Joined: 3/30/2004
Posts: 359
Location: Borlänge - Sweden
Okey.. we got NES, SNES, N64 and Genesis... but what about SMS/GG(Mostly SMS)? Have they been forgotten? :/ I know I love alot of SMS games. SMS was the only consol I had as a kid. All my other pals had Nintendo and all the flashy games to it. But I found more love to my Master System then to Nintendo.
Who can resist games like Golvellius, Alex Kidd, Wonder boy I, II and III, Shinobi, Phantasy Star, Out Run, Double Dragon, YS, Sonic, Psycho Fox, Psycho World, Teddy Boy.... oh I can keep going all day :)
I dont have the programming skills at all this wonderfull things and all that kind of skull.. Infact I cant even write a "hello world" message program.
I dont know if we are waiting for GENS+, which looks very promising or... asch.. I dont know.
I know that Im not alone out there that are waiting for this :]
But what great SMS emulators do we have out there.. I can count up few of them.
MEKA, SMSPLUS, FreezeSMS..
Cheers
I cannot say if sms/gg games are better, since I never had a (s)nes, but since I know sms classics, I'd definetely want to see them on video.
actually, I made a similar request in that topic :
http://tasvideos.org/forum/viewtopic.php?t=2363
to sum it up :
Jyzero did for us the Gens enhanced emulator. he took the .212 source code and added the tas functionalities (savestates management, input rerecording, etc.).
later, nitsuja improved it for the community.
unfortunately, both gave up on the project.
meanwhile, the gens+ coder improved his own emulator, without the tas functionalities, that he does not want/like (aka the "cheat hater leitmotiv").
his emulator became the new gens and reached the .961 version, adding both sms/gg emulation.
what we would need now, would be to find a coder to add again the tas functionalities to the last gens+ version. it has already been done, so I'm asking if it would that complicated to do ? (yeah I know coders have a life u_u)
another solution would be to find another sms emulator with source code, understand how it works and add what's missing.
basically, we need a new hero ! come save us and you will have... the community's gratitude, as well as the guarantee to see the sms classics done.
thanks in advance.
PS : I hope my post won't kill the request like last time U_U;;;
I never sleep, 'cause sleep is the cousin of death - NAS
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Count all brazilians wanting to see it too. SMS is still manufactured in Brazil!
Also, it's not about which system is better, this is very subjective. All systems have at least some good games on them. Except atari jaguar. Even that can be subjective.
Heck i'm looking more forward to an atari re-recording emulator than a psx one.
Joined: 3/30/2004
Posts: 359
Location: Borlänge - Sweden
Yeah, we really need a hero for this for this. I got mostly of the cardriges as a original since I was a kid and I know them back and forth. So I really want this to happen :)
Hmmm. Meka looks like nice cross-platform software on the outside, but the sources.txt is a bit disturbing:
Some parts are better than other, many are bad, some are very bad.
...
So well, this code is hell, but it's better than nothing.
May it serves, may we can work together and improve it.
Joined: 3/30/2004
Posts: 359
Location: Borlänge - Sweden
Any new about this?
We/I really need a knight hero with a awesome and sparkling lance.
Anyway... I thought MEKA could be the best emulator before, but hey... I found this.. DEGA!!!.
AWESOME Win32/Linux Emulator that really knocked me down. It doesnt have that much to options but it is written(?) in C++. On the homepage you got the Source Code and a port to linux.
I think this could be a better choice then MEKA.
it looks indeed nice, and it seems it already has support for savestates and frame advance. maybe you could mail the author (with an example such as vba-rerecording) to ask him if he could implement the missing functionalities for us ?
or, would we find a hero on the forums ? IdeaMagnate perhaps ?
hope is our friend.
I never sleep, 'cause sleep is the cousin of death - NAS
Sounds awesome. Go for it I say. How is it compared to other SMS-emus when it comes to perfection in emulation, such as sound and picture? Also I guess timing is a big concern right?
i would go for the meka Emu, but ehm, i dont know if u can do everything with it like, faster shooting, or stuff like that,
but i like it its in swedish :P ghehe
[MEKA] looks indeed nice, and it seems it already has support for savestates and frame advance. maybe you could mail the author (with an example such as vba-rerecording) to ask him if he could implement the missing functionalities for us ?
Joined: 5/15/2006
Posts: 15
Location: Paris, France
Hello guys,
I am considering to implement inputs recording / replay in MEKA since a while, and under your request I may put this on a higher priority.
I am however particularly concerned about the validity and compatibility of generated data over time. I don't want to break recording on each new release. For information, MEKA savestates have been always imported, savestates from version 0.10 released in 1999 are still usage with latest version. If I implement input recording I'd expect to provide similar support with import. A small change in emulation can easily screw up a replay.
- Can you tell me about how well/bad this old-version import problem is coped with on other emulators supporting inputs record/replay?
- Can you describe accurately the set the feature you'd want?
Ideally, what shall happens if user attempt to load/save states during a record?
- Are you looking for specific features to help the making of "perfect play" movies? What kind of feature that would be?
- How do you want the emulator to cope with settings changes while playing and accross sessions? Do you have any helping suggestions to maximize ease of use and reduce incompatibilities. (eg: change of peripheral, change of NTSC/PAL tv mode, etc.).
Some answers. I hope they make sense.
* In general we are using stable emulators. If multiple versions exist, the author must identify the exact version used for recording. This is most prominent with snes9x. Noting the correct version needed to playback a movie file is probably okay, and refusing to start if there is known incompatibility is also acceptable.
* When someone save-states, the savestate must include (at a minimum) the current frame counter in the movie file. Ideally, it should also include a complete copy of the movie file's input from start to the current position.
* When someone load-states, the movie file should seek to the location saved. If a copy of the input is available, the movie file should have the keypress log replaced with the contents of the savestate's before seeking to the current location.
* If frame-advance is not available, that would be requested. Pause, and execute 1 frame of emulation when the frame-advance key is pressed.
* Unless someone has a good argument against it, making the hardware fixed at startup is probably fine. If you can record changes to the hardware, that's also okay. FCEU records inserts/removals of the disk on FDS systems.
.. How does one change between NTSC/PAL while the system is already running?
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Bock wrote:
I am however particularly concerned about the validity and compatibility of generated data over time. I don't want to break recording on each new release. For information, MEKA savestates have been always imported, savestates from version 0.10 released in 1999 are still usage with latest version. If I implement input recording I'd expect to provide similar support with import. A small change in emulation can easily screw up a replay.
Being that it's practically impossible to future proof this, and would require tons of hacky code to do this well, I wouldn't put too much into it.
Bock wrote:
- Can you tell me about how well/bad this old-version import problem is coped with on other emulators supporting inputs record/replay?
First off, realize the best thing to do is playback using the version that recorded it. It is acceptable if that's what has to be done to have stable playback.
However back in the days when zsKnight still worked on ZSNES, he had some tricks to make a lot of not too long movies play back with quite a few versions later.
He made every movie contain a bunch of variables which he knew would change with timing changes later. So if it was played back with a later versions, some old timing settings can be used. Also in addition to this, you can make every X amount of frames contain another save state, which automatically gets loaded when reaching that point in later versions, so the system can be put into the state the game needs to continue.
However despite this trick, I don't highly recommend it.
Bock wrote:
- Can you describe accurately the set the feature you'd want?
Ideally, what shall happens if user attempt to load/save states during a record?
Ideally on saving, all the variables you use for movie making (this requires planning to see what exactly you need to track), put a current state, and the input history into a special movie save state.
Loading loads this back. Players here have told me they like a checkbox somewhere that loading during playback should put the emulator back into record mode.
Bock wrote:
- Are you looking for specific features to help the making of "perfect play" movies? What kind of feature that would be?
Players need pausing, and the ability to advance a frame of emulation step by step. Being able to show which keys are being held down and this time is also important.
Bock wrote:
- How do you want the emulator to cope with settings changes while playing and accross sessions? Do you have any helping suggestions to maximize ease of use and reduce incompatibilities. (eg: change of peripheral, change of NTSC/PAL tv mode, etc.).
I recommend in addition to storing input, each "frame" of a movie should also contain information about variables being switched.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
I'm not a programmer, but here are what I think are the most important features:
Gamers will load states out of order. People screw up, it's going to happen. That's why it's important to store a complete movie file in each savestate.
The ability to remap all keys used during play and recording.
The ability to advance by a single frame.
The ability to export to AVI during playback.
The ability to start recording from a savestate.
A display for the frame counter and which buttons are being pressed.
It happens many times that a player will save a state and immediately wish they hadn't, and desire to recover the state they just overwrote. If you store the most recently overwritten state, you can give us limited "undo" capabilities. I don't even think this is implemented in any of our emulators to date, but it seems incredibly simple to do and would likely be appreciated.
If the emulator lets the player set options that might affect playback, these settings should be saved in the movie file and automatically loaded during playback. Again, I don't believe any of our current emulators do this, but it seems so simple and would be so much appreciated.
Read-only toggle, so that loading a savestate will cause the movie to play from that savestate instead of record from it.
I wish I knew anything useful, but I unfortunately don't. why not keeping my mouth shut then ? just because I'd gladly encourage any effort done in order to make sms tas a reality. having now great hopes about the upcoming future. so, thank you for helping us Bock, and greetings from Paname ;)
I never sleep, 'cause sleep is the cousin of death - NAS
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
xebra wrote:
It happens many times that a player will save a state and immediately wish they hadn't, and desire to recover the state they just overwrote. If you store the most recently overwritten state, you can give us limited "undo" capabilities. I don't even think this is implemented in any of our emulators to date, but it seems incredibly simple to do and would likely be appreciated.
It's implemented in ZSNES to some degree.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
If the emulator lets the player set options that might affect playback, these settings should be saved in the movie file and automatically loaded during playback. Again, I don't believe any of our current emulators do this, but it seems so simple and would be so much appreciated.
Do you mean synchronization settings like WIP timing? Because SNES9x's later versions do save these settings in the movie file. If you load a movie that was made with an earlier version on a newer version of SNES9x, it will say something like "Verify: Settings not contained in movie file", I think.
Another thing that I have found handy is the read-only toggle. This feature facilitates things like watching what was just done, or finding a specific spot to start re-recording from.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
>Can anyone else think of anything?
Important things:
- Fast forward button.
- Record movie from savestate.
- Number of rerecords, and some kind of text string where the user can write a comment, saved in movie file.
- Timing and ROM info stored in movie file. Examples of things that could be saved:
- - Checksum of ROM
- - Name of ROM
- - PAL or NTSC
- - Emulator version
- - Controllers and peripherals connected (there is no need to be able to change them during recording though)
- - Sound frequency
A lot of these things deal with the movie format. See http://tasvideos.org/VBM.html for an example of a file format used by another emulator.
Not very important things:
- Ability to record a reset.
- Rewind button. (An array of 10 or so temporary save states, saved every 20 seconds transparent to the user, would do)
A lot of things came up during this thread, perhaps we should compile a needed feature list so we have it when the next emulator gets TAS capabilities.
perhaps editors could set up a page, linked from the emulators page, where the community would specify what features an emulator would need to have, to be accepted and added to the submission/publishing system of the site.
this could regroup what we've find best yet, what we find necessary, and maybe encourage development of new emulators (and for even new systems). some sort of faq, as much detailed as possible (like : how the emulator should react if the user reloads a savestate while playing/recording, a template for movie format, etc.)
let's brainstorm ;)
I never sleep, 'cause sleep is the cousin of death - NAS
