Grim Fandango, EMI etc were all part of 'ResidualVM' - a ScummVM sister project. It must be pretty weird to find, decades later, that random hobbyists have rebuilt every piece of that architecture, painstakingly replicating every aspect of the original architecture, reproducing it as some verbatim gospel, even if it was something you barely put any thought into at the time. In other words, suppose you wrote a random engine for a company many decades ago, complete with assorted warts, retrospectively questionable design decisions, and kludges that were ultimately put in just to ship on time. ![]() The reimplementation project is like a weird "echo" through history, echoing off the original engine, caused by it yet done by wholly separate people, who are reduced to piecing through the original binaries like some act of software archeology, yet are motivated to do so by the merits of the original game. One of the things I find fascinating about this is how the original programmers effectively cause the creation of the subsequent project, and their design decisions determine how successful that project is. The effort to develop the engine in the first place probably took multiple people much effort when these games were first developed, and those programmers were paid reverse engineering is harder and requires more effort and tenacity, and yet we still see a seeming overabundance of fully-functional complete reimplementations. I also think it's pretty interesting to consider just how many of these engines had to be completely reverse engineered, and the time investment that implies. Having these open source reimplementations ensures these games remain available to future generations. Really, this is an incredibly valuable thing not just in practical terms for enabling people to play these games on different systems and with open source code, but as I see it this is a significant culture and heritage preservation effort too. I sometimes like to say that the Linux kernel is the world's largest collection of open source drivers, with a decent kernel attached ScummVM is like that for old video game engines. Originally an interpreter for the LucasArts SCUMM engine games, it has now seemingly become effectively a centralised home for assorted open source game engine reimplementations. Jones need GPU-acceleration nowadays? What is going on here? When I remember correct (its so long ago I sat in front of a working ScummVM on a 700Mhz-single core) even Monkey Island 3 was playable without any speed-problems.ScummVM is an outstanding project. Never understand this really.did the system-requiremments for this changed so dramatically? Does Dr. However, how to get this versions cpu-usage to normal and make it useable like it was on a Pi 1 years ago? Why does this nice tool (and others, too.) seem to get no attention on the Raspberry? Is it so hard to get a useable and working version into the repository? Where exactly is the problem? It was fine already years ago on the Pi 1 for a while - so it definately is (was.) possible.īut since then only unusable/defect new versions were released.why?! ![]() It seems at least the stamp-screensize is solved - but why uses it 100% of the cpu now - without starting any game?!įurthermore the mousepointer jumps around like crazy.I thinks its related to the cpu-usage.but why? ![]() Since ScummVM was not working as it should since years, I was very happy to see that there is a "new" release available in the repository today.was very happy.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |