hikari_no_yume
hikari_no_yume
I should investigate whether I can dump lists of function imports in some collection of apps. I could then potentially compare different apps and see how closely their requirements match...
Maybe I should add an outline to it?
See: 31e87f9dc6d16b5a6545ab4780b09fb68850b9f8. This is a known limitation, and not something I'm happy with, but it's the best I could do without spending a lot more time on it. The problem...
I suspect this is related to the game using `glCopyTexImage2D()` and `glCopyTexSubImage2D()`. Adding code to multiply the co-ordinates by the scale factor, like we do for e.g. `glScissor()`, doesn't seem...
This is trivial to do: add `"hidapi"` to the list of `rust-sdl2` features in `Cargo.toml`. We'll need this for accelerometer support: https://github.com/hikari-no-yume/touchHLE/issues/13. It might also improve controller support for some...
Basically, `GuestFunction::call()` pushes a new guest stack frame, but it's called by `CallFromHost::call_from_host()` which writes some stuff to the stack first… which is the wrong order :( @ciciplusplus hit this,...
touchHLE has a hybrid of co-operative and pre-emptive multitasking. There is full pre-emption for guest code (we just swap out the register state for threads like any OS would), but...
Currently the only testing done is, well, manually running Super Monkey Ball and trying to play it. This is a very effective integration test, but it's not going to scale....
For legal reasons, and to avoid bloating this too much, I don't want to include video decoding. But it's unfortunate that apps that want to play video (like Crash Nitro...
There are a lot of things that could be improved about the GLES-1.1-on-GL-2.1 layer we have right now. This issue is about one of the areas that most badly needs...