The Neverhood comes to ScummVM!

[shmerl]

For daily builds it should really be just bundled in the archive and you'll need to point the extrapath at the place where you extracted those. So, if ScummVM does not find the file by default, something with your ScummVM build is fishy.

I downloaded the daily build from here.

The contents of the tarball:

Code: Select all

debian-x86_64-master-fa00a79b/AUTHORS
debian-x86_64-master-fa00a79b/COPYING
debian-x86_64-master-fa00a79b/COPYING.BSD
debian-x86_64-master-fa00a79b/COPYING.LGPL
debian-x86_64-master-fa00a79b/COPYRIGHT
debian-x86_64-master-fa00a79b/drascula.dat
debian-x86_64-master-fa00a79b/hugo.dat
debian-x86_64-master-fa00a79b/kyra.dat
debian-x86_64-master-fa00a79b/lure.dat
debian-x86_64-master-fa00a79b/NEWS
debian-x86_64-master-fa00a79b/pred.dic
debian-x86_64-master-fa00a79b/queen.tbl
debian-x86_64-master-fa00a79b/README                     
debian-x86_64-master-fa00a79b/scummclassic.zip
debian-x86_64-master-fa00a79b/scummmodern.zip
debian-x86_64-master-fa00a79b/scummvm
debian-x86_64-master-fa00a79b/sky.cpt
debian-x86_64-master-fa00a79b/teenagent.dat
debian-x86_64-master-fa00a79b/toon.dat
debian-x86_64-master-fa00a79b/translations.dat

As you can see, it has just a few *.dat files and neverhood.dat isn't there. May be daily builds don't bundle all of them?

[digitall]

This is added by the DIST_FILES_ENGINEDATA variable in:
https://github.com/scummvm/scummvm/blob ... ommon#L265

The standard debian 32-bit package is also missing the same engine datafiles i.e. mort.dat, neverhood.dat, tony.dat and wintermute.zip. These correspond to the latest additions of engines / engine data... so it may be that some linkage has been missed in transferring these, but this is a very odd problem.

[digitall]

AH, for POSIX targets such as Debian, this is copied across by:
https://github.com/scummvm/scummvm/blob ... rts.mk#L18

All the files are available in:
https://github.com/scummvm/scummvm/tree ... ngine-data

Again, no real clue why this doesn't work for some of the files, but does for others.

[LordHoto]

Again, no real clue why this doesn't work for some of the files, but does for others.

