SDL

[danboid]

I'm sure most everyone here will be familar with SDL already but for anyone who doesn't know what it is:

"Simple DirectMedia Layer is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D. It is used by video playback software, emulators, and popular games including Valve's award winning catalog and many Humble Bundle games.

SDL officially supports Windows, macOS, Linux, iOS, and Android. Support for other platforms may be found in the source code.

SDL is written in C, works natively with C++, and there are bindings available for several other languages, including C# and Python.

SDL 2.0 is distributed under the zlib license. This license allows you to use SDL freely in any software."

SDL, 1.2.x, at least, got ported to 68K Amigas and RISCOS so 16 bit machines with non-POSIX operating systems can handle it but do we think that it might be possible to port SDL to the X16, if only maybe for those with 2 MB RAM?

The first game that comes to mind for me that would be ideal for a X16 SDL port is the SDL/C Barbarian remake. I have posted the source to that on the Uzebox forum:

https://uzebox.org/forums/viewtopic.php?f=5&t=11187

I'm sure there are many other SDL games out there that could be easily ported to the X16 if it had a SDL port.

[TomXP411]

That's pretty unlikely. SDL is far too big to be contained in the X16's available memory.

That's not to say you can't borrow some SDL techniques to get started, but based on what I've seen of SDL, it's a lot more complex and really designed around the way modern GPUs deal with things. Trying to port that to an 8-bit environment like this would leave so much out that there'd really be no value in doing so.

[kelli217]

What Tom said.

While the X16 is quite sophisticated as 65C02-based systems go, it isn't that powerful. It's closer to, say, an XT with an early VGA card in it and a SoundBlaster. And while I know there's someone working on a DOS port of SDL (at least, there was back in 2020), I don't think it targets an XT-class system, nor even original AT.

[DragWx]

The X16 already has kernal calls for handling certain things like disk access, and joystick/keyboard/mouse input, so those are some nice things out of the box that a dev could use in place of SDL's equivalent functions.

I'd anticipate what a game developer working in C would need after that is, some kind of memory manager so assets can be arbitrarily located/accessed in high-memory (between banks, etc) or VRAM, and some way to "blit" things to the screen (more likely just converting it to sprites and tilemaps, just thinking about how Amiga -> Sega Genesis ports usually worked). This is probably what a helper library for CC65 would need to supply (unless the kernal is more sophisticated than I thought?).

Sound is weird because it happily operates in a vacuum, so more often then not, it's just a blob of code and data that you literally drop into the project and you're good to go. Most of the work would come from rewriting the music and sound effects for the new music engine.

The fact that a game uses SDL might make it "friendlier" to convert over to an X16 library, but I agree that we're likely not getting an SDL runtime environment on the X16 anytime soon, but I'd love to be proven wrong.

[TomXP411]

I'd anticipate what a game developer working in C would need after that is, some kind of memory manager so assets can be arbitrarily located/accessed in high-memory (between banks, etc) or VRAM, and some way to "blit" things to the screen (more likely just converting it to sprites and tilemaps, just thinking about how Amiga -> Sega Genesis ports usually worked). This is probably what a helper library for CC65 would need to supply (unless the kernal is more sophisticated than I thought?)

I've been pondering a software library for these kinds of things. We've been talking about directory listings in the DIscord, but block copies of graphics rectangles is another useful thing to tackle.

Sound is weird because it happily operates in a vacuum, so more often then not, it's just a blob of code and data that you literally drop into the project and you're good to go. Most of the work would come from rewriting the music and sound effects for the new music engine.

I think we already have a sequence player; what we need is an easy way to encapsulate and invoke that in a C program, along with a way to feed it data. Ideally, a tracker written for the X16 would be nice, along with an IRQ routine to play back files in other programs.

[TomXP411]

Also... this is very much a volunteer community. See a need, fill a need.

We're happy to take "toolbox" contributions at the Demo repository; let me know if you're interested and I'll set up the file structure for that (create a directory named "toolbox", then "graphics" for your contribution.)