Technical question about PCE resolution choices

[spenoza]

Maybe Chris or Bonknuts would be the best to answer this, but anyone with any info should chime in. Why was the 256 x 256 resolution on the PCE used for so damn many games? Why not 320 more often? Were they artistic choices (they liked having all the graphics stretched to 4x3 from 1x1) or technical considerations? What were the technical trade-offs?

Considering the PCE is considered, here at least, to have just as powerful a CPU and sprite blitter as the Genesis and SNES, why would they opt for lower resolution than any other system on the market? That just seems like market suicide. Clearly it went over OK in Japan, but what was up with that?

[ccovell]

Ooh, my favourite kind of topic. 

You could look at it technically: with a 320 (or more, typically) resolution, you can't have a fake layer of sprites going all the way across the screen (maximum is 256 pixels).  Or more commonly, having that extra bit of horizontal resolution would mean more sprite flicker.  But basically, some of the best games on the PCE were in this higher resolution, so this technical limitation is extremely minor when the hardware is in good hands.

You could look at it artistically/culturally: On the one hand, most/many of the PCE developers came from the NES/Famicom world, and treated the PCE as just a souped-up Famicom, especially at the beginning of the PCE's life.  Meaning blocky graphics, low colours when a lot higher number of colours could have been used.  They just didn't push themselves far enough at the beginning.  The most impressive games (with more colours and higher resolutions) came from the companies experienced with Japanese PCs.

On the other hand, a lot of the (earlier) developers on the Gen/Megadrive came from the arcade world, experienced with the 68000 CPU and the wider (typically 320) resolutions of their arcade games.  Either that or they came from the PC world, did X68000 ports, etc.

That's one big difference, as far as I see it.  The PCE was treated by too many of its programmers & artists as an "NES with knobs on", to misquote one British developer.

[nat]

Considering the PCE is considered, here at least, to have just as powerful a CPU and sprite blitter as the Genesis and SNES, why would they opt for lower resolution than any other system on the market?

Correct me if I'm wrong (and I'm sure someone will) but didn't the SNES opt for the lower resolution most of the time, as well, just like the Turbo? I mean, I'm trying to think of an SNES game that used the higher res and I can't. They all are 256x256 (or something close to that).

[TurboXray]

The SNES is basically limited to 256x224. It has a higher res mode for BG (not sprites - they are pixel doubled if you will) but it's not practical and you lose a lot of the SNES abilities with it. I know of one game that used it for text box for an RPG.

 Saying stuff like 256 or 320 horizontal pixels is misleading be cause it's not the same as with PC res of the VGA tweakable register set. You sometimes see mid res referred to as 320, 336, 344, or 352. It can be any of those and still have the same pixel size.  To keep things simple and the ratios the same, the res' are 256, 344, 512.

 Using the 256 res gives some advantages. First off, in relation to a picture onscreen it uses the least amount of video memory. This means you have the most room for tiles and sprites in VRAM. Second, the pixel aspect ratio is easiest to work with. Its pixels are more "square" than the other resolutions in appearance. Third, it offers the best configuration for sprites on screen before you run into sprites per scanline limit. If the limit is reached on a given scanline, the video processor will stop fetching/showing sprites for the rest of that line. The solution is alternate sprite orders,i.e. flicker. With flicker you can at least see the sprites if overflow/limit happens. The sprite limit per scanline is 16 sprites or 256 pixels - which ever comes first. Sprite limit is effected by the whole sprite, not just the visible part. If you have a sprite "bullet" that is 4x4 pixels, the sprite itself is really 16x16 pixels. So if a visible sprite is 18x16 pixels, it uses a 32x16 pixel sprite. Makes you wonder why some PCE games use small objects when they have such extra space for free.

Some programmers are really good at sprite management and other were careless. One example is Parodius. That pirate cat ship in the first level with those cat paws as oars? Those cat paws are extra sprites on top of the cat ship made of sprites. Same with the cat head. They could have easily made a merged layer for the cat paw animation and the cat head, reducing the sprites by quite a bit and this reducing flicker - but they didn't. The same goes for SF2:CE. There are quite a bit of places where they wasted sprite layers, causing flicker (done a lot of hacking with that game).

 The problem with the 344 and 512 res modes is that you still have the same 16 sprites or 256 pixel limit. It doesn't scale with the resolution as it should (there's enough video processor resource, its a hardcoded limit). Like with Chris said, it requires a bit more optimization and cleverness to use the higher res modes. So, other than the sprite limitation it comes down to memory. For hucards that means a larger rom and for CD games that means CD RAM is less efficient.

 Quite a few Genesis games use the 256x224 res mode to save on memory. Street Fighter 2 is one them. And SNES games are pretty much stuck with it.

[ccovell]

The SNES had only a 256 horizontal resolution, and a 512 (slightly goofily-arranged) horizontal resolution.  It couldn't do anything in between, unfortunately.  Would have made arcade ports a little better-looking (SFII all across the board, perhaps?)  Several RPGs use the 256 mode for most of the screen, then the 512 mode for text display in the rest of the screen.  Secret of Mana is a pretty famous game, and it uses it in places.  Syvalion uses the 512 x 4xx resolution, while RPM Racing uses the 256 x 4xx resolution.

