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

[dshadoff]

OK, after re-reading poker's post above, together with the posts in the other thread, I *think* maybe I understand what he is trying to accomplish... a testcase to verify when a system is deliberately overriding the standard region protect code in US games.

This would be the only reason to use the official USA startup code, as region can actually be checked whenever you like in homebrew, and doesn't need to be next to either MMR initialization code or a ' NEC ' string.

(The Everdrive checks this and displays it on the screen displayed when you press 'SELECT', when it identifies 'Console').

[pokun]

So just because that's the only reason you can think of, that's suddenly the only case that can possibly exist? I don't buy that. Any type of modification in hardware or software has the potential to conflict with other hardware or software things, like those hardware mods that clashes with the Everdrive, or the Everdrive itself fighting with the Super System Card for example. Some people says nothing can go wrong and then it happens again and again and again.
The other day I was burned by another flashcart that had a, for me, totally useless feature that only gets in the way of homebrew development. It makes it partly unusable for hardware testing, and no option to turn it off either.


In this case it isn't so bad because, as Elmer said, it's all in software unlike those hardware region mods that messes with the bus timings, and it can be changed in the future if needed.

[dshadoff]

Nov 14, 2019 20:03:45 GMT pokun said:

So just because that's the only reason you can think of, that's suddenly the only case that can possibly exist? I don't buy that.

Since I didn’t hear of a specific goal, I will have to conclude this is the objective. There are an unlimited number of permutations of how to check the region, and a limited number of released software, so the test is confined to that set of software only. It is trivial to check in other ways that the card doesn’t mask.

and I meant to say “pokun” but the autocorrect on the forum overrode it.

[pokun]

Yes but how many software are unaffected is uninteresting. The point is that there is a mandatory modification done at all.

It may play a role when deciding whether or not it's worth it to implement the option or not though.

And there is no goal, the example was a project of no purpose other than to demonstrate a case that would fail (although I might make it anyway as art just for the heck of it).

Anyway flashcards are not that great for homebrew development anyway. They provide a nice and easy way to run the homebrew, but they tend to hide initialization bugs, so at some point the homebrew should probably be tested on a clean devcart without a menu that chain-loads the ROM.

[dshadoff]

Sure, I can agree with that

[lawless]

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...)

[gilbot]

Unless I overlooked, there is no information on how that video was captured, so it could be from an emulator and its output cannot be realiably trusted(I think the VC version of a number of games, e.g. Super Darius, exhibited less flickering).

Also, a point of discussion in this thread was that the Japanese version of R-Type (both I and II, but not Complete CD) WAS able to display full sixteen 16-pixel sprites without flickering on a single line, which actually broke the guidelines (the video RAM are a bit or close to being overclocked) set by NEC but they let it pass as an exception. Later releases such as the combined western version and complete CD adhered to the rules set by NEC and thus there were more flickerings.

[Black_Tiger]

Mar 8, 2020 16:34:57 GMT lawless said:

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 356 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...)

I just watched that specific moment in my phone browser with the video set at 360p and the flicker was noticeable to me.

Flicker isn't a bad thing and doesn't mean that large sections of graphics disappear for a while. Under most circumstances it means that a section appears translucent momentarily.

[lawless]

Mar 9, 2020 1:13:54 GMT gilbot said:

Unless I overlooked, there is no information on how that video was captured, so it could be from an emulator and its output cannot be realiably trusted(I think the VC version of a number of games, e.g. Super Darius, exhibited less flickering).

Also, a point of discussion in this thread was that the Japanese version of R-Type (both I and II, but not Complete CD) WAS able to display full sixteen 16-pixel sprites without flickering on a single line, which actually broke the guidelines (the video RAM are a bit or close to being overclocked) set by NEC but they let it pass as an exception. Later releases such as the combined western version and complete CD adhered to the rules set by NEC and thus there were more flickerings.

Yes, I agree that the source of the video is unknown. However, this is definitely the original Japanese split R-Type Part 1 HuCard, as the video has the continue code at the very end for entering at the beginning of the Part 2 HuCard. Was the split version available as VC game?

It would be great if someone who has original PCE hardware and ability to play the original Japanese HuCard /ROM game could confirm, or even better, make a 60fps video of it.

The snake segment sprites would have to be 32-pixel sprites here, since the horizontal resolution is 352 pixels wide and 16 segments virtually fill the screen horizontally (16 pixels x 16 segment sprites, as you mention, is only 256 pixels wide, far too small).

[lawless]

Mar 9, 2020 15:57:07 GMT Black_Tiger said:

Mar 8, 2020 16:34:57 GMT lawless said:

)

I just watched that specific moment in my phone browser with the video set at 360p and the flicker was noticeable to me.

Flicker isn't a bad thing and doesn't mean that large sections of graphics disappear for a while. Under most circumstances it means that a section appears translucent momentarily.

I took a few screencaptures of the video, and there's clearly no flicker in the snake sprites as they fill virtually the entire screen horizontally in the video I linked. I don't see how to post pics in this thread, or else I'd post them.

