Porting to AmigaOS4 thread

@Raziel
4)GCC 11 should be C++-20 compatible, but you need a stdc++ library that is C++-11 compliants... , did you remember to specify -std=c++11 as argument? (if I remember correctly GCC 11 should default to either C++14 or C++17. so my guess is that the link stdc++ library is not compatible with c++11(+), I don't know if amiga supports STLport which is one way to get higher stdc++ compatiblity. Steven Solie did a port, but it is ancient (2004, but might support C++11)... it was said that STLport would stop being updated after C++14 or C++17.
C++11 should be supported in anything above GCC 4.x.

@Raziel

Quote:

Quote:

When building stuff targeting OpenGL 1.x/2.x you could try to use GL4ES SDK.

Depending on game/app you'll get varying results. It can become a bit challenging to get the used shaders OpenGL ES 2.0 comaptible. Sometimes this can be as easy by simply changing some GLSL specific version and syntax. Sometimes some changes to game/app code to control the modified shaders.

You can easily check shaders for compatibility (before touching the main project at all) by using the glslangvalidator cli utility.

The main downside when using GL4ES is the missing backward compatibility to MiniGL - which is imho completely relativated as newer projects are more demanding and therefore require perfomance levels which cannot be archived using (currently) available MiniGL solutions.

@trgswe

Thank you, no, i missed that, but i will try with that option

@IamSonic

The whole point of me wasting time with that cross-compiler setup is to get a shared library of that special SDL2_gl4es, to be able to build ScummVM with gl4es, since i cannot use the static one provided by kas1e.

Mixing static and shared does'nt work and i need the shared one for my project to even begin thinking of supporting gl4es (or even being able to build it).

I wouldn't drop MiniGL builds for the forseeable future, at least not as long as one has to pay for gl4es support.

Right now i'd only like to try and see if gl4es support does really have the impact everyone is giving it credit for, but i'm already running against a wall with the simplest first steps...maybe i'll just give up on it and let it go.

There doesn't seem to be much demand for ScummVM nowadays anyway...

@Raziel
personally I think you are wrong! the problem is that ScummVm 2.0 for many was pretty much what they expect from
it. it handles lucas arts games, sierra-on-Line games and some other ones like simon the sorcerer and Discworld. the 3D /2.5D games might spark a new interest in adventure games (and scummVM) but I think it is early days for that and it will need a couple of revisions/versions before it is stable.

@Raziel

There is a extension for visual studio code which has gcc 11.x, so when you Install it it Installs gcc,gdb, make etc only trouble is that it is for amigaos <4.x maybe he can do a 4.x version if enough people request it?!

@trgswe

Thank you.
I managed to set up a working cross-compiler toolchain with gcc11.

I have problems with compiling now, especially building shared libraries on that cross-compiler.

Maybe someone who does that more often has some hints...@MickJT?

@all

Maybe someone can help me try to understand this.

I have tried to port some stuff (mostly unsuccesfull) some projects do build, but only as static.

My question now is:
Why do some projects *can* create shared objects of libraries (e.g. SDL2), while others can not (mostly failing with below information during configure)


Are shared libraries locked because of the projects code (using stuff that is not supported in shared builds), or is the project simply too old to know that AmigaOS has moved on to support .so's in the meantime?

And if the latter, how could i force it to do shared builds /w/o rewriting the code)?

Tia

did you pass "-use-dynld" in LIBS/LDFLAGS? because it is needed from configure to understand that OS4 supports shared objects

@afxgroup

I didn't check for that.
I thought that it's mandatory for shared libs and will always be part of ldflags.

Probably not...need to check for -fPIC then aswell

Thanks

usually configure has enable-shared flag but this doesn't enable "-use-dynld" because doesn't know anything about this. But this add "-fPIC" for sure.

Hello all,
I am experimenting the last couple of days on porting an application to AmigaOS 4. It is written in C and Lua, and uses SDL 2 for the window and drawing. This is the first port I am doing and especially something that uses SDL.

I managed to make it compile and run, but it is still very premature.
When I run it all the colours are off, and you can see that in the image below. That should be dark grey but it is blue :D

I assume this might have to do with endianess, but I am not sure what to check for. I checked if there is RGB specified somewhere on SDL code, but didn't find anything.

Also, when I resize the window, it seems the graphics are broken.

What I would like for now guys, is to ask you if there are any SDL defines that I should use or if you could point me in the right direction to understand where the problem is.

@walkero

It could be that application makes some assumptions about bitmap format without checking its parameters. Are sources online somewhere?

@Capehill
Thank you for your reply. Yeap, you can find them at https://git.walkero.gr/walkero/lite

@walkero

Okay, so application seems to assume a 32-bit frame buffer in BGRA format. What is your screenmode?

https://git.walkero.gr/walkero/lite/sr ... gaos4/src/renderer.c#L316
https://git.walkero.gr/walkero/lite/sr ... igaos4/src/renderer.h#L10 // RenColor

You could try to change RenColor struct internally to test but it's a hack.

Proper way would be to inspect surface's pixel format and adapt to that when writing R, G, B and A values.

Another issue seems to be the stride/row length based on your image. Application should use SDL_Surface's pitch field instead of width because bitmap might be wider than requested width in reality.

https://wiki.libsdl.org/SDL_Surface

@Capehill
Thank you for taking a look that fast. The screenmode I use is 32bit.

I think I understand what you mean. I will try to make it work based on your proposal.

@Capehill
I put some output at the
https://git.walkero.gr/walkero/lite/sr ... h/amigaos4/src/renderer.c
and the lines
Lines 278-298

That function seems to be the one that renders the different rectangular boxes inside the app window, creating the backgrounds of the different sections.

the "DBG: rect" below are the dimensions of it's rectangular
the "DBG: surf" are the RGB values of the surface after line 289
the "DBG:" are the RGB values of the color that is in the method args



If you check the RGB values, all of them are different shades of grey. The output I get at the window is blue though.

I checked the blue screen colour values and seems like the blue gets the value of the alpha, i.e. R: 32, G: 32, B: 255. But I don't see something like that in the above output.

I checked all the SDL methods that are used in the application and didn't understand which one is responsible for drawing something on the window, and if there is a parameter I should use to change the Color mode of the app. I am not experienced with SDL library and still investigating though.

Is what I am doing wrong? Is there a method that I should check first?


Below is the same output from my Linux system

@Capehill
Managed to get some better results by changing



https://git.walkero.gr/walkero/lite/sr ... gaos4/src/renderer.c#L294

with








How does it look to you? Is there something else I should do?

@walkero

Application gets pointer to bitmap data and writes pixels there directly:

https://git.walkero.gr/walkero/lite/sr ... gaos4/src/renderer.c#L289

https://git.walkero.gr/walkero/lite/sr ... gaos4/src/renderer.c#L272

To get resizing working, probably at least some of those surf->w should be changed to surf->pitch/4 (for 32-bit). But I didn't read code very deeply.

@Capehill
Thank you so much for your help... Without your help, I wouldn't have that progress. Will check the resizing asap.

Has anyone ported reproc (https://github.com/franko/reproc) before and could share with me? If not, is there something else I could use instead of that?