glutin VS gameroy

Yeah, render Emacs via GPU. We get underlined display server opengl context using surfman or glutin. Since PGTK is gtk, we are using gl_area. Replaced the Cairo drawing with this Firefox's Webrender. Using this, you can except some improvements to rendering. However, I dont know how to do benchmarks regarding GUI rendering.

But I think this will be solved when I switch back the GL context creation to glutin (thankfully, version 0.30 will decouple from windows creation), and I rewrite sprite-render.

Hello, I'm a beginner rust dev trying to make a simple thingy in piston. I've got a picture to follow the mouse cursor, but when I try to hide the cursor with window.set_capture_cursor(true) , it seems like mouse events seize to exist. I found this bug report Mouse Grabbing and MouseMoved Event · Issue #696 · rust-windowing/glutin (github.com) , but that was resolved years ago. I'm using pistoncore-glutin_window = "0.70.1". Am I doing something wrong? If not, is there any other easy way to hide the cursor?

Luckily, there are quite a few libraries out there that provide this functionality, some of them specifically aimed at OpenGL. Those libraries save us all the operation-system specific work and give us a window and an OpenGL context to render in. One of those libraries is glutin. It allows us to create an OpenGL context, define window parameters, and handle user input, which is plenty enough for our purposes.

Yeah this is a known issue in VMs https://github.com/rust-windowing/glutin/blob/master/ISSUES.md but I haven't found a way to fix it. It does not even work with llvmpipe mesa, which provides the newest OpenGL drivers.

I recently found https://github.com/Rodrigodd/gameroy to be a very complete implementation

Hey there! I've been working on a Game Boy emulator since last year and found the GameRoy project, which translated the PPU's logic from SameBoy, the (AFAIK) most accurate GB emulator around. I basically copied the PPU logic into my emulator and replaced the "state" property (an integer) with enums for some extra clarity.

https://github.com/nicolas-siplis/feboy

https://github.com/rodrigodd/gameroy

https://github.com/LIJI32/SameBoy/

What I did was isolate the logic of every component apart from the CPU (video, sound, timer, etc.) behind a correspondent fn update(cycle_count: u64) method (like in the sound controller or in the timer). Currently, I am calling these methods every 4 cycles, but the idea is that I would only need to call it before a read or write to a component register, or before a possible interrupt (I would need to figure out if it is possible to efficiently predict the next interrupt).