ScummVM running on FrameBuffer

[Sorgelig]

I would like to see a self-contained apps being it native games or emulators.
So it would be nice to place all related files into one folder related to specific game/emulator. And put it into FAT, so linux.img won't be affected and can be easily updated in the future independently.

[Sorgelig]

I'm adding the feature where script can set the framebuffer format and size. It will help in terms of performance. It's not free resolution as i want to avoid the non-integer scaling. It will be 1,2,4 division of full resolution. With 4 on FHD it gives 480x270 so should be small enough. Also 1555 or 565 color format gives twice performance boost.

[brNX]

ScummVM emulates an engine, emulates the exact behaviour of a program, so it's an emulator in that sense of the word.

Still that's not the point at all of this conversation here.

The MiSTer is as hybrid as the MiST if you want to be pedantic in that way @Locutus, the diference is the MiST uses a microcontroller that runs firmware and here we have a SoC that runs linux.

I just don't like terms being thrown around and people being pedantic about things that don't matter at all to this situation.

Cheers

[Locutus73]

ScummVM emulates an engine, emulates the exact behaviour of a program, so it's an emulator in that sense of the word.

I agree, I'm a strong advocate of using the word emulation for FPGA; hardware emulation just to distinguish it from the common use of the word in IT jargon... but since emulation as a word without an adjective usually (debatable) refers to software emulation of an old hardware I said: ScummVM is not a software emulator, at least not as in software emulation of a retro hardware (i.e. MAME). meaning exactly what I said.

Still that's not the point at all of this conversation here.

Which is? Banning additional software or banning software emulators of old hardware (as in MAME)?

The MiSTer is as hybrid as the MiST if you want to be pedantic in that way @Locutus, the diference is the MiST uses a microcontroller that runs firmware and here we have a SoC that runs linux.

We can agree, as much as we can agree that there is some difference between a firmware and a whole operating system. Both software, ok, but the second is a little bit more layered/structured and offers many services. SuperNT too uses a MCU for loading the core, loading ROMS when jailbroken, updating the firmware, etc. but I wouldn't put it in the same category as MiSTer where entire functions of the emulated hardware are provided by a software running on an operating system with all the benefits (i.e. accessing to network shares).

I just don't like terms being thrown around and people being pedantic about things that don't matter at all to this situation.

You see pedantic posts, I see interesting ideas... in Italy we say the world is beautiful because it is varied.
Back to the topic, I see ScummVM as an additional optional software package which could run well (we have to see), but I don't see it as a software emulator of an old hardware as in MAME, which I'm less interested in seeing on MiSTer.

Regards.

Locutus73

[Newsdee]

This is great! I can see this as a way for people to add their own custom apps, even if it's emulators, to get the setup they want.
Man... it's getting harder to maintain a "core complete" MiSTer.

[kitrinx]

Which is? Banning additional software or banning software emulators of old hardware (as in MAME)?

SCUMM games did not run on modern ARM. Original binaries run on things like 486 DOS. It is not original source, so it is not a port. Therefor new binary is emulating old binary, by definition emulating its behavior. It is not emulating a full system because it doesn't need to, instead it is emulating the script interpretation engine of the original binaries, just like Exult. Is Exult the same as the original? No, but it tries to emulate the behavior as well as it can. This is a useless semantic argument. It doesn't matter what you choose to call it, that's what it is.

It would be wise for software that plays games to be met with heavy scrutiny, for the health and continued growth of the platform. Even if you want to react to my concerns with derision, it is very possible to confuse people would would cover this on youtube or post about it or otherwise drive its growth. One software application of course won't make-or-break anything, but software is fast and easy to port to ARM linux, especially as more tools and libraries pop up to do so. I don't think it's unreasonable to to be concerned that a lot of things will begin cropping up of more dubious quality. Maybe I am putting the cart before the horse here, but once the precedent is set you can't put the genie back in the bottle.

Sorg's attitude is "if they're too dumb to know it runs poorly, that's their problem" but I'm more of the mind that for a good user experience, the things that make the system better than the alternatives should be highlighted and not obfuscated. MiSTer definitely does not do software stuff better. And, to clarify the "hyrid emulation" hype: it is not really different in any way than normal software using a video card, so calling it that is misleading. It is already difficult to explain to an average person why MiSTer is different from an RPi, and why it worth spending the money on instead of an odroid. If you say to yourself "would this run better on my phone?" and the answer is "yes" then maybe it doesn't belong on a platform with FPGA in the name.

To be clear I'm not saying all software things are bad, but this should be considered carefully, as it has the potential to really shift the perception of the platform.

