MrFish, aren't we a bit touchy? I am pretty certain that R0ger meant it in a humorous way. Do we really have to put smileys in every conversation so that everyone understands our attitude?
So, everything humorous is by definition innocuous and thus should be left alone, or else the humor police will give me a touchiness citation? Give me a break; don't act so naive, and don't mistake me for being so either. I also think you're overestimating the level of my reaction.
So, in answer to your two questions: "no" and "I don't really care".
And here I'm starting new thread, not to derail the original thread any more.
And to MrFish I say:
Yes, in every compatible game there is nothing the PAL version can do in the extra time it gains. Because it wouldn't be able to do it on NTSC version. You have to adjust what the game does to the limit, which is imposed by NTSC. PAL can do 20% more. Of course, at the price of lower FPS. But NTSC software will run on PAL, albeit slower. PAL software won't necessarily run on NTSC.
And my intention is not to denigrate anything. It's just how the things are. As a developer I see NTSC as extra limit. I'm not happy about it. But denigrate ? Cheer up man.
Which leads me to question .. in experience of NTSC user .. how much software is not NTSC compatible ? I guess old commercial software is all NTSC compatible, most of it was created in USA anyway. But considering how much Atari is popular in Europe, I imagine some of the new stuff is not. Especially demos. I wouldn't know, I typically don't try to run stuff on NTSC, and if it is mentioned in release notes, I ignore it, as I don't need the information.
Maybe I wasn't exactly clear when I said, "There are a multitude of cases where having more time in the VBlank does nothing to help PAL systems keep up with NTSC's +20% screen refresh speed advantage".
I'm not just talking about compatible software, I'm even talking about taking a piece of NTSC software/source code and handing it over to be optimized for PAL by someone knowledgeable in the craft. They can do whatever they want in the VBlank, even to the point of making it incompatible for NTSC. They might be able to add more animations, or whatever, but they're not going make it run faster than the original piece of software that does run on NTSC. All they can do is add more complexity to each frame, but whatever they do in the VBlank is only going to happen 50 times in a second while the NTSC's VBlank code will have executed 60 times.
So, I'm talking about VBlank rendering dependant software, which a huge amount of software is and will always be.
So, "it's just how things are" that NTSC Ataris are "damned clunky" because they can't run as much code during the VBlank or HBlanks (because they're busy getting down to displaying the next frame, or line) isn't denigrating? Alright, since you want me to cheer up, I'll call it "laughable" instead.
For modern productions, I'd say 75% or more European demos have one problem or another on NTSC. For games it's more like 25%. Music is probably the biggest culprit, and then other cycle eating techniques after that.
Demos aren't really a problem for me because I usually only view them once and toss them, or if they're good I'll hang on and view them once every few years.
This is bit of a dead horse, been turned to glue and rehashed every 10 or so years....
Yes, some parts of the discussion will be rehashing, but there are plenty of other things to discuss that aren't so commonly talked about. I'll be adding a few of those here myself.
In Bomber we did the "skip every 6th frame" adjustment on NTSC by default. But you can toggle the adjustment by pressing the "A" key. Without the adjustment your reaction times have to be 16.66% shorter.
The adjustment does look jerkier compared to the silky smoothness of full frame-rate but it's not horrible IMHO. Maybe it depends on the kind of game.
Instead of skipping frames, doesn't it make more sense to add some time wasting code that will be executed every frame? The uneven skipping -- like what was added in the Drop Zone NTSC adjusted version (same as you're talking about, skipping every 6th frame) -- takes away from the smoothness of animation and scrolling that make it so good in the first place.
This debate drops me a weird smile.
NTSC has most advances in graphics and sound.
NTSC offers colors in hi res.
NTSC offers a real higher degree of POKEY usage for music.
NTSC offer a better calculation at VB and usable frames.
PAL "only" has the better CPU speed per frame ratio. But PAL isn't allowed to use that single advantage?
But, the workarounds to have some colors in hires, the music playing a 2 times of 50Hz to have real calculable note timings on and on... this is "just given" on NTSC Ataris....
There are still "99%" of games that run better on NTSC. There is a little amount of PAL optimized games.
As any "better graphics and sound" that a NTSC Atari allows , isn't possible to port to PAL Ataris.
Why should PAL Atari users not optimize software to PAL machines?
As soon as they take care of any NTSC timing, the real PAL benefits got lost.
I'm not saying PAL coders shouldn't take advantage of their available resources, I'm really just answering the kick at NTSC machines.
I like to see PAL and NTSC machines pushed to their limits. If a heavy PAL production can't -- or the authors just won't -- support an NTSC version, so be it.
NTSC has the advantage if you want to call it that of flicker methods not looking as bad.
PAL has the advantage, and IMO a big one, of the colour blending between scanlines. Though for broadcast TV it could be considered a liability though it's a side effect of the system that produced true colours without need for user adjustment.
I say flicker methods are quite usable on NTSC. When viewing on a CRT, the flicker on games like Kangaroo cannot even be noticed, even on careful examination. On PAL it's not so pretty.
I really can't speak for every hardware combination, but with my 800XL and JVC studio monitor, I get the same color blending on NTSC that I get on PAL. I've run both machines using Project-M v2 and it's identical. The only thing necessary is that I use composite; using Y/C will dull the colors.
A couple other things that people may not have considered before.
The majority of general purpose fonts that exist in the world have rectangular capital letters, ascender, and descender characters. Since Atari characters are defined in 8x8 cells, the vertically stretched pixels of NTSC help to give the characters a more proper rectangular shape. This is not the case for PAL; characters would probably need to be more like 9 or 10 pixels high in order to compensate.
The fact that NTSC graphics will fill up the screen with less pixels vertically also means that there are less pixels to manipulate for full screen graphics. So less time is needed for rendering.
(This is one that Brian brought up before, which I think is a good point too): NTSC color clock single scanline pixels are closer to square. And I'll add that GTIA pixels aren't as flattened out either.
As a side note, concerning color differences, it would be a good feature for one of these modern video devices to add the ability to swap palettes between NTSC & PAL, if possible.
Edited by MrFish, Thu Mar 1, 2018 9:34 PM.