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.