Joined: 5/15/2006
Posts: 15
Location: Paris, France
Not sure where you thought about this scanline thing, but MEKA *does* poll inputs once per frame, so the choice between 1 and 2 doesn't apply.
I somehow like solution 3 because as you said, I feel it can be more deterministic than with and less replay breakage if emulation change. I'll see what I can do.
Thanks for your infos guys.
Joined: 5/15/2006
Posts: 15
Location: Paris, France
moozooh: It's not much of a problem about the file format - of course, I intend to add some kind of versionning and extension possibility to it. The problem is about subtle emulation change that could affect playback.
I know that some non-determinism code in the emulation of certain inputs (analog paddle control, sports pad, etc.) would certainly affect playback. Not mentionning switching Z80 core as I plan to, and a single opcode emulation change might affect playback (not in all cases).
Joined: 5/15/2006
Posts: 15
Location: Paris, France
stanski wrote:
Meka has such a terrible user interface, and i really hate the flashy backround graphics/everything how fickle it can be sometimes.
Look, I pretty much agree that MEKA is stuck in the past for many things, user interface included. I think it gives it some charm (+ the benefit of portability), thought, but I'm open to any constructive criticism that could help making it evolve.
What do you feel is particularly flashy in MEKA? A background with a grid and an old picture of a Sega Master System? I myself always use MEKA using the "Ocean" theme and this is perhaps a sign that the default theme is annoying even to me. Suggestions welcome. You can post on MEKA forum or e-mail me if this gets off topic for this forum.
MEKA arguably has the best debugging/hacking tool around so that would be of help doing TAS ihmo.
Joined: 5/15/2006
Posts: 15
Location: Paris, France
SXL wrote:
maybe could you work with pcc to make us a nice sms rerecording emulator. and if meka was the target, maybe could you invite Bock (if he's still alive...) to help you both...
what do you think the best solution would be ?
- pcc's rerecording dega, improve this
- add rerecording to meka
- add sms (from meka ?) support into rerecording gens
I am alive. I'm just busy with one trillion things, it's just a matter for me to shut up and start doing something, this could get the ball rolling.
Adding "SMS (from Meka)" into Gens seems pretty much nonsense. It's not much about the code nowadays, it's about emulation quality and this derivate directly from knowledge. Today in 2007 we have enough knowledge (see SmsPower wiki or ask in forums) so that someone competent could theorically do a great SMS emulator from stratch in not much time.
I think that MESS or SmsPlus would be a better choice than Dega or Gens. MESS is being worked on by pretty competent people, and generally I'm sure that Charles Mac Donald's work is accurate enough.
One reason I'm not moving fast with recording in MEKA is that's I'm overally paranoid about data preservation and I don't like very much the idea of providing a version with recording and breaking data compatiblity every 6 months. Simple thing such as "2 bytes per frame for inputs" are not accurate when it comes to handling the various peripherals, slots, ports, etc, supported by the system. This kind of things makes me slow to react.
Can you tell me how other emulators behave on this matter? IF YOU WANT SOMETHING DONE AND DON'T CARE IF DATA COMPATIBILITY GETS BROKEN REGULARLY: I can probably do that.
Joined: 5/15/2006
Posts: 15
Location: Paris, France
OK, I understand the first part of your message and how it'll do crap.
However:
SXL wrote:
if you have bulletproof recording, the movie that brought to the state in slot 2 was saved within the state, and has been loaded with the state, keeping both in synch.
Are you suggesting to switch a savestate during the final playback?
This sounds like cheating based on usual TAS rules. If I understand the (usual/current) rules, the movie is supposed to reflect a run that is doable on a real system/cartridge with an input feeder. It shall run from reset state or possibly from a single start state. Correct me if I'm wrong.
If you load a savestate for the purpose of playing back inputs to complete level X then another savestate to do level Y, the game engine data is "hacked".
When you guys make a perfect-play video, don't you always record levels in *order* ?
What if you have a full game recorded, and then later you find a way to optimize the run on some level, what do you do?
Joined: 5/15/2006
Posts: 15
Location: Paris, France
SXL wrote:
Bock wrote:
I need to clean out part of MEKA code and ensure determinism.
I was so desperate that you would not come back that I started looking in the source code. full C, with very little documentation, and many speed optimizations/obfuscation (hint : hexadecimal/binary calculus) made me give up after 5 minutes (no emulation programming knowledge :(). so yeah it might need some cleaning, maybe try object oriented programming ?
I'm sorry but "hexadecimal" and "binary calculus" are not particularly optimizations neither obfuscation, this is basic programming. I know MEKA code is not brilliant everywhere (most of the code was written in 1998-1999), but OOP has nothing to do with it.
I'm pretty confident about the fact that not everyone can hack into MEKA today, but I'll help anyone who feel has the knowledge to do something on it. Right now, my friend is taking the afternoon to port MEKA to MacOsX and I'm answering his questions.
- rerecording (if possible, bullet-proof*) :
*bullet-proof rerecording : to avoid desynchs with unmatching savestates, each savestate must record the whole movie up to this point. hence, when you reload the savestate, you're always sure that your movie is coherent with the savestate.
Can you elaborate on that? I'm not sure to understand. What's an "unmatching savestate" ?
*cough* so I guess Bock's option is dead now, and xebra left.
I'm not dead yet! :P Just extra busy with my other project. Feel free to harass me, I like it as a motivator (I'm going to do the change on savestate systems now, that'll be a first step :)
Joined: 5/15/2006
Posts: 15
Location: Paris, France
Sorry guys. It's been a busy year for me, and I expect to be busy for a bit more. Still not ETA as for when I can do anything related to this, but it's still in my mind and in the pipeline.
Never hesitate to post or e-mail me, always serve as a reminder.
I need to clean out part of MEKA code and ensure determinism. As a first step, I thought about implementing game-play rewinding. While it's not exactly what you're requesting, technically it would be a decent chunk of the related work done.
Does many emulators have a rewinding feature? (can you list some if so). I thought it would be nice feature, looking a bit "magical". Say, you press Backspace and the game goes back in the past at accerelated rate.
Joined: 5/15/2006
Posts: 15
Location: Paris, France
I'll be working on it!
Sure MEKA isn't perfect, but AFAIK, I'm the only SMS emulator author to have kept his project updated for such a long time, and I intend to continue to.
I'm very busy and can't make any promise, but feel free to harass me periodically for such feature. :)
Joined: 5/15/2006
Posts: 15
Location: Paris, France
Xebra: Thanks. That pretty much sum it up, and I have to agree. I'm one to talk more than I work nowadays, so I'd rather just shut the hell up and take the time to do this sometimes. It's just that MEKA has gazillions of things to do.
Pirate: FreezeSMS is pretty outdated and not being worked on anymore, AFAIK. MEKA has the best compatibility of all Sega 8-bit emulators considering it supports more known mapper and peripherals. KEGA Fusion is greatness but its author is pretty closed and don't expect sources for that. SMS Plus is also good, free software and well ported (more than MEKA). MEKA has a memory editor and powerful debugging tools which can certainly help in order to figure out game engines particularly and abuse them. Paddle Control and Sports Pad are two analog devices for the Master System.
Kyrsimys: MEKA works on Linux except for sound which is jerky if even working, which is a big drawback for most games players (I hope it can be improved).
Joined: 5/15/2006
Posts: 15
Location: Paris, France
upthorn wrote:
The major difference between a gamepad and a joystick is that a gamepad doesn't have a stick, instead it has four buttons underneath a directional-pad. Which, I think, would return boolean "is pressed" values, rather than integer axis values.
This is supported by MEKA.
What MEKA doesn't support yet are analog axises (those would certainly be useful to emulate Sports Pad or the Paddle Control controllers).
Joined: 5/15/2006
Posts: 15
Location: Paris, France
SXL wrote:
short answer : your emulator must obey the rules of this site, so that movies made by it can be accepted to.
OK then, considering all emulators mentionned above (Meka, Dega...) have zero of those features, I don't understand why above is was mentionned that "Meka's GUI and source code both fail those criterias". Is the GUI causing any problem with your set of rules?
Joined: 5/15/2006
Posts: 15
Location: Paris, France
SXL wrote:
I'm not an expert, so I'd show 2 main criterias :
- chance that the emu gets accepted on the site/submission system
- time needed for the coder (you atm) to convert the emulator's source code and maintain it
Meka's GUI and source code both fail those criterias (in that respective order),
I don't understand the first criteria, what acceptance are you looking for?
Upthorn:
Cons: No gamepad support (unless it emulates a joystick)
What do you means? What's the difference between a gamepad and a joystick?
Joined: 5/15/2006
Posts: 15
Location: Paris, France
Thanks for your answers, guys. I'll keep everything in mind.
I'm very busy so I don't expect to add those features so soon, but whenever possible I'll consider this and will keep you tuned.
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.).