According to our buildbot config it seems the files are simply just not included in the list of files to include. Probably they should be included later on in the [url=hhttps://github.com/scummvm/scummvm-sites/blob/buildbot/config/master.cfg#L92-L93]master config[/url].

EDIT: It also seems the same file list is used for Win32 and Win64 where these files should actually already be bundled into the executable. This results in all the additional files being present even though there is no need for it.

[digitall]

Ah. Yep. Will fix the list to add the newer files.

Longer term, we should probably call the "install" package target for POSIX builds... ensuring that DESTDIR is valid:
https://github.com/scummvm/scummvm-site ... mm.py#L154

This would override the default packaging list and package up the contents of the staged DESTDIR instead.

[shmerl]

Thanks for clarifying, for now manually placing neverhood.dat in the ScummVM directory works.

By the way, why do daily builds of ScummVM for Debian use libpng15? ScummVM seem to be configurable with libpng12 at the build time too, and Debian only ships libpng12. Would it make more sense to use libpng12 in the daily builds then, until Debian bumps the version?

See http://packages.qa.debian.org/libp/libpng.html

[shmerl]

Another question. Do sprites in Neverhood when run in ScummVM look a bit rough and pixelated on the edges? I remember when it's run through Wine they looked more smooth. I can't make a comparable screenshot now, since recent kernels broke Neverhood in Wine, but from the memory in ScummVM it looks somewhat worse. I'll post some comparisons when Wine will get back in shape.

[eriktorbjorn]

Another question. Do sprites in Neverhood when run in ScummVM look a bit rough and pixelated on the edges? I remember when it's run through Wine they looked more smooth.

Other than a small difference in colour (that I can only make out if I flip between the image, not by watching them side by side), I don't see any difference in the first room myself. This one's from ScummVM:

klaymen-scummvm.png (17.88 KiB) Viewed 1024 times

And this one's from Wine:

klaymen-wine.png (17.88 KiB) Viewed 1024 times

But of course that's not conclusive so please do check if you can!

[digitall]

[quote="shmerl"]Thanks for clarifying, for now manually placing neverhood.dat in the ScummVM directory works.

By the way, why do daily builds of ScummVM for Debian use libpng15? ScummVM seem to be configurable with libpng12 at the build time too, and Debian only ships libpng12. Would it make more sense to use libpng12 in the daily builds then, until Debian bumps the version?

See http://packages.qa.debian.org/libp/libpng.html[/quote]

schemrl: That is because the buildbot Debian x86_64 builder has libpng15 since the library update I did on Apr 19th 2014.

Yes, it would make more sense and I didn't think about this at the time as I was adding missing libraries for at least 10+ toolchains, but that builder's library is badly out of sync with the Debian x86_64 libraries, so this is a bit of a hack. This was prexisting my changes.. It looks like the libraries are very much older.

It should be made clear that the primary aim of the buildbot is to give an early warning of compilation issues across all platforms. The production of testing builds is secondary and unless the various porters help to maintain the toolchain, it can age / go out of sync.

To be honest, we would normally expect Debian Linux users to compile from source code on their systems against their installed library sets, rather than use a third-party binary and thus the Debian x86_64 build has probably not been tested significantly.

I will take a look at switching Debian x86_64 back to libpng 1.2

[shmerl]

Another question. Do sprites in Neverhood when run in ScummVM look a bit rough and pixelated on the edges? I remember when it's run through Wine they looked more smooth.

Other than a small difference in colour (that I can only make out if I flip between the image, not by watching them side by side), I don't see any difference in the first room myself.

I was able to run it in Wine again - you are right, I don't actually see any quality difference, so no problem here. Since I did it from memory first, and I didn't play it in a while it appeared different. I was probably implicitly comparing it to recent high quality animations from Armikrog

To be honest, we would normally expect Debian Linux users to compile from source code on their systems against their installed library sets, rather than use a third-party binary and thus the Debian x86_64 build has probably not been tested significantly.

I will take a look at switching Debian x86_64 back to libpng 1.2

Thanks!

About building - while it's true for some Debian users (and I personally don't mind building from source), I don't think it's a good generalization. Debian is positioned as a general purpose "universal" system, so expect that Debian users can have any level of technical expertise, which surely means that not all will be able to build the sources

[digitall]

Well, just my opinion (no flamewars please), but Debian is known for being notoriously user-unfriendly... Hence why Ubuntu is basically Debian for "normal" users.

If a user is not capable enough to do a "./configure && make" with a side order of "sudo apt-get install libpng-dev".. then I would hope that they stick to just installing from the standard Debian repository versions of ScummVM.

I think we only started providing these builds on the download page as the Debian repositories were very slow to update... especially for game projects. IIRC the latest in Debian stable is still v1.4.1 which is very outdated... some third party repositories i.e. the Wheezy for Raspbian, have now added v1.6.0 builds.

Anyway, I will look at moving this back to the libpng1.2.X ABI, but tracking the library API against Debian amd64 stable is not guaranteed in future.

[digitall]

Ah yes... http://packages.qa.debian.org/s/scummvm.html

Testing is now on v1.6.0, but Stable is still v1.4.1

[shmerl]

I don't think you should worry about stable, it's not commonly found in desktop use cases. Aiming for Debian testing (+ Unstable) is more to the point. Most often if someone wants newer packages on Debian stable they can get them from backports, but more commonly stable is just used in server installations. The bulk of desktop users are on Debian testing.

About being unfriendly and not having "noobs" - that's a wrong perception which I was trying to point out. Not for the sake of flaming, but for the sake of fixing that perception for the mutual benefit of users and developers. Regarding all Debian users as experts results in inexperienced users left out with little help. Debian strives to be user friendly on its own. Notion that "if you are not an expert - go to Ubuntu" is not helpful. I personally know quite a few Debian users who are regular casual users and gamers and won't even try building stuff from source without help.

I.e. developers should adjust their expectations, and treat Debian users as a mixed crowd like in any other general purpose distro. About Gentoo for example, I'd agree that it's more specialized and has different demographic expectations (i.e. more technically adept). But Debian? Not really, at least not anymore.

[gbell12]

Sorry if this is a stupid question, but how do you save a game? I can't remember (from 1996!) and Neverhood running in Scumm doesn't respond to any keys <mash mash mash>

[digitall]

Escape brings up the Options which include Save and Load.

An alternative is always CTRL-F5 which brings up the ScummVM GMM (Global Main Menu) which also has Save/Load on it.