News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - TheArbiter

Pages: [1]
Programming / Re: Super Hang-On (Genesis) Game Timer - inaccurate?
« on: May 01, 2019, 06:57:45 pm »
Ahh crap I'm sorry! It completely slipped my mind to be clear. There is an Arcade Mode and an Original Mode in the game. We use Arcade Mode for speedrunning, no wonder you are getting such different results because what you mention and the screenshots you have are from Original. I'm using Bizhawk when I do my research. I hope the omission hasn't rendered the obviously sizeable work you've just done invalid! Let me clarify the results I have based on Arcade Mode.

$0554 "TIME", the timer that counts down top-middle of the screen as the time limit to reach next checkpoint
$0556 seems to be tied to Genesis clock speed
$0558 Sector times - after each checkpoint, jumps from 0000 back to where subseconds had left off
$055A Speed
$064A Speed
$C70C Turbo Speed
$0614 X-position relative to track
$065A and $0C70, handle collision detection/behaviour with AI bikes
$040C onwards, stores sector times and totals them for IGT at end of races
These values are also stored in $0484 onwards which at a guess might be the 'best laptime' data
$04EC Minutes of final IGT
$04EE Seconds and subseconds of final IGT

Programming / Re: Super Hang-On (Genesis) Game Timer - inaccurate?
« on: May 01, 2019, 04:23:35 am »
Hi Ryan, yeah I'm one of those people who wants to know the gubbins inside but cannot understand code, so thank fuck for emulators and ram watches or my speedruns would be so basic  :laugh: I found the issue with both Rev 01 and Rev 00 - the only differences between them are things like frame rate and bike handling. I've also got visual evidence that the fault is present on SHO Arcade MAME. I found a simple way to prove it, I started a race in Asia and on the first frame score had ticked to 400 I paused, and set the following values fixed in memory:
-I froze the bytes handling AI collision, $065A and $C7C0, so no collision would affect position or speed
-I set $055A at "500" and $064A at "250" which set speed to 290km.
-I set $0614 to freeze at 0 guaranteeing middle track position throughout to ensure the sectors were the same length.

In S1, I finished with a time of 35"80, and did not change speed for S2. The time for S2 was therefore performed with a constant speed of 290km/h, and was timed at 34"80.

I reset the game, and set 267km/h for S1 - 267km/h. Before the checkpoint for S2 I changed speed back to 290km/h for S2. The time for S1 was 38"56, S2 showed up as 34"53.

As a speedrunner I don't know what level of work would go into making a hack patch of the game. What would be required, is either
-a patch that ensures the timer counts from 00"00 with each new sector, or
-a patch that edits the sector times stored in area $040C onwards to their correct times so that the final IGT shown is correct. To my understanding both of those would result in the same correction. If it is a lot of work however we can use a pencil and paper to do manual adjustments, indeed it didn't take me long to do that for our current leaderboards.

Programming / Re: Super Hang-On (Genesis) Game Timer - inaccurate?
« on: April 27, 2019, 06:54:47 am »
I am confident that it is the game timer yeah - the checkpoint times sum to the total on the score screen at the end. To be sure, I compared a sector split from two runs. The runs showed 'the same time' but when I adjusted for subseconds and played them back in sync, one was faster than the other as indicated. Similar things happened when I used subsecond adjustment on a pair of splits where one player was supposed to be faster but after adjustment and sync video I found the reverse. $0556 only ever oscillates from 1E00 through 1E1D and back around again.

My thought (saying this without having heard from our mod yet, so take with a pinch of salt) was that a patch could be made to eliminate the erroneous behaviour and be sure the timer was properly reset at the end of each sector, which would avoid a player having to use a calc to work out their time. The other option that seemed obvious would be to manually remove the subseconds that were not meant to be there but as mentioned that isn't as transparent as simply repairing the timer - I know someone on the forum has hacked SHO graphically before.

EDIT: as each sector is completed, the time is written to $040C onwards for each sector, and these are summed at the end of the race and shown in $04EC and $04EE, all of that in hex. Poking those values changes the time shown at the end.

Programming / Super Hang-On (Genesis) Game Timer - inaccurate?
« on: April 26, 2019, 07:52:55 pm »
Hi! Hoping someone can help me out here.

