Jump to content
IGNORED

PAL / NTSC


R0ger

Recommended Posts

Hello. We started PAL/NTSC conversation in Stunt car racer. I admired how the conversion supports both PAL and NTSC, and I called NTSC damn and clunky.

 

To which MrFish reacted:

 

What's all this crap about how bad NTSC is compared to PAL?

The vast majority of software that's been written for the system relies on refresh speed and is thus faster on NTSC than PAL.

 

To which I reacted:

 

For games doing things between frames, there is 20% less time between frames.

For games doing things independent of frames (like this one), there is less time, as ATARI has to draw 60 frames per second instead of 50, and there is more DMA. OF course considering the graphics are the same in both versions, but that is usually the case.

Also all VBI and DLI code is called 20% more often, giving you less time for the rest.

Add different style of artifacting, and the fact that as I mentioned, you have to limit graphic to NTSC size, I'm surprised there even are games and demos which work on both. I value such achievement highly.

 

To which _The Doctor__ reacted:

 

Yes true to a point, but the NTSC clock is also faster so more cycles in the given period minus the 5 doubled frames...

 

And MrFish reacted:

 

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.
So, you favor what PAL systems have to offer; is it necessary to denigrate NTSC systems in order to express it?

 

And here I'm starting new thread, not to derail the original thread any more.

 

------

 

To the argument that NTSC has faster CPU I say this. Yes. It's about 1% faster. But considering it has to draw 20% more frames, it doesn't help much.

 

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.

 

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

NTSC games are usually faster simply because there's 60 VBlanks per second vs 50 for PAL (OK, the real numbers are actually some hundredths less for both but it's irrelevant).

Most games do movement processing based on the VBlank interval so unless adjustments are made they'll be faster in NTSC.

 

Few if any games do "adjustments" because that means fractional movement = more processing and it also means jerky movement. For our old games, moving 1 or 2 pixels per frame is way better than 1 pixel every frame except every 6th frame which would look crap.

 

Why so many games refuse to work or are worse on NTSC in the modern day?

Because PAL machines have 312 scanlines vs 262 for NTSC which means a whole lot more CPU time per frame, which means a whole bunch more objects can be shuffled about. That can be problematic if the differences aren't accounted for when developing the game. But it's more desirable to have a working game than it is to cater for every region.

 

And finally, forget the 1.79 vs 1.77 MHz thing - PAL in fact will almost always have more cycles per second available for the CPU. NTSC has more active scanlines being displayed per second, and it loses more cycles to refresh per second. Such that you virtually have to be showing a near totally blank screen for NTSC to actually be faster in the true sense.

  • Like 2
Link to comment
Share on other sites

As an NTSC user, I can say that that I blamed that many European software is not compatible with NTSC, or the speed made them unplayable (for example, ElektraGlide). I even figured out that many polish games in the 90s had issues because the music playing routines are put in the inmediate VB so it takes to many machine cycles to refresh the shadow registers, making the screen collapses. I fixed some of them by simply moving the music routine to the VBD, that is after the shadow registers refresh. It was a pain in the butt, specially for those games compressed.

 

Anyway, I like the software that are NTSC/PAL compatible. I see it as a message that the programmer care about people and users like me.

 

Cheers!

  • Like 5
Link to comment
Share on other sites

I can only respond as a user, not a programmer. As you say, most of the commercial software works great on NTSC. The exception is some of the later software that was developed in Europe.

 

Some of the new, home brew games (Dimo games, dye, and more) did not work in NTSC. 8bitjunkie created NTSC versions of his games and dye is playable if you turn off the music. Some software still does not work on NTSC.

 

Demos do not interest me so I have never investigated their compatibility. For the home brew games, NTSC can be a problem. While it is possible to find a PAL system in the US, it is not so easy to find a TV or monitor that supports PAL here. It is possible, but you have to look carefully.

 

I appreciate it when developers can support NTSC. I realize that most people today are programming the Atari in Europe so NTSC compatibility is not always a primary concern.

 

Bob C

  • Like 1
Link to comment
Share on other sites

