Dwedit wrote:
You can always simply run the game loop 6 times over 5 frames, but that will stutter and look stupid.
I don't think I will have time to update six times in five frames. I fear I'll even need to do some more optimizations in the next days in my game as it is, so I definitely don't have time for rendering an additional frame.
Dwedit wrote:
Or you could just say 'screw it' and do nothing to the game speed like 95% of all PAL released NES games. Europe got shafted so hard with crappy ports.
This will probably be done when I don't find an elegant solution. In this case, I'll only adjust the music. Or let it adjust automatically by setting FamiTone to PAL in the second build of the ROM.
Splitting the code into timed stuff that works independently from the frames per second would require a completely new concept for my game. So, I don't think I can split the tasks.
Also, I don't completely separate game logic and graphics output. O.k., the graphics output is pretty independent. But the game logic does set the ID of the current metasprite/animation frame as well as X and Y for each character.
LocalH wrote:
Another simple option for low-action games would be to design the game around 50Hz, and skip updates (except for vital ones like controller reads, you don't want any dead frames for input) one out of six frames on NTSC.
In my opinion, that's just evil.
I would never create the PAL version as the master version and the NTSC version as some afterthought hack. Either both formats are equally valid (for example calculate the game with 300 frames per seconds and output every fifth frame on NTSC and every sixth frame on PAL, which is obviously not possible on the NES due to processor speed) or the PAL version is the adjusted version.
By the way, what method does the PAL version of "Super Mario Bros." use? As far as I know, this isn't just the NTSC version with altered music, right?