This actually does make a difference if a draw, instead of step, event is the first event after the create and start events. To avoid having to make complicated changes to the event system, my solution in this pull request simply adds a
screen_redrawcall to the end of the load sequence, which gives the same effect anyway. This pull request changes ENIGMA to be more like older GameMaker 5-8, instead of being like GMSv1.4 in this regard.
I made a test GMD project: draw-step-order.zip
- ENIGMA Master: create (black), step (black), draw (black), step (gray)
- This pull request: create (black), draw (black), step (gray), draw (gray)
- GameMaker 5: create (black), draw (black), step (gray), draw (gray)
- GameMaker 8: create (black), draw (black), step (gray), draw (gray)
- GMSv1.4: create (splash), step (splash), draw (splash), step (gray)
I've found one game alone that is directly affected by this and it's the Wild Racing game. Its start screen is drawn in an alarm that is set to
1 in the create event. In GameMaker 8, this means the control information is drawn like a HUD on top of the already drawn scene. In ENIGMA master and GMSv1.4, a step event occurred between create and the alarm, so the alarm event will draw on top of a black backbuffer. This does not entirely fix ENIGMA however because screen refresh differences between D3D and OGL mentioned in #1474 are also related to whether the backbuffer was discarded just prior to the alarm event.
ENIGMA master (D3D and OGL)/Pull request (GL)/GMSv1.4
Pull request (D3D)/GameMaker 8/GameMaker 5
@@ Coverage Diff @@ ## master #1475 +/- ## ========================================== + Coverage 17.42% 17.42% +<.01% ========================================== Files 165 165 Lines 17122 17123 +1 ========================================== + Hits 2983 2984 +1 Misses 14139 14139
|Impacted Files||Coverage Δ|
@JoshDreamland two questions with regard to that.
- If we change it in
events.resthen how would we add forward compatibility? Hypothetically, doing it my way we could use the compatibility flag (if it gets fixed by #1461) and make it compatible with old and new GM.
- It still runs after create events, so why are you initializing in the step event?
For now, they'll switch it out manually in
events.res. In the future, we may want to add preprocessing to that file.
I'm not initializing anything in the step event. I just noticed you're running this immediately after the normal room load event chain, so this is unlikely to hit problems with uninitialized objects, but that doesn't change the fact that it's going against the flow defined in