gilbot
Punkic Cyborg
Posts: 138
|
Post by gilbot on Mar 10, 2020 19:56:19 GMT
As mentioned the US version was "fixed" to follow the official specs so it is normal to see scenes infested with flickerings in the US version to perform better in the original Japanese version.
In the Japanese version it was indeed able to display 16 16-pixel wide sprites in a single line.
I think increasing the number of visible sprites per line is quite a common enhancement option in emulators (at least it us quite common for Famicom emulators).
|
|
|
|
Post by dshadoff on Mar 10, 2020 23:51:21 GMT
Are there emulators that artificially in software increase the horizontal sprite display capabilities exceeding the original hardware? Yes, virtually all emulators have this, at least as an option. It was one of the early goals of emulation back in the 90's. The MiSTer FPGA hardware implementation of PC Engine also has this as an option. |
|
|
|
Post by turboxray on Mar 11, 2020 1:55:33 GMT
Somebody please explain this: At 4:08 to 4:10 in this video of R-Type Part 1 Japan HuCard youtu.be/xW8KsIvLZyw, the ENTIRE horizontal top portion of the screen is filled with the "techno snake" sprite WITHOUT ANY FLICKERING. This is supposed to be running in 352 x 239, from what I read here. I paused the video and counted 16 equally-sized segments of the snake sprite horizontally filling the screen, which would make each segment-sprite at least about 22 pixels wide, so wouldn't that mean these are 32-pixel sprites? And wouldn't that exceed the limits imposed on the programmers, as discussed in this thread? Also, wouldn't the frame-rate of the game (in addition to screen resolution) factor into the time available for the video processor (and/or CPU) to draw more horizontal pixel resolution? So, running a game at 60fps means less time to draw higher horizontal resolution, whereas running at only 30fps would allow more drawing time for higher horizontal resolution? I've never seen R-Type Japan HuCard running on real hardware, and I don't know at which framerate the above video was recorded in, but it's definitely not 60fps. (Although I think that many of Irem's M72 arcade system board games from late '80s to early' 90s ran at something unusual like 52 or 55fps...) That's clearly NOT running on the real hardware, and the video appears to be too old to be Chris Covell's SGX upgrade patch for R-Type. So this is just emulation, because yeah there's no way that top screen is going to show them all solid without flickering. If it was a 60hz flicker thing, and video consolidated the frames down to 30hz, it simply would show as transparent. |
|
|
|
Post by lawless on Mar 12, 2020 18:50:29 GMT
Are there emulators that artificially in software increase the horizontal sprite display capabilities exceeding the original hardware? Yes, virtually all emulators have this, at least as an option. It was one of the early goals of emulation back in the 90's. The MiSTer FPGA hardware implementation of PC Engine also has this as an option. The linked video was posted in 2016, before Mister FPGA was available, I believe, so it couldn't be running on. that. I'm only familiar with Magic Engine, and I don't recall it gad any settings regarding increasing the sprite display abilities. I also did cursory check of Mednafen for such sprite enhancement now, and didn't see any settings. Could you please let me know which PCE emulators have sprite enhancement settings now and/or which had them in 2016? Thanks! |
|
|
|
Post by lawless on Mar 12, 2020 19:20:26 GMT
Somebody please explain this: At 4:08 to 4:10 in this video of R-Type Part 1 Japan HuCard youtu.be/xW8KsIvLZyw, the ENTIRE horizontal top portion of the screen is filled with the "techno snake" sprite WITHOUT ANY FLICKERING. This is supposed to be running in 352 x 239, from what I read here. I paused the video and counted 16 equally-sized segments of the snake sprite horizontally filling the screen, which would make each segment-sprite at least about 22 pixels wide, so wouldn't that mean these are 32-pixel sprites? And wouldn't that exceed the limits imposed on the programmers, as discussed in this thread? Also, wouldn't the frame-rate of the game (in addition to screen resolution) factor into the time available for the video processor (and/or CPU) to draw more horizontal pixel resolution? So, running a game at 60fps means less time to draw higher horizontal resolution, whereas running at only 30fps would allow more drawing time for higher horizontal resolution? I've never seen R-Type Japan HuCard running on real hardware, and I don't know at which framerate the above video was recorded in, but it's definitely not 60fps. (Although I think that many of Irem's M72 arcade system board games from late '80s to early' 90s ran at something unusual like 52 or 55fps...) That's clearly NOT running on the real hardware, and the video appears to be too old to be Chris Covell's SGX upgrade patch for R-Type. So this is just emulation, because yeah there's no way that top screen is going to show them all solid without flickering. If it was a 60hz flicker thing, and video consolidated the frames down to 30hz, it simply would show as transparent. Thanks for your reply. Just wondering how you determined linked vid "clearly" not running on real hardware? There seems to be some confusion on this as to whether the PCE hardware was limited to 16 or 14 horizontal sprites in 352-pixel mid-res, so whether a horizontal row of 16 sprites fully filling screen is possible is debatable, and precisely what I'm trying to determine. The linked video seems to show just that. Further, the linked vid dies NOT appear to exhibit the fps/hz conversion artifacts obscuring flicker because this video indeed displays BOTH intentional flicker (spaceship after killing boss from 2:20-2:30) AND unintentional flicker (small enemy gun installations on bottom of green spaceship at 5:01-5:07 and thrusters at about 5:23). EITHER showing of flicker on the video would be enough to prove this video is encoded with the original display of flicker intact. In fact, the unintentional flicker also shows that there are not any (effective) emulator enhancement settings alleviating sprite flicker in this video. Bottom line is that this video shows a full horizontal row of sixteen 22-plus-pixel sprites (presuming 352-pixel resolution) WITHOUT ANY FLICKER. (Again, I'd be happy to post relevant screenshots from the video if someone could kindly instruct me, otherwise I've already posted the video link and relevant timeframe.) |
|
|
|
Post by Mathius on Mar 13, 2020 4:13:24 GMT
You may want to check Ootake out. It's the other dedicated PCE emulator that most of us gravitate toward in lieu of paying for Magic Engine. I'm no tech head, but I just ran through its options and there are some sprite limit settings but I have no idea exactly what they're there for as Ootake is not documented well due to its age and, I believ, it's Japanese origins can be user unfriendly. Sorry for that run-on sentence lol. I'm not fixing it!
If anyone wants to correct me regarding Ootake please feel free.
...but be gentle
|
|
|
|
Post by dshadoff on Mar 13, 2020 5:45:59 GMT
Basically, if there was any emulator which could run R-Type and didn’t have sprite limit override, I wouldn’t believe it. Go back to 1997 and it’s the same story.
|
|
|
|
Post by turboxray on Mar 13, 2020 16:39:18 GMT
Thanks for your reply. Just wondering how you determined linked vid "clearly" not running on real hardware? Just look at the frame at 4:07. There's more than 8 sprites segments of the snake. Those snake segments are 32 pixels wide, which means at a minimum it using two cells. The PCE's limit is 16 sprites or 16 cells on a line before any sprite drop out. A cell is 16 pixels wide. Those segments of the snake/worm are 32 pixels or two cells wide, which means the PCE would only draw 8 of them per "line". Dropout happens per line, so it all depends on where the "overlap" happens. That's how you can tell. An emulator can ignore this and keep fetching cells and display them, including all 64 sprite as 32px wide (2 cells). There should be no confusion. The PCE will display 256 pixels or 16 cells regardless of the video mode IF it's set properly (i.e. vram is set to run at full speed). There was some titles that under the impression or were instructed to set vram to a slow operation mode for higher res games. Some did, some didn't. JP version of Rtype ran vram full speed, US/NA version ran it at slow speed and tried compensate with clipped res. I.e. if vram is set to slow speed, and higher res, then there might not be enough time to fetch all sprite cells in "hblank area". This isn't a normal PCE thing. It's a DEVs miss-understanding, and only affects a some mid res titles because of their action. But the PCE Video chip itself? It's always 16 cells per line, regardless of the resolution. Flicker is the game logic detecting or anticipating sprite overflow (dropout) will happen. If it's always on, then you'll see it as "z fighting" on sprite overlaps even when there's no overflow condition. So even if an emulator it set to not limit the sprites per line, you'll still see z-fighting on overlaps for those games. So.. what's your point in all of this? That you have some confusion on the PCE specs or that you think that video is from the real hardware? |
|
|
|
Post by elmer on Mar 13, 2020 19:47:49 GMT
There seems to be some confusion on this as to whether the PCE hardware was limited to 16 or 14 horizontal sprites in 352-pixel mid-res, so whether a horizontal row of 16 sprites fully filling screen is possible is debatable, and precisely what I'm trying to determine. The linked video seems to show just that. There should be no confusion. The PCE will display 256 pixels or 16 cells regardless of the video mode IF it's set properly (i.e. vram is set to run at full speed). There was some titles that under the impression or were instructed to set vram to a slow operation mode for higher res games. Some did, some didn't. JP version of Rtype ran vram full speed, US/NA version ran it at slow speed and tried compensate with clipped res. I.e. if vram is set to slow speed, and higher res, then there might not be enough time to fetch all sprite cells in "hblank area". Instead of trying to analyse YouTube videos from unknown sources, you might wish to listen to folks like turboxray , who have years of experience with running/testing stuff on real PC Engine hardware. As he says, and as the official Hudson documentation clearly shows, the PC Engine's VDC chip can display a maximum of 16, 16-pixel-wide sprite cells on a single line of the TV display. That maximum can be reduced if the VDC chip doesn't have enough time during the hblank period to load up data for all 16 sprite cells. In practice, that situation only occurs if the VDC is set to read VRAM using the slower 2-clocks-per-memory-access instead of the normal 1-clock-per-memory-access. NEC believed (rightly or wrongly) that the VDC needed to be set to the slower access speed in medium resolution games, and so forced Hudson to do so for various games, such as the US release of R-Type. There is a list of games that I tested earlier in this thread. More information about this can be found here ... pcengine.proboards.com/post/7667/threadYou can do you own testing on real hardware and emulators by using Chris's excellent screen-test program, both with and without the access speed patch that I mentioned here ... pcengine.proboards.com/post/7891/thread |
|
|
|
Post by Black_Tiger on Mar 14, 2020 3:26:19 GMT
I tried recording video of R-Type I last weekend, but I was and still am missing some crucial cables. So the best I could do for now is record using s-video. This is my TurboDuo playing PCE R-Type using a V1.1 Turbo Everdrive.
Make sure to set it to 720p for 60fps:
|
|
|
|
Post by turboxray on Mar 14, 2020 17:06:51 GMT
Nice vid!
Also, just wanted to put things into prospective:
Genesis would use 32x32 size segments and have a limit of 10 per line instead of 8.
This game running on the SNES, for this boss with segments like this, would have the same flicker conditions. SNES has 272 horizontal pixel limit per line compared to the PCE's 256, so on the snes you'd get something like 8 and 1/2 of those segments before dropout compared to just 8.
But if you were like to compensate for snes lower res and scale the segments to 24x32 for correct pixel ratio, and then use the snes 8x8 and 16x16 sprite mode (you can only have two sprite sizes at a time on the snes), you could reduce the flicker. That would mean two 16x16 cells and two 8x8 cells combined to make a metasprite of 24x32. Each segment would take 4 hardware cells. At the full size of that worm, it'd burn like 92 entries in the 128 sprite table. The ship, project tiles, etc would push it close to that 128 limit, and you get some serious slowdown on the SNES for that management (more than 50% slowdown).. and come out with 11 segments before sprite dropout. Realistically though on the snes, it's gonna be 16x16/32x32 sprite mode and be 8.5 segments per line.
|
|
|
|
Post by Black_Tiger on Mar 14, 2020 18:16:08 GMT
A pixel-for-pixel port like this for Genesis would also run at a resoltion 32 pixels narrower and probably just feature one less segment, which would still be one less twisting around triggering flicker.
|
|
|
|
Post by lawless on Mar 17, 2020 20:50:06 GMT
Thanks VERY much, everyone, for the insightful replies and, of course, the great video running on real hardware.
The flickering in R-Type is quite an issue, and I don't remember seeing it anywhere near as pronounced in any other title.
|
|
|
|
Post by Black_Tiger on Mar 18, 2020 13:36:48 GMT
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. I believe that only the player sprite was reused in Sidearms Special BC. |
|
|
|
Post by turboxray on Mar 18, 2020 15:25:29 GMT
There's a trick called "infinite sprites" (I can't remember the exact name but there's even a PCE rom floating around showing it off.. with a Bonk sprite). It's an old school trick. It totally could be modified for this boss, and remove almost all flicker. It'd have to be modified though.. with an erase function and real sprites to cap either ends of the worm. Chris Covell might know what I'm talking about.
Edit:
|
|
