lynx

Yeah, if you're guzzling memory too fast, even the kernel out-of-memory killer won't help. Did the videos in your 0.6.4 have sound or not? Did you have the main theme music, button clicks ... In the worst case scenario you'll have to run without audio and logging.

That code is optional (HAVE_MMAP), so I don't know why you're even trying. Might be that way only since 0.8.8 though, I don't remember. As for the deep freeze (congrats), I'd suspect some of your changes — c++ is comparatively close to the metal, so shooting yourself in the foot is easier than lets say in python. Maybe look for the useful commits and cherrypick them back.

Cool. Added a reminder on IESDP to make these things more obvious: https://github.com/Gibberlings3/iesdp/issues/111

Clicked is in svtriobj.ids, so using LastTrigger as the object in the action block should do.

Great, will make it fatal then!

We've used threads before — audio has always been on a separate one. So you do have threading supporting, though perhaps it is limited in some way. Now we do use some more modern features related to that. Let us know once you find out more. EDIT: also committed a simple fix that should avoid the need for any PluginLoader hackery.

Can you try using CMAKE_INSTALL_PREFIX instead? PREFIX is an internal cmake variable, so maybe something goes wrong because of that. We try to be smart about this old shorthand, but perhaps that's not enough.

Those are cmake-internal tests, nothing wrong with those error. Check the log to verify: As for "compile warnings are fatal" — well, you didn't disable that, so that's to be expected. So my only current question is, does it compile and link fine when you ensure proper compilers are identified like above?

Something looks wrong with your toolchains, as they're not getting recognized: Try running with CC=gcc CXX=g++-10 cmake .. (or however the gcc and g++ binaries are named for you)

We've merged a few thousand commits and I've added cleaner versions of many of the needed changes, so it'd be great if you could try building from a clean slate, from our git master branch. The std stuff will still be wrong, plugin related stuff (except the missing header is now skipped) and maybe some string includes, but that's all that's expected. It should even auto-switch to static linking if you don't specify it, hopefully not too late. So it'd be good to see where things stand.

Thanks. I see it in gnulib, so it really should be it: if defined __MINT__ /* Atari FreeMiNT */

Are you manually setting any CXXFLAGS? You can see the end effect by running make VERBOSE=1 in my case, extracting the flags:

Have you tried in a fresh build dir?

I've committed some changes that should obviate the need for some of the hacks. I still need a way to detect your platform though.

If none: nothing. If many: there is an order, but it is different between the games. Override is always the overriding one though. Having several slots enables easier development, as common code can be shared by using the same script. Eg. all the "turn to enemy if attacked" stuff neutral NPCs have. Some more info: https://gibberlings3.github.io/iesdp/scripting/actions/index.htm Too much info: https://gibberlings3.github.io/iesdp/file_formats/ie_formats/bcs.htm

Nasty, but it's not like we haven't seen worse. Too bad we can't extend the namespace ourselves — now I don't see a different way than ifdefing them away, one way or another.

The GemRB team is proud to announce a new release. Check out the details here: https://gemrb.org/2021/06/02/gemrb-0-8-8-released.html

The GemRB team announces the availability of GemRB 0.8.8! This release features improvements in several areas, with no new major subsystems. You might be thinking: "What's this, weren't we promised subviews?!" and the answer to that is: yes, yes indeed! Stay tuned for another release in the following days as we integrate the branch back and do some final retesting. https://gemrb.org/2021/06/02/gemrb-0-8-8-released.html

Thanks. What's with the removal of std namespace for some functions? Are they provided elsewhere or what — sounds completely non-standard. Would also be good to know if the platforms define any CPP defines that we could use to differentiate them with. Like there is __APPLE__. Alternatively, some other way to detect them during building and we then just create a define ourself.

Like the entry says, the effect should be considered from the point of view of the creature it is applied to. And you're reading too much into "rolls", these are flat modifiers as usual.

Posted a reminder here: https://github.com/gemrb/gemrb/issues/1254 Your diff would still be valuable.

Nice , didn't think it would work on such slow hardware, since we still have things to optimize (eg. to lower memory consumption). Most of PluginLoader is already skipped for static builds, but I see you're right, dlfcn.h is used unconditionally. We can check for it in the CMake step if needed and cleanly disable things for STATIC_BUILD. When you can, please get me the current diff.

Then also pass --root. Another way would be through something like: git reset --soft initial-commit-sha # and then committing. Or cherry-pick and -n. But really, why bother, when the first two approaches are much simpler.

No need to do it today, but let's get it to 100 % and then I'll need a diff to see what other changes you made. Then we can make it work out of the box. Also, does this "platform based on MC68x or ColdFire CPUs" have a name?

It was known already.