Promote v0 to v1, extend v1 and extend GpuApi #178
Conversation
WSSDude
force-pushed
the
features/api-update
branch
2 times, most recently
from
b47f48b to
caa8d5d
Compare
* promoted v0 to v1 * fixed incorrect naming of State::OnUpdate to State::OnTick (copies game) * renamed GameStates::Add to AddHook and modified comments * split GameState hooks to before/after hooks for more granular control * added EMainReason::Run for notifying plugins about entry to CRunningState
WSSDude
force-pushed
the
features/api-update
branch
from
caa8d5d to
ae4f1c3
Compare
WSSDude
changed the title
WSSDude
force-pushed
the
features/api-update
branch
from
caa50b4 to
b4f0e57
Compare
|
Practically same as wopss/RED4ext#94 (comment), would like to have a more proper look over the Present again if something might not be useful to expose, even if it may not be intresting now due to missing structs (already pre-exposed index into monitors structure that is used with HDR and contains curves for various supported modes by the monitor in the ResizeBuffers...) But those are for the next PR, this was supposed to be about API primarily... |
| @@ -10,6 +10,7 @@ namespace RED4ext | |||
| enum class EMainReason : uint8_t | |||
| { | |||
| Load = 0, | |||
| Unload | |||
| Unload, | |||
| Run | |||
There was a problem hiding this comment.
What would be the advantage of having this instead of just using GameStates?
There was a problem hiding this comment.
@psiberx wanted to include this for those that do not need to be hooking but only know that the game initialized and is running. He even suggested to call it from Running::OnEnter.
There was a problem hiding this comment.
What about calling it on Running::OnTick and change it to Tick?
There was a problem hiding this comment.
I guess at that point, you may hook the game state. Believe psi wanted this as a one-off notification before first OnTick. Also am uncertain from this if you mean there would be some continuous notification, then I suppose it may as well truly be a game state hook 😅
There was a problem hiding this comment.
The only advantage is easier entry for beginners. I didn't suggest adding it though, just gave an example of how it could be handled. In Load you can't even do anything engine/game related. The game states are hard to understand and at least need a better description, explaining which systems exactly are initialized at what point.
There was a problem hiding this comment.
Was unsure now if I should keep it or not, kept it for now.
* revert STL changes, postopned for v2 * change plugin handle to void* * return enum instead of bool from GameState hooks, change docs accordingly
WSSDude
force-pushed
the
features/api-update
branch
from
0f751c5 to
9099004
Compare
WSSDude
force-pushed
the
features/api-update
branch
from
9099004 to
d66f101
Compare
|
Just some update on why nothing gets posted for a bit - I found various issues trying to use this, trying to find some better hooks for initialize/deinitialize or some combination that should be reliable enough. Initialize only does base initialization of devices, not swapchain and some other systems that I had plan to hook. Same for shutdown - is just absolute last step of shutdown as I found out and not shutdown for all systems as I thought at first. Found something already and got a bit sidetracked by it, should hopefully post some updates soon... Also considering swapping the ResizeBackbuffer for some more upper-level function as it may get called twice a frame for no good reason as I found out, leading to some suboptimal things on hooked side. |
1st commit:
2nd commit:
3rd commit: (TBD? considering making this another commit at this point, this is kinda huge...)* added helper function to GpuApi for waiting till all frames were presented* added some basic textures struct to GpuApi* swapchain structure fixes based on some newer knowledge^ split this into new PR