Draw Before Step

[RobertBColton]

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

Pull request (D3D)/GameMaker 8/GameMaker 5

[codecov]

Codecov Report

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

@@            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.

[JoshDreamland]

This isn't how you do this. Change the order in events.res. Although, if this actually solves a problem, we can talk about whether it's worth the new problems it introduces by running before half of everything is initialized.

[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 Compatibility Setting Unusable In Sources #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.

[RobertBColton]

It's possible this could be because alarms are either off by one or that alarms are supposed to go after draw events, not necessarily that a draw event comes before a step event.