Why are PCE games that use >= 320 horizontal res so rare?

[spenoza]

I have always wondered about this. The PCE can generate 320 horizontal resolution. Why didn't more games use this mode? I realize that, unlike the Genesis, the PCE can't support a full line of sprites in this resolution, but shy of a hori shooter or scrolling effects, I'm not sure that's necessarily a problem. Were there other reasons to avoid this larger resolution?

[Black_Tiger]

I think that at least half the library uses horizontal resolutions higher than 256 pixels and probably most games in general use a higher vertical resolution than MD/SFC.

Years ago I started counting some of the games I could confirm used a >256 wide resolution and I probably only checked half the library at most. I stopped when I found well over 100 that used a higher res for a significant gameplay portion and over 100 other games which used a higher res as well.

The main deterrent to using higher resolutions was the extra space they ate up, while the PCE could already do more than well enough at its lowest resolution.

[spenoza]

I don't know of any console that uses 224 on the horizontal. I thought the standard lower res was 256 along the horizontal, for PCE, MD, and SFC.

I'm not talking about bumping up the res for a menu or the fake TATE modes in some shooters. I guess my experience has been that when I boot up a game in an emulator (I can't tell so well on real hardware) in a window and don't stretch the window (so that it uses square pixels), most of the games I've sampled have an almost square display. If that many games were using 320 horizontal the window would be approximately 4x3 when using square, un-stretched pixels.

But it's also possible I was very selective about what games I tested. Games known for scrolling and parallax are most likely going to use the smallest resolution. The SNES rarely used greater than 256 horizontal, but the GEN used 320 horizontal quite regularly, but it also was able to better accommodate that resolution with corresponding sprite handling improvements.

[Black_Tiger]

The 224's were a typo. But many PCE games do use a vertical res of 240 instead of 224'ish like MD/SFC.

I never counted tate mod resolutions either, but it's the same difference, esoecially for ports of tate games and it's no different than Mega Drive games with a vertical side bar.

All of the SNES Modes have compromises. The most popular Mode or two has a HUD layer with extreme color limitations and looks like a b&w Gameboy game on a Super Gameboy with palette swaps. It really clashes with the rest of the visuals.

The Mode that uses the wider resolution has similar extreme color restrictions, only for all of the graphics (and I think only a single later). The end result looks like a high res NES game. I believe that RPM Racing is the only game which legitimately uses it for a gameplay segment. I think that the handful of other games used it as part of a split-screen resolution for text.

[gilbot]

Just registered here because of PC-Engine-FX would sadly become read-only soon. Sorry for digging up an old thread.

