Portable Bioware's Infinity Engine

I got the following information on serial, which looks relevant and might help on a fix. The last line repeats constantly at the log

https://os4coding.net/node/2426

@walkero

Maybe it worth reporting this in sdl github repo aswell

@samo79
You are right. I will create it there as an issue as well. The thing is that right now I am not sure if this is a problem of the old port of GemRB, which might need a new compilation with the latest SDL, or something that has to do with SDL itself, which by chance the old version from 2012 was working fine.

@samo79
Done. :D
https://github.com/AmigaPorts/SDL/issues/163

@walkero

If keyboard and audio works, then it doesn't seem like a crash to me.

I checked some GemRB code and it doesn't call SDL_Init (it calls only SDL_InitSubSystem) which explains ITimer issue.

https://github.com/gemrb/gemrb/blob/ma ... SDLVideo/SDLVideo.cpp#L95
https://www.libsdl.org/release/SDL-1.2.15/docs/html/general.html

I need to check later if there is some workaround that could be done. I remember there was a a need to change the initialization because for some unexplained reason library constructors didn't run, so they are called manually on SDL_Init.

@Capehill
Thank you for your reply and for taking the time to look at it. Much appreciated.

Some clarification on crashes, that might help.

If the game opens on it's own screen and crashes, so the pointer doesn't move and the game is not playable.

After that I can switch to WB with keyboard, but if the game opens a window at WB, and crashes, then the whole system is not usable, because pointer still doesn't move and you can't do anything than reboot the system.

I'm working on the new version.. i had to remove the dynamic linking because with the new gcc there are some issues.. Hope i can release it soon.
I've tagged this version in $VER COVID19 Version.. so.. watch out..

@afxgroup
I am waiting for this and thank you for started working on it. Are you going to push the changes on a git?

Keep it up there. I am watching you :D :D :D

Some changes are already there.. and i didn't remember this.. But that changes comes from svn era.. now they are on git. I don't know if they accepts changes. However i have first to make it works.. and at moment it doesn't.. Or better, it starts but some scripts or paths or something shitty doesn't works correctly..

@afxgroup
What is the repo you use?

The official repository
However i've compiled and found a bug (?) when compiling with -fPIC and linking against python25.so




But i need a lot of bugfix. Not only. This version will be slow because all is statically linked and they have changed internally the virtual file system tu use memory mapped files. So i have to use fake memory mapped files that will load the file into the memory and many files are large. So i don't know neither if it will work on machines with 512MB of ram for example. On my however sam460 it seems to work (to the menu..)

That's great news and an awesome step. I would say, make it work even if it requires a lot of memory, and then optimize it as much as you can to work on low memory systems. Maybe others can recommend good solution on that. And since the code is open, they can also have a look and propose a solution.

Just my thoughts.

The problem is not the optimization. The problem is that one you can read in the other flammed thread..
While the software improves using like in the example memory mapped files we are stuck in 1980 era. And there is no way to improve things. We have reach the end of the tricks.
We need modern stuff to kepp up to the modern stuff.
We have a new gcc that has a lot of problems. We don't have a lot of things in the kernel. We can't update the newlib because is closed source. So how do you expect to improve things?
Honestly i've compiled gemrb in 2012. 8 years ago. And after 8 years the situation is really worst. And why? To make money on old crap hardware and software? This is what the companies around amiga do. And this is the result. No software

@afxgroup

Sorry for derailing, but < sigh > this is exactly what is going on right now.

When even you, a masterclass porter of awesome (and big) projects, say that you can't work with the tools we have available right now then who will?

We need a massive release at Amiwest, covering SDK/adtools/gcc, and all the fixes that are available (kernel, OS)...if there are only talks like all the time, then i fear it's over for good...

Still, thank you for some awesome ports

...back to topic, sorry again

@afxgroup
I totally agree with you. Unfortunately, from our side what we can do is what we can do. We can't change the way the companies work and release software. We have that discussion there so to push a little bit further and make them realize the situation.

But we are developers, and what we do better is to always try to find a solution. What I am about to say might be stupid, because I don't know how to port software from other systems, but, have you tried with cross compiling? Is there a possibility that this would help to overcome the problems you mentioned?

i'm cross compiling everything since ages.. because except for small native projects is fool to use a native os4 to compile. with my laptop, GemRb with a make -j20 compile in 10 seconds. Is not a cross compilation problem or not. Is a library problem. Is a kernel problem. Is as gcc problem. And debug software like gemrb is not easy. I have to use the old "printf" way.. fool. Because we don't have a working debugger. We don't have any modern tool that a developer that came from linux, mac, windows use daily. How do you think we can get new developers if we don't have the basic tools?

@afxgroup

The VIM tool (the latest version 8.2) is available and it's modern

@afxgroup
I completely understand what you say, and sorry for my ignorance on what porting software needs. What is needed to be done, in your opinion so to make your life easier, and others easier?

For example, when I saw that some people had issues to set up a cross development environment to build Odyssey, what I could do, and I did, was to create one that compiles Odyssey and uses Docker (https://github.com/walkero-gr/odysseyOnDocker). Good or bad solution that's an other matter and discussion, but that's what I could do.

With that mentality, do you believe that there is something we could do to change the situation? For example, the kernel is on ExecSG team hands, which seems more active than Hyperion. If we talk with them would there be a way to find some information or ask for some changes?

Would make sense to form a team of people, which will work on fixing this problem? Is it doable? Do we have those minds here that could contribute to this?

If I am not wrong, for VSCode there is an extension that uses a modified WinUAE to give debugging ability for AmigaOS 3 executables. Would there be a potential for us as well?

In general, instead of waiting Hyperion to do their part, is there a way we could work for a solution?

@walkero

It would be awesome if someone from the ExecSG team could provide updates on the matter...and take feedback, and maybe even bug/feature reports.

I'm not a coder myself, so my prorities obviously lie somewhere else, but i for one would love to get my hands on an updated (working) gcc (8.3.0 here atm) together with a new working shared libstdc++.so (one that doesn't crash every time, like it does now)

@Raziel
I am sure they have a lot on their plate as well, but if someone who knows what is required could contact them and try to discuss what is needed. Since they develop the kernel, they might have the same issues, and they might have solutions there, or not.