tepples wrote:More countries used PAL 50 Hz or SECAM than NTSC or PAL-M.
It's not about the countries, it's about the market share of the NES and the general perception.
As a pop culture icon, the NES is mostly perceived in its American form:
When you hear the "Super Mario Bros." theme, you never hear the screwed-up PAL version.
Everybody knows "Contra", but nobody really gives a shit about "Probotector".
When they released "Balloon Fight" on the virtual console, people complained that European gamers got the 50 Hz version.
Also, the speed of the NES matches the 60 Hz that is used in arcades.
Same with Nintendo itself:
Nintendo of Japan is the mother company.
Nintendo of America was lead by the Japanese boss' son-in-law and it's influential for many things that later became popular.
For one, "Donkey Kong" was only programmed because the American branch needed a fresh new game.
And they are the ones who came up with the name Mario.
Now, who was Nintendo of Europe? A bunch of Bavarians who liked to include stupid in-jokes or sexual allusions into the German translations of games.
Also, Nintendo's arcade conversions can only be fully enjoyed on an NTSC machine because American and European arcade games run on 60 Hz.
That's why I would never program a game natively for PAL and then adjust it for NTSC with some half-assed workarounds. The main game is always the NTSC version.
It would be a different story when it comes to C64 games.
Hojo_Norem wrote:The thing is, GradualGames wants to make his game auto adjust for different systems.
The first few posts are helpful comments on how this could be achieved...
... then one comes along saying, in a nutshell "Don't bother. Code for NTSC. PAL is crap."
You're free to suggest more ways to convert a game from NTSC to PAL.
The only other way I know:
Make the playfield five times as big in memory. (I.e. one on-screen pixel is five virtual pixels in memory.)
Calculate all movement based on this larger playfield.
I.e. if a character in a normal game moves two on-screen pixels per frame, let him move 10 virtual pixels in NTSC and 12 virtual pixels in PAL per frame.
Same with the animations:
Pretend that there are five times as many animation frames. If your characater has three running animation images, make an array of 15 animations and distribute the three animation frames evenly in this array.
Use the array in a circular way (i.e. if you're at entry 15, go back to entry 1) to determine the next animation: On NTSC, increment the index of the array by 5 everytime a change is necessary. On PAL by 6.
Do your game logic calculations, like collision checks, normally, once per frame, based on the current character positions after the calculations.
Afterwards, convert all character positions back to actual screen coordinates for output.
I have no idea how playing this would feel, though.
tokumaru wrote:Ironically enough, it was the guy who usually complains when we don't stick to answering exactly what he asks in his own threads!
That's not quite comparable. If I ask a question about suggestions like "Game with a human female main character that is recognizable as a female" and people suggest "Ms. Pac-Man", "Bird Week" or "Metroid", then I'm of course pissed.
But if I'm asking a technical question about some programming issue that I want to do and people say that my line of thought is too complicated and that actual games did a much easier approach than what I have in mind, I often agreed with them and took the easier route.
So, the easier route for this specific problem is: We have 2017. People have access to NTSC versions of the consoles and games. Everybody who strives for authenticity will get a 60 Hz console anyway. People who still use PAL are the ones who accept that games run slower. So, why bother with them? They don't care that "Super Mario Bros." doesnt play at full speed, so they won't care whether your game plays at full speed. Adjusting a game to play exactly alike on both consoles is investing time and energy into a niche market of a niche market.