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?
Jack Nicklaus Golf is one that renders the graphics from a perspective like that, I didn't care much for how slow it is but I thought it was still pretty impressive.
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:
If the perspective changes appropriately, then it's some sort of 3D rendering. If they're all the same, it's 2D vector rendering with a static scene based on the rough distance from the pin.
- 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.
If the perspective changes appropriately, then it's some sort of 3D rendering. If they're all the same, it's 2D vector rendering with a static scene based on the rough distance from the pin.
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?
qbradq wrote:
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.
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.
Wow, I didn't pick up on the fact that it had no work RAM. That's kinda impressive really 
tepples wrote:
Konami's clone of UNROM with that weird rotated chip
These boards are great for making devcarts, because there's plenty of space to solder a 32-pin EPROM/Flash in place of the 28-pin mask ROM. With normal UNROM boards this expansion can be tricky sometimes.
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.
There's a reason I use Goolge Pages for everything 
I am just blown away with how well the golf view is rendered in this game. It's not something I would have ever attempted on the NES
I am just blown away with how well the golf view is rendered in this game. It's not something I would have ever attempted on the NES
Dwedit wrote:
The golf game vaguely reminded me of "Plain Jump" for the TI83
You should at least reference Tetrastar or Cosmic Epsilon to keep it NES-related.
Are you referring to the Famicom 3D System?
Golf games use what appears to be 3D polygon rendering to a 2D image plane, sort of a slow Star Fox, not to stereoscopic display. These sorts of golf games probably wouldn't work with shutter-based 3D TV (such as the Famicom 3D system or modern LED LCD panels) because a game has to be able to switch between the left and right eye images in alternating fields. And for that to work, the game has to be able to draw one complete view in 1/60 s or store two complete views in CHR RAM. The glasses are more for games that use a Pole Position style engine to draw the floor, such as Rad Racer, 3D World Runner, Tetrastar, Cosmic Epsilon, or something like Street Fighter II or NBA Jam.
I couldn't find Tetrastar mentioned anywhere in a game context, and Cosmic Epsilon appears to be a Famicom 3D game.
qbradq wrote:
Are you referring to the Famicom 3D System?
No, the slightly advanced smooth checkerboard scrolling of each game.
http://www.youtube.com/watch?v=stDt8uafBlU
http://www.youtube.com/watch?v=BYUY--Hq ... re=related
I'll check those out on my lunch break. Thanks Chris!
Thanks everyone for sharing your expertise and insights.