Is it possible to change something in the .ini in order to improve performance on a laptop that do not have great cpu/gpu?
I think of, in "Software"-mode primarily.
(Btw I tried a tweaked OpenGL.dll for GF Remastered, which do not work well, but it makes the videos play flawlessly smoothly, compared to "Software", that generally works much better for the rest of the game).
Thank you.
Grim Fandango ini-settings for older computer?
Moderator: ScummVM Team
Re: Grim Fandango ini-settings for older computer?
What you're trying to do is not really clear...
Could you give more specific information on what you're trying to do, and what you're hoping to achieve?
Are you trying to run GF Remastered or the original one?
Are you trying to run it with the software renderer, or with the OpenGL one?
Are you using the stable release, or unstable?
What's the OpenGL.dll have to do with anything?
Could you give more specific information on what you're trying to do, and what you're hoping to achieve?
Are you trying to run GF Remastered or the original one?
Are you trying to run it with the software renderer, or with the OpenGL one?
Are you using the stable release, or unstable?
What's the OpenGL.dll have to do with anything?
Re: Grim Fandango ini-settings for older computer?
Hi and thank you for replying.
I wrote to this forum on a small phone, and i agree that some of the things where not very clear. Lets take one thing at the time here;
What I intended to do should however be clear as it is summarized in the topic definition; Running GF on some slow/older laptops, (single-core) wondering if there is anything one can tweak in the ini file to improve performance. Any suggestions, if things can be improved, would be helpful.
You wondered if i was trying to use software renderer or opengl, and i did in fact write that i was primarily interested in software mode.
What i did not say, but should have mentioned was that i am using the latest Stable on original GF. I did try daily builds too, (like 0.3.0gitc43e761) having the problem with slow cutscenes in software mode that i mentioned. As i said I got rid of the cutscene-slowness by using the tweaked GF Remastered specific mesa OpenGL.dll. https://cristianadam.eu/20150514/grim-f ... emastered/ Its been quite a lot of buzz around it so i though ppl here might know. As i mentioned, it did not help me very much however. Because of all that being quite off topic i wrote about it in a parenthesis.
I am still very interested in *anything* that can improve performance (by reducing quality I guess) in software mode.
Besides this most central question I have another, more specific one, also concerning improved performance:
Version 0.1.1. is lightning-fast on older hardware under Software mode compared to 2.0 and later. I am guessing that it might have something to do with a lighter tinygl, but I don't know. However there are some really heavy game crashes that was not yet fixed in this old version according to later documentation. I have spent hours trying to find old testing versions, post 0.1.1, but compiled before the changes that makes 0.2.0 less suitable for a more aged machine. Could someone help me with this? That would be enormously appreciated.
All the very best,
M.
Ps
(Another off-topic thing, just for the fun of it: The other night I finished the whole game (on slightly faster computer, running in 3d mode) with the "year(x)mus.lab"-files from the GF Remastered version under Residualvm 0.3.0gitc43e761 without any problems that I could notice. Sweet.)
I wrote to this forum on a small phone, and i agree that some of the things where not very clear. Lets take one thing at the time here;
What I intended to do should however be clear as it is summarized in the topic definition; Running GF on some slow/older laptops, (single-core) wondering if there is anything one can tweak in the ini file to improve performance. Any suggestions, if things can be improved, would be helpful.
You wondered if i was trying to use software renderer or opengl, and i did in fact write that i was primarily interested in software mode.
What i did not say, but should have mentioned was that i am using the latest Stable on original GF. I did try daily builds too, (like 0.3.0gitc43e761) having the problem with slow cutscenes in software mode that i mentioned. As i said I got rid of the cutscene-slowness by using the tweaked GF Remastered specific mesa OpenGL.dll. https://cristianadam.eu/20150514/grim-f ... emastered/ Its been quite a lot of buzz around it so i though ppl here might know. As i mentioned, it did not help me very much however. Because of all that being quite off topic i wrote about it in a parenthesis.
I am still very interested in *anything* that can improve performance (by reducing quality I guess) in software mode.
Besides this most central question I have another, more specific one, also concerning improved performance:
Version 0.1.1. is lightning-fast on older hardware under Software mode compared to 2.0 and later. I am guessing that it might have something to do with a lighter tinygl, but I don't know. However there are some really heavy game crashes that was not yet fixed in this old version according to later documentation. I have spent hours trying to find old testing versions, post 0.1.1, but compiled before the changes that makes 0.2.0 less suitable for a more aged machine. Could someone help me with this? That would be enormously appreciated.
All the very best,
M.
Ps
(Another off-topic thing, just for the fun of it: The other night I finished the whole game (on slightly faster computer, running in 3d mode) with the "year(x)mus.lab"-files from the GF Remastered version under Residualvm 0.3.0gitc43e761 without any problems that I could notice. Sweet.)
Re: Grim Fandango ini-settings for older computer?
This is indeed a great clarification 
...and I was indeed rash with
I'm not a ResidualVM developer though, they might pitch in later, until then I can only say a couple of things...
You could take a look at this: https://github.com/residualvm/residualv ... rime-games
Regarding the *.ini, I can only suggest that you try a lower fullscreen resolution or the ARB shaders with OpenGL.
As you say, the software renderer is TinyGL, and since 0.1.1 (which was early 2013) it has gone through several major changes.
In fact the video stuttering might not be TinyGL but changes to the video decoder or the grim engine itself.
I've taken a look at the code tree, and I can see TinyGL was refactored (at one point) around July/August 2014, the earliest commit I could find before that is 9bf27c0 on Jul 17, 2014. This does not guarantee that those crashes you mentioned would have been fixed by then.
I've made a build from that date that you can download here.
Maybe you'll have better results, or perhaps even identify if the video stuttering occurred even then. It's a bit tough to replicate because the issue is hardware specific. E.G. I can't experience stuttering on my regular machine, which is not cutting edge but not too shabby either.
Bear in mind that although it's from the official codebase, this is not an official release but one that I have made myself, so any issues that you might run into could have already been fixed or are already irrelevant. Also it is not from a point that was considered a release candidate, but a point I picked out from the development history. (I guess you can think of it as an unstable build from that point in time)
If you would like to try a different point from the code tree, I would encourage you to take a look at the Wiki at how you can compile ResidualVM for yourself.
It might be a learning experience, and more fun than looking for already compiled older versions, as they can be tough to find as time goes by.
EDIT: Also forgot to mention, savegames across different versions (especially differences in the MAJOR bit of the version) of ResidualVM are not guaranteed to work, in fact it would be safer if you assumed that they wouldn't.
EDIT2: As you mentioned the OpenGL.dll previously, I assumed you are on Windows, hence the build I made is for Windows.
EDIT3: I've read through the article, not sure how you tried out the *.dll or if it would work with ResidualVM, but in this case you would put the DLL where residualvm.exe is, and not with the game data.
...and I was indeed rash with
I had not encountered it before, the developers might have.What's the OpenGL.dll have to do with anything?
I'm not a ResidualVM developer though, they might pitch in later, until then I can only say a couple of things...
You could take a look at this: https://github.com/residualvm/residualv ... rime-games
Regarding the *.ini, I can only suggest that you try a lower fullscreen resolution or the ARB shaders with OpenGL.
As you say, the software renderer is TinyGL, and since 0.1.1 (which was early 2013) it has gone through several major changes.
In fact the video stuttering might not be TinyGL but changes to the video decoder or the grim engine itself.
I've taken a look at the code tree, and I can see TinyGL was refactored (at one point) around July/August 2014, the earliest commit I could find before that is 9bf27c0 on Jul 17, 2014. This does not guarantee that those crashes you mentioned would have been fixed by then.
I've made a build from that date that you can download here.
Maybe you'll have better results, or perhaps even identify if the video stuttering occurred even then. It's a bit tough to replicate because the issue is hardware specific. E.G. I can't experience stuttering on my regular machine, which is not cutting edge but not too shabby either.
Bear in mind that although it's from the official codebase, this is not an official release but one that I have made myself, so any issues that you might run into could have already been fixed or are already irrelevant. Also it is not from a point that was considered a release candidate, but a point I picked out from the development history. (I guess you can think of it as an unstable build from that point in time)
If you would like to try a different point from the code tree, I would encourage you to take a look at the Wiki at how you can compile ResidualVM for yourself.
It might be a learning experience, and more fun than looking for already compiled older versions, as they can be tough to find as time goes by.
EDIT: Also forgot to mention, savegames across different versions (especially differences in the MAJOR bit of the version) of ResidualVM are not guaranteed to work, in fact it would be safer if you assumed that they wouldn't.
EDIT2: As you mentioned the OpenGL.dll previously, I assumed you are on Windows, hence the build I made is for Windows.
EDIT3: I've read through the article, not sure how you tried out the *.dll or if it would work with ResidualVM, but in this case you would put the DLL where residualvm.exe is, and not with the game data.
Re: Grim Fandango ini-settings for older computer?
Wow. Thank you so very much. You wouldnt know how grateful I am for you actually comiling that file. (I have a little brother back home, that is not very well at all, and that is why I have tried to make GF work on his old computer).
Maybe i can reply to your EDITs first:
Yepp, I know about the various save game inconsistencies.
EDIT2, Yes, Windows.
EDIT3, Yes again, that's how i have done it.
So how did things go with the file that you compiled for me?
I downloaded the file, and it initially would not work, because of a "freetype6.dll" missing. I have never seen that error before. However I found this dll on my hardrive (For a portable IF/Inform interpreter called Gargoyle), placed it close to residualvm.exe and it all worked!! The graphics were *fast and supersmooth*, all of it, even the animated water in Rubacava, the Sea-Bees, the crowd in Blue Casket, and other places that tend to get very slowish and also very buggy in 0.1.1. Fantastic!! But then (ofcourse) I noticed something strange. Glottis teeth are gone! During all years! They seem to be hidden behind a digital veil of darkness. (Maybe a malfunctioning bugfix-attempt for bug #887? Or something else?) Also Olivias head disappear in the Blue Casket when she produces a cloud of smoke, and then comes back again, which might be connected to the fact that her glasses are now permanently nailed on a little black square hanging before her face. Well, well, this is what one can expect in "testing" versions. However, besides the graphics being lightning-fast, all the other bugs form the 0.1.1 that i tried to invoke seems to be fixed as far as I can see. Even minor things, like the shadow disappearing in the surrounding areas of the DOD building! So in a way this might in the end be a better version to use rather than 0.1.1 anyway. A pitty that Glottis is completely toothless anyway, and guess what... i swithch on 3d mode... and his teeth are as sharp, shiny and beautiful as always!! Just for kicks I even tried the non-supported datausr.lab patch in software mode, but that did not give either him or Olivia their missing body parts back.
Ok, so that is what happened. Thank you for compiling this however. I am still considering if this build, or 0.1.1. might be the best version to post to my brother or not. The crashes in 0.1.1 can get one really stuck, and the graphical distortions are often worse. If I was at a place with a normal internet connection i would download Git and try to give compiling a go, but now i just have a slow pay-as-you-go phone in the middle of nowhere for many weeks more. I feel slightly embarrassed to mention that I ofcourse would be extremely happy if you would compile something more, but don't break your back over it since i am sure you have other things to do. (Haha, jeeez, I'm anxious that it seems like i am pretending to seem humble and full of understanding in order to get some files i want, when in fact I really do feel that one has to be careful not to try to push needy demands on other people!).
Oh, one last thing. the sdl.dll file you included was just 243 kb in size compared to the one in 0.1.1 and 0.2.1 that is 307 kb. Out of curiosity I tried to replace it and noticed no apparent differences/changes due to this.
Allright, I guess that's it, all the best for now
/M.
Maybe i can reply to your EDITs first:
Yepp, I know about the various save game inconsistencies.
EDIT2, Yes, Windows.
EDIT3, Yes again, that's how i have done it.
So how did things go with the file that you compiled for me?
I downloaded the file, and it initially would not work, because of a "freetype6.dll" missing. I have never seen that error before. However I found this dll on my hardrive (For a portable IF/Inform interpreter called Gargoyle), placed it close to residualvm.exe and it all worked!! The graphics were *fast and supersmooth*, all of it, even the animated water in Rubacava, the Sea-Bees, the crowd in Blue Casket, and other places that tend to get very slowish and also very buggy in 0.1.1. Fantastic!! But then (ofcourse) I noticed something strange. Glottis teeth are gone! During all years! They seem to be hidden behind a digital veil of darkness. (Maybe a malfunctioning bugfix-attempt for bug #887? Or something else?) Also Olivias head disappear in the Blue Casket when she produces a cloud of smoke, and then comes back again, which might be connected to the fact that her glasses are now permanently nailed on a little black square hanging before her face. Well, well, this is what one can expect in "testing" versions. However, besides the graphics being lightning-fast, all the other bugs form the 0.1.1 that i tried to invoke seems to be fixed as far as I can see. Even minor things, like the shadow disappearing in the surrounding areas of the DOD building! So in a way this might in the end be a better version to use rather than 0.1.1 anyway. A pitty that Glottis is completely toothless anyway, and guess what... i swithch on 3d mode... and his teeth are as sharp, shiny and beautiful as always!! Just for kicks I even tried the non-supported datausr.lab patch in software mode, but that did not give either him or Olivia their missing body parts back.
Ok, so that is what happened. Thank you for compiling this however. I am still considering if this build, or 0.1.1. might be the best version to post to my brother or not. The crashes in 0.1.1 can get one really stuck, and the graphical distortions are often worse. If I was at a place with a normal internet connection i would download Git and try to give compiling a go, but now i just have a slow pay-as-you-go phone in the middle of nowhere for many weeks more. I feel slightly embarrassed to mention that I ofcourse would be extremely happy if you would compile something more, but don't break your back over it since i am sure you have other things to do. (Haha, jeeez, I'm anxious that it seems like i am pretending to seem humble and full of understanding in order to get some files i want, when in fact I really do feel that one has to be careful not to try to push needy demands on other people!).
Oh, one last thing. the sdl.dll file you included was just 243 kb in size compared to the one in 0.1.1 and 0.2.1 that is 307 kb. Out of curiosity I tried to replace it and noticed no apparent differences/changes due to this.
Allright, I guess that's it, all the best for now
/M.
Re: Grim Fandango ini-settings for older computer?
OK, regarding this:
http://wiki.scummvm.org/index.php/Compi ... _Libraries
Both SDL and FreeType can be found inside, and you can safely use those, although for SDL you can download the suitable 1.2.15 runtime library from their webpage. Same for FreeType, make sure to get the binary. You'd want to look for a /bin folder in the archive.
It does not look for freetype6.dll on my machine (which is why I didn't remember to put it in the *.zip), but I do have it in C:\Windows, which is a sort of a global place where applications would look in if it is not placed in the same directory.
I can't remember if I put it there manually, or if it was a result of some installation.
The fact that it looks for it at all however, is probably because of the way libraries are linked in Visual Studio. They are dynamic libraries (as opposed to static), which means they're not bundled with the executable. It has not bothered me too much so far and I had forgotten all about it. I'll take a look if I can change that, I may need static versions of the libraries themselves or change the way the project solution is created, or change the linkage. If it turns out to be too much work I'm not making any promises regarding that
Now, for the performance issues, I'm glad it turned out to be smooth!
So, if it's running slow for you on 0.2 but fast with this build, it means that the relevant changes were pushed between then and the beginning of 2015, when 0.2 was released.
I'll try to find a suitable commit that might lead to fixing Glottis' teeth, but this will most likely include the TinyGL refactoring changes, so I don't know if you'll be experiencing the previous issues as well.
I looked at #887, it does address an issue with Glottis, but I don't think it's what we're looking for, that's more related to the direction his head is pointed.
There was a lot of development going on in that timeframe though, so I'll try to find something suitable and make another build later today.
UPDATE:
OK, I've come to the following conclusions:
The black 'veil' in Glottis' mouth was fixed with 2a6f238 and a37e7bc. I've confirmed this, it's occurring with all previous commits that I tried.
However, those were made on December the 28th, which is too close to Version 0.2 release date. Also, putting them on top of the previous build doesn't change anything, because they obviously become relevant after the TinyGL refactoring...
Now that I've taken a closer look (especially with debug symbols present) I can experience the stuttering quite aggressively myself. It seems it has been introduced with the TinyGL refactoring (I suspect the blitting code)
@mangleus I guess you could wait for me to see if I can re-enable the transparency, however this might take a while
I'm using Visual Studio 2013 for building, and I'm using most of the precompiled libraries from ScummVM, which can be found here:mangleus wrote:I downloaded the file, and it initially would not work, because of a "freetype6.dll" missing...
...Oh, one last thing. the sdl.dll file you included was just 243 kb in size compared to the one in 0.1.1 and 0.2.1 that is 307 kb. Out of curiosity I tried to replace it and noticed no apparent differences/changes due to this.
http://wiki.scummvm.org/index.php/Compi ... _Libraries
Both SDL and FreeType can be found inside, and you can safely use those, although for SDL you can download the suitable 1.2.15 runtime library from their webpage. Same for FreeType, make sure to get the binary. You'd want to look for a /bin folder in the archive.
It does not look for freetype6.dll on my machine (which is why I didn't remember to put it in the *.zip), but I do have it in C:\Windows, which is a sort of a global place where applications would look in if it is not placed in the same directory.
I can't remember if I put it there manually, or if it was a result of some installation.
The fact that it looks for it at all however, is probably because of the way libraries are linked in Visual Studio. They are dynamic libraries (as opposed to static), which means they're not bundled with the executable. It has not bothered me too much so far and I had forgotten all about it. I'll take a look if I can change that, I may need static versions of the libraries themselves or change the way the project solution is created, or change the linkage. If it turns out to be too much work I'm not making any promises regarding that
Now, for the performance issues, I'm glad it turned out to be smooth!
So, if it's running slow for you on 0.2 but fast with this build, it means that the relevant changes were pushed between then and the beginning of 2015, when 0.2 was released.
I'll try to find a suitable commit that might lead to fixing Glottis' teeth, but this will most likely include the TinyGL refactoring changes, so I don't know if you'll be experiencing the previous issues as well.
I looked at #887, it does address an issue with Glottis, but I don't think it's what we're looking for, that's more related to the direction his head is pointed.
There was a lot of development going on in that timeframe though, so I'll try to find something suitable and make another build later today.
UPDATE:
OK, I've come to the following conclusions:
The black 'veil' in Glottis' mouth was fixed with 2a6f238 and a37e7bc. I've confirmed this, it's occurring with all previous commits that I tried.
However, those were made on December the 28th, which is too close to Version 0.2 release date. Also, putting them on top of the previous build doesn't change anything, because they obviously become relevant after the TinyGL refactoring...
Now that I've taken a closer look (especially with debug symbols present) I can experience the stuttering quite aggressively myself. It seems it has been introduced with the TinyGL refactoring (I suspect the blitting code)
@mangleus I guess you could wait for me to see if I can re-enable the transparency, however this might take a while
Re: Grim Fandango ini-settings for older computer?
Thank you for letting me know, and for the rich amount of info. I downloaded all the correct dll-files. Everything seems to work fine. (But ofcourse it did not affect Glottis teeth and Olivias head).
I tried Grim-Mouse Version 6 whose specially compiled residualvm.exe was made before 2.0, but after 0.1.1. It is possibly post-TinyGL refactory changes because graphics being as non-smooth as in 2.0. Glottis teeth and Olivias head where normal just like in 1.0 and 1.1. Perhaps there was a unique glitch with the commit 9bf27c0 of July 17, 2014? A slightly earlier build, still without the TinyGL refactory changes might be the best pick, but then there can be other problems.
Once again, thank you for the efforts.
/M
EDIT:
Regarding the
UPDATE
Wow, I now saw your update. Very, very interesting. I wouldn't have had a clue. Great, sure I'll wait.
I tried Grim-Mouse Version 6 whose specially compiled residualvm.exe was made before 2.0, but after 0.1.1. It is possibly post-TinyGL refactory changes because graphics being as non-smooth as in 2.0. Glottis teeth and Olivias head where normal just like in 1.0 and 1.1. Perhaps there was a unique glitch with the commit 9bf27c0 of July 17, 2014? A slightly earlier build, still without the TinyGL refactory changes might be the best pick, but then there can be other problems.
Once again, thank you for the efforts.
/M
EDIT:
Regarding the
UPDATE
Wow, I now saw your update. Very, very interesting. I wouldn't have had a clue. Great, sure I'll wait.
Re: Grim Fandango ini-settings for older computer?
Hi mangleus,
Can you give this build a try?
It's with the latest commit from the 0.2.0 branch, but everything worked fine for me on it. The relevant TinyGL code was removed at that point, so in theory even the official 0.2 release should work, but can you try this out just in case, thanks
Cheers
Can you give this build a try?
It's with the latest commit from the 0.2.0 branch, but everything worked fine for me on it. The relevant TinyGL code was removed at that point, so in theory even the official 0.2 release should work, but can you try this out just in case, thanks
Cheers
Re: Grim Fandango ini-settings for older computer?
Out of curiosity, could you post the HW-specs of the relevant machine? (OS version, GPU and driver, CPU etc).
There is little point for us in maintaining ancient GL/Software solutions if the target audience (i.e. those without too modern computers, or computers with
limited GL support) can't make use of it, so we do care about this, especially when the performance has regressed (which in turn would mean that a solution
DOES exist, it's just a matter of trying to figure it out, without losing the speed-gains we otherwise got from that TinyGL-refactor).
Also, could you tell me how GL behaves on that machine when trying to run Grim Fandango?
As for those glitches, such is life when using random checkout points in our code history, sadly, hopefully we can figure out how to make this work again with the latest
versions of ResidualVM, so that the bugs are fixed. (Do however remember, as stated earlier, that savegames are not necessarily completely compatible, this goes
one step further as well, in that the gameplay bug-fixes are loaded on game start, and will follow THAT chain of savegames, any subsequent gameplay-bug-fixes will
NOT be picked up by that chain).
There is little point for us in maintaining ancient GL/Software solutions if the target audience (i.e. those without too modern computers, or computers with
limited GL support) can't make use of it, so we do care about this, especially when the performance has regressed (which in turn would mean that a solution
DOES exist, it's just a matter of trying to figure it out, without losing the speed-gains we otherwise got from that TinyGL-refactor).
Also, could you tell me how GL behaves on that machine when trying to run Grim Fandango?
As for those glitches, such is life when using random checkout points in our code history, sadly, hopefully we can figure out how to make this work again with the latest
versions of ResidualVM, so that the bugs are fixed. (Do however remember, as stated earlier, that savegames are not necessarily completely compatible, this goes
one step further as well, in that the gameplay bug-fixes are loaded on game start, and will follow THAT chain of savegames, any subsequent gameplay-bug-fixes will
NOT be picked up by that chain).
Re: Grim Fandango ini-settings for older computer?
This is what happened.
I started it together with freetype6.dll that it requested, but this time it was also missing zlib1.dll, that i luckily got already due to the link you earlier gave me. And it all works!! Cutscenes are smooth, game-movements smooth... and grinning teeth in place! All in software mode. In 2.0 branch, the game-movements are not very smooth the rest ok, in 3.0git6aa3538 its not smooth, in particular not the cutscenes. Your build is undoubtly the best one for me. And obviously all the bugfixes long after 1.1 is in it so this is FANTASTIC! I remember trying a post-1.1 build, can't remember which one, on a friends netbook, and it *almost* worked. Just not quite smooth enough. I think this version will work actually. People with fast computers will understandebly go for Remastered, but on other machines residualvm can do the job well, at least with the build you just compiled. Would it not be useful with a lo-tech setting in regular residualvm? Or maybe it would get to messy codewise?
Haha, i even tried Myst 3 in your build, (which i never had to much luck with in 2.0 and 3.0 testing under graphical mode + no aspect ratio + fullscreen), but that was more than it could take, it crashes. (but not in 3d mode). But thats besides the point for this thread.
The only question i now have is wether this build also will go with the sdl.dll you suggested, or with the 307kb one that comes bundled with 1.1, 2.0 and the latest testing as well?
Ok, the most important thing:
A wholehearted, Thank You!
/M
UPDATE:
Hi somaen.
The problem is that out of the 3 computers i have noticed these specific behavious, 2 of them are not in the same county as me, and i can't get the spec for them until after another week. The way i have tried to simulate things here, in order to observe the very same differences (between 1.1 and 2.0 and later), is to switch my dualcore laptop to energysaving mode in AVG tuneup making it using one core only. I am writing all this on a small touchscreen/phone, and will in in a short while be back with a link for the spec. I hope to be of any help.
The savegame info i read about from you in other posts. Good luck with TLJ btw, really great stuff.
EDIT:
The laptop i mention above:
www.support.hp.com/us-en/document/c04332527
I started it together with freetype6.dll that it requested, but this time it was also missing zlib1.dll, that i luckily got already due to the link you earlier gave me. And it all works!! Cutscenes are smooth, game-movements smooth... and grinning teeth in place! All in software mode. In 2.0 branch, the game-movements are not very smooth the rest ok, in 3.0git6aa3538 its not smooth, in particular not the cutscenes. Your build is undoubtly the best one for me. And obviously all the bugfixes long after 1.1 is in it so this is FANTASTIC! I remember trying a post-1.1 build, can't remember which one, on a friends netbook, and it *almost* worked. Just not quite smooth enough. I think this version will work actually. People with fast computers will understandebly go for Remastered, but on other machines residualvm can do the job well, at least with the build you just compiled. Would it not be useful with a lo-tech setting in regular residualvm? Or maybe it would get to messy codewise?
Haha, i even tried Myst 3 in your build, (which i never had to much luck with in 2.0 and 3.0 testing under graphical mode + no aspect ratio + fullscreen), but that was more than it could take, it crashes. (but not in 3d mode). But thats besides the point for this thread.
The only question i now have is wether this build also will go with the sdl.dll you suggested, or with the 307kb one that comes bundled with 1.1, 2.0 and the latest testing as well?
Ok, the most important thing:
A wholehearted, Thank You!
/M
UPDATE:
Hi somaen.
The problem is that out of the 3 computers i have noticed these specific behavious, 2 of them are not in the same county as me, and i can't get the spec for them until after another week. The way i have tried to simulate things here, in order to observe the very same differences (between 1.1 and 2.0 and later), is to switch my dualcore laptop to energysaving mode in AVG tuneup making it using one core only. I am writing all this on a small touchscreen/phone, and will in in a short while be back with a link for the spec. I hope to be of any help.
The savegame info i read about from you in other posts. Good luck with TLJ btw, really great stuff.
EDIT:
The laptop i mention above:
www.support.hp.com/us-en/document/c04332527
Last edited by Guest on Tue Feb 16, 2016 11:44 pm, edited 2 times in total.
Re: Grim Fandango ini-settings for older computer?
Bah, sorry about the *.dll's, it's the result of dynamically linked libraries. Not sure why it would ask for zlib now and not earlier considering I haven't changed anything, just did a stock build. Oh well, must be looking for a dynamic library for *some* reason...
For SDL it doesn't really matter as I believe they have total backward compatibility within major versions. Either use the one that comes with 0.2.0, or download the latest one (1.2.15, not 2.0) from the official website.
As for Myst 3, you may want to look here: http://forums.residualvm.org/viewtopic.php?f=1&t=715
But I guess that's a different story, perhaps you can try the daily builds for it. I don't know what the situation will be with this build.
Cheers, and have fun playing
For SDL it doesn't really matter as I believe they have total backward compatibility within major versions. Either use the one that comes with 0.2.0, or download the latest one (1.2.15, not 2.0) from the official website.
As for Myst 3, you may want to look here: http://forums.residualvm.org/viewtopic.php?f=1&t=715
But I guess that's a different story, perhaps you can try the daily builds for it. I don't know what the situation will be with this build.
Cheers, and have fun playing
Re: Grim Fandango ini-settings for older computer?
Great!
Its all updated now under my previous post.
Its all updated now under my previous post.
Re: Grim Fandango ini-settings for older computer?
Hi again.
Tried a new thing. Tried the unofficial datauser.lab in 2.0 using both cores (normal-mode) on my laptop. It makes it not that very smooth. Then again in energy-saving setting, extremely slow, massive stuttering.
Then i tried Nitro's experimental build with datauser.lab. Everything is smooth, both in energy saving mode, and in normal mode.
Tried the whole thing on another faster stationary computer today. The exact same thing once again, but a bit less dramatic loss in framerate.
This means that its just not a quirk on my specific laptop, but might be a general drop in performance.
Tried a new thing. Tried the unofficial datauser.lab in 2.0 using both cores (normal-mode) on my laptop. It makes it not that very smooth. Then again in energy-saving setting, extremely slow, massive stuttering.
Then i tried Nitro's experimental build with datauser.lab. Everything is smooth, both in energy saving mode, and in normal mode.
Tried the whole thing on another faster stationary computer today. The exact same thing once again, but a bit less dramatic loss in framerate.
This means that its just not a quirk on my specific laptop, but might be a general drop in performance.