Raylib on OS4 (originally v4.5.0)

I don't know whether this is a development topic or not really, but seeing as it's a dev library I'll stick it here.

[EDIT] For anyone who doesn't know, Raylib is simply another option for developing graphical software, most typically games. Think SDL but higher level.

For the last few weeks it's felt like I've been banging my head against a brick wall learning about newlib, clib2, newer clib2 by afxgroup, warp3D, ogles2, openGL in general and I'm sure there's a tonne more. But bit by bit I was convinced I was nearly there with bringing up Raylib on OS4. I'd got close at one point with Raylib not just out and out crashing on me but instead gracefully telling me it didn't find the version of OpenGL it was looking for.

I cannot thank afxgroup enough for taking a look today and finally getting things over the last hurdle and I've just been playing about with Raylib v4.5.0 on OS4. It's not guaranteed bug free by any means at the moment and indeed right now I personally haven't built it with audio enabled. Partly because it was giving me errors and partly because I don't have any speakers attached to my Qemu OS4 machine anyway

I'll continue to look at it as I want to get the game engine I was involved in up and running on OS4. I hope it's OK to say that the WIP is pushed to a repo at afxgroup's GitHub page not surprisingly in an AmigaOS4 branch. It needs to be built against afxgroup CLIB2, and also GLFW from the same and GL4ES, again clib2.

It's a bit painful for me at the moment as Qemu with R290X GPU "passed through" is not exactly any kind of speedy thing, but it enables me to test that things work. I'm really hoping that my OS4 hardware will arrive soon. It's been a month now.

[EDIT] I nearly forgot - thanks also to walkero for his docker containers. Life would have been a lot harder without them.

@MartinW I've been following along on discord, but for posterity sake, would you be able to document how you got your dev environment setup, and what the benefit is of using clib2 vs newlib are?

I too have just come back to amiga dev after any years and I never got that full on in to dev setups/tool chains etc. I'm not using raylib, but am using opengl, gl4es, sdl2, mingl etc.

Any knowledge you can share would be greatly appreciated.

Thanks
Dave

@MartinW

Really nice work, I really believe if more developers came back, this platform can have been shiny beacon, small improvements here and there, can have a massiv impact on user experience.

@davec555

