@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.
Our OpenGL is kind of v1.3 based, correct? What features does it lack? e.g. does it support shaders too (like ogles2?)
Quote:
MiniGL lacks frame buffer objects (FBOs) and shaders.
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.
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...
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
@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.
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?!
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?
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
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)
*** Warning: inter-library dependencies are not known to be supported.
*** All declared inter-library dependencies are being dropped.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
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
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
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
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
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.
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.
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?
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?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
