When you want your timer to start, get the starting time in seconds and save it to a register:
https://qedit.info/index.php?title=Gettime
Where you go from here varies. What Sega usually did was spawn a
thread_stg
for the timer thread in the floor handler of each floor. The
thread_stg
can loop until the timer has started (the register from above is nonzero for example, or another register). A number of custom quests, including my early ones, typically create a single
thread
at quest start that waits until the timer should start. I think a single
thread
is easier but it has some corner case issues if quest failure occurs during a loading screen (which can be fixed by checking for failure in floor handlers).
The timer thread has a few main jobs.
First job is to call
gettime
every frame to get the current time in another register. The difference between this register and the first one is the number of seconds that have elapsed since quest start. You should know the countdown timer's max time, so you can do some math to figure out how many seconds are left in the quest.
The second job is to display the current time using
https://qedit.info/index.php?title=Window_time and
https://qedit.info/index.php?title=Winset_time , where you give
winset_time
the number of seconds you calculated.
The third job, depending on quest, is to detect if the quest is over and how to handle it. Sega was wildly inconsistent with this. Sometimes the timer goes away in a few frames, sometimes immediately, sometimes it sticks around until floor change. Typically the timer thread handles the quest failure message (usually a window_msg with freeze_enemies and return to p2).
Some other notes:
- Typically you
sync_register
some random register from zero to nonzero to indicate the timer should begin for all players.
- Never
sync_register
a value retrieved from gettime
.
- Don't
sync_register
the final clear time or you'll have a jumpy timer when the quest is ending.