ScummVM running on FrameBuffer
Moderators: Mug UK, Zorro 2, spiny, Greenious, Sorgelig, Moderator Team
Re: ScummVM running on FrameBuffer
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.
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.
Re: ScummVM running on FrameBuffer
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.
Re: ScummVM running on FrameBuffer
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
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
Re: ScummVM running on FrameBuffer
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.brNX wrote:ScummVM emulates an engine, emulates the exact behaviour of a program, so it's an emulator in that sense of the word.
Which is? Banning additional software or banning software emulators of old hardware (as in MAME)?brNX wrote:Still that's not the point at all of this conversation here.
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).brNX wrote: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.
You see pedantic posts, I see interesting ideas... in Italy we say the world is beautiful because it is varied.brNX wrote:I just don't like terms being thrown around and people being pedantic about things that don't matter at all to this situation.
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
Re: ScummVM running on FrameBuffer
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.
Man... it's getting harder to maintain a "core complete" MiSTer.

Re: ScummVM running on FrameBuffer
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.Locutus73 wrote: Which is? Banning additional software or banning software emulators of old hardware (as in 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, 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.
Re: ScummVM running on FrameBuffer
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).kitrinx wrote: 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.
Where is the derision?kitrinx wrote: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,
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 intendedkitrinx wrote: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.

Regards.
Locutus73
-
- Atariator
- Posts: 27
- Joined: Mon Nov 20, 2017 3:39 am
Re: ScummVM running on FrameBuffer
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.
Re: ScummVM running on FrameBuffer
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.
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.
Re: ScummVM running on FrameBuffer
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
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
Re: ScummVM running on FrameBuffer
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.Locutus73 wrote: 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).
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.Locutus73 wrote: 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...
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.Sorgelig wrote: 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.
Re: ScummVM running on FrameBuffer
Midnight Commander 'mc' has been included in the standard MiSTer Linux from the beginning...spidersfrommars wrote: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.
Re: ScummVM running on FrameBuffer
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.kitrinx wrote:OpenGL or DirectX hardware acceleration are used in many emulators, especially for shaders, enhanced visual modes, enhanced texture quality, and other such things.
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.kitrinx wrote: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.
Tl;dr: the added weight of software on software on hardwarekitrinx wrote: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.
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.kitrinx wrote: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.
Regards.
Locutus73
Re: ScummVM running on FrameBuffer
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.
Re: ScummVM running on FrameBuffer
Right, people who have latency issue concerns probably just don't understand the genre of these games.Locutus73 wrote: 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.
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...
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.flain wrote: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.
Leisure Suit Larry 7 : Love for Sail! --> http://y2u.be/e6anA4qPgfI
Last edited by BBond007 on Thu May 30, 2019 5:17 am, edited 1 time in total.
- SuperBabyHix
- Atari nerd
- Posts: 45
- Joined: Sun Jan 24, 2016 10:36 pm
Re: ScummVM running on FrameBuffer
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?
I do have a question about the sound emulation options. I figure the adlib is working, what about general midi and MT-32?
Re: ScummVM running on FrameBuffer
Some of these games have FM Towns versions that are worth trying out too...SuperBabyHix wrote: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.
Yes, it has support for FluidSynth which is General MIDI as well as MUNT for MT-32.SuperBabyHix wrote: I do have a question about the sound emulation options. I figure the adlib is working, what about general midi and 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

Re: ScummVM running on FrameBuffer
Would we be able to mix, for example 3 on the x axis and 2 on the y?Sorgelig wrote: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.
Re: ScummVM running on FrameBuffer
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 wrote:Would we be able to mix, for example 3 on the x axis and 2 on the y?
Re: ScummVM running on FrameBuffer
ScummVM wants at least 640x400 and probably 640x480 is ideal.Sorgelig wrote: 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.
Very nice : Thanks!
Re: ScummVM running on FrameBuffer
640x480 is well scaled in 1920x1080 resolution.
Re: ScummVM running on FrameBuffer
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?
Re: ScummVM running on FrameBuffer
it's not FPGA core at all.straddle wrote:I’m not a coder so I’m not going to comment on the debate over ScummVM not being a true FPGA core.
Re: ScummVM running on FrameBuffer
Yeah, why not have this content on your MiSTerstraddle wrote: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?

Phantasmagoria:
Intro --> http://y2u.be/WpFPYcs-QCI
Chapter I --> http://y2u.be/3PY-_VmXTIg
-
- Atariator
- Posts: 27
- Joined: Mon Nov 20, 2017 3:39 am
Re: ScummVM running on FrameBuffer
Looks beautiful! Thanks!BBond007 wrote:Yeah, why not have this content on your MiSTerstraddle wrote: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?![]()
Phantasmagoria:
Intro --> http://y2u.be/WpFPYcs-QCI
Chapter I --> http://y2u.be/3PY-_VmXTIg