It is currently Mon Dec 17, 2018 8:10 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 104 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
Author Message
PostPosted: Mon Jul 23, 2018 4:11 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 835
Location: Denmark (PAL)
Honestly, my opinion is just that no NES game should ever be played on a PAL console. :P
Compensating for PAL systems is and will always be a makeshift hotfix, and doing it for people who don't have much of a choice is a nice gesture, but I wouldn't go out of my way.


Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 6:15 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1786
Location: Gothenburg, Sweden
That's just as valid a viewpoint, and i get the wink. But in practice, it is only sustainable for a small group of very serious NES collectors (with deep enough pockets) out of the broader pool of PAL NES gamers to maintain that ideal.

If you ask the rest of your potential customer base in the PAL region to pay 30-45$ for a cartridge, 12-17$ shipping, and ~10$ import duty, you'd better either

-put a few hours into validating or having someone validate that it plays well enough on PAL
-be upfront about it not being tested properly
-provide a sample ROM (demo maybe) for the potential customer to validate

and if you found your test results a bit on the troublesome side (chances are it’s fine), again:
-see if you can look into it. also the sooner, the better. you can save yourself most of the sweat if you planned for it from the get go.
-be upfront about it.

for downloadables, it's not much of a problem. Less or no financial involvement, ease of distributing versions.

and of course, at that price point you’re bound to filter out a good deal of casual NES owners unless the game really hits a string within that demographic.

The PAL region might be maybe 10-20% (guesstimate) of your cartridge market, which isn't all that much, but it aint getting bigger if you ignore it. And it's a lot less work than doing a famicom release (where the thread started).

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 9:05 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
FrankenGraphics wrote:
That's just as valid a viewpoint, and i get the wink. But in practice, it is only sustainable for a small group of very serious NES collectors (with deep enough pockets) out of the broader pool of PAL NES gamers to maintain that ideal.

Exactly. No one would buy an NTSC console and maybe compatible TV just to play your game. Imagine this:
(sorry for the terrible editing)


Attachments:
mariobrosntscpal.png
mariobrosntscpal.png [ 1.52 MiB | Viewed 1210 times ]
Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 9:16 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 835
Location: Denmark (PAL)
FrankenGraphics wrote:
-put a few hours into validating or having someone validate that it plays well enough on PAL
-be upfront about it not being tested properly
-provide a sample ROM (demo maybe) for the potential customer to validate

Timed code is of course an issue, and I agree you should definitely take that into account!
Aside from the sheer concept of the game working or not working though, I don't think you should trouble yourself more than it's worth to make the game run 20% faster for the PAL territories, which is what I thought we were talking about. Anyone who lives in PAL-land and don't own an NTSC NES is already used to 80-90% of their NES game collection running slower than intended.

orlaisadog wrote:
Exactly. No one would buy an NTSC console and maybe compatible TV just to play your game. Imagine this:
(sorry for the terrible editing)

See above. I agree that an NTSC system shouldn't be required to make the game work. But if you want to play your NES games at the correct speed, you get an NTSC NES. "Retro gamers" for whom it matters have known this for decades. For the rest, they don't care anyway.


Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 9:28 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
The ironic thing is you live in a PAL region but you still don't seem to like PAL console owners.

By the way, I don't own a console.


Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 9:59 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1786
Location: Gothenburg, Sweden
sumez wrote:
Timed code is of course an issue, and I agree you should definitely take that into account!
Aside from the sheer concept of the game working or not working though, I don't think you should trouble yourself more than it's worth to make the game run 20% faster for the PAL territories, which is what I thought we were talking about.


Then i think we're basically in agreement. Timed code is a main culprit to look out for. Emphasis bits is another, since someone thought it was brilliant to switch red and green. I explored ways to make palette animations smoother for a horror game for Orab. Just using all bits, and/or just the blue bit in tandem with palette compensations works great for lights on/off. Image But if i wanted to use the red bit for sunset coming through a window or warning signals, that'd require a region detection feature.

For game speed compensation, see the Project Blue case. Games are variably better or worse at the slower PAL speed. Most are fine/good enough. Castlevania works because of on/off movement. Super Mario Bros. works because of open space, relatively free range movement, scrolling, and that the player is mostly either at max running speed. Project Blue has a *lot* of roadblocks, turns of direction, wait for the right moment tricks, no scrolling, screen switching - that you're riding the de/acceleration curve far more than SMB. They're kind of in opposite ends in that matter. Note that both these games initially had the exact same acceleration curve before PB got snappier + got the physics tweaked to fit both NTSC and PAL. SMB feels alright, but PB was initially more noticeably slow.


