Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 18, 2019 17:02:37 GMT
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. Do you have the video register values for those? The whole subject is utterly confusing, while I doubt I'd learn anything new from those at least I'd have more templates to play with.
|
|
|
Post by elmer on Jan 22, 2019 6:17:18 GMT
Do you have the video register values for those? The whole subject is utterly confusing, while I doubt I'd learn anything new from those at least I'd have more templates to play with. Yeah, I've been trying to avoid having to go too deeply into the whole VDC setup issue myself. I had already seen what Hiromasa Iwasaki was referring to in Hudson's docs, but I didn't think that it was relevant to the final PCE design that was manufactured. His posts suggested otherwise. Except that NEC themselves seem to have changed their minds later on, as they obviously stopped forcing developers to adhere to that particular requirement ... even though some still did anyway. I don't think that it should really cause us too much in the way of problems today, but it is something that we should be aware of, because it does sound like it will have a small effect on hblank timing (for split screen scrolling and parallax). I still need to write a test to confirm this on real hardware though. I'll post something in the Homebrew section, and talk about recommended VDC settings if you like, but it won't be the big "breaking-news" story that it was looking like a few days ago.
|
|
|
Post by elmer on Jan 22, 2019 6:20:06 GMT
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. It's a hardware limit, not an option, and there is no software checking to do. It's a result of NEC believing that the VRAM that they're using in the PCE isn't specified as fast enough to work reliably at 1 clock-per-access-cycle when using the 7.16MHz medium-res pixel clock, and that it needs to be switched into running at 2 clocks-per-access-cycle. When the VDC is running at that 7.16MHz clock rate, the cycle time is 140ns. That is pretty darned close to the VRAM's specified cycle time of 120ns, and it doesn't allow for much in the way of timing slop before you're potentially going to get problems. But running the VDC at 2 clocks-per-access-cycle doesn't give it enough time during the non-display period (beginning-of-line, end-of-line & horizontal-blank) in medium-res to load the next line's pixel data for all 16 sprites. With the settings that the TurboGrafx version of R-Type uses, the math in the official docs says that it can only display 14 sprites per line, which is what Hiromasa Iwasaki was talking about. I suspect that he may have been overestimating the hardware, and that he might have only been getting 13 sprites per line. That's probably one of the reasons why Daimakaimura uses a 320-wide screen mode instead of a 336-wide overscanned screen mode ... it gets them an extra 2 sprites-per-line-per-VDC. Anyway, it seems that they may have been a bit paranoid back in 1988/1989, and cautious of facing a consumer backlash if they shipped games that glitched badly on random consoles that were using RAM that was only just in spec. That's not an unreasonable position for them to take early on in the console's history, even if they relaxed their position later on. 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. As I mentioned above, it looks like NEC changed their mind sometime in 1989 (after the MegaDrive shipped???), and stopped forcing developers to switch the VDC into 2-cycle mode when using medium-res. Of the games that I've tested, only 40% of them switch into 2-cycle mode. Here is the list ... DATE | PUBLISHER | GAME | COUNTRY | FORMAT | WIDTH | HDS HSW | HDE HDW | MWR | SPRITE LIMIT | Mar 1988 | Hudson Soft | R-Type Part 1 | Japan | HuCard | 352 | $03 $03 | $06 $2B | $x0 | - | Jun 1988 | Hudson Soft | R-Type Part 2 | Japan | HuCard | 352 | $03 $03 | $06 $2B | $x0 | - | Jul 1989 | NEC Avenue | Side Arms | Japan | HuCard | 352 | $03 $03 | $06 $2B | $x0 | - | Nov 1989 | Hudson Soft | R-Type | USA | HuCard | 336 | $04 $03 | $06 $29 | $x9 | MAX 12 SPRITES PER LINE | Dec 1989 | Hudson Soft | Ys I&II | Japan | CD | 320 | $05 $03 | $06 $27 | $xA | MAX 14 SPRITES PER LINE | Dec 1989 | IREM | Mr Heli | Japan | HuCard | 352 | $03 $03 | $06 $2B | $x0 | - | Dec 1989 | NEC Avenue | Side Arms Special | Japan | CD | 352 | $03 $03 | $06 $2B | $x0 | - | Jul 1990 | IREM | Ninja Spirit | Japan | HuCard | 352 | $03 $03 | $06 $2B | $x0 | - | Jul 1990 | NEC Avenue | Daimakaimura | Japan | HuCard | 320 | $05 $03 | $06 $27 | $xA | MAX 14 SPRITES PER LINE | Dec 1990 | NEC USA | TV Sports Football | USA | HuCard | 352 | $03 $02 | $03 $2B | $x0 | - | Mar 1991 | IREM | Legend of Hero Tonma | Japan | HuCard | 352 | $03 $03 | $06 $2B | $x0 | - | Jun 1991 | NEC USA | TV Sports Basketball | USA | HuCard | 352 | $03 $02 | $03 $2B | $x0 | - | Aug 1991 | Riverhill Soft | Burai | Japan | CD | 320 | $05 $03 | $06 $27 | $xA | MAX 14 SPRITES PER LINE | Sep 1991 | NEC USA | TV Sports Hockey | USA | HuCard | 352 | $03 $02 | $03 $2B | $x0 | - | Oct 1991 | Telenet | Tenshi no Uta | Japan | CD | 352 | $04 $02 | $04 $2B | $x0 | - | Nov 1991 | System Soft | Lord of Wars | Japan | CD | 352 | $04 $02 | $06 $2B | $x0 | - | Dec 1991 | Hudson Soft | R-Type Complete | Japan | CD | 336 | $04 $03 | $06 $29 | $x9 | MAX 12 SPRITES PER LINE | Mar 1992 | NEC Avenue | Forgotten Worlds | USA | CD | 352 | $03 $02 | $03 $2B | $x0 | - | Aug 1992 | NEC Avenue | Dragon Knight 2 | Japan | CD | 320 | $05 $02 | $03 $27 | $x0 | - | Sep 1992 | Victor Musical Industries | Loom | USA | CD | 352 | $02 $02 | $04 $2B | $x0 | - | Sep 1992 | Micro World | BuilderLand | Japan | CD | 352 | $04 $00 | $04 $2A | $x0 | - | Sep 1992 | Naxat | Zero Wing | Japan | CD | 320 | $06 $04 | $07 $27 | $xA | MAX 14 SPRITES PER LINE | Sep 1992 | Naxat | Wizardry V | Japan | CD | 304 | $06 $03 | $07 $25 | $xA | MAX 16 SPRITES PER LINE | Dec 1992 | Riverhill Soft | Burai 2 | Japan | CD | 352 | $03 $03 | $03 $2B | $xA | MAX 10 SPRITES PER LINE | Mar 1993 | Telenet | Tenshi no Uta II | Japan | CD | 352 | $04 $02 | $04 $2B | $x0 | - | Jul 1993 | Naxat | Wizardry I & II | Japan | CD | 304 | $06 $03 | $07 $25 | $xA | MAX 16 SPRITES PER LINE | Oct 1993 | Hudson Soft | Might & Magic 3 | USA | CD | 320 | $05 $02 | $04 $27 | $x0 | - | Jan 1994 | IREM | Sol Moonarge | Japan | CD | 336 | $04 $03 | $06 $29 | $x0 | - | Mar 1994 | Naxat | Wizardry III & IV | Japan | CD | 304 | $06 $03 | $07 $25 | $xA | MAX 16 SPRITES PER LINE | Apr 1994 | NEC Avenue | Puyo Puyo | Japan | CD | 304 | $06 $03 | $07 $25 | $xA | MAX 16 SPRITES PER LINE | Jun 1994 | NEC Avenue | Tenchi o Kurau | Japan | CD | 368 | $03 $02 | $03 $2D | $x0 | - | Jul 1994 | NEC Avenue | Dragon Knight 3 | Japan | CD | 336 | $03 $03 | $07 $29 | $xA | MAX 12 SPRITES PER LINE | Mar 1995 | NEC Avenue | Dragon Knight & Grafitti | Japan | CD | 336 | $03 $03 | $07 $29 | $xA | MAX 12 SPRITES PER LINE | Nov 1995 | NEC Avenue | Dokyusei | Japan | CD | 320 | $05 $02 | $08 $27 | $xA | MAX 14 SPRITES PER LINE | Dec 1996 | NEC Avenue | Madou Monogatari | Japan | CD | 320 | $05 $03 | $06 $27 | $x0 | - | Mar 1997 | NEC Home Electronics | Tekipaki Working Love | Japan | CD | 320 | $04 $03 | $08 $27 | $xA | MAX 14 SPRITES PER LINE |
<EDIT 1> Added Forgotten Worlds, Might & Magic, and the Wizardry games. <EDIT 2> Updated with the true sprites-per-line limits from a test on real hardware. Ouch!!!
|
|
gilbot
Punkic Cyborg
Posts: 138
|
Post by gilbot on Jan 22, 2019 8:31:07 GMT
Ah, so you really can limit how many sprites are visible in hardware by setting the registers to specific values. (Edit: And after reading your explanations, by reducing the actually displayed pixels per line you have more blanking time and thus it's possible to display more sprites per line even though you need 2 clocks-per-access-cycles, so that's why the shooters won't have any compromises in "vertical" modes as you have at most 256 pixels displayed per line, leaving a lot of spare hblank time, right?)
It is possible that NEC was more strict on Hudson about the rules since Hudson is the 1st party developer/publisher of the system. IMO Hudson was "more 1st party" than NEC Avenue/NEC HE or later, NEC Interchannel as they designed the system, and that those "NEC" publishers usually outsourced the developments to other companies, whereas for Hudson it's usually letting staff from other companies (in many cases, Alfa System) to join them as a team in Hudson's office.
From this list at least, all the games developed or published by Hudson (except R-Type I and II) had imposed restrictions on sprites. Iwasaki was heavily involved in the development of Ys I+II and Daimakaimura (which was actually developed by Hudson, but published by NEC Avenue for some reasons) and from that blog entry about R-Type he had mentioned while Ys I+II was in development the programmers asked again whether the limitation could be lifted, and NEC replied "no".
Edit: I wonder whether this affect the ~10MHz(512 pixel) mode though.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 22, 2019 17:26:06 GMT
I feel like now it's a good time to move this thread to the homebrew section. Creating another thread will kill momentum... Anyway, I'm reading the documentation and I think I kinda get it now. This is not as hard as I thought it would be but I still have some questions: If we stick to the Access Width = 1 setting in R09 the VDC has enough time to do everything on valid scanline settings? How about hi-res 512 horizontal pixels? If it's 10MHz then VRAM access width = 1 is too fast? Do you have to actually set it to 2 for everything to work properly? What changes the VDC's internal clock, the setting itself? VDW is 9 bits, what stops us from having a 512 vertical res signal, the hardware or the NTSC standard? Is HSW the horizontal blanking interval?
Edit: If I set the horizontal resolution to 240, the formula on the manual claims that there's only time to fetch 63 out of 64 sprites from SAT when in width = 1 , is that correct? It's kinda odd that reducing the number of characters to be displayed horizontally also reduces the time to find stuff in the SAT.
I think that's it for now.
|
|
|
Post by elmer on Jan 22, 2019 19:06:45 GMT
And after reading your explanations, by reducing the actually displayed pixels per line you have more blanking time and thus it's possible to display more sprites per line even though you need 2 clocks-per-access-cycles, so that's why the shooters won't have any compromises in "vertical" modes as you have at most 256 pixels displayed per line, leaving a lot of spare hblank time, right?) Yep, exactly. I feel like now it's a good time to move this thread to the homebrew section. Creating another thread will kill momentum... I'm not so sure, I kinda like this one being here to talk about the game library itself, and then create another thread in the Homebrew section to talk about the really technical stuff. Sure, it turns out that there is a hardware limit that effected the original game developers, but we're going to get far more deeply into the PCE's guts in a Homebrew thread! I'll leave your other questions for that other thread. Back to this thread ... I really appreciate gilbot 's adding in his background knowledge of who was developing what, and so giving us in insight into when this limit was imposed, and when it was ignored. Interesting details like that are exactly why I'd like to keep this thread where it is.
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Jan 22, 2019 19:12:47 GMT
What is the point to use more than 344 pixels in 7.16mhz ?
Forgoten worlds also use the mid-res .
|
|
|
Post by spenoza on Jan 22, 2019 20:39:02 GMT
Oops, I went ahead and moved this. Should I move it back and should we select some posts to splinter off? I figured we were already digging down into the dirt a little. I certainly don't think the post is out of place here in Homebrew... I'm honestly more interested in what you folks would find helpful than anything else with this thread.
|
|
|
Post by elmer on Jan 22, 2019 23:37:09 GMT
OK, punch , touko , I've started a thread in the Homebrew section to talk about the nitty-gritty technical details that matter to new projects; let's take our boring stuff over there and leave this thread to talk about the PCE's existing library of medium-res games, and see if anyone can dig up any more historical info about why so many games didn't have to follow the restrictions that NEC placed on Hiromasa Iwasaki and the Hudson team.
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Jan 23, 2019 13:05:30 GMT
We can take in account AOf which switch between lo-res and mid-red to simulate a zoom .
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 23, 2019 15:44:25 GMT
I always wondered why Ryuuko no Ken didn't use more resolutions in between to smooth out the zoom. Now I know.
Touko: doesn't it use high res too?
|
|
|
Post by elmer on Jan 26, 2019 0:55:04 GMT
I've run a test on real hardware (with a SuperGrafx and a CoreGrafx II) and updated the sprites-per-line limits in the table above for each game that used NEC's recommended 2-clocks-per-cycle for medium resolution. The results are even worse than predicted ... OUCH!!!R-Type in the USA was actually limited to only 12 sprites-per-line, and not the 14 sprites-per-line that Hiromasa Iwasaki expected from Hudon's official PCE documentation. The exact reason for the difference, is what we're discussing (in highly technical and deadly boring detail ) over in the Homebrew section.
|
|
samiam
Punkic Cyborg
Posts: 100
|
Post by samiam on Jan 26, 2019 2:46:53 GMT
Well, R-Type on PCE was always known for having a lot of flicker.
Personally, I always thought it would have been cool for Hudson to release a SuperGrafx port of R-Type, maybe even as a launch title. They could have eliminated the flicker (mostly), restored the multiplane backgrounds from the arcade version, and sold the entire game as one Hucard instead of two.
It definitely would have been better than having no games other than Battle Ace on the system for five months.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jan 26, 2019 2:50:51 GMT
edit: I keep mixing up threads... anyway good work, elmer.
|
|
|
Post by ccovell on Jan 26, 2019 3:17:47 GMT
Personally, I always thought it would have been cool for Hudson to release a SuperGrafx port of R-Type, maybe even as a launch title. They could have eliminated the flicker (mostly), restored the multiplane backgrounds from the arcade version, and sold the entire game as one Hucard instead of two. This is getting on in age, but I actually started a PCE->SGX conversion hack for R-Type back in 2011, but I got sidetracked with family matters...
Each level needs to be hacked individually, as each background split / sprite interaction with scrolling/split backgrounds is custom for each stage...
Anyway an example of PCE->SGX:
|
|