[WIP] Small Abstract Fish

Hello, this is me.

I’ve started an experimental project: SAF (Small Abstract Fish). It is like a super simple SDL for open consoles, it is a suckless portable interface, you can even see it as a fantasy console. It should prevent the pain of always having to port games between platforms: with SAF you write the game once and can immediately compile it for Pokitto as well as other consoles like Arduboy and also PC, web browser etc. Basically generalizing what I’ve done with Anarch.

Some basic features of the SAF console:

  • 64 x 64 pixel 256 color display (332 palette) running at fixed 30 FPS.
  • 8 buttons.
  • Simple speaker.
  • 32 bytes for save/load.
  • Built-in 4x4 font (the one from Anarch).
  • Resources (RAM, CPU frequency, cores, …) are not limited.
  • Of course everything will be in a single header, CC0, super simple. There will be all you need for simple games (image drawing, sin/cos etc.).

There should be more advantages, for example I’ll create a script that will be able to merge multiple SAF games into one program that will let you choose which one to play from the menu. I can also add functions that emulators have (time manipulation, demo recording etc.).

Don’t know where it will go or if I abandon it but I am sharing to get some ideas and feedback. It is not usable yet but most functions are implemented already.

I’ll create some example programs if this continues so a byproduct should be a few simple games and programs.

It lives here:

Thanks :slight_smile:

9 Likes

This concept is great! I seriously hope you do continue to work on it.

I think for my small level of experience, seeing some examples will definitely help with the types of feedback I may provide :smiley:

2 Likes

Another advantage I just realized could be that SAF might support other languages than C/C++. That is because SAF programs are advised (not forced but expected) to use no libraries besides SAF so transpiling from another language to C wouldn’t be complicated by needing to also bring over the libraries, it would just need to translate the code to C.

Dynamically typed languages would be challenging – not that it wouldn’t be possible, but tranpilers translate these to a code relying a lot on malloc and other potential performance/compatibility killers.

Anyway let’s say it’s doable. Suppose e.g. Pascal:

  • I’d implement the SAF interface in Pascal using whatever multimedia library is available for Pascal – this is easy. Now you can write and test SAF games purely in Pascal.
  • When you have a SAF game written in Pascal and want to port it to Pokitto, you transpile it to C and the calls to Pascal version of SAF functions should translate exactly to calls to the C version, and now you have a C version of that game.

I’ve been checking the transpilers and indeed there even exist JS -> C ones: ts2c. There’s a live web version and it seems to generate nice code, only creates huge boilerplate if you actually utilize dynamic typing, otherwise the code is very cool. Also I’ve found wax and I really love it: it’s a “boring” (in their own words) language without any fancy features designed exactly so that it can compile to basically any other language, and it is written in C – very awesome.

2 Likes

You don’t necessarily need a transpiler. If you compile to a static or dynamic library then a lot of languages can just hook onto the library as long as it follows the expected calling convention (usually cdecl).

I know for definite that C++ and C# can do this because I’ve used them for that before. (E.g. I once wrapped a large chunk of SDL2 in a C# wrapper, though I never published it.)

I think Java and Haskell can too. I’ve never actually attempted to use their foreign function interfaces so I don’t know the ins and outs, but I’m acutely aware of them.

Nim ‘compiles’ to C anyway, so that’s probably fairly simple to hook up. (Someone managed to write an Arduboy game in Nim once.)

Yes that’s an option too, I wanted to try that in the past with Haskell + Pokitto but didn’t finish that. But then I’d have to deal with each specific console/platform as each has potentially different processor = compiler, which is an issue I am trying to solve with the project, so I would contradict my effort. Basically I’d like to use C as central language to connect a number of different languages with a number of platforms

language A  \   / platform X
language B  - C - platform Y
language C  /   \ platform Z

test program:

saf

9 Likes

Wow. My excitement definitely is beginning to grow :grin:

1 Like

Should we organize a small jam?

5 Likes

I appreciate the effort to make one lib that can be used for games and just recompile for different platforms. However, I am not a fan of using a letterbox in already a tiny Pokitto screen even if the lib probably uses the low-res mode in Pokitto.

How about having two panels, vertical and horizontal, which could be used for showing stats (and maybe the name) of the game? If the screen HW has enough extra space, the panels could be a separate areas, outside the game screen, with a black background color. Otherwise, the stats panels would be a transparent layers over the game screen. Then there should be an info struct which tells how “important” the panel is, e.g. can it be left out instead of layering over gfx.

2 Likes

Creating a system of sidebars in the vanilla version would be adding complexity, I want to avoid exactly these kinds of things. However each platform can choose what it will draw in the empty areas. I also have a special function in the API for extending SAF functionality that could allow e.g. access to file system even if “vanilla” doesn’t support that, so some kind of sidebars could be added as an extension via this later. On Pokitto I’ll try to experiment with scaling the screen as much as possible to leave only small area empty.

Awesome idea! But let’s wait if I actually get this to some usable version xd

4 Likes