SDL2 or Libretro backends

[vanfanel]

Hello there, Josh!

I am very excited over this AMS project of yours, I read about it on hackaday yesterday! So I have been trying it, and it seems to use the old fbdev graphics backend. Would it be possible that it gets an SDL2 or LIbretro backend? That would allow CPU-free screen scaling using the GPU (particularly useful for Raspberry Pi setups with no Xorg running at all!) via underlying GLES2. You don't have to program GLES2 or KMS/DRM (modern Linux framebuffer), you just port to SDL2 or Libretro, and you get free support for a LOT of systems in a modern way.

Libretro in particular would give free supports for shaders. But SDL2 would be more than enough! :) What do you think?

[jjuran]

Since Advanced Mac Substitute is focusing initially on monochrome applications, shaders might be slightly overkill. :-) Also (my work in progress on the Vertical Retrace Manager notwithstanding), AMS doesn't really have a concept of video frames, so this might be an impedance mismatch with libretro.

I agree that a higher-level front end is desirable. That said, right now there are even higher priorities for me, like proper application packaging and distribution. But in the meantime, I invite you or anyone else to take a look at interact-linux and display-linux (in graphics/) and have a go at converting them from fbdev + /dev/input/mice to something else.

Finally, try setting DISPLAY_FORMAT=fullscreen on a Raspberry Pi — fbdev uses the GPU for scaling.

[vanfanel]

@jjuran : Shaders provide scanlines and screen curvature, too, which would mimic a Macintosh screen pretty well, so it's not only about colors! So, from what I understand, you're trying to implement framerate control? Ideally, framerate should exactly match the physical screen refresh rate instead of being forced to 60.0000Hz or something like that: libretro's frontend, RetroArch, provides physical screen refresh rate detection, so games are smooth on, let's say, 60.0168Hz screens, while it also takes care about audio resampling to match the physical screen refresh rate.

[jjuran]

Ah, good point — it would be nice to mimic CRT blur and phosphor delay. But those kinds of bells and whistles are less important than literal bells and whistles from the Sound Driver. :-)

Vertical retrace interrupts are a complex topic. Originally, the refresh rate was 60.15Hz. With the Mac II came NuBus graphics cards, Slot Manager, and other refresh rates. If you call SlotVInstall(), your task gets called at the appropriate rate. Whereas classic VInstall() remained 60.15Hz for backward compatibility.

But not all games use interrupts at all. Classic games from 1984 often loop until Ticks advances. Nyan Cat is newer and calls WaitNextEvent() for timing. Some games are turn-based, and some applications aren't games at all. Running down your phone's battery while Solitaire waits for you to make a move isn't acceptable. Managing the power consumption of time-polling applications is a complicated balancing act.

The first step is creating a new front end alternative to interact/display that reads the same shared graphics buffer and produces a SPIEL event stream. Streamlining AMS into a single binary and fine-tuning performance will come later.

[probonopd]

it would be nice to mimic CRT blur and phosphor delay.

Check out whether it can be hooked into https://github.com/Swordfish90/cool-retro-term :-)

[vanfanel]

@jjuran What about moving from FBDEV to KMS/DRM on GNU/Linux? FBDEV is too primitive: with KMS/DRM, you could get full-screen scaling to any resolution for free, perfect screen synchronization, and every system supports it nowadays (it's what fbdev used to be, just better).

But, I must say, porting to SDL2 solves the same problem even better, because SDL2 itself supports KMS/DRM but ALSO you get AMS to run "for free" on any system running SDL2, which is not restricted to GNU/Linux: it would automagically run on current Mac OSX, IOS, Windows, and modern consoles, among other! And you get CPU-free fullscreen scaling too.

[jjuran]

I'm open to working with someone who wants to create a front end for either KMS/DRM, SDL2, or both. :-)

[vanfanel]

"Working with" includes a direct way to ask A LOT questions about the code so I could hook up an SDL2 blackend? If that is the case, I may do it. But I need that: a way to ask many many questions about where complete frames are produced (so I just have to upload them to SDL2), the buildsystem so I can easily add the new source files, etc.

I believe SDL2 is a better idea and is way easier to maintain.

[jjuran]

It would be great to have you as a contributor. :-)

Most discussion of AMS development occurs in #mac68k on Freenode.

As front ends are distinct components, there's no requirement they use the same build system as the back end. However, it does need to implement the protocol. You can use as much or as little of the existing infrastructure (like exhibit) as you want, though you'll probably need the rasterlib library at least. Take a look at apps/mac/Amethyst for an example of a front end that doesn't use exhibit/interact and is more self-contained.

[vanfanel]

@jjuran Still wanting to see this, so I am giving it a try.

For an SDL2 backend, should I use https://github.com/jjuran/metamage_1/blob/master/graphics/display-fbdev as a template/example?

[jjuran]

Sure, display-fbdev demonstrates the raster update loop, as well as transcoding 1-bit graphics (in case that's needed). Also look at interact-fbdev, which is considered the fbdev front end, although much of what it does is launching other programs (including display-fbdev, as well as programs to read the mouse and keyboard device files and generate serialized input messages).

A more self-contained example is interact-x11, which does all of that without any helper programs.