Actions

Saxman's Sonic Boom Engine

From Sonic Retro

Revision as of 00:12, 2 October 2022 by Saxman (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Saxman's Sonic Boom Engine is a modification of the 2007 Sonic 2 disassembly that cleans up the code base, provides a plethora of bug fixes, and adds new functionality geared specifically toward ROM hackers.

The project started in 2011 by saxman with the intent of being an unofficial third revision of Sonic 2. The idea was that every change made to the game had to stay true to the core of Sonic 2 -- that is, changes that made the product seem unofficial would not be considered.

Inspired by Team TNT's BOOM engine, saxman decided to add new features to the engine that might be desirable to hackers interested in making their own games out of the existing Sonic 2 code. Thus, the Sonic Boom engine was born.

The name

One definition of the word "boom" is to progress or develop rapidly. The name "Sonic Boom" was chosen to emphasize the goal of the project. When Sega introduced the Sonic Boom franchise, saxman's name was added to the beginning of the name (though, the engine boot screen still says "Sonic Boom").

Version 1.00

Saxman's Sonic Boom Engine was first revealed on December 3, 2014. This release was aimed at fixing bugs and giving ROM hackers some desired features.

Engine 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.
Bug fixes
  • A mistake in the 2007 and all previous disassemblies has been corrected where the continue screen would malfunction if its associated data moved to a different location in the ROM.
  • A typo in the credits (Carolann Hanshaw) has been fixed.
  • The 14 continues cheat now plays the correct sound. The chimes for that cheat and 7 emeralds cheat were also fixed so they play when the region is set to European.
  • Rings will now wrap the level when vertical wrapping is used.
  • Collision behavior has been corrected with the final boss.
  • It is no longer possible to walk on air when walking off an arrow in Aquatic Ruin Zone's boss area.
  • Players no longer get stuck at the edge of the screen when doing a spindash.
  • The player will now move correctly while in air in Sky Chase Zone when the camera begins moving backwards.
  • The Super Sonic ring count now changes every 60 frames instead of 61.
  • You can no longer turn into Super Sonic at the end of a level.
  • Super Sonic now has a high jump when underwater.
  • The invincibility stars will disappear when turning into Super Sonic.
  • When the player has the super sneakers, the speed no longer reverts back to normal once the player goes underwater.
  • The player's speed is reset when death occurs in 2 player vs. mode.
  • Tails now has the correct speed when he flies back to Sonic after previously being underwater.
  • The speed of the music will revert back to normal after death in 2 player vs. mode. Invincibility music will also be replaced by the level music. This is assuming the other player does not have the super sneakers or invincibility respectively.
  • When turning back into Sonic in debug mode, the speed will adjust properly if the player was previously underwater.
  • The player's speed is no longer capped when trying to move in air.
  • The placement of objects in debug mode is now impossible when the player has just died. This is so the game won't crash.
  • Monitors can now be placed despite being previously broken in debug mode.
  • Tails starts at the same X position as Sonic in 2 player vs. mode.
  • Scrolling in Emerald Hill Zone has been fixed so the bottom two rows of pixels scroll as they should.
  • The bottom half of the background now scrolls correctly in Casino Night Zone for the second player in 2 player vs. mode.
  • The game will no longer crash after hitting Rexon in Hill Top Zone.
  • The vertical camera position is now correct for Tails when rolling.
  • The ring count is now restored when leaving the special stage.
  • A bug with the Casino Night Zone bumpers has been corrected. The bug was only exposed for 32X ROM builds.

Future

The next major release of the engine will completely integrate the original Sonic the Hedgehog in with the Sonic Boom codebase. That is, it will allow Sonic 1 and Sonic 2 ROMs to be built from the same code. Additional features planned are to enhance the sound driver to support PWM channels for 32X builds, as well as, implementing the Sonic 3 object manager to improve the speed of gameplay.

Sonic Boom Level Format (SBLF)

The new Sonic Boom format for levels uses a more complex way of storing levels into memory. SBLF uses some light-weight compression schemes to store a level with less memory. This also opens the door for larger levels. The maximum theoretical size for a level is 32768x8192.

The meta-block layout format is as follows:

[code] HEADER:

byte frontRows byte backRows

{ short format // visual layout } ... [frontRows]

{ short format // physical layout } ... [frontRows]

{ short format } ... [backRows]

A maximum of 64 rows are allowed for each group.

The 'format' word is broken up into the following bits:

tttttppp pppppppp

t = type p = pointer

The following types are valid:

0x00 (00000) = AST: Always specified type 0x01 (00001) = BALE: Bitwise-AND at line-end 0x02 (00010) = WOLE: Wrap once at line-end 0x03 (00011) = ZLE: Zero at line-end 0x10 (10000) = (reserved -- acts as AST) 0x11 (10001) = BALE4: Bitwise-AND at line-end 4-bit 0x12 (10010) = WOLE4: Wrap once at line-end 4-bit 0x13 (10011) = ZLE4: Zero at line-end 4-bit

For types other than AST, the pointer refers to a multiple of 2, added to address 0x8000 in RAM. For an example, if the pointer is 0x13B, the location in RAM that it is pointing to is 0x8276. The location referenced will hold row data.

In the case of AST and AST4, the pointer is used to reference a tile number from 0 to 255. No row data will be used with these two types.

The BALE format will loop a row after a certain point, and that row will be looped for the rest of the row. Because it uses a bitwise-AND operation, the row length must be a power of 2 (e.g. 16, 32, 64, etc.).

WOLE allows more flexibility in terms of setting the loop point. The length of the row can be any size. The downside to WOLE is it only wraps once. The wrap point in WOLE must be 64 or greater.

Finally, the ZLE format will assume the value of zero after the end of the row is reached.


ROW DATA FORMAT:

byte attribute byte [...]

The row format type specified in the header will determine how the row data will be formatted. The following formats are used following the 'attribute' byte:

BALE FORMAT:

{ byte metaBlock } ... [attribute + 1]

WOLE FORMAT:

{ byte metaBlock } ... [attribute]

ZLE FORMAT:

{ byte metaBlock } ... [attribute]

BALE4 FORMAT:

{ nybble metaBlockRef } ... [attribute + 1]

{ byte metaBlock } ...

WOLE4 FORMAT:

{ nybble metaBlockRef } ... [attribute]

{ byte metaBlock } ...

ZLE4 FORMAT:

{ nybble metaBlockRef } ... [attribute]

{ byte metaBlock } ...

The 4-bit formats rely on meta-block references. This means that after the first array of bytes, there will be a dynamic array containing every single meta-block used in that row. The nybbles refer to which byte in the second array is used for the given point in the level. Take the following data for example:

nybble 0, 0, 1, 2, 0, 5, 2, 2, ... byte 0x2A, 0x07, 0x0B, 0x0D, 0x5F, 0x21, ...

The actual layout would be as follows:

0x2A, 0x2A, 0x07, 0x0B, 0x2A, 0x21, 0x0B, 0x0B, ...

Because a nybble is 4-bits wide, only 16 different meta-block values can be referenced in a 4-bit formatted row. [/code]