jumpy

jumpy copied to clipboard

Some features are missing after the merge:

• In-game menus (both Macroquad and Internal)
• Main menu (Internal only)
• Particles (Internal only)

Main menu has been reimplemented as a game state, so it will just be a matter of transitioning it to egui. The Menu and Panel widgets must also be transitioned to egui (the latter only if we can't use an egui window to draw panels) and a Menu can then be attached to DefaultGameState instances and toggled with input (the input part is disabled but I will fix this). I think the best course of action will be to just go ahead and transition the menus to egui, while we are at it, as the gui is the only feature that requires the Macroquad backend, at this point. Doing this will let us remove the Macroquad backend from core, which will clean things up a lot and make the code more manageable.

To enable particles we will have to import the particle system from macroquad_particles into core and refactor it to use our OpenGL context, instead of Miniquad. This shouldn't be too hard.

Some bugs that should be corrected:

• Missing character portraits in character selector
• Jump physics are off (too little jump force is applied)

The missing character portraits should be adressed when we transition the main menu to egui. To draw textures with the ui system, we have to set up access for egui to our OpenGL textures, use images (less performant and more hacky solution) or create a new rendering pass, after egui has drawn, that draws textures on top of the ui. We should probably go for the former solution. If we choose the latter, we will have to do some work on the renderer, as the renderer just draws immediately when the batch is full, in stead of collecting draw calls and drawing them at a set time (this should probably be fixed, long term, any ways, so that we can control when, specifically, draws happen).

Jump physics is probably something wrong in the player state handling as the rest of the physics are right. When adressing this, we could also go through all our other physics variables and divide them by two, so that we can up the physics resolution to 120 (it is 60 now). Either that or just divide all forces and velocities by PHYSICS_RESOLUTION and multiply by 60.

I heard that we might be using Raui earlier, are we switching to Egui instead?

From my experience with both, Egui is nice and simple, while Raui is powerful and natively handles 9-patch style UIs well, but is much more complicated and can lack some developer-experience polish.

I noticed the course select screen starts the first level regardless of which one we select, and I was going to fix it, but it might be better just to start working on migrating the UI. Is there anybody else working on UI, or would that be a good thing for me to start on?

There were some issues with main, so it was reverted to pre merge state. I will merge this again, properly, but probably not until in a week, as I am stacked with work the upcoming week. We can begin that work then :)

OK cool.

As a side-note, I just happened to start testing out egui more heavily for a personal project for an NES sprite pallet viewer/editor thing, and I'm really liking it. I think it could be really good for the editor, Even when I needed to integrate a custom widget renderer for my image viewer widget that went rather painlessly.

And designing great user-experience GUIs is something I enjoy, so I might be able to help out a bit with the editor when we migrate the UI.

That work is largely done already in #407 ;)

Hey @olefasting let me know if there is anything I can do to help get the rendering stuff ready.

I'm brave enough to start messing with it, even if it's still really work in progress, assuming there isn't stuff that you specifically need to do first. I just need to know what direction we're going with it.

When I looked at the work-in-progress branch, I could see that there's the new custom renderer backend and there's the macroquad backend, but I didn't know whether or not we wanted to get the branch working with the macroquad backend again, or if we just want to fully migrate to the custom renderer.

I'm good working on the full migration to the new renderer if that's what we want.

Also, I just finished creating a 9-patch component for Egui for Bevy Retro, so I should be able to migrate the UI to egui and keep the current look-and-feel, too:

Everything's changed with the Bevy rewrite, so we'll open new issues for any problems we have now.