Monday, July 9, 2018

An overview of the new API features in SonLVL

Okay, here we go. As promised in my previous post, here's a rundown of all the features MainMemory has graciously added to SonLVL's API in order to support my ongoing object definition adventure.

Debug overlays: Like I hinted at in last week's post, objects now have the option of drawing a secondary sprite, which is rendered with high priority above all regular sprites and level blocks. The most basic use of this feature is to plot out the movement patterns of continuously moving objects, such as floating platforms.


Beyond that, I also made it so that objects which are configured to move to a predetermined position will plot out the location of their collision box at the end of their movement pattern.


Streamlined sprites: Under the hood, the sprite rendering code has been greatly improved, resulting in faster load times and smoother scrolling when compared to previous versions of SonLVL. Sprites are also refreshed more often now, allowing me to do crazy stuff such as have crushing objects automatically detect the floors and ceilings as you drag them around the level.


Depth and priority: SonLVL now considers VDP priority information when rendering the main level view: high priority level blocks will hide any overlapping sprites, unless they are also set to high priority. Objects can now also optionally report the sprite's SST priority value, known here as depth, for proper sorting between sprites.


Extra colors: Four additional color palettes are now available in each level. These are hidden in the editor, but can be used by sprites in order to render objects which normally overwrite one of the palette lines, such as bosses, as well as grant the Knuckles player start its proper coloring.


XML player starts: Player start markers can now be defined using a limited subset of the XML syntax for regular object defintions, allowing for custom poses in each level, as well as composite sprites where necessary.


Layout swap option: This is a big one. It allows level configurations to define a set of layout copy areas in its level layout, and then swap them into the main layout through a menu option. This is absolutely vital while editing LBZ1, but also quite useful in FBZ, and to a lesser extent AIZ1, LBZ2 and SOZ2.


Animated PLC support: Levels can now optionally load blocks of uncompressed art, which are then rendered in place of the placeholder blocks in the main level view, allowing for a level's animated tiles to be rendered as they appear in-game. This is a really big one because it's not useful for just Sonic 3; MainMemory has already gone ahead and added animated tiles to the Sonic 1 and 2 level configurations.


So that's where we stand. The whole thing is still a work in progress -- only the S3 levels are done at the moment. If you're feeling intrepid enough, you can always grab the current stuff from my personal Git repo; constructive feedback is highly appreciated if you have any.

Monday, July 2, 2018

What I've been up to this whole time

It's been a while, huh?

You may be wondering where the hell I've been. Unfortunately, progress on the hack is pretty much where I left it four months ago -- I've produced a couple of assets and had a couple new ideas, no doubt in part due to all the crazy Mania Plus stuff just around the corner -- but I seem to have a knack for getting into digressions which soon become much more work than anyone could have reasonably anticipated.

Case in point: right now, here's what your average Sonic 3 stage looks like when opened up in the SonLVL level editor:


Urgh. A bunch of floating question marks, the actual level layout covered by a brick wall, and to round it out, a couple of placeholder numerals hanging around near the corner.

Now, let's check out what the same section looks like when using my work-in-progress SonLVL configuration files:


OMG there's so much stuff to talk about in this screenshot.

What you're seeing here is the result of a semi-joint venture between the author of SonLVL, MainMemory and myself, with the goal of providing a complete set of SonLVL object definitions for Sonic 3 & Knuckles. Essentially, what that entails is reverse-engineering the original 68k code, and producing accurate representations of all the objects within the level editor.

This process can be further boiled down into three core points:
  1. Identify every object ID used in a given stage, and give each of them them human-readable names;
  2. Document the effects of the subtype byte and the X/Y flip flags on the object's behavior and appearance, and provide a reasonable way for the user to view and modify these properties;
  3. Render a visual representation of the object, which should first and foremost be accurate to the object's in-game appearance, and if possible, illustrate the object's movement pattern as defined by its properties.

Let's focus on that last point. SonLVL already has a definition for Sonic 2's invisible block object, which highlights the object's actual size by drawing a yellow box around the rather unhelpful Tails block that appears in-game.


Upon porting this object to the Sonic 3 side of things, I quickly realized that a similar concept could be used to illustrate the alternating movement pattern of objects such as retracting spikes, thus making them stand out from their stationary brethren. Just draw the spikes at their "on" position, and the box at the "off" position!


There were two problems with this idea. Since the box was logically part of the object's sprite, you couldn't draw the spikes without the box, which ruined the map export feature. This wasn't an issue with the invisible block object, since its status as a "debug object" meant it didn't appear in the exported map anyway.

The other problem was that because the sprite was now twice as tall, so were the object's selection bounds!


Yuck!

No, if I was doing this, I was doing it right, which meant that somehow, I had to make SonLVL draw an optional "debug overlay" on top of an object's regular sprite. Luckily, I was already in talks with MainMemory at this point, and little did he know, I was about to make him work on SonLVL more than he had during the entire preceding year.

Next time, I'll go over all of the new features, and how I'm currently using them to make the Sonic 3 object definitions vastly superior to the ones available for previous titles.