btw it's not all that dark for PAL. Whenever a game runs out of Vblank on NTSC is a moment where PAL excels.. provided the software doesn't forcibly cancel updates under the assumption of the Vblank being "NTSC narrow". Again in project Blue, you sometimes run out of bandwidth during the boss fights on level 1A & 1B, due to the numerous bullets, causing some visual artifacts. Not so on PAL; it's stable as a rock.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 10:37 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20890
Location: NE Indiana, USA (NTSC)
FrankenGraphics wrote:
btw it's not all that dark for PAL. Whenever a game runs out of Vblank on NTSC is a moment where PAL excels.. provided the software doesn't forcibly cancel updates under the assumption of the Vblank being "NTSC narrow".

True, but the update buffer might be sized for NTSC. In my experience, a buffer spanning the unused part of the stack page, such as $0108-$01BF, happens to be about the right size to fill NTSC vblank, and there isn't a lot of RAM in the system to store a bigger buffer. So a bigger buffer would likely need to be stored either in ROM (such as copying uncompressed tiles) or in WRAM at $6000. Where are you storing the source data for an update buffer bigger than 192 bytes?


Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 11:14 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11013
Location: Rio de Janeiro - Brazil
Some updates don't need a buffer, such as patterns that go straight from the ROM to VRAM. Things that are constantly animating, such as the player and the background, will most likely not use compression, so you can copy them directly, instead of wasting time and space copying them to a buffer first.

Another example is my raycaster, which renders columns as fast as it can, and during vblank, as many columns as possible are copied to VRAM. The bigger is larger than what can be copied in one NTSC vblank, so the renderer doesn't need to be stalled, which would cause slowdown. PAL consoles can make even better use of the larger buffer by uploading more data (the whole buffer, in fact) to VRAM each frame.

My VRAM update system keeps track of how much buffer space is left, as well as how much time is left. Space is the same for NTSC and PAL, but the time is significantly increased for PAL, so that updates that don't need much buffer space can take advantage of it.


Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 12:10 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1786
Location: Gothenburg, Sweden
I'm honestly not quite sure what makes the PB boss fights on level 1 solid on a PAL NES, or what nmi/main topology it is using. I have never bothered asking for a look at the source. I'm just assuming that since NMI strikes less frequently, game logic manages to finish up all the metasprite handling before the OAM buffer is uploaded, even in more crowded scenarii. Mostly, rooms are designed to avoid sprites flashing up in the wrong places on NTSC, but there are a few exceptions where other goals were prioritized. This game doesn't need to update the nametable frame for frame since it doesn't scroll, and all bg animations are palette based.

Tokumarus' example sounds like the ideal NTSC/PAL-aware implementation for NT updates, though.

Else, wRAM isn't costly (~1$?), and might be an option if you're thinking about blowing the internal RAM budget anyway or about having battery saves (~1-2$ for battery and battery clip?).

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 12:39 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3727
Location: Mountain View, CA
OP: aren't you glad you started this thread?


Top
 Profile  
 
PostPosted: Mon Jul 23, 2018 11:55 pm 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 835
Location: Denmark (PAL)
orlaisadog wrote:
The ironic thing is you live in a PAL region but you still don't seem to like PAL console owners.

I don't think I ever implied that I have anything against anyone. I just don't like the PAL consoles.
Doesn't that make sense, too? As a European, I've been shafted hard by the concept of PAL games and consoles all the way up to the 6th console generation.

FrankenGraphics wrote:
btw it's not all that dark for PAL. Whenever a game runs out of Vblank on NTSC is a moment where PAL excels.. provided the software doesn't forcibly cancel updates under the assumption of the Vblank being "NTSC narrow"

I guess that bears mentioning - PAL itself is actually great. The issue here isn't the PAL standard, but the fact that PAL was always second fiddle to NTSC on the video games market. If PAL had been the international standard, we'd have 288p games with less slowdown. :) Instead we got European releases running too slow, with huge black borders on the top and bottom of the screen.


Top
 Profile  
 
PostPosted: Tue Jul 24, 2018 12:05 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7833
Location: Seattle
Sumez wrote:
If PAL had been the international standard, we'd have 288p games with less slowdown. :)
I'd hunch that in that alternate history, second and third generation consoles probably would have drawn 256 visible scanlines, for memory addressing reasons. (In comparison, most of the 2nd generation NTSC consoles only drew the 192 scanlines in the title-safe area; 256 out of 269 scanlines isn't too badly underscanned; and the costs of complexity memory to go above 256 is a lot bigger than to stay a little below 256 )


