The game physics freeze until no end-of-level jingle is playing. The trick is: Disable the music by pressing F3 at end of stage. This immediately unfreezes Fox. Then press fire to play the next stage, and, if you like, press F3 again to re-enable the music.
Another method would be to play without music whatsover, by disabling music with F3 in the first level and never re-enabling music. I've always liked the runs better with the music.
In 2017, Covert_Madness, RikusOrs, and I found that disabling music quickens end-of-level, and we all began using it without discussing it much further.
You're right, there is almost no documentation on tricks speedrun.com. Thanks for asking!
-- Simon
Hi!
If you'd like to learn the run in OpenJazz, go ahead -- we can make a separate category for that, or you can switch to Jazz 1 after you've learned the route.
I wouldn't mix OpenJazz and Jazz 1 on a single leaderboard. The physics and timings are radically different: OpenJazz is not a reverse-engineered Jazz 1, but a very liberal re-implementation of the rough physics. Notable differences of OJ to Jazz 1:
- Long fadeouts, near-instant loads
- Can't skip score counter by firing
- Damage boost preserves horizontal direction
- In mid-air, you can accelerate left/right quickly
- Enemies compute/move before they would spawn in Jazz 1
- Bullets fly further than the Jazz 1 screen size
- Acceleration in general feels odd, but hard to describe
I've ground Diamondus 1 and 2 with single-episode timing. Good runs finish around 1:13 in OpenJazz when I can get 1:06 on average in Jazz 1 in Dosbox. Looks like OpenJazz runs will be roughly 10 % slower, it would be unfair to have OpenJazz and Jazz 1 on the same leaderboard.
If you have the Jazz 1.3 fullgame (e.g., the 2017 GOG release), you can get 1.0 (Floppy version) physics: Download the shareware of Jazz 1.0 or 1.1 at [1] below, copy the shareware's JAZZ.EXE and MENU.000 into Jazz 1.3, replacing the 1.3 files with these names. Run this hybrid in Dosbox. This will only play episodes 1-6 and will even claim "This is shareware" during the main menu, but physics will be like Jazz 1.0.
[1] https://www.classicdosgames.com/game/Jazz_Jackrabbit.html
I maintain a webpage with Jazz Jackrabbit 1 version differences:
http://www.lixgame.com/jazz/versions.html
-- Simon
I've watched WanderingMind's GoE All Stages in 16:27. Really solid play and bullet dodging, congrats! I can't assess the efficiency in the later stages yet, but I've dabbled in GoE stages 1 and 2 and understand some ideas here.
In stage 2, the TAS faces the wallhugger miniboss whereas RTA faces the car miniboss. What's the reasoning behind this? Both routes have a room with many elves, but the car route must wait for a extra conga line. Are the car elves easier to kill than the TAS route's elves?
Room before stage 2 main boss: I found the same strat that gets the triple early, then moves to top edge and face straight down. The room is still scary. Ideally, you don't get cornered, but the fight takes very long and seems to rely on random powerups spawning during this fight.
Stage 2 main boss: Your strat looks both safe and fast: Piledrive turret 1, kill turret 2 on the same side of the room, then hug the wall (to dodge yellow bullets) and find reference points to shoot turrets 3 and 4 with ricocheting rainbow (the boss blocks the big green bullets from turrets 3 and 4). Nice!
Cool, thanks for the reply.
I run the game in Wine on Linux, and the GM5 version runs perfectly with 40 FPS throughout, except for the expected 20 FPS after bosses. I had issues with GM7 (no sound effects, doesn't remember window size) and will stick with GM5 since the choice has no effect on the run.
GoE All Stages is a beautiful run. Scary that it's so marathon-unsafe, but I'm super happy that you showed it nonetheless. I wasn't there in the chat, but saw the vod afterwards. Thanks also for catching my Jazz run, even though I didn't have the time to reply to all the chatters!
After seeing WanderingMind's HPP on hardest difficulty at Shots Fired, I've downloaded HPP again.
Are there any requirements or suggestions whether to use the HPP GM5 or GM7 executable?
The options menu offers a choice between v1.4 and v1.5. According to the readme, that's purely cosmetic. Does it have any effect on the speedrun?
I've only been interested since a day or two yet. Therefore, I can't promise to learn the run or even stream the game regularly, but the itch is there. :-)
"Verifying" merely means accepting the run to the leaderboard.
Look at the run, be sure that the category's goals were met, be reasonably confident that it's not cheated, and that the submitted time is accurate. Then you accept the run by verifying (click the three dots in upper-right corner of a run's page, select verify). The site can't check how closely you looked at the run before verifying the run. Instead, the runners trust the moderators to do a reasonable job.
You can't rule out cheating 100 % from a video recording. Some trust is required. :-)
If you're suspicious about a run, ask community members. If nobody finds solid proof, I'd verify the run. Most submissions are not cheated, that's the important base case. In a pinch, moderators can remove a run after it got verified.
You'll develop intuition for what is good human play, and what is probably TAS. In some 3D games with analog directional input, you can distinguish good TASing from human input from character movement. In old 2D platformers, that's much more difficult. :-) Humans nail frame-perfect presses and can button-mash faster than 10 Hz with good rhythm.
"Cheating in Speedrunning - How easy is it? A brief history and assessment" talks about game modding, TASing, and splicing (stitching videos together), along with examples how each got debunked: https://www.reddit.com/r/speedrun/comments/6ci50v/
-- Simon
Manual splitting can be inaccurate. Re-timing a run from the proof video allows better comaprison. Here's how I do it, will update this according to feedback.
- Read all of this enumeration. Agree silently with me, otherwise please debate. I'd like to know a well-defined and reproducible method. :-)
- Ignore the speedrun timer shown in the video, instead open the run in a tool that shows frame numbers or milliseconds. At 60 fps, there will be 16 or 17 millisecond values that all refer to the same frame. Let's always choose the earliest millisecond value per frame.
- Find the value A = the milliseconds of the last fully-lit screen of the main menu (multi-episode run) or the last fully-lit screen of the episode selection (single-episode run). To do that, let A' be the earliest millisecond value of the first fading-out screen, then compute A = (A' − 33 ms) for a 30 fps video or A = (A' − 17 ms) for a 60 fps video.
- Find the value of frame B = the first completely-black frame after the final boss fight. Let B be the earliest millisecond value of this frame.
- Compute the run's duration as B − A.
- As a moderator, edit the run and set its time to B − A. I find it good style to add your computations to the run's description: The ignored speedrun timer's value, A, B, and B − A.
It's possible that two players have different loading times. This exact computation from video frames will not solve that problem; it will preserve the difference. You'll need another method or more reasearch to strip loading times.
In 2017, I've re-timed the episode 4 runs tonight according to this. Vortale, CapnClever, and I were nearly tied at 3:45.xx, so I wanted a good, reproducible re-timing method.
From experience, the re-timed times are 0.1 to 0.2 seconds better than the manually-split times because all runners like to split at the end on a guaranteed-black frame, not necessarily on the first black frame.
-- Simon
Calling time on last input wouldn't make runs re-timeable from their videos.
There is a screen that reads "Level 15, Just Married" in golden text. I will call this screen level 15's intro screen, L15IS.
This is the final part of a run:
- Titus walks to end of stage and freezes
- Music plays until disabled
- Screen fades out
- Screen is black
- L15IS converts extra bonuses, then waits for Enter press
- Screen is black
- Cutscene fades in
Last input happens about 250 ms before the cutscene fades in: Pressing Enter dismisses L15IS and loads the cutscene. We could call time here.
But speedruns should be re-timeable from the visuals alone. Therefore the best rule for last input would be "time ends on first completely black frame after level 15's intro screen, right before the cutscene fades in". Problem: Is it possible to dismiss L15IS so quickly that you cannot decide between the pre-L15IS blackness and the post-L15IS blackness? If you called time on the post-L15IS blackness, you couldn't re-time runs.
Splitting on first frame of cutscene doesn't have this problem. The cutscene is unique.
-- Simon
I've written into the rules: "Time ends on first non-black frame of the kissing cutscene."
Reasoning: For the past weeks, I've ended time on first frame of kissing cutscene. Rikus practices any% code and times in the same way, even though he hasn't yet submitted a run to this site.
-- Simon
Everybody is welcome to join the Titus the Fox Discord group -- not merely the speedrunners and TASers, but also casual players and those struck by pure nostalgy. :-)
-- Simon
Update 2017-05-29: Time ends on first non-black frame of the kissing cutscene.
Below is the old post from 2017-03.
¤ ¤ ¤
Covert_Madness wrote in https://www.speedrun.com/titus/thread/152l1 : Start: I would say start button pressed. Finish: I would say exit of level 20 (when black screen is seen).
I'm good with starting time on pressing START in the main menu. Main menu fade-out and level 1's title count towards the time.
To clarify the exact end of time time: You probably mean "exit of level 14" instead of "exit of level 20". Black screen after level fade-out means that we should cancel the music before stopping time, okay. But what happens if you get extra lifes after level 14, should they count towards the time? Can you get extra lifes here in the version without the kissing cutscene?
In 2017-04, Neither Covert_Madness nor I wanted to step forward and agree on an end time. We figured it should probably be one of these:
A. The SDA-conforming control loss of main character. This is when the end-of-level jingle starts after level 14, or, if you disable music, screen after level 14 begins to fade out.
B. On first frame of the kissing cutscene. This would measure the extra lifes.
We defer this decision to when more people begin running Fox.
-- Simon
I'm perfectly good with 6,000-or-less.
Fresh thread for start/stop time: https://www.speedrun.com/titus/thread/jiycm
Xarthok: Thanks thanks! All levels is scary because of level 9's super-precise jumps before the boss, but I have the itch to run all levels.
-- Simon
CapnClever, Vortale, and I run JJ with 40,000 fixed DOSBox cycles:
core=auto cputype=auto cycles=40000
It's been like this for over 2 months already, it looks like a stable decision. I've added it to the run's rules. We'd need really good counter-arguments to change it. :-)
-- Simon
At 3,000 cycles, Fox lags with 3 or more enemies on the screen. Level 2 has many enemies and lags almost everywhere. I have a soft spot for 3,000 because it was DOSBox's standard setting years ago, before they changed the standard to max cycles; also one SDA topic [1] suggests 3,000 acknowledging the lag. But I find the lag unfitting.
At 8,000 cycles or more, music and sound won't initialize. I settled on 6,000 because it's a reasonably round value smaller than 8,000. I'm not sure if 6,000 still lags, it's much smoother than 3,000.
It's possible to start the game at slow cycles, then raise cycles far over 8,000 and still have music. I'm not sure how e.g. 10,000 and 20,000 differ in Fox, I believe you get slightly faster level loading, but I haven't measured this yet. During levels, there's no difference, Fox caps fps.
TASVideos doesn't accept DOSBox, but has two suggestions: "Estimate the CPU power wanted by the game in megahertz. Multiply by 1000." [2] Fox was developed on a 12 MHz machine, but 12,000 cycles already prevent the music. The other suggestion is "Use the largest possible value that you think makes the game run more fluently, but not larger. If uncertain, use 40000." Again, this disables music.
Maybe level loading is similar enough to allow unlimited cycles, even though this might depend on the host computer. We rejected max in Jazz Jackrabbit because it would save about 5 seconds in a 30-minute run over existing runs; instead we settled on 40,000 to match existing runs and the TASVideos suggestion.
Try core=auto, cputype=auto, cycles=3000 to get a feeling for the lag. It's OK to postpone the decision and measure more first. But I'm happy that the discussion is on the table. :-)
-- Simon
[1] https://forum.speeddemosarchive.com/post/official_dosbox_settings_discussion_topic.html [2] http://www.tasvideos.org/DOSBox.html
BinaryBlob wouldn't like the autosplitter uploaded yet. I haven't tested the autosplitter -- I'm on Linux and split with urn. Allegedly, LiveSplit works in wine here, but I haven't tried to install it yet.
Thanks for the quick run verification. :-)
-- Simon
I asked CapnClever during an unrelated stream, so he didn't have time to ponder much. His first reaction: "If the game runs smoothly at 3,000, use that. If not, and the game runs smoothly at cycles=max, use that. If not, look for a fixed value that makes the game smooth."
Problem: Max cycles produce different load times for us. With max, I get comparable load times as in my 31:31 run at 20,000 cycles, and CapnClever has blazingly fast load times.
Lacking a decision for now, I'll RTA at 40,000 for my next attempts, just to be on the safe side. 40,000 doesn't exceed Vortale's or CapnClever's loading speed, and 40,000 seems unlikely to be banned since the JJ manual recommends a 486. I'm still open to no-limit.
-- Simon
Re IGT: The ideal would be autosplit IGT. The TAS [1] memory-watches the game's IGT variable and explains why it's fairest. I have no experience with TASing or observing programs from other programs, I don't feel like I could contribute to a solution.
Without autosplitting, RTA with or without DOSBox cycle restrictions feels more precise than manual IGT over the 42 levels, split by the runner during the run. While we can post-process the existing runs for precise IGT, requiring post-processing for all future runs sounds anticlimatic for streaming. :-)
Another beauty of RTA is simplicity, you can explain the competition rules to anybody in 2 or 3 sentences.
Re milliseconds: Yes, please! :-)
Re cycles affect gameplay speed: Yes, you're right. At 5,000 cycles, the game plays far slower than at 20,000. The game seems to cap at 60 FPS, and 20,000 cycles hit this cap easily. Therefore I used to play with 20,000, hoping that it would settle all questions. But apparently, the load screens behave different even above 20,000.
-- Simon
[1] TAS by Ilari, Mothrayas, slamo, http://tasvideos.org/forum/viewtopic.php?t=15553
Edit 2017-03: We're running at 40,000 fixed cycles now, and I've added it to the run's rules.
Here's my original post for the discussion's completeness:
¤ ¤ ¤
I've recorded my 31:31 run at 20,000 fixed cycles. Vortale's 30:32 run seems to use a faster setting, he reaches the fade-in of Diamondus 1 about 0.7 seconds faster than I do. His main menu navigation seems slightly faster, and the level load times are noticeably faster. I estimate a difference of 5 to 10 seconds over the 6-episode RTA.
I've played around with DOSBox cycles. Using core=auto, cputype=auto, cycles=50000, I get comparable times like Vortale's 30:32. With cycles=80000, it seems slightly faster even, comparable to CapnClever's 31:46.
Is there an agreed-on setting for cycles? Should there be one? On slow physical machines, emulating more cycles might harm performance. Should everybody use what happens to be fastest for them instead?
The best resource I found was TASVideos, even though they disallow DOSBox: "Use the largest possible value that you think makes the game run more fluently, but not larger. If uncertain, use 40000. This corresponds to an average 486." Source: http://tasvideos.org/DOSBox.html
-- Simon
Glad to see some action for this game. :-)
Vortale hasn't speedrun JJ recently at all. CapnClever maintains splits for single episodes, but not single levels.
I haven't felt like running anything less than the full game yet. I have practised single levels, but never timed episodes. Probably because 6-episode has well-established rules already, and it doesn't feel pieced-together.
-- Simon