I've been thinking about this over the past year. Well, more than a year, but definitely this past year. Old consoles, especially small home computers, have really been pushed to their limits as of the past 7 or so years. Demos are all nice and such, but I'm talking about stuff that works in game (even if it is limiting to the game engine). I bring this up, because the approach is more of
thinking outside the box - non traditional approach to the system.
Some people just want to make games. Some people just want to push the system as far as they can. I'm interested in doing both.
So I was thinking, what would be a non-traditional approach to game design on the PCE, in relation to hardware? Parallax has always been the achilles heel for the PCE. I personally think this stigma would be so much as it is, if devs had taken the time in presentation. As in, you don't need parallax everything. But if you sprinkle enough of it across a game, even if useless but fancy in specific parts, it distances that feeling of lack of parallax or depth. But that's more about polish presentation in game design than what I want to talk about here.
So how can we get parallax on the PCE? The two practical methods are hsync scrolls (think AirZonk) or dynamic tiles (think Gradius 2 @ second level). Sometimes sprites are used to help out (Rondo is filled with examples; the ghost ship areas are excellent examples). A rarely used method is tile/cell scrolling (think Ys 3). But is there another way?
I propose that there is; Sprites. We all know, or most of us, that the PC-Engine only has 1 background layer. So with that in mind, and the PCE is fast at fetching sprite pixel data in hblank, then why didn't the developers extended the PCE's sprite per scanline pixel count? If the PCE was capable of 32 sprite cells per scanline, there wouldn't be a need for a second BG layer. I could make some examples that would run in an emulator; the parallax layering would be quite nice. It's a little more work on the cpu, but it's cheaper. But the PCE can't. So how does this help us?
The problem is that the sprite pixel count per scanline is exactly 1:1 to the PCE low res. Can we change this? The answer is
yes. The VDC is very powerful in its frame defining attributes. You can clip the screen, on both ends, horizontally in 8pixel increments. For instance, I could setup the screen to only show 240 pixels. I've now changed the SPL (sprite pixel line limit) ration from 1:1 to 1:0.9375.
This in itself is significant, because I can actually scroll an un-interruptable stream of sprites from edge to edge. On a 256px wide screen, at any given point scrolling a solid horizontal stream of sprites would be either 16 or 17 sprites per scanline. As soon as you hit 17 sprites, which is going to happen ~99% of the time, the overflow limit kicks in and one of those sprite cells will drop out. That breaks the illusion. But with a 240px wide window, the requirements will be 15 or 16, and since 16 fits within the SPL (16x16=256px) - the illusion is maintained. You can visualize this as a block wall that a sprite can't appear in front of.
But what if we take this even further? What if did 224px wide screen? Or even lower.. 208px screen? Now keep in mind the resolution of the pixel itself isn't changing, so the pixels aren't getting any fatter - it's just clipping the display. So at this point, you're probably thinking that's not going to look so hot. Black borders on the side of the screen usually aren't desirable, right? I counter that thought with..
maybe. If you saw the PCE doing some really extraordinary things, with that clipped window, you might change you mind.
So far, this is all talk. Why not look at an example:
-0000.png)
Recognize that game? (You better!) Yeah, the scrolling is kinda choppy, but there are a lot of fans of this port (myself included). While the scrolling might be choppy (it's 15fps on average), the gamelogic itself is not. Which actually makes the game playable, even if a bit awkward as first. That why people/gamers tend to get used to the scrolling.
Anyway, that's not the point of the example pic. Look again. See those black borders on either side of the screen? Let's put some numbers to this screen shot. First, from the edge to edge horizontally of that gold border, it's 288 pixels wide. The actually playable area, inside that window, is 256 pixels wide.
This game runs at a higher res than the standard PCE used resolution. So those numbers don't really mean anything because they aren't in low res form. So let's change that. Mid res is ~7.159mhz and low res is ~5.369mhz. So mid res is 4/3 more pixel area (horizontally) than low res mode. So the first number: 288 / (4/3) = 216. And the second number: 256 / (4/3) = 192.
So if the game ran in low res mode, with the correct window aspect ratio, the edge to edge horizontal gold-ish/trim border would be 216 pixels wide. The playable window inside it would be 192 pixels wide. The idea of
that much clipping sounds horrible, or at least unpleasant/undesirable, and yet when you play the game.. it isn't really that noticeable. To top it off, the vertical height of the playable window in that game.. is 128 pixels!
Bringing this back into prospective, I made the suggestion of 208px wide screen (viewable area). That's only 8 pixels shorter than the border with, and 8 pixels larger than the active playable window. 208/16 = 13 cells to fill edge to edge, and +1 for scrolling so 14 cells needed for edge to edge streaming/scrolling. I just want to clarify here, when I talk about edge to edge streaming - I'm talking about a solid horizontal stripe of sprites going across the screen without interruption. This is worse case scenario, because not all of a BG layer made of sprites would be solid runs of sprite pixels or cell segments.
The idea to create large sections of a scrollable fake BG layer with sprites. This layer could be the background, or the this layer could be the foreground.
I think a Sonic type design would a good example of a foreground method, simply because the far background in sonic is edge to edge (think of the green hill zone, the lake and the mountains).
Here's a pic:
I enlarged the viewable area to get a sense of the foreground design, but the yellow tinted block is a 208x160 window.
Let's switch to a more zoomed in view with 16x16 cell definition:
Each square is 16x16 pixels in the above pic. Assuming a game like Sonic, the main character isn't going to go behind that wall, so if the camera is focused on the main character being in the middle of the screen, that wall doesn't present a problem. But notice cell segment just below the top grass line and the wall to the right of it. Together, of the camera scrolled over more, would make a solid edge to edge row of sprites. This won't be a problem because we've allowed up to 14 cells per width for this very issue. With sprites being the foreground layer, though, we're optimizing for that open area above the grass line. There are a lot more open areas in the green hill zone of Sonic 2.
What about the grass that appears on front of Sonic's feet? That constitutes sprite overlapping, increasing that cell limit for whatever scanlines affected by it. If the main character was 32x32 sprite cell, and the edge to edge scenario only takes up 14 cells max, then we're exactly at the 256px sprite scanline limit.
Are you going to run out of SAT entries doing this? At a 208x160 viewable window, it's 7x5 entries if the ENTIRE screen was filled with 32x32 sprites. That's 35 sprite entries of the 64. So I think we're in a pretty safe zone. If even that max was pushed to 48 entries, for whatever reason, that still leaves 16 entries open for the character and enemies. More than enough for considering sprite objects can be quite large. Do the sprites for the pseudo layer have to be 32x32 in size? No. I would do a 32x32 tilemap system, with a meta tile lookup table that would be capable of displaying any size and combination of multiple sprites inside that definition (including fine pixel offsets).
In this Sonic type example, the foreground would be all sprites and the background would be the real BG layer. Well, hsync scrolls are easy to do on the PCE, so all the nice background parallax/linescrolling is easily replicated on the PCE. The Chemical Zone in Sonic 2 would be even easier to do on the PCE than Green Hill zone.
I personally think this would be an impressive sight to see. Combine this with the PCE's color capabilities and we've got a win IMO.
Now to take this one step further; what if the game ran at 30fps instead of 60fps, but added even
more complex layering scenery/capability? Stuff like complex dynamic tiles (larger areas), and realtime masking/ORing pixel data over sprites to do more complex fake sprite layer (ease the limitation of solid areas and add more possible enemies). I mean, there are games on the PCE that run 30fps (like Tenchi o Kurau).
It's note just parallax layering that's an issue on PCE, it's also more shallow depth issues that plague the system. As in if the BG layer is the foreground - it's rare that anything shows in front of sprites/enemies/main character simple because the PCE lacks the per tile priority for this. Using the TRB instructions, which both ANDs and copies sprite data from vram to vram, a game engine could easily be setup have complex layering depth on a per pixel basis of objects in relation to the BG layer. Think of light posts, signs, grass, etc - appearing in front of a sprite object without the need to use sprite masks, which wastes SPL bandwidth.
There are many options, configurations, and combinations one could use, in relation to this, but the idea is to think outside the standard design approach on the PCE.
The question to the PCE gamer is: would 60fps game with a clipped window be an issue? Would 30fps be an issue? Or 30fps and a clipped window? Where would you draw the line when it comes to squeezing out the most of the PCE graphical capabilities?
PS: I'll edit for any grammar mistakes later. This is all off the cuff.
