i'll look into it.
Yes, the screenshots are there.
But in that case, the message after submission should not say that the page has been edited, when it in reality it is still up to appoval by moderation. That’s just wrong.
Everything is fine, new version gets publicly visible after moderators approved it; just check the page, new screenshots should now be visible
I agree that the distinction between emulators and virtual machines in kind of fuzzy. Games running in ScummVM require a virtual machine to interpret their byte code, but the same is true for any Java, .Net or Python games. On the other hand it would be possible to write an interpreter for X86 machine instructions and run DOS games in it, but still it wouldn't make those games submission candidates.
My attempt at writing down a rule would be: If any code originally written for a physical (hardware) machine is required to run a game it's not a Linux game. It's still fuzzy, because there are things like software synthesizers that emulate obsolete hardware, but I guess you have to draw a line somewhere.
> As far as I know, Wine works similarly to Mono. It runs Windows applications more or less like native Linux applications.
No, Wine and Mono are fundamentally different. .Net applications are byte code and require a virtual machine, just like Java (or Scumm). They don't run native on any platform, and if they are properly maintained they can be considered Linux games just as well as Windows games. Prominent examples are FEZ, Bastion or SpaceChem.
I never implied that it was. I'm saying that even though some Windows games run flawlessly under WINE, they are still not listed here. So if we consider WINE off limits, then we should consider ScummVM and DOS off limits, which are more VM-like.
As far as I know, Wine works similarly to Mono. It runs Windows applications more or less like native Linux applications.
Dosbox is an emulator (of CPU, sound system, graphics system, etc.) with operating system (DOS-like) bundled.
> at the cost of a huge performance loss(which is totally irrelevant for that kind of games).
It depends. Many interpreters use "mixed approach" by precompiling pieces of code and keeping it, instead of reinterpreting same instructions again and again. Moreover, together with different optimization techiques (e.g. runtime statistics and analysis), several pieces of code can run _faster_ in interpreter than "plain" binary. Again this is broad topic.
> If WINE is to be considered an emulator
Please, never call Wine an emulator (even if you know it's not), because it will confuse people. Wine has nothing to do with emulation. What it actually does is:
- Take x86 machine instructions out of *.exe file
- Run them _as is_
- If those instructions try to call another piece of x86 code that initially resided in some *.dll files provided by microsoft & co (and entirely depends on windows os), don't do that...
- ...but instead call the code that does the same thing, but was written by Wine team and can work on Linux
Very rought and simplified description:
Interpreter is a piece of software that takes some kind of code written in a language (whatever it means) X as and input, "translates" it to the code written in a language Y as an output and "executes" it. This is not a strict definition, but this should give you the general idea.
Emulator is a piece of software that tries to imitate some piece of physical hardware. This can be done at different levels, e.g. we can imitate the harware by imitating work of physical elements (e.g. transistors) or some higher level (e.g. registers, memory cells, etc.). Depending on a technique used, particular emulator can act very similarly to interpreter.
Virtual machine is a description (read, peace of paper) of an abstract piece of "hardware".
From the theoretical point of view, these are rather different concepts. Practically, they can be rather tightly related, but I'm not going to describe how does this happen as this is a broad topic.
ScummVM is best described (IMO) as an interpreter of commands for SCUMM virtual machine.