Username:
B
I
U
S
"
url
img
#
code
sup
sub
font
size
color
smiley
embarassed
thumbsup
happy
Huh?
Angry
Roll Eyes
Undecided
Lips Sealed
Kiss
Cry
Grin
Wink
Tongue
Shocked
Cheesy
Smiley
Sad
1 page
--
--
List results:
Search options:
Use \ before commas in usernames
Edit history:
Bigmanjapan: 2015-10-03 06:12:50 am
Hello!

As we know virtual machines and DOXBox are now allowed to use for old DOS games speedruns (https://forum.speeddemosarchive.com/post/virtualization_software_and_dosbox_allowed_for_old_games.html).

I also encountered a common opinion that ScummVM is allowed if a game got re-released with ScummVM bundled.
ScummVM uses plug-ins that add non-original features to the games like animations skips, dialogue speed-ups etc
This results in speedruns on ScummVM being considerably faster in comparison to DOSbox.

Let's look at Kyrandia 1 for example. In this video I did a short part of the game on both emulators (game files used are exactly the same). ScummVM is twice as fast due to animation skips and texts speed-ups.
The problem is that it creates visual glitches that are definitely were not present on native environment (or DOSbox) and could possibly lead to abnornal game behavior in other games.



Another important point is that re-released games that got ScummVM bundled don't really get any tweaks from the releasing company (like GOG), they use plug-ins made by ScummVM devs. So there is not that much of a difference between official re-releases and players downloading ScummVM on their own and using original games' files.

My questions are:

1. Should ScummVM be allowed to use for speedrunning if a game got official re-release with this emulator (even if ScummVM makes game behave abnormaly)?
2. If yes, should runs done on ScummVM go under a separate category?
3. Should there even be a restriction on using only official re-releases bundled with ScummVM since there is no difference between official rereleases and players own ScummVM setups?

Thanks!
Thread title:  
I've been thinking about this question quite a bit in the past couple of days.  A couple months ago, I was speedrunning Simon the Sorcerer (GOG release) which forces you to use ScummVM to play the game.  I discovered that by pressing CTRL + F, you could play the game in "Fast mode" which sped everything up substantially - roughly 300%.  However, after reading around online and in the ScummVM documentation, I've found that this fast mode is an emulator feature, not part of the game itself, and this has led to me distrusting the emulator entirely; if such an option exists in the emulator, who knows what other options there are, hidden or not, that speed up the game? 

Also, at what speed is ScummVM running the game normally?  Is this speed set in stone, or dependent on your computer?  How do we know that, for example, when I'm playing a game, it may take me .3 seconds to load the next screen, but someone with a slower computer may take .5 seconds to load a screen?  Because you cannot set a defined speed in ScummVM like you can in DOSBox (establishing the number of CPU cycles and frameskip to ensure everyone is on an even playing field), it is my opinion that ScummVM should not be allowed, especially if DOSBox runs the game just fine (and it runs quite a few games just fine).  However, this answer is solely dependant on if ScummVM preforms the same across different machines, or not.

As far as the glitches and dialogue skips available only in ScummVM instead of DOSBox, I am perfectly fine with those.  To me they are similar to the case with many many different speedruns - you play the game on the fastest version possible.  As long as ScummVM is standardized across multiple machines (and it very well might be, I just don't know though), I have no problem with using it instead of DOSBox in order to be playing on the fastest version of the game.

So, to answer your quesions, Bigmanjapan, I say yes, yes, and no.  ScummVM times should be tracked separately from DOSBox times, although I feel like if both were accepted, people would generally tend to use ScummVM more than DOSBox.
Everyday is puppies and sunshine...
This is extremely interesting and totally want to look into this more.  Thanks, Bigman.
Heavy Metal Powered
Knowing how ScummVM operates, I would say no on allowing it.
What ScummVM does is simulate the game engine used. The name comes from the early Lucas Arts games like 2D Monkey Island since they used the SCUMM engine, which this is a virtual machine for.
So, in other words, ScummVM takes over the role of the executable files that are part of the game, therefor it can take liberties DOSBox does not, like add the skip dialog function to the above mentioned game even though the original didn't have it.

Taken directly off their homepage:
"ScummVM is a program which allows you to run certain classic graphical point-and-click adventure games, provided you already have their data files. The clever part about this: ScummVM just replaces the executables shipped with the games, allowing you to play them on systems for which they were never designed! "

So, the difference here is that DOSBox is a virtual machine that runs DOS, and executes the game executables like a real DOS computer would (assuming there aren't any bugs), while ScummVM is a virtual machine for the game engine (a re-implementation if you will), which means it's a virtual machine on a much more abstract layer, as they also mention in the above quote, it enables games to run on machines they were never designed for, as the executable is never used, just the data files.
What's that gemma?
The issue with ScummVM is that it is not an emulator.  It is an alternative game engine which is incidentally capable of reading the games' data files.  There are many cases where how ScummVM does something (especially animations and timing) is completely different from how the original game engine did it.  And this is considered okay, because duplicating the behavior of the original game is not ScummVM's goal.

Under no circumstances should a game run on ScummVM be directly compared to a game run on an actual emulator.  My opinion is that games with an official release that uses ScummVM could be acceptable for SDA, but it could never obsolete a DOSBox run.  (Also, the ScummVM engine used would have to be the particular version that was packaged with the game, and not a more recent one).
Edit history:
Bigmanjapan: 2015-06-23 03:37:22 pm
Bigmanjapan: 2015-06-22 05:28:07 pm
Bigmanjapan: 2015-06-22 05:22:01 pm
Quote from Crow!:
My opinion is that games with an official release that uses ScummVM could be acceptable for SDA, but it could never obsolete a DOSBox run.


I'm inclined to agree with this opinion. Only official releases. Under a separate category. ScummVM runs have a certain charm to them because of all additional speedups (even if its not a true emulator). However, I would totally understand a full ban on ScummVM runs (for the reasons stated above) if that's gonna be a final official decision.

Just like with DOSbox, runners can send scummvm.ini configuration file (Windows Vista/7: \Users\username\AppData\Roaming\ScummVM\scummvm.ini). Although, it doesn't hold any information on CPU cycles etc.

I would also be glad to read El_Nino's opinion on this topic since he hosts adventure-speedruns.com and is a great DOS games enthusiast.

Thank you for your inputs.
Everyday is puppies and sunshine...
Is adventure-speedruns.com still being updated?  It doesn't seem like it is active.  The poll on the front page is from August 2013.
Well, El_Nino updates the runs list on his site, so it's somewhat active.
Adventure Speedruns
He guys,
in fact Adventure Speedruns is still running and gets some updates from time to time.
Because I am the only Admin who adminsters the website it is quite time consuming to look for new runs in the web and implement them on the website.
I will remove the poll from 2013. This one is really old, your are right. :-)

But let's get back to the topic.
In my view ScummVM, DOSBox and all other Emus are okay.
But they have to be declared in a specific category.
There are still some things which are different on a native host.