Sonic and Sega Retro Message Board: saxman - Viewing Profile - Sonic and Sega Retro Message Board

So, a few of you have figured out that the driver behind Sonic 2 revision 3 is Sonic Boom. But what exactly IS it?





BACKGROUND:
It's called Saxman's Sonic Boom engine, but you can just call it Sonic Boom for short like I do (and did going all the way back to 2011). Why Sonic Boom? Because "boom" means to progress rapidly.

The project started out as a series of bug fixes for Sonic 2 with the intent of being released as THE unofficial revision 3 of Sonic the Hedgehog 2. However, at some point along the way I decided this project should be much more than simple bug fixes, because who would really want to download that? I probably wouldn't bother myself. So, inspired by Team TNT's BOOM engine (Remember that? No? Well, it was a pretty big deal back in 1998), I decided to make this an enhancement of the Sonic 2 disassembly itself and focus on trying to turn it into a developer's crutch of sorts. The idea was that new features could be plugged in by setting certain flags in the code. That way, hackers can pick and choose what they want for their projects.

The source code is intended to replace the need for any other disassemblies currently being used. The source code is based on the 2007 disassembly, partly because I did not really like the overall state of the SVN code. I decided to clean up the code myself and slowly but surely make it more maintainable, customizable, and readable. That effort is not done, but I did make a lot of progress on that front. If you want byte-by-byte perfection, look elsewhere. The Sonic Boom source code is intended to provide you with a plethora of bug fixes and enhancements designed to make your hacks better.

I wrote a wiki entry on Sonic Boom -- http://info.sonicret...nic_Boom_Engine. I will highlight the engine enhancements which I think are most important changes below.


ENHANCEMENTS:
## A new level layout format was created to conserve RAM. This allows levels to be much larger than even those from Sonic 3. It also separates physical layout from visual layout, allowing one meta-block to use a different meta-block's physical properties.
## Levels can now wrap at points other than 0x800. These include 0x2000, 0x1000, 0x400, 0x200, and 0x100.
## The maximum number of pattern load requests has been increased from 15 to 24. No additional RAM is required to make this possible.
## Each act can now have its own set of art.
## Now any level can have water, and you can also control the movement of the water for each level.
## Sonic and Tails can now start in different locations of a level. The 2 player vs. mode also has its own start positions for both players.
## Game demos now have more data associated with them. Each demo has data for the start position, length of the demo, which player the demo was recorded with, the zone and act, and whether or not two player split-screen was used.
## Knuckles the Echidna has been imported from Knuckles in Sonic 2. He can be enabled using the cheat code U, U, U, D, D, D, L, R, L, R at the title screen.
## The "Saxman" cheat was added to allow many other cheats and options be enabled through one code. The code is 01, 09, 08, 04, 00, 07, 02, 07.
## Invulnerability mode from the original Sonic the Hedgehog can now be used. It is enabled when the debug cheat is entered. To activate, hold A and press the start button when starting the game.
## A demo recorder has been added to the game. Hold the B button when entering a level with the demo recorder flag enabled (via the Saxman cheat) to start recording gameplay. Press the start button to stop recording. The demo will be played during the normal game demo sequence following the title screen.
## The in-game debugger from the original Sonic the Hedgehog has been imported.
## Support for 6-button controllers has been added.
## Sega 32X support added.
## The 32X version includes a new version of the Kosinski decompressor that runs on the SH-2. It provides a modest speed increase.

Additionally, the source code has been restructured in certain ways so data can be more easily maintained. For instance, the animals designated to each zone is now controlled by simplified tables that allow for easy maintanence and expandability. The same with water settings for each stage.


SONIC BOOM LEVEL FORMAT (SBLF):
I completely rewrote the code for the handling of level data. The source code still supports the original Sonic 2 level format. But now, optionally, hackers can choose to use the brand new Sonic Boom Level Format (SBLF). It does a couple things:

First, it separates physical layout from visual layout. This allows collision properties to be placed independant of their original meta-block associations. So the same meta-block at two different locations in the same level could have different collision properties assigned to it.

Second, a number of light-weight compression schemes are used so the levels take up less space in RAM.

Third, as made possible by the point noted above, levels can now be much larger than they were in the original Sonic 2. The maximum theoretical size of a level is 0x8000 x 0x2000. That's freakin' huge.

An earlier version of Sonic Boom was supported by an earlier version of S2LVL, although the current version does not fully support Sonic Boom (ring layout is, but not meta-block layout). I have provided plenty of documentation though, so interested individuals could add this support. Thanks to MainMemory for working with me on this.

