New post.. new video!

So this is something I’ve been talking about and wanting to do for about 10 years now. It’s an object-based map for the pc-engine. In this context, the object pretty much means metasprite. The metasprite object is a collection of hardware sprites with all their relative attributes, as well as an X and Y offset. Since these are objects and not tiles, they’re fixed to a specific alignment to the grid. They’re defined by a grid, but directly resolved to the grid. I.e. you can have an object that is +2,-5 for x,y an offset. The individual cells in the meta-object can be set to show in front or behind the player and enemy sprites.

The first question I always get asked is.. isn’t it going to flicker??? Well no, not necessarily. There are limitations; I’m not going to hide that fact. But the limitations are actually pretty tame in comparison for what this offers.. an additional layer of parallax. You can see the demo for yourself, running on a real PCE. The 2nd question I get asked is, doesn’t it up a lot of sprites? And the answer to that, is generally no. The number of sprites being displayed (actual hardware sprites).. including the player and all enemies you see on screen, is located in the status bar.. to the upper left. This number is in decimal. I don’t think it ever goes over 40 and that includes player and enemies on screen for that frame. In this demo, the max size sprite I allow is 32×32, but I have an update that allows a 32×64 and 16×64 sprite sizes. This helps bring the number down when you have more complex scenery.

So, a little background on this object engine. It’s very cpu resource light. Since the object layer is on a 32×32 grid, it’s pretty quick to scan through the map. The map entries are metasprites and those get decoded with their x/y offsets being added to the current position of x/y. The routine then checks if the sprite is partially onscreen. If it is, then checks the size and does any necessary clipping of the object. So say one block has a 32×16 sprite, and is at the left side of the screen, well if 16 or more pixels into the left side of the screen then the code converts it to a 16×16 and adjusts any offsets. You get very efficient left and right side automatic clipping. And of course, it only parses a slighter larger window than the screen, so I can have maps the size of 16384×16384 pixels and that doesn’t affect performance in anyway. The clipping helps reduce any potential sprite scanline limit. Another requirement for this to work, is that the visible screen area needs to clipped. Some PCE games already do this for scrolling psuedo-layer via sprites. The PC-Engine allows you to set both the horizontal and vertical display able, regardless of resolution. In this demo I opted to set the visible horizontal area to 208px. It didn’t need to go that small, but I wanted some additional overlap sprite capability (not currently in use in the demo video though). In comparison, even with this demo clipped to 208px, it’ll still show more active window area than Ys 1&2,3, and 4 on PCE (and ports on other systems). In my opinion its totally worth the traded off. The visible area also gives the sprites a more pronounced screen real-estate presence in the active window. The minimal clipped size needs to be at least 240px horizontally, but you do have to be careful about how many sprites you put on screen. The more 32×32 or 32×64 you can get on screen, the better. The nice thing about this approach is that it can be paired with other effects – giving it even more ability as a layer. But that’s an advance topic for another time.

I use Tiled to edit the maps. It’s a pretty nice tool. I actually use it for the level design, with a layer for collision and a layer for enemy and game object placement. I wrote some python scripts to convert the Tiled format. I’ve written some gui tools to help aid in making the definitions for the metasprite objects, including an automatic color sorting algo that creates the palettes for me. My object-to-map collision engine is actually separate from this object map engine. There didn’t seem to be an advantage to making it a dependency of the object map engine. The demo itself has a lot of real game logic in it, including actual sprite sheets (as meta-tables), animation frame tables, enemy AI states and logic, etc. Because this is an actual game engine I’m working on, and not just a demo, it has real moving parts. I know that’s sometimes difficult to distinguish from demos that are a proof of concept but no actual game engine logic driving it. The purpose of this demonstration isn’t to show off the game engine itself (as clearly, slope collision is missing), but rather the object map engine in how effective it can be on the PCE. But what you see here is in-game test footage.

I’ll release a few playable demo roms. I want to create a few different levels (game tributes) to show its use. I do plan on making the PCEAS source code/lib available, and hopefully an integrated HuC version as well.

1 thought on “Started a new blog for PC-Engine related development

  1. incrediblehark says:

    This is some really impressive work with the PC Engine, and I’m always happy to see more PCE projects out there… I’ll be watching this periodically and hoping to one day be able to play a finished game!

Comments are closed.