This is bit of a dead horse, been turned to glue and rehashed every 10 or so years.... there are ways to get more out of it going both ways... people have counted the cycles etc. It ends up pretty much being a wash depending on planning and how the software is written to one system or the other. Same results come from different methods to get there, that requires shuffling the code or even a re code to get it to be the best on each system... as it is already starting to be noted yet again, moving the music, a little trimming of lines off the display which are normally just blank wasted or not being used to any real purpose in a game. Many times the NTSC conversions have delays installed to make the pal version slow down to human levels... instead of moving the the counter or timer. That makes it possible to complete a thing, it does nothing to keep the pace the same though. if more code were executed in between the counter or loop the pace would adjust and the speed would be about the same. That requires work to do.

Some software is designed from the start or at least give some thought to what if it runs on NTSC or a speeder/video upgrade board... those convert well... sometimes we just get lucky too.. :)

How you get there is up to you.

 

If you are accustomed to 50 hz displays you don't notice the flicker and jerky display, you are adjusted to it from a lifetime of television and computer displays and it's normal and is not noticed. Many people used to 60 hz can't stand that or it bothers them to the point of headaches if watched too long. They were noticing that in the 50hz countries the younger generation are getting used to devices that don't do 50hz displays and that and when confronted with retro or older machines that it bothers them as well or they don't like it and have bad things to say... they don't understand... once it's explained the derogatory comments 'usually' go away. Many scaling devices also help to minimize the effect as well as the display devices themselves, this has helped greatly in the past 6 or so years and we see less complaints and more kids are liking 'retro' again. Well sorta retro ;)

 

Using a slightly different bag of tricks on the same game for the most part yields the same great results, if the programmer is willing to write to each systems methods of getting maximum returns. It almost always becomes a darn near dead even wash. Fact is there are far less NTSC coders now... we're all dying or dead. Unlike 50hz world who understands learning on these old machine can get them much further in life and enjoy playing with them, the new generation 60hz world appears to just use the new stuff and don't look back... with a few exceptions, I've seen engineering students who love going back and seeing how being steeped in every aspect of how the machine makes video and sound... counting the cycles, racing the beam, its exciting and gratifying. They realize it helps them make better product in modern creations. Less bloat can still count for something to great advantage.

 

Many people say conversion to PAL is easier, but I don't always agree... sure it will play... but it's still way easier to win, it's slow.. it's not really converted. We are all just happy to play the game. I often wondered if true conversions would be done for PAL... side by side actual comparisons to make it as close to exact in pace as well as time to do a thing.

 

In any event that would be a great deal of work for what some call minimal gain, so it is what it is. I'm sure we all would like the same experience both ways. And it is true the conversion should take far less to do than the original game did from beginning to end. It does require in some cases at least 30 percent to 50 percent more work to do this when dealing with games that utilize a number of tricks, or have coded to timing specific limits to the very edge of cycles available. That requires re ordering and changing where some heavy lifting gets done. It's the opposite of what they fought so hard to do in their native system, as the split is different or moved.

 

A definitive list of conversion techniques and why or how they are done has never been written, a book or technical guide with examples would have been invaluable to people who enjoy these wonderful machines. Imagine what those understanding could do in helping tailor an efficient set of routines for both systems... It might be tough, but it sure can be rewarding.

 

hmm a discussion of conversion methods, the best method to use on each, that would be different and more productive than the old cycle fights and calcs being re done all over again..

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

Few if any games do "adjustments" because that means fractional movement = more processing and it also means jerky movement. For our old games, moving 1 or 2 pixels per frame is way better than 1 pixel every frame except every 6th frame which would look crap.

I absolutely agree with this. It actually doesn't sound that bad on the paper. But once you actually implement it - it's truly a WTF on a grand scale when you see it jerk like that :)

 

So, we need to move both versions 1px a frame.

 

Option 1:

- Translate the ~20% performance difference into the level dimensions - e.g. make sure that in a, say, 10 second period, the player gets to travel the same distance across the level (even if it is different amount of pixels) in both PAL/NTSC versions.

- This is, of course, extremely prohibitive in terms of art asset creation, testing, different bugs, etc.

- this also means, that PAL version will be "zoomed in", as it needs to show 20% more of environment, so it would look more detailed than NTSC

- so while you get same speed, it's still an advantage "to those PAL suckers :) "

 

Option 2:

