3DO ZONE Forums

Regarding the JagDoom source code Chilly Willy wrote:Doom is rather interesting - the rendering is split into stages, each one triggering the next. After a few stages, the variables in ram aren't needed anymore, so the 68000 is allowed to continue running the game logic in parallel to the later stages of the GPU code finishing the rendering. Once you're down to columns and spans (the two graphical operations done in Doom rendering), the GPU starts sending operations to the BLITTER. Funny enough, the 68000 handles all the OP setup for each frame after the GPU finishes the last stage. Having the GPU load later stages of code to work on a problem is very similar to how the RSP works in the N64 - since there is only 4KB of instruction ram in the RSP, the "microcode" is split into sections which are loaded into instruction ram as needed. Given how efficient loading the GPU local ram is, having GPU code load itself in stages could have easily been used by more games than just Doom. It probably would have become standard if the Jag had lasted in the marketplace.

Regarding possible JagDoom optimizations Chilly Willy wrote:Doom on the Jaguar divides the task of running the game between the 68000 and the GPU, with each being roughly able to run at the same time. The 68000 runs nearly all the game logic, while the GPU runs nearly all the rendering code. Remember that Carmack himself worked on this code. The rendering code had to be broken into NINE SEGMENTS of 4K each. The 68000 runs all the game logic, starts the first GPU segment, then waits until the third segment is done. By that time, the rendering has finished using the game variables that will be changed by the game logic (player position, etc). The 68000 then starts on the next tick worth of game logic. Each GPU segment interrupts the 68000 to blit the next segment into local ram, with the last segment triggering the 68000 to build the next OP list. The GPU uses the blitter as it goes where it can for drawing. If the 68000 finishes the game logic before the rendering is done, it must wait on the rendering. So the 68000 has one spot where it always waits, and another spot it MIGHT wait. It's possible the GPU might finish the rendering before the 68000 finishes the game logic (for example, your nose right up against a plain wall), and so it has one place it MIGHT wait as well.

Concerning the Atari Rendererer Gorf wrote:The problem with the Atari renderer that is in source form is that it is loaded with a lot of 68k code. Not only that, the renderer itself is poorly written in the fact that it not only uses 16 bit values to work with, but it also uses the matrix instuctions and that it was written to draw one model at a time as opposed to building a list of polygons to rip through, as it should. So for every model you want to draw per frame, it processes each one through all the set up....very inefficient. A good renderer would consider ALL models per frame, build a list of polies and then render them using 32 bit values and instead of the matrix multiply instructions which take WAY too much setup, it should use the MAC instructions which would better handle 32 bit values. Something the MMULT instruction can't do.

What Scott (JagMod) did to speed up the renderer is get rid of the 68k code all together, eliminate all the blits of the code to GPU local and put them in to one big chunk. The other issue with the Atari renderer is it has the GPU stopped completely while the blitter keeps loading in vertices to the RAM. What should be happening is that the verts should be out in main and keep the GPU running at all times. OR use a small portion of the local to have the blitter move the verts to WHILE the GPU is constanly processing them or at least doing something else while waiting for the blitter to load the next set.

A big problem besides the 68k running way too much is the fact that the GPU is constantly waiting in a tight loop for the blitter to finish moving the data.....a ton of wasted cycles right there. JagMod had a small sample code where the GPU never stops working and got well over 80,000 blits PER FRAME using this method. This was a first attempt too.

I maintain that we have not seen anywhere near the true ability of the Jaguar's 3D capabilities just based on these serious flaws of coding inefficiencies. Just about every game uses this piss poor method of GPU waiting and over use of the 68k.

