Draw Before Step

Reporter: RobertBColton  |  Status: open  |  Last Modified: March 09, 2019, 11:24:54 PM

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_redraw call 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)

Practical Implications

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

Wild Racing Init Black

Pull request (D3D)/GameMaker 8/GameMaker 5

Wild Racing Init Scene

codecov[bot]  
>Codecov Report

Merging #1475 into master will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            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 Δ
ENIGMAsystem/SHELL/Universal_System/loading.cpp 87.5% <100%> (+0.32%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 092a9c3...4c2cffa. Read the comment docs.

RobertBColton  

@JoshDreamland two questions with regard to that.

  1. If we change it in events.res then 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.
  2. It still runs after create events, so why are you initializing in the step event?
JoshDreamland  

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 events.res.

Please sign in to post comments, or you can view this issue on GitHub.