Labels Milestones

WIP: Reorganize the codebase, splitting game, render and input logic #3

Draft

Avery wants to merge 7 commits from Avery/MineClone:master into master

pull from: Avery/MineClone:master

merge into: itycodes:master

itycodes:fix-depth

itycodes:master

Conversation 0 Commits 7 Files Changed 20

Avery commented 2 months ago

PR marked as WIP since I am very much learning as I go and I expect that this first attempt needs a few time back and forth between reviews and fixes before it can be merged.

In this version, the game logic is driven by the state of the game, making it essentially a state machine. While currently there is only states for loading and InWorld, once a main menu and such is implemented, those will get their own states in the state machine, thus being able to render their own things and handle their own input. I imagine a valid and sensible flow of states could look something like this:

Unstarted ->
(create basic rendering data)  ->
RenderAvailable ->
(create main menu and its renderer) ->
MainMenu ->
(Select world to play and set target state to Loading world) ->
(then destroy main menu renderer) ->
RenderAvailable ->
Create world renderer part 1)-> 
LoadingWorld
(Load world, potentially mods, and create world render part 2) ->
InWorld -> 
(Exit world and destroy world renderer) -> 
RenderAvailable -> <Back to creating main menu>

For further details on the reorg, see 2f15842ca4.

PR marked as WIP since I am very much learning as I go and I expect that this first attempt needs a few time back and forth between reviews and fixes before it can be merged. In this version, the game logic is driven by the state of the game, making it essentially a state machine. While currently there is only states for loading and InWorld, once a main menu and such is implemented, those will get their own states in the state machine, thus being able to render their own things and handle their own input. I imagine a valid and sensible flow of states could look something like this: ``` Unstarted -> (create basic rendering data) -> RenderAvailable -> (create main menu and its renderer) -> MainMenu -> (Select world to play and set target state to Loading world) -> (then destroy main menu renderer) -> RenderAvailable -> Create world renderer part 1)-> LoadingWorld (Load world, potentially mods, and create world render part 2) -> InWorld -> (Exit world and destroy world renderer) -> RenderAvailable -> <Back to creating main menu> ``` For further details on the reorg, see 2f15842ca45d29316a35b1fe5ee1e7bf8b5ddb3c.

Avery added 3 commits 2 months ago

3da43d5a69

Seperate shader for skybox, shader and cube in one scene

8168eebf7b

Reflective cube

2f15842ca4

Reorganise and split `main.rs` ...

- The state of the game is now tracked using a simple state
  machine, where the main struct representing the game is `Game`
  and its state a generic implementing `GameState` on that struct,
  the following states exist:
  - `Unstarted`: Nothing has been done yet
  - `RenderAvailable`: The very basic things for rendering are available
    (sdl context, entry, instance, device, cmdbuf, surface, etc)
  - `LoadingWorld`: We are loading into a world, the only thing that
    can be done here currently is add things to be rendered (Components)
	of which only the `Cube` is available, with the skybox being
	automaticall added.
  - `InWorld`: We have loaded a world and can (theoretically) render things
    and move about
- The render logic now lives in `render/` and is split both by phase, as well as
  components and the swapchain having their own modules
- The input logic now lives in input and constits of one trait that should be
  implemented for states that should handle input, and is currently capable of
  handling mouse movenent, key presses and keys that should be held down (ex,
  movement keys)
- The game logic lives in `game/` and is/will be responsible for driving both
  the input and render modules

Note: the current commit is broken, as our surface is lost when returning from
`Game<Unstarted>::init_render`

Avery added 1 commit 2 months ago

dbce32f625

Fix `VK_ERROR_SURFACE_LOST_KHR`, `VK_ERROR_OUT_OF_POOL_MEMORY`, typos in shader names ...

- `VK_ERROR_SURFACE_LOST_KHR` was caused by the sdl window being
  dropped, it is now kept in gamestate to prevent that
- `VK_ERROR_OUT_OF_POOL_MEMORY` was caused by the descriptor pool having
  a hardcodes size for the number of descriptor sets instead of that number
  depending on the required number of sets

Note: We are still broken, a window opens and controls seem to work
      fine, but nothing is shown in the window

Avery added 1 commit 2 months ago

b09eedafab

Fix pushing constants not using specified flags and offset, rendering now works

Avery added 1 commit 2 months ago

32aa330b33

Add doc comments to various things ...

Doc comments were added to:
- States and their components, expaining their meaning
- Traits
- Functions transitioning game state

Avery added 1 commit 2 months ago

c9fdcfe008

Deduplicate setup_dest_layout ...

The vube and skybox need the layout of their desc_set twice,
once for creating their pipeline, once for creating their desc set,
two different functions were used for that (one of which belonging
to the `WorldComponent` trait), now since they can't be fully merged,
one just calls the other.

This pull request is marked as a work in progress.

Sign in to join this conversation.

Reviewers

Request review

No reviewers

Labels

Apply labels

Clear labels

No items

No Label

Milestone

Set milestone

Clear milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Assign users

Clear assignees

No Assignees

1 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: itycodes/MineClone#3

Write Preview

Loading…

Cancel

Save

There is no content yet.