Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Main Menu With Egui #38

Merged
merged 1 commit into from
Jul 2, 2022
Merged

Conversation

zicklag
Copy link
Member

@zicklag zicklag commented Jul 2, 2022

This implements the main menu with Egui.

An organizational change I made you might want to be aware of before reviewing is I removed the distinction between the Game asset and the GameMeta structs. Now everything is just in GameMeta. It started to get really cumbersome to have the loaded assets inside of Game in a separate tree from the GameMeta where all the non-asset stuff was held. What I did was move all of the asset handles inside of the Meta structs, and did serde(skip) on them all, so they will be loaded with initially meaningless values, such as null Handle<Image>'s.

After the asset is deserialized and it's corresponding load_<asset_name>() system has run, the handles will be replaced with meaningful values.

Technically I could have used Option<Handle<Image>> instead, but that would require unwraping all over the place in systems where we know they should only run once the data has been loaded. By just using dead Handles, we get predictable behavior without having to unwrap().


On the UI front, it's worth noting that Egui doesn't render perfectly crisp fonts when you use pixel-style fonts most of the time. You have to kind of get the screen size and position just right if you want to get perfect lines. Otherwise it ends up a little blurred at the edges, just across 2 pixels. In Bevy Retrograde I fixed that by creating a custom bitmap font loader and renderer, but that's a bit more work to integrate/use and I'm not sure if you guys are really set on the pixel fonts or not anyway. It just something for future discussion, and maybe opening an egui issue/disucssion to explore whether or not egui can just fix it anyway.


Anyway, this is a big one, so let me know what you think! I'll start working on the pause menu on top of this, which should go relatively quickly, tomorrow I think.

@zicklag zicklag marked this pull request as ready for review July 2, 2022 01:22
@erlend-sh
Copy link
Member

and maybe opening an egui issue/disucssion to explore whether or not egui can just fix it anyway.

Yes, please do that and link back here from that issue so we’ll see the backlink.

@zicklag
Copy link
Member Author

zicklag commented Jul 2, 2022

There we go, created emilk/egui#1790.

@zicklag
Copy link
Member Author

zicklag commented Jul 2, 2022

The font rendering issue is something I could spend a little time investigating how to fix in Egui. I found a lead on what the issue might be, but if this isn't relatively important right now, I could just continue more work on Punchy instead.

@erlend-sh or @odecay do you think this is something I should look into now, or later?

@erlend-sh
Copy link
Member

Yeh just keep it going as a casual side-track, no need to chase it down to its end any time soon.

@odecay
Copy link
Collaborator

odecay commented Jul 2, 2022

Alright I think this is looking good, I appreciate all the comments you left, made the code easier to review. I'm not really familiar enough with egui to have feedback on that section but I am happy to see the image backed frames + buttons are working.

In terms of the empty handles during loading I think that makes sense. Also I noticed load_fighters is being run in GameState::InGame, does it fit best there or is it something leftover from before?

@zicklag
Copy link
Member Author

zicklag commented Jul 2, 2022

does it fit best there or is it something leftover from before?

Load fighters only has anything to do if there are fighters in the world, which should only be while the game is playing, at least so far. So I think it makes sense right now, but it could change later, when we have player selection screens and stuff like that.

///
/// This is run in a chain as either `not_hot_reload().chain(load_game)` or
/// `is_hot_reload().chain(load_game)` so that logic for hot reloading the game and loading the game
/// can be shared.
fn load_game(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to make sure I'm understanding correctly, this runs in loading state and then if hot reload is enabled/configured also in a hot reload state with some conditional logic that determines what to do in the hot reload case?

Copy link
Member Author

@zicklag zicklag Jul 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, exactly.

Since all the logic was almost exactly the same for both an initial load and hot reload it seemed reasonable to run the same system for both cases and just check an extra is_hot_reload flag.

Granted, it did make it a little more complicated, and I wasn't 100% sure it was worth it, but I think it's better than writing most of the same code twice and adding more opportunities for bugs where the hot reload runs different than the initial load.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was kindof unintuitive to follow at first but I think it makes sense. I wonder if it could be split up into a needs_hot_reload() iyes_loopless run condition which is then applied to a conditionset that runs the hotreload logic in its own system before the load system?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could be left for a future pr though if it even makes sense

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think we could try it layer if we wanted to. I was just analyzing to try and see if it was possible/beneficial.

The issue I see with it is the code that needs to run only when it isn't a hot reload. It'd need to be split up into somewhat more independent systems, which might be a better design anyway, but yeah, I'll probably try that in a separate PR after this one.

@zicklag
Copy link
Member Author

zicklag commented Jul 2, 2022

I just finished a slight update which adds the pause menu, do you want me just to add that commit to this or open another PR?

It's mostly just the implementation of the pause menu UI system, but also a small change to where the font sizes are stored in the assets.

@odecay
Copy link
Collaborator

odecay commented Jul 2, 2022

I just finished a slight update which adds the pause menu, do you want me just to add that commit to this or open another PR?

It's mostly just the implementation of the pause menu UI system, but also a small change to where the font sizes are stored in the assets.

I say open another if it doesn't really implicate what is in this one.

@zicklag
Copy link
Member Author

zicklag commented Jul 2, 2022

Got it. 👍

@odecay
Copy link
Collaborator

odecay commented Jul 2, 2022

I dont think there is much point delaying getting this in, lemme do that then open the pause menu PR.

@zicklag zicklag mentioned this pull request Jul 2, 2022
@odecay odecay merged commit fe2d3fc into fishfolk:master Jul 2, 2022
@zicklag zicklag deleted the main-menu branch July 2, 2022 19:24
@odecay odecay mentioned this pull request Jul 2, 2022
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants