brNX wrote:ScummVM emulates an engine, emulates the exact behaviour of a program, so it's an emulator in that sense of the word.
brNX wrote:Still that's not the point at all of this conversation here.
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.
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.
Locutus73 wrote:Which is? Banning additional software or banning software emulators of old hardware (as in 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.
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,
kitrinx 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.
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).
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...
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.
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.
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.
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.
kitrinx 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.
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.
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.
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.
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.
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?
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.
BBond007 wrote:Would we be able to mix, for example 3 on the x axis and 2 on the y?
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.
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. 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?
BBond007 wrote: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. 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
Intro --> http://y2u.be/WpFPYcs-QCI
Chapter I --> http://y2u.be/3PY-_VmXTIg
Users browsing this forum: No registered users and 9 guests