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.
no its not it's an interpreter(like AGS) for many text adventure engines and every single engine is done due reverse engineering.
I'm not a programming guy but afaik: emulators like dosbox run the orig. game binaries and interpreters replace those binaries with their own implementation, but instead of a compiled application you doesn't need to recompile the whole game code at the cost of a huge performance loss(which is totally irrelevant for that kind of games).
maybe we have a programming guy here that could clarify it? (=
Thanks, for the clarification, 100% agreed. You point the results of our last discussions out in a very comprehensive form. i think we can include that in our submission guidelines.
A little bit more specific for the NaCl discussion:
Not all NaCl games run on Linux and if the developer advertises Linux or a Linux distribution (e.g. Ubuntu) Point 5 of Curly Braces posts gets applied:
Simple => NO
Cool => GO
(please, forgive my simplistic view)
I've noticed there were many debates raised recently regarding game inclusion/exclusion policy, so I think I can bring my 5 cents.
First of all, I would like to remind anyone few things:
- This is not the first time such discussions appear.
- Each time most people agreed that LGDB has no 100% strict inclusion/exclusion policy.
- By examining those games already included in LGDB, other Linux gaming related websites, blogs, etc. it seems to be practically impossible to create such policy, which would allow to easily determine what needs to be included and what not (and make people happy at the same time).
- Hence, currently games are included according to some "general" guidelines, with exceptions being made for particular games.
- The ideas behind submission guidelines can be described as: do not flood the database with unrelated, poor quality games that has nothing to do with Linux (99% Flash & browser games); support Linux friendly developers; popularise Linux as a platform (make exceptions for good quality games, even if they are not really native); give people stuff they want to see here; popularise FOSS games and technologies. In other words, support Linux (hence, some "political" decisions can be made).
- If I remember correctly, we've also agreed to avoid where possible exclusion of those games that were added to DB (relatively) long time ago.
Regarding NaCl games - I'm not really fan of these (this is subjective opinion), but if they are already here, then we can go with this. Just keep the quality to be decent.
Forum topic: Not sure if I agree with this submission
They are completely different games! Unlike, say, PySolFC, it would just be unfair to say that these are single units, as they don't show up as one game on the desktop. Beyond the obvious fact that they are developed and played as individual games as well. Either way, I'm sure we can agree that they are not components of one game.
Also, they don't have to get updated at the same time; in fact, many of them don't as you would be aware if you follow KDE development. In the upcoming release (4.12), only KNetWalk received updates.
There is a core KDE games library but that's like saying that any game that uses SDL should be listed as a single game.
I'd suggest dividing these into several games. It's a chore, but remember, we are building the best database of Linux games in the world. =p
These are really browser games. NaCl is meant for browsers to run native code, not for operating systems (like Linux) to run them directly. So one might call them Chrome platform games, not Linux games.
They are exclusively available in the Chrome web store and cannot be played in other browsers. I don't see any other browsers adopting NaCl either since Firefox went with OdinMonkey.
It is also worth noting that none of those games are available native on any GNU/Linux platform.