[Locutus73]

SCUMM games did not run on modern ARM. Original binaries run on things like 486 DOS. It is not original source, so it is not a port. Therefor new binary is emulating old binary, by definition emulating its behavior. It is not emulating a full system because it doesn't need to, instead it is emulating the script interpretation engine of the original binaries, just like Exult. Is Exult the same as the original? No, but it tries to emulate the behavior as well as it can. This is a useless semantic argument. It doesn't matter what you choose to call it, that's what it is.

I repeat, please re-read my posts: I'm the first advocate of using term emulation for anything trying to replicate the functional behaviour of another thing, I'm the first saying FPGA is emulation. But on the other side we must take account of the usual IT jargon, and people associate the term emulation to MAME, Retroarch, etc.: emulating with software the function of a whole hardware in order to run its original software with all the pros and cons (mostly added lag) and it this sense ScummVM is a different thing, just as I said in my original post at least not as in software emulation of a retro hardware (i.e. MAME).

It would be wise for software that plays games to be met with heavy scrutiny, for the health and continued growth of the platform. Even if you want to react to my concerns with derision,

Where is the derision?

And, to clarify the "hyrid emulation" hype: it is not really different in any way than normal software using a video card, so calling it that is misleading.

Yea and no... the parallel is good, but the use case is new, very specific to emulation of old hardware platforms. MiSTer probably is the first platform which uses both FPGA and software on an OS to emulate different aspects of a retro machine (at least that I know). Maybe I see a closer parallel with ParaLLEl (pun intended ) a Libretro N64 core where part of the actual emulation is offloaded on the GPU, not only the rendering (at least as far I understand).

Regards.

Locutus73

[spidersfrommars]

It's a hard question, I feel that if we start doing a bunch of emulators, then it would make devs less likely to try and make a fpga version. On the other had i don't think we should try and restrict people from doing it. I think the middle ground would be to just make them separate from the main repos. On a side note it would be cool to have other applications in the main repo like media applications like kodi, or file browsers such as midnight commander. Also, I really like sorlig's self containg apps idea.

[Sorgelig]

I din't make MiSTer to prove something to someone.
More over - it's open source platform. The one who understand the difference will make a right decision (any decision, not exactly toward the MiSTer).
The one who doesn't understand the difference from RPi i would really, REALLY glad if he will choose the RPi and there will be less strange requests from such users.
In ideal case i would like to see only users who understand what is FPGA, what can expect and what is less expected. Because i'm tired to explain why some essential to software emulators features are hard to make on FPGA.

[Locutus73]

And just to make my point more clear: again I agree that anything acting as something else emulates, but what people don’t like about “software emulation as in MAME” is the added software layer with all that comes with it (i.e. the need of raw power, the added lag, etc.). Let me explain...
On a retro computer/console we have a software running on hardware (let me omit OS for simplicity sake), so software on hardware. If we software emulate (as in MAME) that platform we have a hardware (the modern computer) running a software (the emulator) running another software (the original game), so we have software on software on hardware (one added layer).
We all love FPGA because it’s a hardware which is reconfigured to run the original software, so we are back to software on hardware, the same layers as the retro hardware.
When we come to SCUMM, back then we had retro hardware running a software (the SCUMM engine) running a script (the game), so script on software on hardware. Nowadays we use a modern computer running ScummVM running the same script (the game) so we still have script on software on hardware: the same layers as the retro hardware (actually with better software and hardware layers).
Both FPGA and ScummVM try to functionally behave as something else (emulating) and both have the same number of layers. So, ok still something acting as something else, but in the layering I see a great substantial difference with software emulation as in MAME, not just semantics.

Regards.

Locutus73

[kitrinx]

Yea and no... the parallel is good, but the use case is new, very specific to emulation of old hardware platforms. MiSTer probably is the first platform which uses both FPGA and software on an OS to emulate different aspects of a retro machine (at least that I know). Maybe I see a closer parallel with ParaLLEl (pun intended ) a Libretro N64 core where part of the actual emulation is offloaded on the GPU, not only the rendering (at least as far I understand).

OpenGL or DirectX hardware acceleration are used in many emulators, especially for shaders, enhanced visual modes, enhanced texture quality, and other such things. Even software rendering or direct framebuffer rendering has been used many times. Occasionally things like NEON are used to speed an emulator up. Literally no different, except on more powerful platforms that include ASIC video. We are just creating a video card out of FPGA because mister doesn't have one built in, otherwise this is identical regular ARM software. There is no special hardware enhancements, no mixing of "chips and software". It's just a regular old executable.