- use Widescreen for PAL (hence it burns more cycles) and Normal for NTSC

- that should bring the speed difference to a negligible ~5%, while keeping the same art assets.

- the additional gfx in Widescreen mode should be mostly decorational, as seeing more of a level (say, in a platformer) would give unfair advantage "to those PAL suckers :) "

- hopefully the tearing introduced by switching the display list pointer in the middle of the frame is tolerable, but I haven't seen it on real box yet, so can't comment on it

 

 

The moral of the story is, that no matter how you look at it, there's simply more CPU power in a PAL box.

 

 

But, if your racing/flying game engine can run at full-speed, the fluidity of 60 fps movement on NTSC totally destroys the uber-pathetic 50 fps :D

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Would it be possible to implement a "rolling" frame skip? Meaning rather than always skipping frame 1 out of 6, the game skips frame 1, then 2, then 3, etc.?

Link to comment
Share on other sites

Would it be possible to implement a "rolling" frame skip? Meaning rather than always skipping frame 1 out of 6, the game skips frame 1, then 2, then 3, etc.?

 

If I understand correctly, that would mean after skipping frame 6 you'd skip frame 1 in the very next frame which would be a double skip. I think that would look jerkier than a regular skipping interval.

 

Also, the term skip could mean two things. If adjusting NTSC to match PAL, then skipping could mean repeating a frame. If adjusting PAL to match NTSC, then skipping could mean actually removing a frame. In Bomber it was the former -- we just show every 5th frame of the original animation sequence twice.

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Hmm, games that were developed for NTSC are mostly playable on PAL systems, but some really suffer. I was a sceptic at first, but after seeing Donkey Kong Jr. on NTSC at the Atari Invasion 2k18, I'm won over. BITD I found it too sluggish, but at 60fps it's a way better game. OTOH, there are PAL only games that are, well, PAL only because of the increased amount of cycles per frame, which you'll never get on an NTSC system.

  • Like 1
Link to comment
Share on other sites

Hmm, games that were developed for NTSC are mostly playable on PAL systems, but some really suffer. I was a sceptic at first, but after seeing Donkey Kong Jr. on NTSC at the Atari Invasion 2k18, I'm won over. BITD I found it too sluggish, but at 60fps it's a way better game. OTOH, there are PAL only games that are, well, PAL only because of the increased amount of cycles per frame, which you'll never get on an NTSC system.

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.

Link to comment
Share on other sites

NTSC isn't better for graphics. The vertical resolution means you see scanlines even with interlaced displays on CRTs.

 

The artifact colour in hires is just a side effect of the pixel clock having a direct relationship to the colour clock. If they'd done the Atari as a ~ 2.2 MHz machine then it would have been PAL that had the "nice" feature of artifact colours in hires.

 

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.

 

Neither IMO has an advantage for music. If anything PAL would be better as less DMA and less VBlank interference means digital playback can be better.

On either system, alternate music timing like 100 Hz, 75 Hz, whatever can be done with a little bit of extra effort.

Edited by Rybags
Link to comment
Share on other sites

A definitive list of conversion techniques and why or how they are done has never been written, a book or technical guide with examples would have been invaluable to people who enjoy these wonderful machines. Imagine what those understanding could do in helping tailor an efficient set of routines for both systems... It might be tough, but it sure can be rewarding.

 

hmm a discussion of conversion methods, the best method to use on each, that would be different and more productive than the old cycle fights and calcs being re done all over again..

I wish a book/guide like that did exist. Generally, I develop and run in Altirra with both settings. I know I am consuming too many cycles in the VBI when NTSC doesnt work and PAL continues to work. Because we only had real NTSC hardware and we expect a large number of potential players to have PAL systems, Eric traded with someone to get a real PAL Atari. An emulator is great but not enough to trust at release time.

 

At the end of our development cycle, NTSC is always faster because so much of the timing is cycle based. The last step is to speed up the game when running on PAL. This is where I use those extra PAL cycles and, if any on the fly calculations need to be done to convert the speed, the heavy lifting is done in the PAL sections. Another note is that most speed adjustments are set at startup in our games so if you want to speed them up more, you can start Altirra in PAL and switch to NTSC after the game is loaded.

  • Like 1
Link to comment
Share on other sites

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?