Graphics Gems
___________________________________________________________
File Name Archive # Description
-----------------------------------------------------------
2DClip 1 2D Clipping: A Vector-Based Approach
2DClip/Makefile 1 Makefile
2DClip/bio.c 2 Basic operations
2DClip/box.h 1 BOX definition
2DClip/clip.c 2 Clipping routines
2DClip/cross.c 4 Intersection calculation
2DClip/line.h 1 Major definitions
AALines 1 Rendering Anti-Aliased Lines
AALines/00README 1 Information about AALines Gem
AALines/AALines.c 4 Code to render an anti-aliased line
AALines/AALines.h 1 Symbols & globals
AALines/AAMain.c 1 Calling routine
AALines/AATables.c 4 Initialization of tables and frame buffer
AALines/FastMatMul.c 5 Fast routines to multiply 4x4 matrices
AALines/LongConst.h 1 High-precision constants
AALines/Makefile 1 Makefile
AALines/utah.c 3 Interface to Utah Raster Toolkit
AALines/utah.h 1 Declarations for URT interface
AAPolyScan.c 4 Fast Anti_aliasing Polygon Scan Conversion
Albers.c 3 Albers Equal-Area Conic Map Projection

xlines.c I.2 Mukesh Prasad, "Intersection of Line Segments"

Peano/ I.7 Ken Musgrave, "A Peano Curve Generation Algorithm"
Makefile
main.c
mapply.c
peano.c
types.h

Hilbert.c I.8 Douglas Voorhies, "Space-Filling Curves and a Measure of Coherence"

dither/ II.3 Spencer W. Thomas and Rod G. Bogart, "Color Dithering"
dither.3
dither.c

RealPixels/ II.5 Greg Ward, "Real Pixels"
color.c
color.h
colrops.c
header.c
rasterfile.h
ra_pr24.c
resolu.c

rotate8x8.c II.6 Sue-Ken Yap, "A fast 90-Degree Bitmap Rotator"

inv_cmap/ III.1 Spencer W. Thomas, "Efficient Inverse Color Map Computation"
inv_cmap.3
inv_cmap.c

quantizer.c III.2 Xiaolin Wu, "Efficient Statistical Computations for Optimal Color Quantization"

File or Gem
Directory Number Author and Title of Gem
--------- ------ -----------------------

I. Image Processing

fastBitmap.c I.1 Tomas Moller, "Fast Bitmap Stretching" (doesn't compile)
comments: ANSI C

filter.c I.2 Dale Schumacher, "General Filtered Image Rescaling"

bitmap.c I.3 Dale Schumacher, "Optimization of Bitmap Scaling Operations"

rgbvary.c I.4 Bragg, "A Simple Color Quantization Pre-processor"
comments: ANSI C

contour.c I.6 Tim Feldman, "Generating Iso-Contours from a Pixmap"

scallops8.c I.9 Eric Furman, "A Fast Boundary Generator for Composited Regions"

II. Numerical & Programming Techniques

sqrt.c II.1 Steve Hill, "IEEE Fast Square Root"

alloc/ II.2 Steve Hill, "A Simple Fast Memory Allocator"
alloc.c
alloc.h

3d.c II.3 Steven Hanson, "The Rolling Ball"
defs.h

interval.C II.4 Jon Rokne, "Interval Arithmetic"
comments: C++

CONTENTS:

file or book chapter title and author
directory chapter
------------------------------------------------------------

I Polygons and Polyhedra

centroid.c I.1 Centroid of a Polygon
Gerard Bashein and Paul R. Detmer

convex_test/ I.2 Testing the Convexity of a Polygon
Peter Schorn and Frederick Fisher

ptpoly_weiler/ I.3 An Incremental Angle Point in Polygon Test
Kevin Weiler

ptpoly_haines/ I.4 Point in Polygon Strategies
Eric Haines

delaunay/ I.5 Incremental Delaunay Triangulation
Dani Lischinski

vert_norm/ I.6 Building Vertex Normals from an Unstructured Polygon
List
Andrew Glassner

collide.c I.8 Fast Collision Detection of Moving Convex Polyhedra
Rich Rabbitz

WEEKLY REPORT for Eric Smith
Week ending: 6/23/95


Hoverstrike CD
--------------
Implemented a dissolve routine in the
GPU to run during transitions (i.e.
while data is being loaded from CD).

// mkbnd.c - utility to convert 3d studio (*.asc) text files into *.inc source files

Building Big Worlds:

To build a large (multi-piece) world, we need to link
bands together. This is done with the "band list".
Each band has a band list, which gives what other
bands need to be drawn and in what order. The bnd2mdl
program generates band lists (and other special band
information) from a "link" file.