Something special ;)

[emkay]

And just for records... NTSC calcs faster.... 1,79 MHz vs 1,77...

OK. Thanks for being here.

Next please.

[Heaven/TQA]

Ok. Never ever ask me for something again.

 

Nothing to add.

[Heaven/TQA]

The problem is , you don't get the difference.

Thanks anyways for showing that copying code isn't the same than understanding the code.

Honestly. I dont need to get insulted by you. Make my day.

[emkay]

Thinking about it, the NTSC Version could gain more speed than I suspected.

Less Cycles used for DMA means more speed for NTSC than for PAL.

The DL there leaves almost similar cycles on both systems, belonging to the available Systems.

The problem still is that PAL suffers by longer waits for the VBL time.

The less Cycle stealing, the more benefit for NTSC Systems.

[emkay]

PAL 5 FPS , NTSC 6 FPS

 

One FPS slower means 20% slower there. The difference in the game shouldn't be recognizable.

[Wrathchild]

Based on the figures shown in the emulator, I don't think PAL is suffering any waits in VBL time, its utilising it to keep pace.

 

In the videos, the general range of frames between the main loop executing are PAL = 17->20 & NTSC = 21->25

 

So dividing that up by the frame rate shows:

 

PAL = 17/50->20/50 = 0.34s->0.40s

NTSC = 21/60->25/60 = 0.35s->0.41s

So performance wise graphically, I'd conclude they are about the same, so any DMA cycles saved vs extended vblank cycles would appear to balance each other out in this case.

However, as theorised before, the physics adjustments are being updated more frequently on NTSC than on PAL.

So looking at the NTSC/PAL frame ratios we have at the lower end 21/17 = 1.235 and at the higher end 25/20 = 1.25

Or looking at the PAL/NTSC frame ratios we have at the lower end 17/21 = 0.81 and at the higher end 20/25 = 0.8

So there could explain the NTSC 'feeling' 25% quicker or the PAL version 'feeling' 20% slower.

Therefore Heaven's description in post #44 holds:
"Assume you move 1 virtual meter per tick. In NTSC you would move 60 meters and in PAL 50 meters. That gives you the feeling PAL is slower."

Edited April 30, 2019 by Wrathchild

[emkay]

"Assume you move 1 virtual meter per tick. In NTSC you would move 60 meters and in PAL 50 meters. That gives you the feeling PAL is slower."

 

See the mistake?

 

Let's say we talk about 300m.

In NTSC it needs 5 Frames to get there. In Pal it needs 6 Frames to get there . The NTSC Engine produces 6 (50m) frames to get there. To compensate that, the PAL Version needed the Adjustment for 5 Frames (60m) .

The C64 Version is compensating that, by showing Frames inbetween.

[emkay]

Also interesting:

The Atari Version shows some kind of Jitter in the buffered screens. The C64 version is less Jittering. On stock machines not really recognizable.

Edited April 30, 2019 by emkay

[Wrathchild]

Sorry, a mistake on who's part - the developer / the publisher - who has stated that they specificly made a PAL version or solely released an NTSC version - so if the latter then there is no mistake.

Edited April 30, 2019 by Wrathchild

[emkay]

Sorry, a mistake on who's part - the developer / the publisher - who has stated that they specificly made a PAL version or solely released an NTSC version - so if the latter then there is no mistake.

Come on. They didn't care of PAL Systems anyways. Did they even know of it?

The stock Atari is NTSC in the US, and it is clearly the System they had used.

Most Games suffer on PAL Machines by that. As POPEYE is boring slow on PAL Machines, not to mention Sea Dragon.

Or Salmon Run. Running at 50Hz instead of 60Hz means to have the scrolling too slow, and the Bear, that acts on the "free cycles" is running too fast, making the game sometimes unplayable on PAL machines, while in NTSC the Game is fairly balanced.

[emkay]

So there are crossovers in simulation, calculation, and visualization.

Today we could only suspect, what they would have done, having a PAL Machine for development and the first working code, instead of an NTSC Machine.

[+Stephen]

And just for records... NTSC calcs faster.... 1,79 MHz vs 1,77...

And 60Hz vs 50Hz. Best to not argue with someone that doesn't code, but is a self proclaimed expert at everything. God damn - time for him to make #2 on my ignore list in nearly 12 years.

