Jump to content

Home

ScummVM versus native interpreters


Recommended Posts

For Sierra games, I'm very grateful they fixed the bugs because there were so many, especially in Quest for Glory III and IV, which are some of my favourite games ever.

 

For legacy SCUMM games, I agree that adding a toggle to switch between versions is a good idea. Then again, I personally never encountered bugs while playing any of them and often thought that the code behind these games was error-free (but reading this thread certainly highlighted the fact that it wasn't).

  • Like 1
Link to comment
Share on other sites

Yeah, some Sierra games had far more timing-related bugs where they just ran too fast or stopped working on faster computers. I could never get past the start

in Quest for Glory 4 when I bought the QfG collection back in the late 1990s. A sequence in Space Quest 4 ran too fast so it was impossible to survive.

NewRisingSun made a bunch of patches for these games about 10-15 years ago, but they had to be applied manually so it's nice to see all that stuff integrated into ScummVM since it makes it easier for people to play these games.

  • Like 2
Link to comment
Share on other sites

Rightly or wrongly, I don't think ScummVM has ever been aiming for software preservation in an archival sense. Just look at the UI in LucasArts games running in ScummVM, for example. The "Are you sure you want to win?" pop-up gag in MI doesn't look anything like the original modal window. Nor do any of the save screens (even the really pretty Last Crusade one). But there's also functionality differences: The way you can save any time you like. Or the fact that you have basically unlimited saves whereas you were often limited in early LucasArts games. Then there's all the filters they added to make the games look "better" that have been there since the beginning. 

 

Just to be clear, I'm not having a go at anyone who appreciates software preservation. I do too. (Part of me actually wants to sit and listen to the Amiga floppy drive sounds again as SOMI boots up :)I just think ScummVM has always been about getting the games up and running, and less about preserving them. (Personally I wish the "alternate" save windows that tried to preserve the original look in ScummVM hadn't been abandoned, but it apparently has.)

Edited by ThunderPeel2001
Link to comment
Share on other sites

20 hours ago, ThunderPeel2001 said:

(Personally I wish the "alternate" save windows that tried to preserve the original look in ScummVM hadn't been abandoned, but it apparently has.)

As I understand (someone correct me if I'm wrong), part of the savegame/pause UI is hardcoded and different for every game, and it would require a great amount of work (per game) to add all those quirks back in exactly the same way they were originally presented.

  • Like 1
Link to comment
Share on other sites

6 hours ago, AndywinXp said:

As I understand (someone correct me if I'm wrong), part of the savegame/pause UI is hardcoded and different for every game, and it would require a great amount of work (per game) to add all those quirks back in exactly the same way they were originally presented.

There was an Alt-F5 option to use the original Save/Load GUIs (though not the Game Paused bars etc.) in SCUMM games rather than the ScummVM default, but it's been broken for one to two years now. (And it was already inferior to the fancy "use original Save/Load GUI" checkbox in the startup menu for Sierra games, but I'm digressing.) On Discord a while back Sev said it was probably just a bug that hadn't been fixed. However, it's been languishing in the bug list for over a year now without anybody bothering to fix it.

 

Honestly, most of the bug fixes and feature improvements to ScummVM are now happening on the Sierra side. The LucasArts games are treated as basically "done", even when there are still significant improvements that could be made, or even just notable bugs like the one above that are left unfixed.

Link to comment
Share on other sites

At this point I’d probably say that it’s a volunteer project and so perhaps there simply haven’t been people interested enough in the LucasArts games to work on them.

 

However, I have also seen the… warm and inviting… conversations in some of the code repository threads and pull requests, and it seemed unnecessarily challenging and thankless getting a change accepted.

 

That sort of thing can quickly lead to people not wanting to bother with the hassle, hence a decline in contributions.

 

It may stem from good intentions like not wanting to break all the (Now almost as ancient as the games themselves were!) ScummVM code, but if nobody wants to touch that old stuff it also means those imperfections may stay baked in forever.

 

I agree though Thunderpeel, ScummVM does achieve its goal of making the games functional and portable, albeit with a range of issues from minor (SOMI quirks) to quite major (CMI iMuse, thankfully fixed after 18 years). It has done great stuff allowing people to enjoy them in an accessible manner.

  • Like 3
Link to comment
Share on other sites

17 hours ago, ATMcashpoint said:

Honestly, most of the bug fixes and feature improvements to ScummVM are now happening on the Sierra side. The LucasArts games are treated as basically "done", even when there are still significant improvements that could be made, or even just notable bugs like the one above that are left unfixed.

 

This is a volunteer project, and as such, developers are allowed to work on whatever they feel most fun working with, all of this with its advantages and disadvantages of the thing.

 

Also, LucasArts games are currently being worked on more than you would expect: there has been a SMUSH font rewrite last year which makes it pixel perfect, there have been lots and lots of fixes in the walk code for every single major SCUMM version (from v2 to v8), v7-8 font drawing routine is currently in the process of being overhauled with a version which makes it pixel perfect and which correctly wraps text, COMI sprite decoding routine saw a major bug being fixed, and don't even get me started on iMUSE... :)

 

I do understand the frustration in seeing that developers apparently neglect or forget old bugs, I really do: I was one of those :)

But:

1) it's simply not true that they are not working on SCUMM games anymore, it's just that every major developer is working on at least two engines at once, so (being an after work activity) they might just not always have time to deal with them;

