It is indeed pretty superficial

Looks something like this:

(Apologies in advance for what blog formatting does to the erlang syntax).

-module(canvas).
-compile(export_all).
-define(WIDTH,640).
-define(HEIGHT,480).
-record(sdlmem, {type, bin, size}).
-define(_PTR, 64/unsigned-native).

go()->
setup().
setup()->
case catch erl_ddll:load_driver("../priv", "sdl_driver") of
ok -> ok;
{error, R} ->
io:format("Driver failed: ~s ~n", [erl_ddll:format_error(R)]);
Other ->
io:format("Driver crashed: ~p ~n", [Other])
end,
Port = open_port({spawn, "sdl_driver"}, [binary]),
register(esdl_port, Port),
cast(21, <<0:32/native>>),
io:format("Connected to C through Port: ~p~n",[Port]).
cast(Op, Arg) ->
erlang:port_control(esdl_port, Op, Arg),
ok.
call(Op, Arg) ->
erlang:port_control(esdl_port, Op, Arg).
send_bin(Bin) when is_binary(Bin) ->
erlang:port_command(esdl_port, Bin).
send_bin(#sdlmem{bin=Bin}, _, _) -> send_bin(Bin);
send_bin(Bin, _, _) when is_binary(Bin) -> send_bin(Bin);
send_bin(Term, Mod, Line) -> erlang:error({Mod,Line,unsupported_type,Term}).

That's hardcoding every constant that they generated for esdl, and inlining a whole bunch of stuff that they rightly had in separate files. I'm thinking at this point, though, that there's no point erlang being the one to drive the gl. For one thing, all the other devs on my team are going to want to have documentation resources available to them for the gl work they have to do, and it's all in C. All of it. Which I guess makes sense because as far as I know OpenGL itself is in C.

So. Design decision now is, do I have a high level or a low level API for my erlang stuff? I really don't want Erlang specifying vertices, for instance. I'm much more inclined to build a detailed stroke object with color, pressure, timestamps etc., serialize it down to C and let it throw away the information it doesn't care about (which isn't much really) as it turns it into GL code. The cool thing about that would be that if there's another rendering engine which isn't OpenGL (say, for instance, a JS implementation in-browser or a superfast DirectX one), the erlang client wouldn't need to change anything.

Yah, that's pretty much the decision made for me, I think. Although I do think that I might accept more detail than I send. Maybe the API would look something like this:

C Rendering front End
---------------------
Stroke begun(Point)
Stroke point(Vertex,Pressure etc)
Stroke ended()

Erlang Client
-------------
Render(Strokes, Children, Whatever else I can think of)

Anyway, that's a start. And a lot simpler to deal with (although much less powerful) than the whole big ESDL kit and caboodle. Much credit to Dan for his work, just not worth the porting effort for the 1% I'm actually going to use.

Damn.

Well, I give up on the way I was doing it. The problem isn't SDL 1.3 at all. The tests accompanying that are fine. It's this effort to port ESDL over to 1.3 for the bits I need that's going nowhere. I'm not convinced it's the way I want to do it anyway.

Now, I don't know much about this stuff, but wouldn't it be cool to have a rendering model where every erlang process took responsibility for maintaining its own render state? Maybe? Sort of objects in the old sense, along with visual responsibilities. I guess I'm thinking a sort of Smalltalky thing - although in my mind Smalltalk is very MVC?

Anyway, superficial glue C code coming up, instead of a voluminous ESDL port that I'd never use most of.