Well, it was a US designed machine. I often wonder how much time at all went into thinking about adapting the machine to PAL. Perhaps it was a lucky hack it worked at all?

 

That being said, all the cool demos from 90s up required PAL so I gladly had my uncle ship me a machine over, and made sure to have PAL capable displays here. The only thing I have trouble with is the 50Hz CRT flicker. My eyes are incredibly sensitive to flicker, such that when I was still using CRT on PCs, I had to use 72Hz or above to not see it. I can see flicker on the new car tail lights and headlights when I move my eyes, and I believe they are > 300Hz. So at 50, I can almost see the screen turning on and off.

  • Like 4
Link to comment
Share on other sites

Well, it was a US designed machine. I often wonder how much time at all went into thinking about adapting the machine to PAL. Perhaps it was a lucky hack it worked at all?

 

That being said, all the cool demos from 90s up required PAL so I gladly had my uncle ship me a machine over, and made sure to have PAL capable displays here. The only thing I have trouble with is the 50Hz CRT flicker. My eyes are incredibly sensitive to flicker, such that when I was still using CRT on PCs, I had to use 72Hz or above to not see it. I can see flicker on the new car tail lights and headlights when I move my eyes, and I believe they are > 300Hz. So at 50, I can almost see the screen turning on and off.

 

Indeed. I'm not used to 50 Hz flicker anymore either. But it's the age of LCDs. Flicker is not an issue.

Link to comment
Share on other sites

 

Indeed. I'm not used to 50 Hz flicker anymore either. But it's the age of LCDs. Flicker is not an issue.

I'm stubborn, and keep my A8 gear on a Sony PVM. They just look so much better on CRT. I guess to be fair - I do have an Eclaire beta board, so I have a valid way of using PAL or NTSC via HDMI. But I try to stick to vintage gear.

  • Like 3
Link to comment
Share on other sites

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
Link to comment
Share on other sites

How is sound on NTSC machine better ?

You have 10 manipulation steps per second more, to adjust frequency and volume.

If you listen to Fragmare's latest conversion, and have a closer look at the drums, you may get it fast. They sound a little more like "digis" .

You don't even need to use double VBI speed , to have a more fluent melodic range.

And, you can play 1/2 and 1/4 notes by just 60/30/15 frames.

Low and high notes fit slightly better aswell.

  • Like 2
Link to comment
Share on other sites

It's actually a little more than I expected it to be.

 

- NTSC Characters are a full 2-pixel's height taller.

- NTSC lower-case characters are slightly taller

than PAL upper-case characters (disregarding

lower-case with ascenders and descenders of

course).

 

PAL characters still look good and are of course composed of

the same number of pixels; they just look a little deflated by

comparison. But this demonstrates what I was talking about

above. The NTSC characters resemble more the proportions

of what you see in paper printing and on modern computer

systems (for monospaced fonts).

 

These are characters of exactly the same width, believe or not.

[Note: some vertical character spacing does not line up exactly,

due to pixel scaling, bilinear filtering, and the chosen Altirra

window size.]

 

post-6369-0-72582100-1519976093.png

Edited by MrFish
  • Like 2
Link to comment
Share on other sites

Pixel aspect ratio is an inexact science. The old CRTs varied widely, even some PAL TVs only barely show the 240 scanline normal display area.

 

And even plenty of LCDs cut off overscan. It does seem ridiculous but in some cases even though you've got a 1920x1080 panel the pixel mapping isn't 1:1. Especially if you're using an analog input type which = anything short of HDMI. Generally it'll be remapped such that you're not seeing the full display.

 

But that said, it's a long known fact that the NTSC hires pixels are stretched vertically, the PAL ones are almost square.

  • Like 3
Link to comment
Share on other sites

You have 10 manipulation steps per second more, to adjust frequency and volume.

If you listen to Fragmare's latest conversion, and have a closer look at the drums, you may get it fast. They sound a little more like "digis" .

You don't even need to use double VBI speed , to have a more fluent melodic range.

And, you can play 1/2 and 1/4 notes by just 60/30/15 frames.

Low and high notes fit slightly better aswell.

 

HM .. ok .. I understand. Might be useful sometimes. It's basically the same issue as screen flicker, just in audio :-)

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...