In the downloads below, I have included a link to some utilities I created to convert standard Sonic 2 level format files over to the new Sonic Boom format.


DOWNLOADS:
Get Saxman's Sonic Boom engine source code and other goodies below:

Sonic 2 R3 (Genesis and 32X ROMs): https://onedrive.liv...88367A4D%211723

Saxman's Sonic Boom engine source: https://onedrive.liv...88367A4D%211722

Level layout format conversion tools: https://onedrive.liv...88367A4D%211716

SonLVL INI files (legacy level format only): http://1drv.ms/1z4fOUV

Sonic Boom engine documentation: https://onedrive.liv...88367A4D%211720

Sonic Boom Level Format (SBLF) documentation: https://onedrive.liv...88367A4D%211719


GIT HUB REPOSITORY
Saxman's Sonic Boom Engine is now on GitHub: https://github.com/saxman727/sboom

Please create a new branch with a unique name (I.e. NOT "sboom_#.##") if you wish to make modifications.


THANKS:
I didn't do a good job of keeping track of everyone who helped me in one way or another. If I forget anyone at all, then please accept my fullest appologies!

- redhotsonic
- Chilly Willy
- FraGag
- MainMemory
- nesboy43
- 87th
- MarkeyJester
- KingofHarts
- Eric Wright
- Overlord
- sasuke

I'm offering $10 via PayPal to the first person to figure this out. I tried to figure it out about a year ago and gave up in frustration. I also didn't get very much feedback from those I approached for help. I have attempted it again recently, but have yet to break the ice.

I want to turn off the V-Int entirely and use the H-Int exclusively to handle all interrupts. I have code I have written:

http://www.4shared.c...4F/s2_hint.html
(if download won't work, I can e-mail it.)

The source file replaces the 's2.asm' file from the 2007 disassembly.

It starts at the H_Int label (line 1465) and checks which phase it needs to handle (page interrupt or line interrupt). It works when used as a straight forward replacement for the V-Int, but it gets messy when attempting to handle H-Ints (used when drawing water).

Go to ARZ1 and you'll see immediately how problematic it is. I tracked it in a debugger and it appears the interrupt timing is unstable at times. What I think is happening is something is preventing the interrupts from being triggered on time, resulting in the timer being reloaded from register 10 and thus getting out of sync. As a result of this, the color lines tend to not match with the water at all, will blink repeatedly, and many other quirks. I would like to believe that this is possible, but I have not been able to pull it off correctly.

I'm serious about the money. Please, take a look at this and see if you can figure out what I'm missing here! I am good on my word and will pay the money upon successfully getting this concept working correctly without slow-downs, flickering, etc. I'm not overly concerned with 2P split-screen at the moment. It that's broken, that's fine. It's the water I'm concerned with.

My laptop is an HP Pavilion DV6-2173CL. It has had a bad fan for many months now. It's so bad, I rarely use this thing anymore because of how loud and obnoxious the fan has become (and because I'm afraid of my computer overheating unexpectedly). I have been searching a bit for a fan and found this:

http://www.laptopinv...2173CL/Fan/1215

I know nothing about fans. I've never had to replace one before. Does it matter what type of fan I get for my computer? Do only certain fans fit/work in it? Is the price and quality of that fan in the link a fair deal? Is there a better deal out there? Anyone who might be able to steer me in the right direction gets some cyber beer and pizza.

I don't have a great deal of experience with ANT scripts. I have a Java application structured like this:

/src -> source files
/bin -> "mreq" package
/lib -> JAR files
/dist -> program JAR compile

I created an ANT script that copies the /lib folder files to /bin and compiles the contents in there together to make /dist/PortableRequestDispatcher.jar. It's supposed to be a stand-alone executable JAR. The problem I found is it looks for libraries in ../lib instead of inside itself like it should. As a result, it throws a ClassNotFound error.

I don't know why it's looking for the library files outside the JAR, and my lack of experience with ANT unfortunately has made this very difficult to resolve. I'm posting the script below. Can anyone help me by telling me what I need to do differently here?

<project name="MultiRequest" basedir="." default="jar">

	<description>
		Build file for Portable Request Dispatcher
	</description>


	<tstamp>
		<format property="date" pattern="MM/dd/yyyy" />
		<format property="time" pattern="hh:mm:ss aa" unit="hour" />
	</tstamp>


	<path id="libraries.path">
		<fileset dir="lib">
			<include name="*.jar"/>
		</fileset>
	</path>


	<target name="clean" description="Clean">
		<delete dir="bin" />
		<delete dir="dist" />
	</target>


	<target name="compile" description="Compile source files">
		<echo file="src/mreq/Generated.java"
