Hello,
Thanks to @jamesnvc post: For fun: rushhour game - #6 by jamesnvc
I went back and cleaned up my SDL bindings, porting to cmake + SDL3: GitHub - kwon-young/sdlpl: SWI-Prolog bindings to SDL · GitHub
I have working Pong game example !

Here is the code: sdlpl/examples/pong2.pl at b011fcfb92e7b19d6370f1e8130edbf577d3757c · kwon-young/sdlpl · GitHub
I also made a wanabe qml like api: sdlpl/prolog/qml.pl at b011fcfb92e7b19d6370f1e8130edbf577d3757c · kwon-young/sdlpl · GitHub
with some demos: sdlpl/examples/qml_demo.pl at b011fcfb92e7b19d6370f1e8130edbf577d3757c · kwon-young/sdlpl · GitHub
The actual SDL bindings are here:
- cpp bindings: sdlpl/sdl.cpp at b011fcfb92e7b19d6370f1e8130edbf577d3757c · kwon-young/sdlpl · GitHub
- light prolog overlay for type safe and convenient flags: sdlpl/prolog/sdl.pl at b011fcfb92e7b19d6370f1e8130edbf577d3757c · kwon-young/sdlpl · GitHub
@jamesnvc if you had such bindings availables would you have used it for your own ECS framework ?
The idea when creating the bindings was really to keep a 1 to 1 mapping with sdl api.
The only differences are:
- SDL handles are put in interdependent blobs, so it is memory safe and garbage collection safe.
- SDL flags are translated to user readable atoms.
- everything is type checked through
library(error)with must_be, even blobs and flags.
@jan would you consider the inclusions of such bindings into swi-prolog itself ? one major advantage would be that user could experiment writing gui applications in prolog without having to install a c/c++ compiler.
The bindings are currently really bare-bone and ideally, we would also have bindings to cairo and pango to be able to draw more complex forms and write text.