The SNES' vertical display could be interlaced, as in the games above, but usually games were either 224 or 239 lines vertically, similar to (but technically 3 lines fewer than) the PCE's maximum vertical resolution.

[spenoza]

Well, I shall consider myself enlightened. I guess I've always felt the different between playing PCE games in an emulator and on TV seemed to have more stretching going on and the emulator always felt more square-ish. I assumed this was because the GEN and SNES were comfortably capable of 320 x 240 and used it for most of their games. I went and did some reading elsewhere after reading your responses and discovered I've been under some crazy misconception.

Thanks for the info!

I swear, if I was gay I'd have to ask potential mates to "talk techie to me".

[Keranu]

I swear, if I was gay I'd have to ask potential mates to "talk techie to me".

Totally! But you could also get a tech chick to talk techie to 'ya.

[Turbo D]

doode, those tech chicks are hard to find (well, maybe the hot ones, lmao!). They're like rare pokemon.

[spenoza]

I already have a wife. She doesn't talk techie to me, but I wouldn't trade her for one who does.

[Keranu]

You could always have your wife read out of a C Programming book or something ;) .

[Turbo D]

Keranu is right, role-playing is a good way to fire up the sex life, lol.

[NecroPhile]

Keranu is right, role-playing is a good way to fire up the sex life, lol.

That and anal.

[spenoza]

Wow, you guys want me to never get laid again.

[PCEngineHell]

Nah,just the ultimate goal of ruining your marrage,sex life,and over all well being and mental state,nothing major. If you wanna do sumthin major fun,have her dress up as  anun,and read the bible while you are behind her spanking her,or whatever else pleases your dirty foul mind,yea,that will make sure you stay married forever.

[CrackTiger]

I think that stuff like title screens, RPG battles, puzzle games etc should've use higher resolutions more. Not every game is a horizontal shooter.

Even if the shading per screen portion didn't increase, it'd still look nice for things like cinemas to have sharper edges. Many great CD2 cinemas have multiple loads during a single cinema and are still impressive. If high res cinemas in a Super CD game would mean a few extra load times, that'd be fine by me.

[spenoza]

I wonder what determined sprite limits at the time. Obviously they are coded into the hardware, but what elements of hardware capacity influenced their choices? Our only option is to cut open the heads of the designers and extract the information with grapefruit spoons.

And yeah, what BT said    I'm all for high-res RPG battles. Or heck, even the exploration screens. That'd be even more useful than in battles.

[TurboXray]

 PCE is unique in that it has an internal buffer and 16 hardwired registers for each sprite on a scanline. The sprite table is transfered into the a special area of the chip right before the start of the frame. What ever changes one makes to the sprite table isn't updated until the next frame. Since the video processor doesn't have to "fetch" sprite info entries from vram like the position, size, flipped modes, palettes, sprite number (etc), it is able to give the CPU read/write access to VRAM during "active display". In 7.16mhz or 10.5mhz mode of the VDC, it has enough speed to handle more sprites and still have resource to let the CPU read/write to VRAM, but there aren't anymore internal registers to handle them. They could have increased the internal registers to more than 16, but such type of registers are a cost issue. Note: 5.37mhz mode is 256 pixel mode.

The NES, SNES, Genesis, and other systems are different. They have a buffer that they fetch all necessary sprite data per scanline into. Once the buffer is full OR it runs out of time, it stops fetching sprite data. There are *no* slots open for the CPU to access VRAM during active display on those systems because the processor is tied up busily reading from vram for both the sprite table and sprite data (among other things). These systems make all changes during what's called vblank. Vblank for consoles loosely means the area outside of the active display. If the SNES/GEN display is 256x224, then it has 38 scanlines of vblank. Some SNES and Genesis games turn off the display even earlier to gain more vblank time. To aid them the SNES and Genesis have a memory controller(DMA) that stops the CPU and transfers data from the CPU memory to VRAM for vblank because neither CPU is fast enough to transfer the data themselves considering a games structure.

 The PCE has something similar in the form of CPU instructions though not quite as fast, but is not limited to vblank window of time. You can decode/decompress tilemap areas directly to VRAM without having to use main ram as a buffer,i.e. scrolling. Another advantage is that the PCE can have more than 64k if graphic data shown on screen at once even though VRAM is only 64k. It can write to VRAM ahead of the display as the display is drawing. I don't know of any games that uses this though. There are still some tricks you can do with the PCE's video system that no developer has done. Like reading out X/Y scroll tables from VRAM for hsync effects or using VRAM as buffer to store and play a frames worth digitized PCM samples at 16khz with less overhead. And still another advantage is that you can directly output to VRAM from a renderer, like a scaling routine or a raycaster engine. I have a test engine that converts bitmap or rendering on the fly directly to VRAM and automatically converts the pixel data to planar using clever arranged tiles and setting the vram write incrementor. Did I mention it's really fast too?

 
 Maybe you could find some hot college girl to read that to you 

[spenoza]

Hrm... technical questions answered. Now if only I could find someone to add proper functions to Mednafen to support TASing.