I'm not the best of people to explain the clib2 vs newlib situation. In this case the decision was largely made for me as Raylib is built on top of GLFW. It does have it's own fork of the official one in it's source tree but it's also possible to use an external one and afxgroup had an existing GLFW for Amiga OS4 that was understandably built using their new clib2. It's certainly possible to build a newlib version of Raylib and indeed it should be possible to use Raylib's internal GLFW (I've not looked at the differences in detail yet) but I haven't been successful in either of these endeavours yet. I will look at it again now that Raylib works. Ideally Raylib would be available for either runtime.

As far as I know the new clib2 produces smaller binaries and takes care of some of the things that you need to do yourself in newlib for you. But exactly what these are, I don't know - I'm not that much of a low level developer yet. I'm sure it's all documented somewhere.

As for the dev environment, it depends what you want really and which host you use. If you're running an Ubuntu-like linux and are in this for the long haul then it probably makes sense to build up your own cross-compiler environment but I'm on MacOS and use more than one machine so for me it made sense to use this container:

https://hub.docker.com/r/walkero/amigagccondocker

This is all more or less documented there but I'll go through it anyway.

That container pulls pretty much everything that you need including a whole bunch of packages from afxgroup's Ubuntu clib2 repository. If you're using Apple Silicon then you'll need to specify that you want the amd64 image which is a pain as it's probably 5 to 10 times slower at building and crashes if you try to use multiple make jobs, but while there is an arm64 version of the image, the clib2 repo only contains amd64 packages so you miss a lot of clib2 versions of things.

From there you just need a toolchain to tell cmake where everything is. Obviously if you're not using cmake then you're probably good to go with whatever makefile you're using. I'll create a gist with the toolchain in a bit. I have a really busy day today. But there is one linked in the discord chat somewhere not that far back.

I bring the container up with the following docker-compose:



So I have a folder in my home called "Dev/OS4" where this docker-compose lives. I have a "code" folder with all my projects and that is mounted into the container. Docker being docker, if compiled libs and the like were put into the SDK local folder as they normally would be, they'd be lost on restart so I've mounted a host folder to keep my stuff and added a bunch of ENV VARs to help me use them. Finally I mount a file to maintain bash history.

That's about it. Bring it up with "docker-compose up -d" and connect to it with "docker-compose exec -it <name> bash" and off you go. If I'm doing a bunch of source work then I connect through Visual Studio Code instead, sometimes I don't bother and just use the command line.

Hope all of that helps. I don't have a website or blog or anything like that these days, otherwise I'd be happy to write up more of my experiences. If there was demand and somewhere to put it, I could look into it I guess. I'm not a fan of the negativity that invariably comes along with it these days.

@MartinW

Congratulations on getting Raylib working on AmigaOS (albeit minus sound at this stage)! Nicely done.

MY apologies for my contribution to the confusing array of libraries. I'll do my best to outline how it all fits together.

Newlib/Clib2/Afxgroup's New Clib2

Newlib and clib2 are C runtime libraries that implement the C standard library. Clib2 gets statically compiled into your binary, while newlib relies on a newlib.library. This results in smaller binary files, because the bulk of code is in a shared library.

AFAIK, the intention was for newlib to become the *only* C runtime library. Unfortunately, that never happened. I'm not sure exactly why, but clib2 remained available, and there were some features that newlib missed (and vice versa).

Fast-forward by a decade or so, and both newlib and clib2 are missing features people want to aid porting software from the posix world. Some argue that POSIX compliance is beyond the scope of the C runtime libraries, but both newlib and clib2 already had some POSIX functionality. The newlib.library is closed source, so only Hyperion can update it. Those updates are rather slow to happen. The AmigaOS clib2 project suffered from having to support older versions of AmigaOS as well as OS4.

So, afxgroup created his own fork of clib2, made it OS4 only, and added the features that he and others needed.

Hence, we now have 3 C runtime libraries. They're incompatible with one another, so if you use newlib, then you need all static link libraries to be compiled with newlib as well.

Yes, it's more complicated than needed, but it's where we're at. I really wish we could get newlib brought up to standard, and make that *the* C runtime library that's usable for everything.


GL4ES Ogles2.library MiniGL Warp3D Nova, and Warp3D

Warp3D is the original 3D API for AmigaOS, and was based on the capabilities of 3D graphics cards of the time (e.g., no support for shaders or even hardware accelerated Transformation, Clipping, and Lighting (TCL)). MiniGL (and StormMESA) provided OpenGL 1.3ish compatibility. Performance was hampered by the lack of TCL and other problems.

Warp3D Nova is a (relatively) modern shader based 3D graphics system. It's incompatible with its namesake (Warp3D) out of necessity. There was no way to add shaders to the old API in an efficient manner. Instead, it's design is based on how modern GPUs work (with some inspiration drawn from Vulkan, and the original Warp3D).

Obviously, we need OpenGL compatibility. To get there faster, we decided the best path forward was to implement the OpenGL ES 2/3 API. Hence, the ogles2.library. OpenGL ES ditches a whole lot of old functionality that you shouldn't be using any more, making it much more doable. The plan was to use something like the angle library to get full desktop OpenGL compatibility on top of the ogles2.library. Kas1e found that the GL4ES project was a better fit.

What about backward compatibility for old software? I wrote NovaBridge for that. It provides the backward compatibility layer to let old MiniGL/Warp3D software work on newer graphics cards.

Unfortunately, NovaBridge is currently available as a separate purchase, so it isn't bundled in on all machines with Warp3D Nova capable hardware. So, the confusion I hoped to eliminate with NovaBridge remains. That should disappear in future, when it comes bundled with all new machines.

Development-wise, it's a bit messy because GL4ES is a separate download. Ideally, it would be bundled in with the ogles2.library and Warp3D Nova's SDKs, along with clear documentation.

In brief, here's how the libraries fit together:



NOTE: You don't have to use GL4ES. If the ogles2.library has everything you need, then use it directly. You could even use Warp3D Nova directly if you wanted.

The legacy graphics (lower half) should fade away over time.

I hope that helps clarify things.

Hans

@Hans
Need to add that since some time afxgroup's clib2 comes as shared clib2.library, and even as .so version too. So it have no point anymore to worry about newlib, which always will be bad choise when one need to fix something in it. Waiting years for public release of C library fixes its just unnaceptable anymore. IMHO. Even if Hyperion will made newlib opensource someday (which i doubt), its just too late for newlib.

@Hans never apologise for your contributions!!

That is another great read that I will sit down and digest this evening.

[edit] ps: I purchased 2 of your books on Friday night and am working through them. The OpenGL tutorial isn’t playing ball at the moment because I’m on Mac which has to be about the worst idea going. I’ll restart on either Linux or OS4 ASAP.

I didn’t get the book on the theory behind modern graphics as I felt it might be too low level for me at the moment. Maybe that’s not the right decision. I don’t know.

@Hans
Quote:I was even part of my newlib contract with Hyperion that support for clib2 has to be removed, since I didn't want to have a mess of different and incompatible C libraries like it was on AmigaOS <= 3.9 (libnix, ixemul, Lattice/SAS C, Aztec C, DICE C, etc.), but as anyone should know by now papers on which Hyperion contracts are written on are worth as much as used toilet paper...

Quote:Wrong, newlib is open source, only the very small AmigaOS parts aren't.
Creating a new AmigaOS 4.x port of newlib would have been at least 10 times less work than getting something halfway usable out of clib2.
Before I implemented the newlib port I found hundreds of bugs in clib2, and I very much doubt afxgroup fixed most of them. If I'll ever start any serious AmigaOS development again the first thing I'll do will be to do a new newlib port (estimated time required for libc.a and libc.so: 5-10 hours), incl. a newlib4.library (more work required).

I think that new clib2 has really few bugs compared the current newlib. The only part that is slower (not bugged) it is the I/O because the way was originally written. I've made hundreds of tests against Linux for old and new functions and at moment no bugs are popped out. Not speaking about the cleaning. Linux code (newlib one) is a mess. Clib2 code is way better than that.
Not only, but the most important thing, is that if a bug is found anyone can fix it. And of course this isn't valid for any OS4 version of newlib. Past, present and most probably future.

@afxgroup
Quote:Linux? 🤣
Like any usable AmigaOS C library always was, for example ixemul, it's based on the NetBSD libc, no GPL junk involved.
The main difference between newlib and the NetBSD libc is that newlib is easily portable, for example it's used in Cygwin as well, while the original NetBSD libc isn't portable. Similar to WebKit (not easy to port) vs. OWB (works on any OS with only very minor changes).

@joerg

Linux is bigger platfrom then NetBSD.

If 99% of the software we need Is ported from Linux wont it be better, to be more Linux compatible.

@LiveForIt
Most of Linux, incl. glibc, is GPL and therefore unusable for closed source software.
Linux has more users and developers than NetBSD (and OpenBSD and FreeBSD), but Android has more than Linux, and even Google switched from glibc to newlib in 2013 in their NaCl.

Closed source software is less frequent nowadays. Except maybe for games. That however doesn't have this problem because almost all of them is created through external platforms. I know that on Amiga platform the people think that closed source is still the best solution. But fortunately 99.9% of the world doesn't. And if wasn't for newlib, owb and all other libraries most probably we where stuck on a closed source browser with iff support and nothing else... Same for morphos an all other minor platforms. Android included..

But hey, Raylib!

Just saying 😂

@joerg

Is most library distributed under LGPL, to allow to be linked with closed source games, programs etc.
I agree other license, like MIT makes more sense.

@afxgroup

I think close source is good when developers are paid, when developers can focus all the time on project instead of dividing there time up between day work, and hobby work.

if its not your lifeline, perhaps its not as important, you take your time on it, not feeling pressure to complete it.

On the other hand, see some developers are good at cooperating on things, that’s is good a about open source.

Perhaps contracts should have a clause, if contract is broken, the source code should be open sourced.

Of course. But who is paying in Amiga Land? Should be better to release sources so any other developer can learn something? We are a small community. Closing the sources is the worst thing can happen

Closed source is main reason why amiga os environment has never growth.
Sadly even in these dark days major part of apps and 3rd parts of system components, like libs and devices, are still closed source.
Even firmwares of death mainboards are closed source and don’t let compatibility with modern hardware.
I.e. pegasos 2 buggy firmware who don’t like many usb keyboards and any Radeon rx cards.

@flash

Yeh, split between old 3D and new 3d is not good in a tiny market, at least Hans is working on improving the kernel to support proper PCI scanning. Its not chocking, that the Pegs II port was quick and dirty when so few that owns Pegasus II’s. Even if did support RX/HD. it does not solve the slow bus speed problem, its only 66Mhz bus, unless its under emulation that is.

@joerg

Quote:

I'd certainly welcome an updated newlib. However, if it's incompatible with the existing one, then we end up with an even bigger mess: 4 incompatible C runtime libraries.

The key problem we've had with the runtime libraries, is that the small closed-source part means that only Hyperion can update it. And, Hyperion haven't been able to update it in line with what developers need. If newlib had been updated with full POSIX compliance (or at least the most needed bit), then I doubt anyone would be using clib2 let alone creating their own forks.

Hans