Top
 Profile  
 
PostPosted: Tue Jul 24, 2018 1:26 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 835
Location: Denmark (PAL)
For 8 bit consoles, absolutely.


Top
 Profile  
 
PostPosted: Wed Jul 25, 2018 6:11 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 1009
Location: Hokkaido, Japan
rainwarrior wrote:
Pokun wrote:
I only heard of one commercial game actually trying to detect NTSC and PAL and be dual compatible like that. And it's an unlicensed game.

What game was that?
I think it was that Dizzy game, I saw it being mentioned on the wiki, I've never played it myself.
I didn't knew there were any licensed games doing it though. As you said it was partly a region lockout thing, so I don't think Nintendo would want it normally.

rainwarrior wrote:
Pokun wrote:
I don't think any licensed games goes through the trouble of dual compatibility, it makes more sense for them to make separate NTSC and PAL versions.

It makes a lot of sense to do it now, though, in an era where NES region locking has been thoroughly defeated and lots of people in the PAL region especially have NTSC units. A cart that works with both is a useful thing in this situation. (It's also good for the user who doesn't know the difference.)

The situtation for us here and now is a lot different than Nintendo in the 80s, where they controlled distribution pretty tightly and were actively working to maintain region locking (which was an important component of their business strategy). Multi-region detection is an anti-region-locking device; there would definitely be no encouragement from Nintendo for any licensed developer to do this.


PAL vs NTSC (vs Dendy) is something that is very reasonable to detect, IMO, and seems it can be done robustly across clones and emulators too. The test strongly correlates, and isn't particularly prone to error. (Mainly because CPU overclocking isn't much of a thing with NES and its clones, since it breaks so many games.)

Maybe worth pointing out though that the only thing typically done with a PAL/NTSC detection is directly related to the thing you detected. You measure the framerate, and you do something to compensate for that framerate. It's pretty much worthless for determining tangentially related things like language, for instance.
I fully agree!
Although I think it may be a good idea to give the user options to manually set the flags you use to compensate these things, in case the user is using a setup not covered by the detection routine somehow. For example can you test things like emphasis flags? I don't know if all UMC-based Famiclones are using PAL emphasis or if only the PAL ones (like Dendy and Pegasus) do. Then there is the RGB PPU that I'm not sure if it can be detected at all.
If the game isn't using any way to save it might get tiresome to set the options every time you start the game though.


FrankenGraphics wrote:
Timed code is a main culprit to look out for. Emphasis bits is another, since someone thought it was brilliant to switch red and green. I explored ways to make palette animations smoother for a horror game for Orab. Just using all bits, and/or just the blue bit in tandem with palette compensations works great for lights on/off.
Image
But if i wanted to use the red bit for sunset coming through a window or warning signals, that'd require a region detection feature.
On a Famicom Titler (or other RGB PPU setup), instead of dimming the screen it will just become all white when you set all the emphasis bits though. Edit: Oops I somehow missed that you were setting the blue flag, not all flags at once.


Last edited by Pokun on Wed Jul 25, 2018 8:44 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Jul 25, 2018 9:39 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7025
Location: Canada
Pokun wrote:
For example can you test things like emphasis flags? I don't know if all UMC-based Famiclones are using PAL emphasis or if only the PAL ones (like Dendy and Pegasus) do. Then there is the RGB PPU that I'm not sure if it can be detected at all.
If the game isn't using any way to save it might get tiresome to set the options every time you start the game though.

I'm not sure how reliable using the frame vs CPU timing stat is to determine emphasis color. NTSC NES, Famicom, PAL NES and Dendy seem to be mostly consistent, though there are some rarer but official RGB variations of the PPU which implement emphasis in a very different manner too. Other clones, who knows, and also a lot of emulators don't have different emphasis colour for PAL. (I suspect there are quite a few emulators that don't implement emphasis at all, actually.)

Since there's no direct feedback of this information from the PPU itself, I agree the most appropriate thing is to ask the user. It's very common in modern games to do gamma correction configured by the user on first play. "Adjust the brightness until (something) is barely visible."

Since flash ROM is common, you might be able to use this to save settings, though you have to give up a whole block to that save ability (depends on flash type, maybe 4k).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 104 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group