>package mreq;

public class Generated {
	public static final String BUILD_DATE = "${date}";
	public static final String BUILD_TIME = "${time} EST";
}</echo>

		<mkdir dir="bin" />
		<javac srcdir="src" destdir="bin" debug="true"
				debuglevel="lines, vars, and source" includeantruntime="false"
		>
			<classpath refid="libraries.path" />
		</javac>
	</target>


	<target name="jar" depends="clean, compile" description="Generation distribution">
		<mkdir dir="dist" />

		<mkdir dir="bin" />
		<copy todir="bin" flatten="true">
			<path refid="libraries.path" />
		</copy>

		<mkdir dir="bin" />
		<copy todir="bin" flatten="true">
			<fileset dir="res">
				<include name="log4j.properties" />
			</fileset>
		</copy>

		<manifestclasspath property="manifest.classpath" jarfile="dist/PortableRequestDispatcher.jar">
			<classpath refid="libraries.path"/>
		</manifestclasspath>

		<jar destfile="dist/PortableRequestDispatcher.jar" basedir="bin">
			<manifest>
				<attribute name="Main-Class" value="mreq.MultiDispatcher"/>
				<attribute name="Class-Path" value="${manifest.classpath}"/>
			</manifest>
		</jar>

		<mkdir dir="dist/cert" />
		<copy todir="dist/cert">
			<fileset dir="cert" />
		</copy>

		<mkdir dir="dist/cfg" />
		<copy todir="dist/cfg">
			<fileset dir="cfg" />
		</copy>

		<mkdir dir="dist/xml" />
		<copy todir="dist/xml">
			<fileset dir="xml" />
		</copy>
	</target>


	<target name="run">
		<java jar="dist/PortableRequestDispatcher.jar" fork="true" />
	</target>

</project>

What I have here is a version of Sonic 2 that doesn't use the vertical interrupt at all. It instead relies entirely on the horizontal interrupt to do both page and line code.

Here's the source code and ROM:
http://uploading.com...4f1c1/s2hint.7z

I have an issue with the horizontal interrupt timing though. I have battled with this for a while now, and I cannot for the life of me figure out what is going on. I've read every VDP document known to man, many times over. I've debugged the heck out of my ROM.

In Regen, set a breakpoint for a write to address FFF520. Go to Aquatic Ruin 1. When the debug window pops up, you can use this guide to see what's going on:

D0 = current VH pos
D2 = previous line interrupt VH pos
D4 = previous page interrupt VH pos
D5 = interrupt count
D6 = Hint_counter_reserve value
D7 = interrupt type (0 = first page, 2 = page, 3 = line)

The interrupt count (D5) will tally up how many times an interrupt has occurred when the Hint flag (Hint_enable) is on. Take a look at when D5 is equal to 0x5E:

D0 = DF17 (this interrupt has occurred on line DF)
D2 = DF79 (previous line interrupt occurred on line DF)
D4 = DF76 (previous page interrupt occurred on line DF)
D5 = 005E (interrupt number 5E)
D6 = 8ADF (reserve DF)
D7 = 0002 (do a page interrupt)

Now take a look at when D5 is equal to 0x5F:

D0 = E6A6 (this interrupt has occurred on line E6)
D2 = DF79 (previous line interrupt occurred on line DF)
D4 = DF77 (previous page interrupt occurred on line DF)
D5 = 005F (interrupt number 5E)
D6 = 8ADF (reserve DF)
D7 = 0002 (do a page interrupt)

The problem here is the 5F interrupt is occuring when the VH pos (D0) is E6xx. It should never be anything higher than DFxx. Everything is working up until this frame. But when you look at the Hint_counter_reserve (D6), it still says 8ADF.

Naturally, I begin to think that somewhere else in my code register 10 is getting changed. However, I can't figure out where. I can't figure out how. Unfortunately, Regen can't trace writes to the VDP registers which would probably be the key to this whole thing. All I can figure out so far is having an interrupt at E6xx is wrong!

Here's what the problem looks like in the game:


If the H-int timing gets thrown off as demonstrated earlier, then the game will do what it's doing in the video.



I've been trying to fix this for a month now. Is anyone out there willing to take on the challenge and see if they can get the H-int timing working properly? I know it's a challenge, but I'm hoping some of you will like the challenge and what to take a crack at getting the H-int to handle everything as intended.