How did they program 3d rendering for golf games?
Moderator: Moderators
How did they program 3d rendering for golf games?
Hello everyone, I was wondering if anyone could shed some light on how graphics were rendered and displayed for golf games on the NES and 8-bit computers, or games with similar graphic rendering. I'm talking about the scenes that take a few seconds to display, as the golf course is rendered from the player's perspective, and you can see the screen slowly filling with grass, trees, water, etc. Are the principles used to create these scenes the same as those used for modern 3d graphics, hindered only by using a slow 8-bit processor? If it was done a different way, how did they do it?
I seem to remember some adventure games for the Apple II using 2D vector graphics for their static scenes. They too used slowly filling shapes.
So let me see if I can rephrase your question: These 8-bit golf games appear to use vector graphics. Are they stored in 2D, with a fixed set of perspectives, or in full 3D?
Can you give a title so that someone can possibly analyze the graphics engine?
So let me see if I can rephrase your question: These 8-bit golf games appear to use vector graphics. Are they stored in 2D, with a fixed set of perspectives, or in full 3D?
Can you give a title so that someone can possibly analyze the graphics engine?
Black box testing involves testing the behavior of a program solely by providing input and interpreting the output. It differs from white box testing, which involves analysis of the program code itself. Here's the outline of a black box experiment to try in Nicklaus:
- Save the state, then take a shot. Save a screenshot of stroke 2 setup.
- Load the saved state, line up the next shot slightly differently but the same distance, then take another shot.
- Load the saved state, line up a shot at a slightly shorter distance, then take it.
- Paste links to the screenshots here.
Jack Nicklaus golf uses soft renderer with CHR-RAM. It does some tricks to make you think that the game window is larger than it is. On screen it is 176*128 pixels, but top of the window is always the same and constructed from just a few tiles (four rows), and also there is a trick at bottom part of the window (two rows displayed as four, through doubling scanlines). So there is just 176*80 window, which is 220 tiles total. Not that special.
It is not a true perspective rendering. Altering the angle and even distance slightly produce identical results. Rendering appears to be based on a grid system. By that I mean that the image only changes when you reach the next grid location.
My guess is it does use some form of perspective rendering, otherwise why would it take so long to render the display?
My guess is it does use some form of perspective rendering, otherwise why would it take so long to render the display?
Because rasterization of even a 2D vector scene takes a long time on a 1.8 MHz 6502 CPU with a slow bus to the PPU. (Remember Videomation?) The scene at each grid point might be static.qbradq wrote:My guess is it does use some form of perspective rendering, otherwise why would it take so long to render the display?
You can transfer ~270 bytes (roughly, could be less actually) to CHR-RAM per frame. 220 tiles *16 is 3520 bytes - you need 13 frames just for transfer. You may need even more time to do actual render, because it is more complex than just transfer series of bytes, and there is the trick with doubling scanlines on the screen. Also, I don't know if it has additional RAM, because without it you can only have a small buffer in normal RAM, it makes render more difficult.
On top of this, there is no reason to expect code in this game to be state of art. It maybe just written to do job just somehow.
On top of this, there is no reason to expect code in this game to be state of art. It maybe just written to do job just somehow.
Nicklaus does not use extra RAM. It uses Konami's clone of UNROM with that weird rotated chip, as seen in its entry on NesCartDB.
Greg Norman's Golf Power seems to be the most graphically advanced of the bunch. It renders the scene very quickly, and even small changes in position are rendered acurately and with perspective. It's quite impressive really.
Here's an animated GIF of three different positions on the tee, each just a few pixels appart. Note, I don't know if this will show up for everyone. Let me know.
View image
Here's an animated GIF of three different positions on the tee, each just a few pixels appart. Note, I don't know if this will show up for everyone. Let me know.
View image
Greg Norman's does not use actual raster buffer in CHR RAM, at least not one with all the points addressable. It uses tile fill, and few first tiles in CHR are always fills. It uses less than half of one CHR bank to render background, just 112 tiles. The game does have both CHR RAM and WRAM, though, so my guess is that it renders frame into RAM, and then constructs nametable+needed tiles replacing repeating ones with 'fills'. Don't know how they were able to fit into 112 tiles all the time, though, maybe they drop some details if there is not enough room for all the unique tiles of a frame.
Try to use imgur.com for image hosting, it's much nicer than Google pages attachments.
The golf game vaguely reminded me of "Plain Jump" for the TI83, except this was more like Mario Kart mode 7 than simple horizontal line drawing.
The golf game vaguely reminded me of "Plain Jump" for the TI83, except this was more like Mario Kart mode 7 than simple horizontal line drawing.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!