|
Post by spenoza on Dec 6, 2022 21:13:58 GMT
Folks, I've noticed that the majority resolution for PCE games is 256 horizontal. There are a lot of reasons for this. But I'm wondering why more games didn't use 320 horizontal resolution. I know it makes VRAM pretty tight and you have to be more careful with sprites, but are there any other caveats? I am imagining that for a variety of puzzle-style games which use repeating tiles and don't cluster sprite objects up on a line together that 320 would be perfectly manageable, but I also don't know enough of the fine details to know if I'm missing additional constraints.
|
|
gilbot
Punkic Cyborg
Posts: 137
|
Post by gilbot on Dec 7, 2022 5:36:08 GMT
One important reason was that NEC didn't encourage developers to use the mid-res. (320, or 3XX something) mode, as officially the mode is only safe when there are at most 14 sprites before drop-out in a line (vs. 16 in low(256) and high(512) res. modes). This is opposite to the case of the Mega Drive, where at 320 res. you can display more sprites in a line (in either cases, just enough pixel count to cover up whole line), so you'd see more games running in 320 res. there. NEC would not approve official releases (unless they overlooked the games, or maybe they had loosen the rules in later years) that managed to display 16 sprites in a line in the mid-res. mode. R-Type I and II were exceptions, as developers in Hudson Soft didn't know the limitation until it was too late, and because the game(s) were too good to ignore, NEC stated that they would only let this pass for one time. The later US release and the Complete CD version were fixed to OBEY the rules, with a price of more sprite flickering. There had been some research here (mainly by Elmer I think) and there is at least a thread here (which I'm too lazy to look up atm) which detailed the findings. The main reason is that to fetch 16 sprites to display in a line in the mid-res. mode, VRAM needs to be overclocked a bit, according to the official spec. of the minimum RAM speed used at least, so the number of sprites in a line has to be reduced a bit for safety. However, in actuality, it's just a very slight overclocking and the actual RAM chips used in real hardware are all good enough to handle this, so there should be no danger, unless you build a system using components that match the absolute minimum specs. (which NEC might have thought of at some point, to cut cost or whatever).
|
|
|
Post by dshadoff on Dec 7, 2022 13:18:26 GMT
Well, first of all, not all games use a lot of sprites... but certainly the ones which do, are generally action games which benefit more from a 256 wide canvas for multiple reasons - first, the sprites, but secondarily, a larger scroll area within the same amount of video memory.
Memory was a huge consideration for all HuCards because it had to be loaded from somewhere, and the HuCard had limitations which affected end-user pricing.
Even when CD-ROM games came out, there would have been a question about how much the extra memory usage *helps* a game versus its cost - because for CDROM, it needs to be loaded into memory from CD - either directly to video RAM to stay until the next load cycle, or somehow in the very limited CD system's memory to be used as a 'second set'. It wasn't until Super CDROM came out that this realistically could have been an option without huge costs.
There would also be the issue of aspect ratio - in the early days, they would draw graphics on paper first, to be encoded into memory. A different aspect ratio would mean at least different graph paper to encode from (until the development kits were advanced enough to design on PC and display on PC Engine). And again, the question would be "how much does the extra resolution benefit the game ?"
(Also, 320 is a misnomer - performing the calculations gives a mid resolution of closer to 348 or so).
There is one area where it was a huge benefit, but many developers might discount it as "not a *real* use of mid-range": text. 256 wide text is pretty limited. Many games squeeze the resolution to mid-range simply to squeeze more text onto a line. Lots of later games such as dating sims or digital comics will even set a raster interrupt and switch modes mid-screen to allow graphics to be in 256 mode, and text to use the mid mode.
|
|
|
Post by spenoza on Dec 7, 2022 14:46:09 GMT
Yeah, nothing here make it sound like the mid-res mode would be a problem for a tile-based puzzle game. Reusing lots of tiles reduces memory impact, and sprites can usually be kept minimal as well. I've had a few ideas rolling around. I'll have to keep this in mind. As an example, one thing that has always bothered me was how large the Lode Runner characters are and how limited the screen area is for the PCE (and other console versions of) Lode Runner. Mid-res mode won't recover extra vertical space, but it would grant narrower characters and tiles, allowing for a little more flexibility in level creation. This is just an example, of course. The Boulderdash series never saw a lot of console ports, either, and I think it would be a fun title to adapt to PCE. Basically, I'm eyeballing beginner projects to see if anything could be viable, and I'd like to explore mid-res mode in the process.
|
|
nicole
Gun-headed
Posts: 50
Fave PCE Shooter: Magical Chase
Fave PCE Platformer: Legendary Axe II
Fave PCE RPG: Ys III
|
Post by nicole on Dec 8, 2022 3:24:49 GMT
I used the mid-resolution mode in Space Ava 201 for the dialogue cutscenes. I guess there probably wouldn't have been any problem to use it for the gameplay scenes as well, thinking about it; I kind of just did 256-mode there because it felt like the norm.
|
|
|
Post by turboxray on Dec 8, 2022 3:57:45 GMT
One important reason was that NEC didn't encourage developers to use the mid-res. (320, or 3XX something) mode, as officially the mode is only safe when there are at most 14 sprites before drop-out in a line (vs. 16 in low(256) and high(512) res. modes). This is opposite to the case of the Mega Drive, where at 320 res. you can display more sprites in a line (in either cases, just enough pixel count to cover up whole line), so you'd see more games running in 320 res. there. NEC would not approve official releases (unless they overlooked the games, or maybe they had loosen the rules in later years) that managed to display 16 sprites in a line in the mid-res. mode. R-Type I and II were exceptions, as developers in Hudson Soft didn't know the limitation until it was too late, and because the game(s) were too good to ignore, NEC stated that they would only let this pass for one time. The later US release and the Complete CD version were fixed to OBEY the rules, with a price of more sprite flickering. There had been some research here (mainly by Elmer I think) and there is at least a thread here (which I'm too lazy to look up atm) which detailed the findings. The main reason is that to fetch 16 sprites to display in a line in the mid-res. mode, VRAM needs to be overclocked a bit, according to the official spec. of the minimum RAM speed used at least, so the number of sprites in a line has to be reduced a bit for safety. However, in actuality, it's just a very slight overclocking and the actual RAM chips used in real hardware are all good enough to handle this, so there should be no danger, unless you build a system using components that match the absolute minimum specs. (which NEC might have thought of at some point, to cut cost or whatever). There's no need to guess; mid-res mode is 7.159mhz so 1/7159090 = 140ns. The static ram chips are rated for 120ns (which is faster than 140ns). Not only is it faster, safe, and within range - but I've run 10.74mhz mode without any wait states and that over clocks the video ram to 93ns and it's never failed on me - for multiple systems, for hours at a time (even overnight multiple times), over the years. RType Complete CD is just an asset/code re-use of the US version (which is still a Japanese code base - much like a lot of localizations for TG16). It's an anomaly in the later released games that use mid res. Mid-res mode is interesting, but the negatives really don't out weight the positives. SGX, sure. PCE, not so much. The question I would ask is; what is it in mid-res mode that you're trying to do that can't be done in low-res mode? The answer to that question is: well, what would you do if you were doing it on the SNES then? Personally, one of the best setups on PCE is using low-res mode clipped to 240px or 224px screen instead of 256px.
|
|
|
Post by spenoza on Dec 8, 2022 14:59:43 GMT
The question I would ask is; what is it in mid-res mode that you're trying to do that can't be done in low-res mode? The answer to that question is: well, what would you do if you were doing it on the SNES then? Personally, one of the best setups on PCE is using low-res mode clipped to 240px or 224px screen instead of 256px. If you're doing a tile-based puzzle game it gives you a larger map space before you have to scroll. Low res mode is closer to square, but not perfectly square, so as long as you're accounting for the fact that your tiles are going to be pronouncedly rectangular, it means greater detail and/or complexity on a single screen. I think Lode Runner would have been more analogous to the computer originals had it used mid res mode instead of low res, for example.
|
|
|
Post by spenoza on Dec 12, 2022 19:24:42 GMT
To clarify, I'm kind of eyeballing a Boulder Dash clone to learn HuC. In its original version on the Atari 8-bit platform it used, I think, the 320 resolution mode. The playfield consists of 20 x 12 tiles of 16x16 pixels each. That would make for a smooth transition in trying to keep the general feel of the game if I used the 320 resolution mode on PC Engine. I know other versions varied the size of the play field and maps could scroll, I think being able to stick to the canonical, original resolution would be nice as it would easy map design. I'd be trying not to rip off maps wholesale, but it's fair to say I'd be taking a LOT of inspiration from the original.
|
|