Falco GirgisYesterday at 8:06 PM
@cykboy damn that was fast.
okay, so here's the thing.
You won't get libGyro to build. The idea is not to build the libGyro PC build or whatever. It's to implement a web back-end. The *_api.h" headers are all of the generic API functions, then you'll notice within source there's /x86, /dc, /sdl, etc for all of the different back-ends. The idea is to create a /web and implement the C functions provided by the API.
BUT BUT BUT
It's not that complex. EVMU BARELY uses anything at all. Just the WAV API (one play function), file API, and input API mostly.
very very simple ones. You only have a few functions you'd have to implement to get enough libGyro up for EVMU web.
But that's the libGyro paradigm. Then also once more functions are implemented, anyone using libGyro (including Elysian Shadows itself), will automatically support whichever platform.
It's less daunting than it looks for EVMU, though, because it's very simple and doesn't use anywhere remotely near the amount of API from libGyro as like the engine does.
So what i would do
Is create a /web/* and then try to build, and for every "undefined symbol" from evmu-core accessing libGyro, just add an empty function.
and slowly start filling it in
shit like audio obviously can come at the very very end.
Video isn't even using libGyro. It's extremely easy.
Just somewhere in your web code, create a render function that simply loops for each each pixel on the screen and uses the gyro_vmu_display.h api
like this:
for(unsigned y = 0; y < VMU_DISP_PIXEL_HEIGHT; ++y) {
    for(unsigned x = 0; x < VMU_DISP_PIXE_WIDTH; ++x) {
         if(gyVmuDisplayPixelGet(device, x, y))  //draw a black square (pixel is ON)
         else //white/blank (pixel is OFF)
    }
}
@cykboy does that make sense?
very very easy to do video and that's the main part.
and then from your actual APP, set it up like this:
1) Create VMUDevice
2) Every frame call gyVmuDeviceUpdate() and pass it the frame delta time
3) every frame call your draw function
4) destroy device when you're done
and that's literally basically it for the app layer/UI client
I have a feeling this is something that would lend itself EXTREMELY well to the whole native web thing, and also all of the more advanced shit, like decoding the files on the filesystem, showing their properties, decoding/ripping their images and all that... that's included in the CORE layer, not the Qt layer, so you have access to all of that too. You could very, very easily for the web implementation also make it a filesystem manager like I'm doing natively with Qt, instead of only a GAME mode emulator.
and then do that, add the ability to create user accounts and load/download save files, and then give me a web API to interop with the EVMU app, and you have built the VMU-in-the-cloud server I want so fucking badly, and then we win, and we rule the world.
Our entire VMU infrastructure would be unstoppable.
every base covered.
VMU everywhere.
ALL THE PLATFORMS, UBIQUITOUS VMU COMPUTING