2) if you are upset about a certain bug, maybe an ancient one which nobody seems to care about anymore, do what I did: learn how to do it, and do it yourself, because if you really are the only one who cares, nobody else is going to do it for you! I'm serious, not being sarcastic, insulting, or anything! It can be a good learning experience and rewarding for sure. ;)

 

Quote

However, I have also seen the… warm and inviting… conversations in some of the code repository threads and pull requests, and it seemed unnecessarily challenging and thankless getting a change accepted.

 

Also, about this: I can see how from the outside the attitude might seem a little cold :) but rest assured, that is how pull requests usually work, after all they are just requests for code review for a new patch. 

Of course most of the comments are going to be request for fixing syntax, memory leaks, and whatnot, but that is to be expected: the project has to maintain a very high code quality since the application is actually used to ship games on Steam/GOG nowadays.

Edited by AndywinXp
  • Like 4
Link to comment
Share on other sites

The thing I'd change in ScummVM if I ever had the time or inclination is the interface. It's really quite ugly and not particularly new user friendly. I don't know why "Aspect ratio correction" isn't enabled by default, for example. Or why it doesn't cleverly calculate the best resolution for your screen to have a pixel perfect experience. (Apparently it can be done.)

 

But the amount of work going in that project is still pretty astounding. The world that was done on Blade Runner for example was incredible. 

Link to comment
Share on other sites

  • 3 weeks later...

The release notes for the new ScummVM release point out there's more support for the high-resolution Macintosh fonts in games like Last Crusade and LOOM - if it was there already in daily builds I must have missed it, but as a Mac gamer back in the day I quite appreciate it. And after I filed a bug report they put in the moveable Practice box in the LOOM Macintosh port, which is quite excellent!

 

On the other hand, the Mac high-res fonts on some screens in Last Crusade (eg, the Grail Diary pages) are not pixel perfect in ScummVM, and the comments on the bug ticket say they have no intention of making them be so, because the original implementation of the font kerning "looks bugged" apparently. Maybe? But I do wish accuracy to the original interpreter was a goal ScummVM strove for all the time, rather than picking and choosing.

Edited by ATMcashpoint
Link to comment
Share on other sites

Update: I mentioned on the ScummVM bug tracker that I would prefer it if ScummVM emulated the original, possibly buggy Mac font spacing in Indy 3, and eriktorbjorn very graciously agreed to see if it could be done as an option. That sort of incredible generosity reminds me that ScummVM is indeed a labor of love. My hat is off to him. :D

Edited by ATMcashpoint
  • Like 5
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...