It looks like you're new here. If you want to get involved, click one of these buttons!
Is there any way to have Orx built on SDL2? Or is it too difficult to abstract the low-level audio and video?
Hi Lamper, welcome here!
SDL 2 is certainly on the backlog: https://trello.com/c/yGJuRRJq/35-investigate-sdl-2
There's been some chatter on and off about SDL 2 plugins for Orx since 2017, one reference is https://gitter.im/orx/orx?at=57d35298b37816b14fa5f38d
An advantage would be Orx on the Raspberry PI 3.
Hi @lamper and welcome here.
As @sausage already pointed out, the abstraction is already there, the implementation isn't though. Back in the days we had SDL 1.2 plugins but they got obsolete and I removed them.
Out of curiosity, for which target platform would you need SDL2?
Thanks for the replies, @iarwain @sausage!
My platform is ARMv7, using an Odroid SBC. I tried to keep things minimal, so there's no X Windows/desktop environment. It uses an accelerated driver and I have the primary SDL2 libraries installed (SDL2, SDL2Image, SDL2TTF, SDL2Mixer). That means there is full support for audio, video, input.
I've used Orx in the past (on Windows) and I liked it. If I can find a way to get it to work, that would be great. It's certainly preferable to writing a game engine from scratch. Being able to build on SDL2 would add a lot of portability to Orx (including the RPI3, as @sausage noted).
So yes, it's definitely doable, there are 4 of the 7 plugins that would need to be ported: Display, Keyboard, Mouse and Joystick.
Display being the one that will require the most work, all three others are rather short.
One could look at the latest version of the SDL 1.2 plugins as a base to start, even though they're probably quite outdated by now.
Another option would be to start with the GLFW plugins and replace GLFW calls by their SDL2 equivalents.
Until last year we had some RPI defines in orx's core to get proper setup of all the internal defines, I could bring them back along some ODROID ones, but I do not have any hardware on which to test any more.
Oh, as long as we're on that topic, does Odroid have some OpenAL support? If not, the SoundSystem plugin might require some porting work as well.
If it came up in the priority list, I'm sure the community could organise a RPI3 for whoever could pick up the SDL porting.
@iarwain It does have OpenAL support (at least, in the OS version I'm using). However, with some work, Orx could use the SDL2 audio subsystem, right? That would probably increase portability but I'd probably start with OpenAL to get a test version working.
I'd volunteer an Odroid, if that helps. Whoever got it would probably want the OS image I made. It seems like it was a pain to get SDL compiled with just the right drivers but I don't remember, now.
So I'd recommend going with OpenAL first in that case.
Regarding SDL audio, back with SDL 1.2, doing any audio work that requires anything beyond the most straightforward sample playback was either very difficult or very unreliable. I do not know in what state the audio subsystem is with SDL2, but a quick search hints at very little progression on that front.
In any case, there's always SoLoud that has all the features orx needs (and more) and that ships with a SDL 2 backend out of the box, so that'll always be an option as well.
Ah, good to know. And when you talk about audio with SDL, do you mean including SDL2_Mixer?
I meant to not use SDL_Mixer which had a lot of shortcomings in 1.2 that haven't been fixed in 2.0 apparently. So SoLoud will be used instead and use SDL's audio low level API as backend.
Understood. Thanks for the clarification! It sounds like SoLoud is the way to go, then (if we want to stay within the realm of SDL2).
I've been wanting to try SoLoud for a couple of years now, so that might just give me the motivation to finally do it.
It looks like quite a nice sound API with a lot of out-of-the-box backends and I know that it was used with commercial games on all current gen consoles as well, so writing console-specific backends was probably a straightforward task and might prove useful if one day someone decides to use orx on those platforms (a past project was targetting the Vita a few years ago, but I don't think it ever got released unfortunately).
If no one has the time, I will try to have a look at SDL2 during my summer vacations, but that won't be before another 1.5 month.
Cool. I'll post updates, if I make progress. If you want the Odroid to test out, let me know.
Ah no worries, thanks for the offer, but maybe if there's a way to remote connect to it later when I have something in order to test, that'd be nice, but I don't need to have the actual hardware with me, it's unlikely I'll use it beside working on the plugins port.
I would like to see if I can deal with the platform, first. @iarwain How can I get the build system to work on ARM? I need to start with a compatible build of code/build/rebol/r3-linux but I don't know where to get that. Is there sourcecode for that I can compile?
I've never compiled Rebol 3 for Linux/ARM, but here's the source repository I've been using: https://github.com/orx/r3
I also found this with a quick Google search: https://ameridroid.com/blogs/ameriblogs/how-to-new-update-of-rebol-3-scripting-language-for-arm-boards
Gah. This thing is a disaster. There are multiple versions of everything - documentation, source, binaries, etc. etc. Nothing seems to add up.
The ARM versions are out-of-date. One is 2014 and the other is 2016. Both fail with their provided scripts. The link to the CMake instructions points to nothing.
Note: The build process is much more complicated than it should be
Note: The build process is much more complicated than it should be
Thanks for the link to Ameriblogs. That build was recent (2018) but still threw an error when I tried it. They provide yet another fork (!!!) of the source. The instructions don't make a lot of sense and don't work, as they're written. It also apparently needs SDL for some reason (???). I'm stuck right now with a build error where it fails to find SDL.h, even though it's in the standard location for Linux.
Isn't this supposed to be generating build files for Orx? Can I just write a Makefile for Orx and skip this mess? I don't need "R3" for the engine, do I?
You should be able to cross-compile it, there's a short HOWTO.md I wrote in the root directory of my clone (the one I linked earlier) that mentions it.
I grepped its source file for SDL.h and didn't get any result. Where did you see this dependency?
R3 is only needed for the setup and init scripts.
The generation of the build files are handled by premake, which you'd also need to compile for your target if you want to use it there (orx's dependencies repository lives at https://bitbucket.org/orx-extern), and the latest of this repository is what is fetched by setup.
What I did when I started porting orx for RPi was to simply cross-compile from a linux box instead, which is also an option.
Quick update: I updated all orx's script to use the latest from ren-c/r3 and upgraded all the binaries as well.
That means you can compile the latest from https://github.com/orx/r3 and it should be more straightforward than the earlier version.
If you're on linux/osx, to compile the bootstrap it's a matter of calling ./make.sh and that should be it.
Then you can copy build/r3 to your home.
After that you can easily cross compile by adding a config file in the configs folder. For testing aarch64, I added a file named test.r in /configs with the following content:
ld %aarch64-linux-gnu-gcc ; Linking is done via calling gcc, not ld
and called it with ~/r3 config: ../configs/test.r
~/r3 config: ../configs/test.r
As a result, I got an aarch64 binary as build/r3.
Hope this helps.
@iarwain without checking myself, is the repo readme updated to reflect the changes for linux/osx?
The HOWTO.md file is up-to-date.