And just to make my point more clear: again I agree that anything acting as something else emulates, but what people don’t like about “software emulation as in MAME” is the added software layer with all that comes with it (i.e. the need of raw power, the added lag, etc.). Let me explain...

What people don't like about them is that they are either made unintentionally inaccurately or intentionally inaccurately so that they will be able to run on under powered hardware like the raspberry pi. Accurate software emulation needs powerful CPUs. So you get compromises in performance, audio, video, stability, and accuracy in order to make them run on weak CPUs. In ways, it's much harder to get the order of execution correct in software vs FPGA, so it can be quite tricky to make them accurate, comparatively. The extra latency from using a framebuffer also bothers people, but that's not especially different than what we are doing on MiSTer's HPS video here. We are using a framebuffer too.

I din't make MiSTer to prove something to someone.
More over - it's open source platform. The one who understand the difference will make a right decision (any decision, not exactly toward the MiSTer).
The one who doesn't understand the difference from RPi i would really, REALLY glad if he will choose the RPi and there will be less strange requests from such users.
In ideal case i would like to see only users who understand what is FPGA, what can expect and what is less expected. Because i'm tired to explain why some essential to software emulators features are hard to make on FPGA.

I understand your point of view, and surely you know that I respect you very much, but I don't agree with you that this is how reality works. I believe that MiSTer is something really special, and the only thing between it being a niche project and having a ton of users is enhancing the user experience. The more people that have a good experience, the more developers will take interest, and the more the project can advance. Users aren't black and white. There isn't the "dumb user that should use RPI" and the "smart user that should use fpga". Depending on how the developer starts that user out, they can grow in either direction. If the platform is confusing and full of pitfalls, it will not be a surprise if they end up being an RPi user. If the platform is easy to set up and helps them get started and find information, then they can turn into a good FPGA user.

[BBond007]

On a side note it would be cool to have other applications in the main repo like media applications like kodi, or file browsers such as midnight commander.

Midnight Commander 'mc' has been included in the standard MiSTer Linux from the beginning...

[Locutus73]

OpenGL or DirectX hardware acceleration are used in many emulators, especially for shaders, enhanced visual modes, enhanced texture quality, and other such things.

Yes, but I was citing ParaLLEl because, instead of emulating N64 RDP through High Level Emulation translating its rendering functions with shaders and stuff like that, as far I understand it offloads proper N64 RDP Low Level Emulation to the GPU through Vulkan API... basically the accurate Angryllon software emulation parallelized and offloaded to GPU. in this use of GPU for low level emulation I see a sort of (far stretched) parallelism between MiSTer and ParaLLEl (again pun intended) and something different from the usual GPU based HLE.

Even software rendering or direct framebuffer rendering has been used many times. Occasionally things like NEON are used to speed an emulator up. Literally no different, except on more powerful platforms that include ASIC video. We are just creating a video card out of FPGA because mister doesn't have one built in, otherwise this is identical regular ARM software. There is no special hardware enhancements, no mixing of "chips and software". It's just a regular old executable.

I agree, it's a plain regular executable running on a low powered hardware just like scumm engines were back then... again I see a parallelism.

What people don't like about them is that they are either made unintentionally inaccurately or intentionally inaccurately so that they will be able to run on under powered hardware like the raspberry pi. Accurate software emulation needs powerful CPUs. So you get compromises in performance, audio, video, stability, and accuracy in order to make them run on weak CPUs. In ways, it's much harder to get the order of execution correct in software vs FPGA, so it can be quite tricky to make them accurate, comparatively.

Tl;dr: the added weight of software on software on hardware

The extra latency from using a framebuffer also bothers people, but that's not especially different than what we are doing on MiSTer's HPS video here. We are using a framebuffer too.

Point'n'click adventures were never meant to be blazing fast zero latency experiences, and I don't think ScummVM running on a (weak) ARM on a framebuffer will be slower than i.e. the original engine running on a Amiga... at least I'm curious to see it in action, not stopping the effort preventively.

Regards.

Locutus73

[flain]

It's good to see ScummVM on MiSTer, i don't see what the problem is if it can be self contained in it's own directory on the SDCard like other cores. If it's not modifying the Linux OS then it shouldn't be an issue. It would be good to have it in the update script, if purists have problems with it being there then maybe just make it an optional command line switch in the update script or something.

[BBond007]

Point'n'click adventures were never meant to be blazing fast zero latency experiences, and I don't think ScummVM running on a (weak) ARM on a framebuffer will be slower than i.e. the original engine running on a Amiga... at least I'm curious to see it in action, not stopping the effort preventively.