According to Hiromasa Iwasaki, NEC actually advised against using resolutions with more than 256 horizontal pixels.
The reason was something like according to specs, the VRAM would be slightly overclocked when the limit of displaying 16 sprites on a single line is hit, and it's only safe to have at most 14 sprites on each line at the same time, though Iwasaki's explanations were a bit... hard to believe, like stating each sprite was 32 pixels wide (as opposed to 16, as far as I remember if you use a sprite 32 pixels wide it's actually counted as TWO sprite cells during display). Maybe I was just not competent enough to understand what he said, or maybe it's been too long ago that his memory were a bit hazy?

I'm not sure but I think there was no hardware option to keep the maximum number of visible sprites on a line to 14 (and even if that was, that means sprites had even fewer than 256 pixels of coverage in 320 mode, so that could also make it a less popular choice) and it would be tedious to check this every line in software.

So I think the higher resolutions were usually used in less sprite-intensive (or where it's easier to manage what were being displayed) games, such as RPG and adventure games, etc.

As explained in the linked articles, R-Type adopted the 320 mode to make it as close to the arcade version as possible, but then Hudson received a warning from NEC for not following the specs. NEC eventually allowed the publication of this game(s) as a sole exception (probably since it's an arcade perfect port and definitely an early killer app of the system). The game was updated to follow the specs for the western release (and by extension, Complete CD) with the price of more sprite flickers.

While it's not that uncommon for a PCE game to adopt the higher resolutions it's still not as common as the Mega Drive, in which a few games used the higher resolution on MD than on PCE.

There were also cases where later installments of a series used a lower resolution. Two examples I could quickly think of are:
1. Puyo Puyo CD Tsu used a lower resolution than Puyo Puyo CD. Maybe there were more stuff moving in the sequel? Or, maybe it's just because they're developed by different people.
2. Ys IV actually ran at a lower resolution than Ys I+II (couldn't remember which mode was used in III, but as that game was so different it could be excluded in comparison). Maybe it's also because of more stuff happening in IV, but while the graphics in I+II were great, IV looked even better(possibly due to the involvement of the late animator Toyoo Ashida), despite the lower resolution, which proved that with talented people and enough experience slight difference in resolution would not be a main factor on whether a game looks good.

[ccovell]

Apr 25, 2018 14:39:29 GMT spenoza said:

I don't know of any console that uses 224 on the horizontal.

1941 on SGX at least uses a 224 horizontal resolution, probably to keep the vertical appearance from the arcade game.

About NEC's edict to use 256 horizontally, that's just the company being overly conservative.  What a shame.

If I remember, Charles Macdonald in his PCE technical docs says that the PCE used some of the fastest VRAM chips available at the time, so the PCE could manage higher resolutions with full sprites just fine.

The PCE hardware starts dropping sprites if you make the screen too narrow, but sprite drawing only goes haywire once resolutions get set to 580 pixels or something huge (from my Dim Test program).

[Galahad]

It would nice if someone documented the games that use 320 pixels.

[ccovell]

More info: gilbot above has the right to be suspicious of Hiromasa Iwasaki's posts / NEC's reasoning for NO res > 256.  I'll quote Bonknuts from the other PCEFx forums:

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)....Yeah, there's enough hblank time to handle more sprites per line. There's also enough free access slots during active scanline - more than what the cpu is capable of using even with extreme code. Even the entire SAT is copied into special ram (nor vram) for super fast access/parsing. So it has all the bandwidth needed to show more. The PCE doesn't use a line buffer system like the Genesis and SNES, but instead uses dedicated sprite shifters. So the limit doesn't come from bandwidth, but rather the number of shifters. A line buffer system uses the previous scanline to fetch sprite pixel data and display it on the next scanline (snes/gens). But the PCE builds and shows the sprite on the same line. Supposedly sprite shifters are more complex and more expensive (chip real estate and cost). The VDC is fast enough to handle more, it just needs more sprite shifters to hold more pixel data.

And from Elmer:

The VDC only uses approx 50% of the bandwidth of the fast VRAM, and that allows the CPU to have unrestricted access to video memory. That's extremely rare to see in a console of the time, and allows programmers to do all sorts of neat tricks.

OTOH, using the same fast VRAM specs, something like the Genesis uses that extra VRAM bandwidth to display a 2nd background layer.

But the tradeoff is that the programmer is locked-out of doing any writes to VRAM while the display is active, and can only do updates in the very-limited horizontal and vertical blank periods. That is incredibly limiting, even with the Genesis's (not-very-good) H-DMA and V-DMA hardware.

In my experience, a lot of the power of the 68000 processor in the Genesis is thrown away because you just can't do much useful work while you're waiting for the next h-sync so that you can stuff a few bytes of data into VRAM.

So Iwasaki in his post was doing his math in terms of line buffers for BG pixels and SPR pixels on one line, but that logic appears not to apply to the VDC in the PC-Engine; thus the reasoning is incorrect.  There is no danger in high-resolution modes (we think) because the limitation is not one of speed or timing per scanline, but rather a hardcoded limited sprite slot number (16 slots per scanline).

[Deleted]

I still don't get why the PCE can display only 14 sprites per scanline on 320 h-res mode. Is it related to the 5.37 mhz clock too (being too slow to build all 16 sprites)?

Also, since people are talking about VRAM speed: isn't the PCE supposed to have unrestricted CPU<->VRAM access at all times? When I was designing how I would approach road rendering in my racing game I simply assumed that I would have enough time to change at least 8 colors per scanline, which backfired immensely since in real hardware the PCE repeats the current "pixel" like ten times or so horizontally generating this ugly artifact. I ended up having to place palette changes in the hblank and this limited me a lot (now I get why some PCE racing games keep two different colored copies of the same road graphic to change its color via BYR instead).

[elmer]

Jan 17, 2019 6:49:29 GMT gilbot said:

Sorry for digging up an old thread.

According to Hiromasa Iwasaki, NEC actually advised against using resolutions with more than 256 horizontal pixels.
The reason was something like according to specs, the VRAM would be slightly overclocked when the limit of displaying 16 sprites on a single line is hit, and it's only safe to have at most 14 sprites on each line at the same time ... or maybe it's been too long ago that his memory were a bit hazy?

Thank you for bringing this back up and pointing out those interview posts; you've sent me down an absolutely fascinating rabbit-hole that I've not seen talked-about before.

I think that Hiromasa Iwasaki is entirely correct in his overall impression, but he just didn't remember the exact details quite correctly.

There *is* a hardware limit of 14-sprites-per line in the TurboGrafx R-Type HuCard and the R-Type Complete CD , different from the Japanese R-Type HuCard ... and it's pretty obviously because NEC or Hudson is enforcing some technical standards on the developers.

Jan 17, 2019 23:55:24 GMT Galahad said:

It would nice if someone documented the games that use 320 pixels.

Yes, I'd absolutely *love* to have a list of games that I could go through and look at to investigate this more.

The medium-res games that I've looked at are ...

Daimakaimura	Japan	HuCard
Legend of Hero Tonma	Japan	HuCard
Mr Heli	Japan	HuCard
Puyo Puyo	Japan	CD
R-Type Part 1	Japan	HuCard
R-Type Part 2	Japan	HuCard
R-Type	USA	HuCard
R-Type Complete	Japan	CD
Zero Wing	Japan	CD

Jan 17, 2019 23:29:37 GMT ccovell said:

About NEC's edict to use 256 horizontally, that's just the company being overly conservative.

Yep, there *does* seem to be a real issue involved here, but it doesn't seem to be too difficult to take into account.

Jan 18, 2019 1:02:06 GMT ccovell said:

I'll quote Bonknuts from the other PCEFx forums:
...
And from Elmer:
...
If I remember, Charles Macdonald in his PCE technical docs says that the PCE used some of the fastest VRAM chips available at the time, so the PCE could manage higher resolutions with full sprites just fine.

Ahhhhhhh, yes ... but as is often the case, "the devil is in the details". It looks like there is more here than meets the eye.

Bonknuts is not taking into account the fact that the sprite hardware must load the the actual pixel data for each sprite line at some point. *That* seems to be the limit that is coming into play here.

And Charles MacDonald must have missed the fact that some games actually *do* set the bottom 4-bits of the VDC's Memory Width Register.

Hudson's official VDC manual, together with Hiromasa Iwasaki's account of his experience, gives us a clue to figure out what is going on.

I'm going to open up a new thread in the "Homebrew" section, since this is going to get technical, and I think that we've stumbled onto something that assembly-language homebrew developers are going to want to be aware of.

Jan 18, 2019 2:08:08 GMT punch said:

I still don't get why the PCE can display only 14 sprites per scanline on 320 h-res mode. Is it related to the 5.37 mhz clock too (being too slow to build all 16 sprites)?

It's an artifact of the VRAM chips' access timing, the 7.16MHz and 10.72MHz VDC clocks, and the horizontal blank timing.

Jan 18, 2019 2:08:08 GMT punch said:

When I was designing how I would approach road rendering in my racing game I simply assumed that I would have enough time to change at least 8 colors per scanline, which backfired immensely since in real hardware the PCE repeats the current "pixel" like ten times or so horizontally generating this ugly artifact. I ended up having to place palette changes in the hblank and this limited me a lot (now I get why some PCE racing games keep two different colored copies of the same road graphic to change its color via BYR instead).

You are confusing the VDC with the VCE ... they are different chips, and have different access restrictions.

I recommend that you read the available docs again, especially Charles MacDonald's PCETECH.TXT.

And, yep, that's one of the reasons why you'd want to have 2 copies of your road graphic instead of just 1.

[elmer]

Oh, and since we're talking about screen resolution here ... was anyone really offended (or even noticed) that both of the Legend of Xanadu games run in 240-pixel-wide screen modes?

This potentially offers a nice advantage in VRAM usage, even if it does limit you to a maximum of 61 sprites on the screen instead of 64.

[dshadoff]

Aside from the whole sprites angle, there are other, much more mundane reasons you might want to use a 320-pix screen (or not).

Pros:
You can print more text on a given line. Some of the later CD-ROM text-type games (dating simulations and digital comics) use it this way.
I know there was actually one game (can't recall which one at the moment) that used the HSYNC raster interrupt to switch modes halfway through the screen, so that they could print more on the lower half. I'll have to go digging to find out which one though...

Cons:
It's always nice to know what your art is going to look like... on a 4:3 screen, a 4:3 ratio of horizontal to vertical pixels means that the pixels are basically square, which is a great place for artists... they can design on graph paper, etc. Also, I'm pretty sure that the on-computer tools assumed basically square pixels.
If you change the horizontal resolution without changing vertical, then the pixel aspect ratio is not square. This isn't too hard to deal with, if your tools assist you... but I'm pretty sure that this was more difficult than it sounds (back in the day). I'm pretty sure that the developers would have tried to build custom tools on the machine itself in order to support such resolutions.

On the subject of 320-pix horizontal games, I'm pretty sure that Sherlock Holmes was one of them (though you won't have to worry about sprites on that one).

Dave

[gilbot]

 Yeah. I think those technical discussion would be better placed in Homebrew, so let's get back on stuff that are less technical.

Considering the harsher limitations it's no wonder why relatively fewer games used the mid-res than on the MD.

I think one reason a game would be presented in mid-res was whether it's a port. PC ports with the original versions using 320 or 640 pixel horizontal resolutions might be presented in mid-res to make them more faithful conversions of the source materials(usually RPG and adventure games, Ys I+II being an example) and it's more free for the developers when it's an original game(so, Ys IV used the lower res).

For arcade conversions, this is also in effect, but since there are usually a lot of stuff moving on screen, if the original game used a higher resolution the developers might have to decide whether using the mid res was feasible due to its limitation, and so a number of arcade conversions used a lower resolution than the source materials.

One notable division is the Capcom games. Since many of this company's arcade boards had a relatively high horizontal resolution (they're usually even higher than 320 in fact) so it's more often than not that Capcom games would use the mid res, with some exceptions, such as Strider (I think if it was an SGX exclusive like in the previous plans it would use mid-res and arcade perfect graphics like Daimakaimura) and Street Fighter II'(though this was probably more due to the fact that nearly all the console ports were based on the SFC version, and of course to reduce storage).
Of Special(pun ) mention is Side Arms Special. The original Side Arms used mid-res, so is the normal mode of Special(of course), but the BC mode actually used low res, so the sprites looked different even though the assets were reused due to them being stretched horizontally(and appeared larger) on a real TV. BiTD I thought they redrew everything for this new original mode.


I'm curious now. Does the 14-sprite limit apply to games displaying in mid-res but have the visible resolution reduced, such as those vertical shooters which have an "arcade" mode? So, would there be more sprite flickers when these games are put into arcade mode?

[elmer]

Jan 18, 2019 4:22:52 GMT gilbot said:

Yeah. I think those technical discussion would be better placed in Homebrew, so let's get back on stuff that are less technical.
...

I'm curious now. Does the 14-sprite limit apply to games displaying in mid-res but have the visible resolution reduced, such as those vertical shooters which have an "arcade" mode? So, would there be more sprite flickers when these games are put into arcade mode?

So now you're OK with "technical"?

It's not a 14 sprite-per-line limit in medium-res ... it's a 14 sprite-per-line limit with the specific settings that R-Type uses.

Daimakaimura and Ys I&II have a 15 sprite-per-line limit, and the 256-pixel-wide-in-medium-res "arcade mode" hacks would have a full 16 sprites-per-line.

[gilbot]

Jan 18, 2019 5:26:12 GMT elmer said:

So now you're OK with "technical"?

Hehe yeah... 
Though to defend myself I was more about seeking a "Yes" or "No" answer rather than an explanation(though I wouldn't mind to see one).