handmade.network » Forums » Work-in-Progress » Pixie Game System
wilberton
Andy Gill
18 posts
#14205 Pixie Game System
4 months, 2 weeks ago

Yes, I thought of that! I think it could work fine if you're just doing software rendering into a buffer, but if the client code made it's own calls to OpenGL it would probably fail. Also if the client required any iOS specific code (integrating with leaderboards, or a third party sdk) it might be a problem because a lot of the iOS apis can only be called from the main thread, and the client would have no way to do that.
Mattias Gustavsson
@Mattias_G
36 posts

Amateur (ex-pro) game dev, making retro styled games and small public domain C/C++ libs.

#14206 Pixie Game System
4 months, 2 weeks ago Edited by @Mattias_G on Feb. 4, 2018, 8:40 p.m.

For the iOS API calls, it should be possible to queue them up as they are called from app_proc thread, to have them transferred to main thread on the next call to yield, and have them executed on main thread in the event callback.

For OpenGL calls, I believe it is possible to migrate the GL context to another thread, so main thread could hand it over to app_proc thread when calling app_yield/executing event loop. As long as it is not accessed from both threads at the same time, it should work. I seem to recall doing just that when porting Frostbite engine to iOS (unless it's changed since then, it's been a couple of years since I looked at iOS).
wilberton
Andy Gill
18 posts
#14207 Pixie Game System
4 months, 2 weeks ago

For fire-and-forget api calls I think I can see how that could work, but what if you needed to do something like this:

1
2
  if(some_ios_api_call())
    some_other_api_call();


Anyway, it sounds like it's getting a bit too hairy for me. I only take on simple projects :)
Maybe I'll look at linux instead...
Mattias Gustavsson
@Mattias_G
36 posts

Amateur (ex-pro) game dev, making retro styled games and small public domain C/C++ libs.

#14208 Pixie Game System
4 months, 2 weeks ago

Personally, I think a Linux version is more interesting than an iOS version anyway :)

As for those type of ios calls, there's nothing like that in the app.h api, and I don't think I would opt to add any ios specific stuff either (such as leaderboards or whatever). Instead, I'd use something like a global function pointer which can be called from within the ios event loop, if it is not null. And from that function, I would call the ios specific stuff, and handle synchronization with the rest of the code on a case by case basis. But specifically NOT try to make it platform agnostic.
wilberton
Andy Gill
18 posts
#14217 Pixie Game System
4 months, 2 weeks ago

Ok I've added initial Linux/X11 support to my local copy (here). Same caveats as before, various missing functions, probably buggy, code could do with tidying up. Still, OpenGL, windowed/fullscreen, audio, and mouse input are all working.
Audio seems to have a very high latency, this could be because I'm running it through VMWare, or it could be my fault because I have to buffer it again (I didn't find a way to map the api to ALSA directly).

There's definitely a ton of code that could be shared between the linux and mac versions, and probably with the windows version too. Also this is just a first pass, so the code is fairly messy.

You'll need libasound2-dev to compile (plus X11 and glx headers). And you need to link with -lX11 -lGL -lasound.

Mattias Gustavsson
@Mattias_G
36 posts

Amateur (ex-pro) game dev, making retro styled games and small public domain C/C++ libs.

#14234 Pixie Game System
4 months, 2 weeks ago

Did you take a look at the API in the version I linked to a few posts ago? Specifically the sound API have changed, maybe it will make it easier to implement the sound on linux without extra buffering.

In the windows version, I use LoadLibrary and GetProcAddress to eliminate having to link with anything but the core windows libraries (kernel32, user32 and gdi). Is there anyway to use dlopen/dlsym on Linux to achieve the same thing? It's not the end of the world to have to link stuff on the command line, but it is just so convenient to not have to. On windows, I can go "cl main.cpp" and that's it. I guess on mac, I have to at least add the core framework - at least I don't know a way around it. But on linux, I'd hope it would be possible to do "gcc main.cpp" or "clang main.cpp" to build, and not have to add any libs.
wilberton
Andy Gill
18 posts
#14238 Pixie Game System
4 months, 2 weeks ago

Not yet, I'm half way through that merge. I was going to suggest switching to a callback for the audio (the main thread stalls on macOS when the global menu is open, which causes the audio buffer to loop atm), we'll see if that helps on linux with the latency.

Loading the libraries at runtime should definitely be possible on linux, but you'll still need to link with libdl to get the dlopen & dlsym functions. Also, unlike Windows and MacOS, you don't have any standard platform sdk, so before you can compile you may need to install the dev libraries for X11, glx and alsa. In theory after that you should just be able to compile with 'gcc main.c -ldl'.
wilberton
Andy Gill
18 posts
#14239 Pixie Game System
4 months, 2 weeks ago

Initial merge is done, but I'm getting some compile errors on Windows now:

1
hr = IDirectSoundBuffer8_QueryInterface( soundbuf, GUID_IDirectSoundBuffer8, (void**) &app->dsoundbuf );

error C2440: 'function': cannot convert from 'const GUID' to 'const IID *const '

and

1
hr = app->dsoundbuf->QueryInterface( GUID_IDirectSoundNotify8, (void**) &notify );

error C2039: 'QueryInterface': is not a member of 'IDirectSoundBuffer8'
C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\um\dsound.h(783): note: see declaration of 'IDirectSoundBuffer8'
abnercoimbre
Abner Coimbre
283 posts
2 projects

Founder

#14264 Pixie Game System
4 months, 1 week ago

As an aside, this thread is so exemplary of what the Handmade community is about. I've enjoyed reading the whole thread (did so twice), and learned quite a bit about the (horrors of?) Mac OS development.
Randy Gaul
50 posts
#14733 Pixie Game System
2 months, 3 weeks ago

abnercoimbre
As an aside, this thread is so exemplary of what the Handmade community is about. I've enjoyed reading the whole thread (did so twice), and learned quite a bit about the (horrors of?) Mac OS development.


It is indeed difficult if you really want to just stick to C. Apple is really "proprietary", sort of like Microsoft can be sometimes. I worked for a little while as an iOS engineer, and have also implemented this code, and this code too (puke). My experience can be summed up as: "Imagine you're writing native win32 code, except there are less docs, and oh BTW some stuff is only accessible through Obj-C, which would be a lot like as if one was forced to write some win32 things in C#".

Props to Mattias for attempting to make a nice platform header! Shows some real gumption. I buckled years ago and went with SDL instead :P