Right, people who have latency issue concerns probably just don't understand the genre of these games.

I think you'll find the performance to be close to perfect.

Sierra game in particular seemed to have strange behaviors and be crash-prone (needing fixes/updates/patches) on faster machines than they were originally designed to run on. Their coding skills were not on par their art and script writing...

Probably the most demanding off all these games is Leisure Suit Larry 7 : Love for Sail! and it still runs pretty well.

I just purchased the GOG version and I can't seem to get it to run om my Windows 10 x64 machine...

It's good to see ScummVM on MiSTer, i don't see what the problem is if it can be self contained in it's own directory on the SDCard like other cores. If it's not modifying the Linux OS then it shouldn't be an issue. It would be good to have it in the update script, if purists have problems with it being there then maybe just make it an optional command line switch in the update script or something.

Yes, it will be contained in a single folder which can be deleted if you don't want it anymore. The Linux OS image will not be modified.

Leisure Suit Larry 7 : Love for Sail! --> http://y2u.be/e6anA4qPgfI

[SuperBabyHix]

Thanks a bunch for porting this. I personally think ScummVM is a great fit for the MiSTer. I sometimes like to compare different versions of the same game and this gives us access to a few more.

I do have a question about the sound emulation options. I figure the adlib is working, what about general midi and MT-32?

[BBond007]

Thanks a bunch for porting this. I personally think ScummVM is a great fit for the MiSTer. I sometimes like to compare different versions of the same game and this gives us access to a few more.

Some of these games have FM Towns versions that are worth trying out too...

I do have a question about the sound emulation options. I figure the adlib is working, what about general midi and MT-32?

Yes, it has support for FluidSynth which is General MIDI as well as MUNT for MT-32.

FluidSynth (General MIDI) works well.

The MUNT (MT-32) support is currently not working but I have not got around to looking at the problem yet. I suspect mt32d is just not finding its ROMS.

Even if I do get it working it will probably suffer from occasional tempo problems as it does with MidiLink. Lucasfilm SCUMM games don't reprogram the default MT-32 soundbank so I would suggest to use a MT-32(or CM-32L) soundfont anyway for better results with those games. You can configure a different SoundFont per game.

I have not tried with my UM-ONE MIDI adapter with physical Sound Canvas or MT-32 modules yet. I do intend on making sure that works

[BBond007]

I'm adding the feature where script can set the framebuffer format and size. It will help in terms of performance. It's not free resolution as i want to avoid the non-integer scaling. It will be 1,2,4 division of full resolution. With 4 on FHD it gives 480x270 so should be small enough. Also 1555 or 565 color format gives twice performance boost.

Would we be able to mix, for example 3 on the x axis and 2 on the y?

[Sorgelig]

Would we be able to mix, for example 3 on the x axis and 2 on the y?

I've extended the video modes for FB, so now it's possible to set any FB resolution not higher than screen resolution (as scaler doesn't support downscale for FB). Choosen resolution will be upscaled with integer factor. Pixel is always 1:1.

[BBond007]

I've extended the video modes for FB, so now it's possible to set any FB resolution not higher than screen resolution (as scaler doesn't support downscale for FB). Choosen resolution will be upscaled with integer factor. Pixel is always 1:1.

ScummVM wants at least 640x400 and probably 640x480 is ideal.

Very nice : Thanks!

[Sorgelig]

640x480 is well scaled in 1920x1080 resolution.

[straddle]

I’m not a coder so I’m not going to comment on the debate over ScummVM not being a true FPGA core. That being said, I would love to be able to play my old ScummVM games on my MiSTer and if they run well on the platform, then why not?

[Sorgelig]

I’m not a coder so I’m not going to comment on the debate over ScummVM not being a true FPGA core.

it's not FPGA core at all.

[BBond007]

I’m not a coder so I’m not going to comment on the debate over ScummVM not being a true FPGA core. That being said, I would love to be able to play my old ScummVM games on my MiSTer and if they run well on the platform, then why not?

Yeah, why not have this content on your MiSTer

Phantasmagoria:
Intro --> http://y2u.be/WpFPYcs-QCI
Chapter I --> http://y2u.be/3PY-_VmXTIg

[spidersfrommars]

I’m not a coder so I’m not going to comment on the debate over ScummVM not being a true FPGA core. That being said, I would love to be able to play my old ScummVM games on my MiSTer and if they run well on the platform, then why not?

Yeah, why not have this content on your MiSTer

Phantasmagoria:
Intro --> http://y2u.be/WpFPYcs-QCI
Chapter I --> http://y2u.be/3PY-_VmXTIg

Looks beautiful! Thanks!