I've been speedrunning Super Hang-On (Genesis) and one of my recent runs finished with a lower time than a fellow runner, but the checkpoints time was also lower which made no sense. Researching into this I think I found a problem in how the game calculates in-game times for sectors, but I need to be sure since this could have implications for our community.

At $0558 in RAM time counts up in hex, and when you reach a checkpoint it temporarily zeroes, the time is shown for that sector and kept track of for overall time. Then the weird bit is that ones and tens seem to carried over.

For example: the value gets to 3466, zeroes, a time of 34"70 is shown. Then rather than counting up from 0000, it starts from 0073.

That would appear to indicate that subseconds are carried over between sectors, which would be subject to manipulation. I am not quite sure however since freezing $0558 did nothing to change the sector time: it was only when I froze $0556 that this was achieved.

Can anyone help clarify this?

I noticed there's one mod of Super Hang-On that changes some graphics: without knowing such things, it'd be so great if someone could make a hack of Rev 00 which removes the AI riders in Arcade Mode, you wouldn't believe how often those gits ruin speedruns and it'd be nifty to have a TT version!

ROM Hacking Discussion / Alex Kidd Advanced (AKIMW hack)
« on: July 14, 2018, 12:34:24 pm »

I hope to get constructive criticism, feedback etc from you on an AKIMW rom hack. I intend to release two games in the series - one for regular fans/players, more challenging than the original. One extremely difficult (but not kaizo unfair) for speedrunners/bored platformergods.

The aim is to extend the challenges from AKIMW based on understanding of its gameplay and style, as well as updating some graphics. Notably much more powerful jumping and fluid squatting - no more crawling under rocks at the speed of snail maze. You can wall-kickaround obstacles, and a curve back in on yourself when jumping out and around things. It does take a little getting used to but it works well.

I feel like my strengths lie in platforming ideas/design. If people feel the gameplay jars too much compared to the original I am quite open to reskinning, in the vein of a ninja game, or an obstacle course style bent. If it turns out to flop, I can share a compendium of the elemental ideas I have created with KiddEd for others to use in their designs and no loss.

Enough rambling: go here
and try the patch at the end for a sample of level one. Try it on emulators, brave warriors. Use v1.1 of the original to patch to. Youtube recorded playthroughs would be great. It would be far too unwieldy on an everdrive. 50fps please!


1. Take some time to get used to jumps. If you get used to stopping it's a little tighter than the old akimw physics. You can now preserve momentum off walls - so sometimes you will have to shape your jump correctly.
2. Ghosts can be eliminated by spawning 2 moneybags from boxes on screen at once. Does the design makes this clear? Walking at the top of the level confuses ghosts into going below - this is the purpose of the exclamation blocks later in the first level, which also mean 'hint: use an item to progress'. I intend this to be a device in later levels for people to go around a few times.

3. I use half and quarter blocks, allowing diagonal stepped sections, extra play area, and half-breakable blocks. This also allows blocks that can only be broken from one side, or only with the punch or ring. The first block you start against would be breakable if there wasn't a wall directly behind you
4. Star blocks are the same, punch to trigger. Bullseye means 'pass through me', the first use is just money to give an example. Later levels show a red and white target which is outside the star blocks: this is the trigger that can be moved, so in some areas the target punch area is smaller. This allows for 'punch at the apex of the jump' puzzles.

5. I've also added a 'HELP' mechanic where for a cost of U100 at first, you can walk through a green tunnel and have a ghost removed from gameplay. In some instances this will also mean a separate path, and I will typically give the player an item as well for his money. The main idea is to give players of all levels good ways to enjoy the game. The help 050 is for if you fail the flame race - calindo is working on negative money for me among other things.

6. Ladders are tricky to implement in horizontal levels, hence the odd tunnel after the water. Let alex rise to the top of the water, then wait a moment before climbing. If he freezes or starts to float downwards in mid air, press up again, it should work ok there.

EDIT: I have now created a blog at Alex Kidd Advanced where I hope to detail progress and get feedback on designs, and other aspects of things. Any comments or complaints about what you see would be most welcome.

Pages: [1]