Jump to content

Trouble with starting new game in menu (old version :) )


jury

Recommended Posts

OK. I have got something. I'm not a professional c/c++ developer, just a hobbyist with some knowledge of c and almost non knowledge of c++ (well, it theory I quite understand the workings of object oriented programming, but never coded anything in oop) So this is what I got when searching the web on making diff file. If its not what you expect, just let me know and I will correct myself.

This is a current state of patching the source for the need of cross-compiling for atari platform. I have not had a chance to work on this for the last 2 weeks unfortunately, but this weekend I should have a lot of free time so I will try to finish this having a working binary :)

 

diff.txt

Link to comment

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.

Link to comment
4 hours ago, lynx said:

Thanks. What's with the removal of std namespace for some functions? Are they provided elsewhere or what — sounds completely non-standard.

As a no c/c++ developer I can write silly things, so feel warned :) But I see it this way: I do not have knowledge from the roots, and there is quite some history there for sure, but at some point "our platform" received really nice tool for cross-compilation, based on gcc 4.6.4. It was not 1:1 "conversion" as in "normal" gcc at the point of 4.6.4 the standard library for example had math library integrated. But "our" toolchain still had this library externally, so when I cross-compile most of things I must provide the linker with "-lm" flag. Now we have gcc 9.sth.sth (and if I remember well, there is already 10.x.x or even 11) but its base is still that 4.6.4 one, so the story continues. And if I remember correctly, those functions I decapitated where some math functions (log or sth like this) so this is why it compiles without "std::" prefix and complains otherwise.

As for the second question, hmm, no idea, but I think I had seen something like that in some cross-compiled project, so will check there and be back.

Link to comment
7 hours ago, lynx said:

I still need a way to detect your platform though.

I've checked the projects that I thought in their README's I've seen some macros that would fit what you need, but with no success.

So I've searched the web to see if its possible to list all macros and found something like this "-dM -E - < /dev/null" And after searching the results, I think I found something what almost for sure was created exactly for this purpose:

__MINT__

 

Link to comment

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.

Link to comment

:(

I have downloaded latest sources from git repository and the first compiler errors I hit were connected to threads (condition_variable, mutex, thread) and as far as I know, this toolchain does not have thread support. I've searched the sources regarding this and found out that quite some modules use this approach in git sources, so I guess this is a show stopper :( (unless you have some neat peak) But I need to dig in some more on this subject thou, as I do not understand it for sure. The toolchain has got all the required .h include files, so during compilation it doesnt complain that it can not find them. But from what I have read many times that "our" platform doesn't support threads, period. So I will try to find out why the toolchain has the includes which can not be used.

So now, I guess I have to fall back to 0.8.7 version. Especially that when I left it over 2 weeks ago, I remember there were only 2 more things standing in the way to finish compilation.

Link to comment

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.

Edited by lynx
Link to comment
On 6/6/2021 at 3:06 PM, lynx said:

EDIT: also committed a simple fix that should avoid the need for any PluginLoader hackery.

Great, thanks.

And if it goes for thread support, I still do not have a sure answer, so I need to dig more. But meanwhile I decided to continue the work on adjusting code to compile for the destination platform. The next (and I think the last one) thing is replacing mman.h stuff as we do not have this library. I have read some stuff on what this library is and if I'm not wrong all I need to do is to adjust readonly_mmap function in VFS.cpp. I came up with something like this:

	void* readonly_mmap(void *vfd) {
   char *tab;
    int fd = fileno(static_cast<FILE*>(vfd));
    struct stat statData;
    int ret = fstat(fd, &statData);
    assert(ret != -1);
   tab = (char*)malloc(statData.st_size);
   fread((char*)tab, statData.st_size, 1,static_cast<FILE*>(vfd));
   return tab;
//    return mmap(nullptr, statData.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
}
	

right before sleep yesterday. It compiled fine on my linux box and first Baldurs Gate started! So I thought that today its just a matter of couple of clicks and I will have a working 0.8.7 on the destination platform. But no success, gemrb doesnt even start there (havent "debugged" it yet why) giving segfault and on linux box it starts fine, but quite fast it crashes or hangs the machine the way that only hard reset helps (cant even switch to console to kill the process, not many things can kill linux this way) 

Do you have any clues why the above could behave like that, or have a better idea how to replace mmap function?

Link to comment

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.

Link to comment

Thanks, I have some ideas why that build completely freezes my linux box. Will try to investigate it.

19 hours ago, lynx said:

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.

Yes, I've checked sources now and its optional since 0.8.8. And I tried to adjust it to my destination platform firstly because of course it is mandatory in 0.8.7 and secondly because when I read a bit on mmap it seams that it could be ideal for my platform, as I have read that mmap can out-perform standard file access methods. And optimization of file access is definitely on my list of things to take care of after all will build fine and will be stable. So I will spend some more time to try to "simulate" mmap, but not too much as its not the highest priority for me.

Edited by jury
Link to comment

OK, my linux machine was freezing because I forgot to free what I malloc'ed :) And when I run "htop" before starting gemrb, I saw it could eat 3 gigabytes in few seconds. And as I do not use swap  in my operating systems and linux memory management is as is (if I remember correctly, when I was using Windows it always informed that it does not have more memory not allowing to continue what I wanted so never froze because of no memory) it sometimes crashed and most of the times it was freezing the machine to the state that only cutting power supply from it worked. After freeing the malloc'ed chunks it works fine, so that malloc is ok (and I was pretty sure that the malloc was the culprit)

 

On 6/6/2021 at 3:06 PM, lynx said:

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.

And as for the destination platform, I could not find the accurate answer to the question on thread support so I asked one of the operating system devs. And I got a short answer, the platform does not support threads :(

 

Edited by jury
Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...