[+Stephen]

The problem is , you don't get the difference.

Thanks anyways for showing that copying code isn't the same than understanding the code.

So mr know it all expert. Let's see any of your fractal or 3D rendering codes on any of 7 platforms I previously mentioned. Put up or shut up and leave this forum you blow hard.

[Rybags]

NTSC likely has less free cycles actually - it can be dependent on graphics modes in use but by default PAL is faster for unconstrained (not VBI dependent) programs.

 

PAL suffers less overall DMA, Refresh, and less VBI code overhead which more than makes up for the slower clock speed.

 

But yes, if a game in fact does world calculations @ the native frame rate and renders at whatever speed it's able to then it'll appear slower in PAL. Especially so if it pauses until vblank to start the next render operation.

Edited May 1, 2019 by Rybags

[_The Doctor__]

.83361 approximately

is the magic number. as it's not a perfect 60.

the reason the calculations ended up at .81 to .8 is due to lost cycles and other alchemy.

Your' rough calculations were damn near spot on.

+1 WrathChild

[emkay]

One question to you "professional Coders" ...

Why is a difference spotted in the Atari Version and not in the C64 version?

[emkay]

NTSC likely has less free cycles actually - it can be dependent on graphics modes in use but by default PAL is faster for unconstrained (not VBI dependent) programs.

 

PAL suffers less overall DMA, Refresh, and less VBI code overhead which more than makes up for the slower clock speed.

 

But yes, if a game in fact does world calculations @ the native frame rate and renders at whatever speed it's able to then it'll appear slower in PAL. Especially so if it pauses until vblank to start the next render operation.

Reading that one sentence by HEAVEN made me almost falling over backwards from the chair . It actually fits "a bit" in Rescue on Fractalus, but in any game that uses "normal" Graphics, the cycle stealing is far from any good for NTSC Systems.

And Character modes were the overkill. Allowing some games to run fairly on PAL Systems, while CPU Cycles weren't availabe on NTSC Systems .

Things turn crazy , if people take part then, who claim , the Atari can do the same on NTSC, while they already went off the path, using an accelerator cart. And so on...

[emkay]

Koronis Rift could be a better example. The Screen is not using Mode D , as it is using GTIA 10 it needs Antic 2 or F.

 

Even more interesting: The "Dashboard" is done, using Mode 2 , which means Character Mode at a Screen Range where nothing is moving.

 

Not to tell that "my personal Favorite" on the Atari isn't finished at all, there are optimizations possible.

[emkay]

So mr know it all expert. Let's see any of your fractal or 3D rendering codes on any of 7 platforms I previously mentioned. Put up or shut up and leave this forum you blow hard.

One Question: Is that Subscriber status a paid qualification for trolling ?

Without your misplaced statements, as in many other threads, the technical aspects could have been forced more clear and in a common sense.

Please, put me on you ignore list. This would solve a lot Problems, and helps for more fluent technical discussions.

[+Stephen]

One Question: Is that Subscriber status a paid qualification for trolling ?

Without your misplaced statements, as in many other threads, the technical aspects could have been forced more clear and in a common sense.

Please, put me on you ignore list. This would solve a lot Problems, and helps for more fluent technical discussions.

You mean your incorrect statements, proven wrong by people who actually code? No - I don't need to let false information spread thank you very much.

 

Also, I don't subscribe so I can troll trolls like you. I subscribe to help Al offset the high prices for hosting this fine forum.

[emkay]

 

 

 

You mean your incorrect statements, proven wrong by people who actually code?

Yeah, I have still no answer to your post, as I could write something in German, but the translation would not fit.

 

So , I ask you with polite Words : WHAT did coders actually prove where I was wrong?

 

It is still NOT explained, why the C64 Version is not recognizable different in PAL or NTSC, while there is a clear difference between the PAL and NTSC Versions on the Atari.

I also wouldn't count on people's statements that tell the C64 had 256 colors. If someone was writing a real 3D routine for the 6502 , I'd listen. Just like Pr0be did. "Control" reaches something between 6 and 14 fps. C64 is in no way able to show the same flexibility in 3D with that framerates.

But the C64 has MooD. The Atari has nothing comparable, even if it is the better machine for this.

 

The worst part is that , even if people want to do real new and possible stuff, they always get redirected into those blind alleys.

Not by me...