| Commit message (Collapse) | Author | Files | Lines |
|---|
|
Darwin only for now since that's what I'm on, will migrate the others a
bit later. Trying out a different plugin system that probably makes more
sense as an interface to each other. Might shuffle things around even
more later.
This is based somewhat on Tsoding's audio visualiser plugin system, I
thought that was way more elegant (the 'state' object), as opposed to
whatever the hell we were doing.
|
|
Oh boy this was a bit of a hassle lol - dynamic loading was the easiest
part... but then came both sound and x11
Using SDL for now but I'd really like to change it for even lower layer,
but then I might have to make my own mixer... oh no.
|
|
This should be better, maybe the variable names could be better though.
Init is more extensible, we take in a 'board_data' struct on the plugin
end that has everything it needs (mainly function pointers for now).
Then, a 'board' struct is given back to the main Clak runtime, with
everything it needs to know (again, mainly function pointers).
It is a bit weird that the board is not stored with Clak but as a
pointer to the dynamically loaded bit, but not sure.
|
|
The .h files are pretty weird, should look at other C projects to see
how they load plugins. This function pointer business with typedefs is
kinda weird, not sure where they should live.
|
|
Just more attempts, but I think I'm gonna switch over to dynamic
.so/.dll loading. That would be pretty fun to check out.
|
|
Not sure if I'm really doing it in the best way possible. Feels a bit
weird that some place assumes the existence of other functions.
|
|
Had to do some stuff with the previous VK tracking, just like what I had
to do in C# with Meccha, since it keeps firing events.
GetMessage part also just blocks to ensure we keep receiving Windows
events, but not sure what to do otherwise.
|
|
|
|
|
|
|
