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.

9 comments:

  1. I sure like that sprite floor detection stuff going on. MainMemory has done well here.

    Also I've not had a chance to comment on here but I have had a good look at this blog from time to time and I do appreciate what you've done with breaking down Sonic 3 much further than what most people have done. It truly shows that there is still plenty of research to do on these games.

    I also look forward to playing the hack when you are ready to show it off.

    ReplyDelete
  2. This would have changed the amount of development time I spent on Sonic 3: D.A. Garden Edition significantly... Oh, well. In hindsight, eh?

    Also, I know you're a way off, but Lava Reef Zone Act 1 has a 'rock object' definition file it uses for the floor (MainMemory definitely knows about this). It works in a similar way to Casino Night Zone's bumper objects, but is used a lot more significantly across the Act, and I'm curious as to how you would handle it.

    ReplyDelete
  3. I know this is a pretty basic question but why does Sandopolis have significantly less data left over in S3A compared to Lava Reef? it seems like the amount of data left intact for the S&K levels gets smaller and smaller the later into the game it is. Flying Battery being the most intact, Mushroom Valley coming in 2nd, and Lava Reef coming in 3rd and so on and so forth but why does Lava Reef have more than Sandopolis? I'd think since Sandopolis comes before Lava Reef in the level order, they'd have worked more on Sandopolis than Lava Reef. But I guess Sandopolis just wasn't a priority.

    ReplyDelete
    Replies
    1. Dude, they don't work on zones in order, It's not like they work AIZ, Then HCZ, etc.

      Delete
  4. This is going to make object editing even easier to handle than it is in Sonic 1 & 2! Great work as always.

    ReplyDelete