Regarding the issue, I think that something as simple as passing an event
structure pointer to a function and having it return a structure from the
union would work. Like SDL_GetEventMotion(Event *e) Or something like
that. But I see that as only being helpful for getting it to work with
C#. I’m just stubborn and don’t want to give up on the project since I
got so much done already
I’m not sure how you’re going about this, but in general, one solves these
kind of issues by implementing part (or all) of the foreign language binding
in the native language of the API. This can often be automated to some extent.
So, in this case, you’d implement your own SDL_GetEventMotion(Event *e) in C,
and have the C# side of the binding (or C# applications directly) calling
Another option would be to rework the event interface to something more
suitable for a proper high level language. In my SDL binding for EEL, an event
is simply a ‘table’ (an associative array, that is) containing the fields that
are relevant for the event type at hand. It would probably make sense to do
something like that in most dynamic languages.
There is more tricky business down the road, though. Callbacks is one API
design that can be nasty to interface to, especially from languages running on
a VM of some sort, and even more so when the calls are made from other
threads, “interrupt” context or worse, a real time context such as an audio
I/O thread. One way is to handle it via IPC and some sort of messages/events,
but that’s obviously a problem in realtime applications. One thing to keep in
mind when designing new APIs for C/C++ engines and libs.
I agree with your statement about it being like 5/95. I didn’t notice any
speed difference from the test I developed in C# compared to the similar
tests in C and C++. Even with all the hand-holding C# does it didn’t seem
to slow it down. But then it was a very minimalistic test.
In the game I’m working on right now, Kobo II, I’m dealing with physics and AI
for literally hundreds of enemies, everything processed at a fixed 100 Hz
logic frame rate, and it’s mostly written in EEL, which currently runs on a
"pure" VM without JIT, so it’s probably a lot slower than C#.
Even so, performance issues are not anywhere near the “once per object, every
frame” level, but rather “hundreds of times per object…”, like rendering
particle explosions all in OpenGL 1.1 style code. Or the na?ve all-to-all
collission testing that the current physics engine is doing. That part is
actually written in C, and still maxes out at only some 600 objects on a
single 3 GHz core - but that’s 18 million tests per second! Some basic spatial
partitioning, and one could handle a few thousand objects in pure EEL code.
Of course, whenever you have “too much” power, you come up with all sorts of
fun stuff to do with it - but that’s where friendly high level languages come
in handy again: You can actually try a lot of that stuff real time, in-game,
without spending unreasonable amounts of time hacking and debugging prototype
code.On Wednesday 24 August 2011, at 17.22.21, “MBrening” <micah.brening at gmail.com> wrote:
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |