Some video output information.

Discuss miscellaneous N64-related matter here.
Post Reply
User avatar
The Extremist
Posts: 29
Joined: Sun Nov 03, 2013 6:11 pm
Location: Canadian Prairie

Some video output information.

Post by The Extremist » Tue May 03, 2016 1:23 pm

Seen this?
NTSC to PAL Conversion

After completing the American and Japanese versions of the game, it was my task to convert the game so that it could run on the European PAL television standard. Being British, I had a vested interest in making sure that the conversion was a good one. This meant two things: first, that the game used the whole of the vertical resolution of the PAL display (625 lines vs. 525 lines of NTSC); second, I wanted to ensure that the speed of the PAL game was the same as the NTSC one, even though the PAL refresh rate is 50hz rather than 60hz.

Fortunately, when we started work on Shadows, we realized that one of the most important things to consider was that it had to be a time-based game, rather than a frame-based one. This would allow for update rates that could vary considerably depending upon scene complexity, as well as the simple fact that we didn’t have any real hardware from which to measure performance characteristics. Essentially, the program keeps track of the absolute time between each update of the game. This value, which we called delta time, became a multiplicand for any movement or other time-based quantity. By this method, the game runs independent of the video refresh rate, with all objects moving and responding at the correct frequency.

The other issue had to do with the “letterbox” effect that is common to many NTSC to PAL conversions. In most cases, there is no extra rendering or increase in the vertical frame buffer size, leaving unsightly black bands above and below the visible game area. Since the vertical resolution is now greater than the original NTSC display, the aspect ratio will also change, causing the graphics to appear stretched horizontally.

While I wasn’t willing to accept this, I had presumed that I couldn’t afford the extra CPU time necessary to render a larger frame buffer, even with the extra time available due to the 50hz video refresh rate. There was also a question of the additional RAM usage required by our triple buffering of the frame buffer. My first attempt, therefore, was simply to change both the field of view and aspect ratios of the 3D engine.

This simple fix solved the “stretching” problem quite nicely, although the display remained letter-boxed, of course. Unfortunately, it also meant that any 2D-overlay status information remained “stretched.” There was the potential that game play could be affected because the field of view, by definition, would affect the player’s perception of the 3D world.

Again, this just wasn’t good enough. What I needed was a solution that didn’t require extra rendering, yet would fix the aspect ratio problems. After a little bit of research, I realized that I had discovered earlier that it was possible to change the size of the final visible display area on the output stage of the display hardware. In reality, it’s possible to shrink or enlarge the display both horizontally and vertically. To compensate for the letterboxing, all I had to do was change the vertical display size by a factor of 625/525 or 1.19. Once I did this, I immediately had a full-screen PAL version. Or so I thought….

One of things about Shadows is that we had to compress everything in the game to fit it into the cartridge space available. This included the thin operating system that SGI provides as part of the development system. Therefore, upon machine reset, it’s necessary to decompress this OS to run the game. To perform this decompression, we wrote a small bootstrap program, which introduced a small amount of time between the hardware being initialized and the OS starting. This lag introduced a onetime glitch on the screen as the video hardware started. Not very noticeable, except to me. After many late nights, I discovered a way to remove the glitch by directly accessing the Nintendo 64 video hardware registers.

Bad Idea

We then discovered that because we had accessed the hardware directly, it caused an infrequent bug. Rarely (1 out of 50 times) the Nintendo 64 would crash if the reset button were pressed at a particular point in the game. Not only that, I couldn’t repeat the bug on my hardware (I hate it when that happens).

After a number of very late nights (over the Christmas holiday), with the help of Nintendo of America’s technical staff (thanks Mark and Jim), we finally resolved the problem: first, by removing the code that directly accessed the video registers, and second, by restoring the registers controlling the scaling of the output in the vertical axis upon reset. Sometimes, the simplest solution is the best. ... Empire.php

Some other neat stuff in the article as well, though mostly dealing with development kits.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest