SCUMMVM mega drive port

[matteus]

Hi folks,
I'm not sure how many people on here would interested in starting a project to port SCUMMVM to the MD? Specifically the engine components for EGA games that are controlled using a mouse.

I've been chatting with the devs of scummvm and they seem to think it's possible. A lot would require rewriting from c++ oo objects to C. My biggest concern though is the lack of ram, I don't know enough about the use of ROM to know what can and can't be done.

Hopefully someone will be interested though.

[Sik]

The Sega CD port of Monkey Island is running on a port of SCUMM, for what's worth. And then there's this, although no idea what engine is that using (assuming it's not its own), but it gives an idea of what's possible.

But yeah, RAM is gonna be a big issue, especially with C++ (with C it's easier to keep under control). Keep in mind that graphics and such will most likely remain in ROM, so RAM will mostly have variables in it. If you convert the code to C as you said then you probably won't have much of a problem though (just stick to explicitly small integer sizes where you don't need large values, which is likely most of the variables), unless you put a framebuffer in RAM =P

[matteus]

Thank you for the reply Sik! It'll be something I look at after I've finished my current project. I just know it's going to be a huge challenge and I'm not sure a lone average C programmer will cut the mustard with it.

[Sik]

I imagine that writing a new interpreter from scratch would be easier than trying to port the existing SCUMMVM engine, given the large amount of rewriting you'd have to do anyway.

[matteus]

I imagine that writing a new interpreter from scratch would be easier than trying to port the existing SCUMMVM engine, given the large amount of rewriting you'd have to do anyway.

Indeed a lot of the code base would be needed to interpret existing games though.

[mikejmoffitt]

Not exactly. SCUMMVM is already a reimplementation of the original engine. As long as your engine follows the "standard" of what it is expected to do, a brand new engine with no shared code base should still interpret a game properly. It's not wildly different than writing an emulator. Certainly considerations like accuracy and timing are much more relaxed.

[djcouchycouch]

Don't have to support every game at first. Start with your favourite one

[matteus]

True, I'm not sure where this sits legally though! It's acceptable to make a new version of scummvm but is it acceptable to just make a random interpreter?

I've been trying to fathom the indiana jones and the last crusade ega resource files but the only way I feel I can truly understand is by working with the existing engine code. I'm a bit backwards in that respect I tend to learn that way! Cracking open the resource files as they are now with the wiki documentation doesn't make any sense to me but running it through code makes it clearer

[djcouchycouch]

There shouldn't be any problem if you decide to reverse engineer the interpreter from scratch. I wonder if there's a ScummVM virtual machine spec somewhere to start from. (EDIT: here we go: http://wiki.scummvm.org/index.php/SCUMM ... _Reference)

I was curious so I downloaded the ScummVM source and built it for Win32. It's way bigger than I expected. Even if you cut everything out that isn't scumm, there's gonna be a lot of work just to pair everything down to support just EGA games. Not to mention the C++ to C conversion. I think it's still possible to do, but I don't think it'll be very fun.

EDIT2: Looking at http://wiki.scummvm.org/index.php/SCUMM/Versions, graphically the Genesis looks like it could support up to version 4 of the scripting engine. http://wiki.scummvm.org/index.php/SCUMM says they've rewritten the engine from scratch several times, so I don't know if an interpreter that supports 4 is also backwards compatible with the earlier ones. You might need multiple interpreters if you wanted to support all the version 0 to 4 games. Not really sure, though.

EDIT3: looking at the source a bit more, there are individual interpreter files for each version, so the answer is yes.

[matteus]

Versions 3 and 4 of the interpreter are all that is needed as prior versions require a keyboard.

How much code is there for version 3? I really need to have a look myself? Would you say it's a hell of a lot of work? Could we get a github setup and see if we can't get a community project? We may be able to get some interest from the scummvm team to help in this.

[djcouchycouch]

Taking a look at https://github.com/scummvm/scummvm will give you the best idea.

I just pretty much skimmed it and saw that there's a lot of stuff there. I imagine the interpreters are relatively straightforward. It's everything else around it (graphics, sound, input, ui, os) that'll take the bulk of the porting work.

[Sik]

In other words, the stuff you'd have to redo from scratch to accomodate the different hardware anyway. (well, the video part can probably be redone with software rendering, but how do you handle the sound?)

[matteus]

I don't think the MD can accommodate the music, you could convert the midis but it would be a time consuming process.

[matteus]

The graphics logic was always going to need altering to support the MD but the game logic I'd hoped would be easy.

[Sik]

Game logic is probably trivial in comparison, yeah.

About the MIDIs, actually thinking about it, they had to be played through Adlib so they can't be doing too much crazy stuff either (and Adlib has 2-op FM hardware, to boot), so maybe it's more manageable than I thought at first. You'd still need to convert them but in hindsight it's more doable than I made it look like.