Flicker would necessarily mean that some of the sprites would be completely gone at some point , and they would only be "translucent" if the software /hardware were programmed to have the display of affected sprites very quickly alternate, rather than only some of them completely disappear, in order to comply with the hardware limitations. Neither is the case in the linked video; all the sprites are simultaneously visible, there is no flicker, and none of them disappear at any one moment.

[Black_Tiger]

Mar 9, 2020 17:33:59 GMT lawless said:

Mar 9, 2020 15:57:07 GMT Black_Tiger said:

I just watched that specific moment in my phone browser with the video set at 360p and the flicker was noticeable to me.

Flicker isn't a bad thing and doesn't mean that large sections of graphics disappear for a while. Under most circumstances it means that a section appears translucent momentarily.

I took a few screencaptures of the video, and there's clearly no flicker in the snake sprites as they fill virtually the entire screen horizontally in the video I linked. I don't see how to post pics in this thread, or else I'd post them.

Flicker would necessarily mean that some of the sprites would be completely gone at some point , and they would only be "translucent" if the software /hardware were programmed to have the display of affected sprites very quickly alternate, rather than only some of them completely disappear, in order to comply with the hardware limitations. Neither is the case in the linked video; all the sprites are simultaneously visible, there is no flicker, and none of them disappear at any one moment.

Flickering was often used as a "transparency" effect and many game fans couldn't tell the difference between flickered and realtime translucency unless seeing them side by side.

That video wasn't uploaded in a 60fps format, so the flickered frames have melded together, but it still looks like sprite flickering/drop out if you know what it looks like in games.

[Black_Tiger]

I ripped the video and snapped a few frames in an editor:

[lawless]

Mar 9, 2020 18:14:30 GMT Black_Tiger said:

Mar 9, 2020 17:33:59 GMT lawless said:

I took a few screencaptures of the video, and there's clearly no flicker in the snake sprites as they fill virtually the entire screen horizontally in the video I linked. I don't see how to post pics in this thread, or else I'd post them.

Flicker would necessarily mean that some of the sprites would be completely gone at some point , and they would only be "translucent" if the software /hardware were programmed to have the display of affected sprites very quickly alternate, rather than only some of them completely disappear, in order to comply with the hardware limitations. Neither is the case in the linked video; all the sprites are simultaneously visible, there is no flicker, and none of them disappear at any one moment.

Flickering was often used as a "transparency" effect and many game fans couldn't tell the difference between flickered and realtime translucency unless seeing them side by side.

That video wasn't uploaded in a 60fps format, so the flickered frames have melded together, but it still looks like sprite flickering/drop out if you know what it looks like in games.

Yes, flicker was often, for example, used to simulate shadows below character sprites (usually a flickering circle or oval). That's one tell-tale way of seeing
whether a video was recorded in 60fps from a game originally running at 60fps; these shadow will be either gone entirely or else appear in solid black in the video if it was recorded at only 30fps from a 60fps source.

As far as sprite "dropout" (exceeding the hardware limits) the sprites, similarly to the shadow example above, (but in the original game, not just in a video recording of the game) will either disappear entirely or else alternate extremely quickly (every 30th of a second in a 60fps game) with other sprite(s) causing flicker (with the advantage that all affected sprites are still visible, albeit "transparent").

NEITHER sprite dropout nor flicker occurs in approximately 4:05 to 4:10 in the video I linked ; ALL 16 visible, countable segments of the snake are simultaneously visible across virtually the entire horizontal plane of the top of the screen. I absolutely do not see any of the flicker you are referring to.

[gilbot]

Did you see the GIF image captured by Black Tiger?
There are indeed missing sprites in the snake.

[lawless]

Mar 10, 2020 5:15:06 GMT gilbot said:

Did you see the GIF image captured by Black Tiger?
There are indeed missing sprites in the snake.

I sure did! But it's 2 or 3 frames and doesn't even address the moments when the top row of screen is completely filled with sprites. R-Type indeed has flicker at points, sometimes intentionally (like when bosses explode), sometimes not, and that's apparent in the video I linked. The gif provided strangely drops a group sprites when there are only a few displayed horizontally. It's also weird that it's a contiguous group of 3 dropped. I don't know if it's a video capture issue, or otherwise why the game program might behave that way, but it's not visible in the original video. Maybe it's merely a one-time and single-frame drop for some reason other than horizontal sprite display hardware limitations that wouldn't constitute continuous sprite-drop flicker.

The one spot where flicker is very evident (as least in USA Rtype complete HuCard) is on first alien boss' tail when player ship and its satellites and shots are horizontal aligned with the tail towards screen bottom . However, in this video, the player avoids going to screen bottom and very quickly destroys alien boss otherwise.

Have you seen the original video I linked?
Do you see where the top row of screen is filled with 16 snake segment sprites?
Do you see it flickering?
Do you see the code entry at video end indicating it's indeed Japanese R-Type PART 1?
Was R-Type PART 1 ever on Virtual Console?
Are there emulators that artificially in software increase the horizontal sprite display capabilities exceeding the original hardware?