Well, I would prefer not sleeping as that is dependant on OS scheduler resolution, if that's what you're doing. I haven't look at which of those things GTK handles more intelligently, but if you already know that it avoids any of those pitfalls then it might be a smarter choice.Īside: my other targets are SDL and Cocoa, which are not otherwise relevant. They're a relatively recent addition, and will make your packaging more complicated.Īctually, packaging is a hassle in general - I've been trying to package my emulator as a Snap in order to appear in the Ubuntu storefront, amongst others, and haven't even managed to get a Snap-installable version with working audio yet. * none of the Linux distributions I tested, even those that are natively Qt, came with the Qt gamepad libraries installed. That approach is another of the great latency sources of emulation and if you want to synchronise on vertical sync, you'll have to post a frame and block. * video output is about as primitive as it can be - e.g. * audio buffers are hard-coded to a minimum size of 2048 samples on every platform I've tested, so there's a significant quantity of latency there * it provides no meaningful game-like keyboard abstraction at all, so either you'll end up writing only for one platform or you'll also need something like qkeycode It's really just not very good for audiovisual usage. Having recently added it as a supported target for my emulator, I'm going to advocate against Qt.
0 kommentar(er)
