The frontends were copies of each other. The help was the same text three times, the chain that picks the screen to show was the same branches three times, and the SDL2 and SDL3 keyboards, joysticks and mice were the same files twice with the constants of each toolkit. frontend/shared holds them now: the view with what is on screen and the help, the keyboard with the codes of the Apple II keyboard and the commands of the emulator, the paddles with the four axis and the three buttons, the mouse, and the mixer with every sound source of the machine already attached. The frontends keep what belongs to their toolkit: the translation of their keys to shared.Key, the clipboard, the instance ids of the SDL3 joysticks and the file system Ebitengine hands the dropped files in. The drop targets take the drag over the window too, so a frontend only tells which drive the pointer is on. One implementation aligns what the frontends did differently, following a2sdl where they disagreed: - Ctrl with a letter was broken on a2ebiten and a2wasm. The key was already zero based and 97 was subtracted from it again, so Ctrl-A sent 160 and not 1. - The libretro core gets Ctrl-Left, the Delete of the Base64A. - a2sdl3 marks the drive under the pointer when the areas are shown with F8. - a2sdl finds the apple keys by scancode, so they work on the layouts where the alt keys produce another symbol, and releases them when the window loses the focus. Both come from a2sdl3. a2ebiten keeps Ctrl-F5 for the readout of the speed it draws on the corner of the screen, the only key that does something else anywhere. The mouse leaves the pointer where it was on a window without size instead of dividing by zero, which SDL3 can report when asking for the size fails. What needs no machine is tested: the codes of the keyboard, the paddles, the mouse and the drive the drop targets mark.
2.0 KiB
The SDL3 frontend
a2sdl3 is a2sdl on SDL3. It does the same things, with the
same keys, the same diskettes dropped on the window and the same joysticks. The
difference is in what it takes to build it: it uses SDL3 through
go-sdl3, which needs neither cgo, nor a C
compiler, nor SDL developer files. SDL3 itself travels inside the binary, and
is extracted to a temporary directory while the emulator runs.
It is experimental and it is not in the releases, which stay on SDL2.
Building
On Linux, MacOS and Windows alike, with nothing installed but Go:
git clone github.com/ivanizag/izapple2
cd izapple2/frontend/a2sdl3
go build .
As there is no cgo involved it also cross compiles, so a single machine can build for all of them:
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build .
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build .
The resulting binary carries the SDL3 library for the target platform, so there is no DLL to copy next to it.
Running
casa@servidor:~$ ./a2sdl3
The same command line as every other frontend, see command_line.md. Press F1 for the help.
Keys
The same as a2sdl, including the paste with Shift-Insert or Cmd-V and the Open-Apple and Closed-Apple on the alt or option keys. Both frontends decide the keys with the same code, so they answer to the same ones.
What is different from SDL2
Nothing that you use, and a few things underneath:
- SDL3 reports a file being dragged over the window, so the screen with the areas of the drives it can be dropped on is shown while it moves, with the one under the pointer marked. SDL2 only knows about the file once it is dropped, and has to show the areas with F8 or after the drop.
- Ctrl-C on the terminal quits the same way as closing the window, releasing everything on the way out.
- The scaling of the picture is a property of the renderer instead of the global hint SDL2 uses.