Amiga 3D game programming

[Steve]

Hi

I may have a go at programming a 3D Amiga game in the future once I've completed a few 3D demos. What I want to know is how well the Amiga can process filled and filled/textured polygons. For example how many filled polys can the standard A500 handle compared to a standard A1200. Anyone know?

[musashi5150]

Filled polys are ok - but textured ones? Unless you have a heavy-accelerated Amiga or want to use a Coppertrick (Alien Breed 3D) then you should be able to make a cup to tea between frames

If you are using the Blitter to draw filled polys, there won't be a world of difference between A1200 and A500. The A1200 will do the math faster and maybe render slightly quicker due to the enhanced bitplane DMA fetching - but actual polygon rendering speed is the same as A500 as the blitter isn't ANY faster.

Having some fastram in the machine will help a lot for sure - as it will keep your code out of chipmem

[Photon]

Yeah, if you're using an accelerator with Fast RAM the CPU is faster. The blitter just trundles along at its base MHz. Check out the end part of Arte by Sanity for a 3D routine which makes use of accel.

Forget about textures I say. I doubt 20 textured polys of like 40x40 pixels gives you 1 fps on an A500. Few programmers have succeeded in real texture mapping at all, one exception might be Virtual Intelligence by Horizon. It doesn't seem to use perspective though, i.e. isometric 3D, might be wrong (hard to see).

I think TEC/Cryptoburners made a nice shaded filled poly routine, I'm sure the source is available somewhere. Never did get any of the demos with those routines to work on an OCS A500 though. Probably a small bug like relying on some content of a blitter register that isn't there in OCS.

The Amiga chipset has its limits, but it also allows for creative possibilities. So have a think how you could trick the hardware to save chunks of time.

[Doc Mindie]

While we're wandering down the limited Amiga Hardware line.....

In todays world, you just throw a faster processor into the system..... while on the amiga, you use programming tricks to recieve a good result. IMO, you make a better coder when you have to use tricks and circumventions, than just throwing some more horsepower at your code to be able to run it at adequate speeds.

YAY for tricky coding

[musashi5150]

Originally Posted by Doc Mindie

In todays world, you just throw a faster processor into the system..... while on the amiga, you use programming tricks to recieve a good result.

Indeed Ghz machines today take the brains out of coding. Get a machine running only a few Mhz with limited RAM and we can see who the good coders are That's one of things I love most on Amiga... clever coding tricks

[Galahad/FLT]

Originally Posted by musashi5150

Indeed Ghz machines today take the brains out of coding. Get a machine running only a few Mhz with limited RAM and we can see who the good coders are That's one of things I love most on Amiga... clever coding tricks

One of the reasons why so many Amiga demo coders were snapped up to write on SNES and Megadrive

[Frog]

if you want to see some mapping on A500 :
Blitter Disaster / Storm http://www.pouet.net/prod.php?which=14569
Cube'o'Matic / SPREADPOINT http://pouet.net/prod.php?which=5849

or BlitterMiracle / BRS http://pouet.net/prod.php?which=5853

BTW why not make "Stencil vector" like in Mental Hangover ? with some good maps it can look pretty nice.

@Proton : didn't know Virtual Intelligence / Horizon , i'll watch it http://pouet.net/prod.php?which=19102

[Photon]

Photon! I'm a cool zippy light particle, not a measly nucleus pea.

Well it's not really texture mapping as we know it if it's a special case that can't be put on a poly of your choosing. It seems the Brainstorm one and the Storm one are non-perspective blitter routines, too. I liked the Spreadpoint one, they seemed to do it right, and they had shading, too. Horizon put that on a bunch of objects, but I'm not sure I saw a texmapped poly that was a tri, only quads?

Stencil vectors look good if you have many small polys, i.e. don't get close to objects. It would probably look not so good in a Dungeon Master type game

[P-J]

Originally Posted by musashi5150

Indeed Ghz machines today take the brains out of coding. Get a machine running only a few Mhz with limited RAM and we can see who the good coders are That's one of things I love most on Amiga... clever coding tricks

...and limit your target audience to a handful. No thanks.

[Steve]

Hey great comments.

I was more thinking along the lines of writing a 3D game. Maybe an updated version of Castle Master or Legends of Valour for the AGA Amiga's. That would be pretty sweet. The Amiga is certainly very capable of texture mapping. You only have to look at games like Gloom Deluxe and the amazing looking Breathless. Even Legends of Valour had a bit of texture mapping and that was an Amiga 500 game. I'll probably start with a 2D game though.

[Photon]

Hey Steve, tried them and well... remembered I played LoV back then. Looks good but it's a 100x50 pxl screen and 4 fps? If that's what you want but speeded up for AGA, sure. But texture mapping at least resembling what we're used to in games now or maybe 6 years ago is tricky on an Amiga. I will never say anything is impossible on Amiga. Never. Maybe a cool project for the lucky A1260T owners out there?

Breathless was pretty much the same as LoV, twice the screen size but twice as big pixels Better FPS though, but it's AGA of course. Gloom Deluxe - tiny screen again, good FPS but if you ran fullscreen you got gigantic pixels :'( Only tried the demos though, maybe full version is better?

About your 2D game: Yeah, if you're not an Amiga Ace texture mapping is not the easiest start Will be interesting to see how your programming comes along!

[Photon]

Originally Posted by P-J

...and limit your target audience to a handful. No thanks.

Hey P-J, what do you mean by that???

[Steve]

Originally Posted by Photon

Hey Steve, tried them and well... remembered I played LoV back then. Looks good but it's a 100x50 pxl screen and 4 fps? If that's what you want but speeded up for AGA, sure. But texture mapping at least resembling what we're used to in games now or maybe 6 years ago is tricky on an Amiga. I will never say anything is impossible on Amiga. Never. Maybe a cool project for the lucky A1260T owners out there?

Basically I'd like to do a full screen version of a 3D classic like Castle Master or LoV. I wouldn't want them to run in a tiny little screen like the original versions though. An upgraded A1200 should easily be able to handle a fullscreen AGA version of LoV.

Breathless was pretty much the same as LoV, twice the screen size but twice as big pixels Better FPS though, but it's AGA of course. Gloom Deluxe - tiny screen again, good FPS but if you ran fullscreen you got gigantic pixels :'( Only tried the demos though, maybe full version is better?

No, no, no! You must have tried the games in their default 2x2 'chunky' pixel mode. You can change the display settings in both games so they render in 1x1 pixel mode and look very nice indeed. The pixels are more noticable nowadays (in 3D Amiga games) because modern games use texture filtering which the Amiga can't do.

About your 2D game: Yeah, if you're not an Amiga Ace texture mapping is not the easiest start Will be interesting to see how your programming comes along!

Well I write 3D games for a living so I reckon I've got half a chance. lol. I'm really still learning about the inner workings of the Amiga though. I might have a go at making a version of Gloom Deluxe for the DS. I think the DS would be perfect for a game like that. What do you guys think?

[P-J]

Originally Posted by Photon

Hey P-J, what do you mean by that???

The smiley face says it all

[Frog]

Originally Posted by Photon

Photon! I'm a cool zippy light particle, not a measly nucleus pea.

oops sorry Photon...

[Kalms]

Just a word or two regarding performance...

The total number of pixels displayed by a copperscreen display is limited by the speed of the copper itself.
The copper can do approx. 57 MOVEs per scanline in normal 15kHz PAL/NTSC resolutions.

This means that if you want to have chunky-pixels that are 2 scanlines high, you can have up to 114 chunky-pixels horizontally.
If you want to have chunky-pixels that are 3 scanlines high, you can have up to 128 chunky-pixels horizontally. (You'll stop at 128 since you're double-buffering the palette.)
This means that the best resolution you'll get for a full-screen copperscreen is 2.5x3 pixelsize.

If you have a copperscreen at a high resolution, the copper will consume a lot of your chipmem bandwidth too. If you target 68030+ then you are probably better off with a C2P based solution.

Chipmem write bandwidth: ~7MB/s
Fastmem read bandwidth, Blizzard 1230: ~30MB/s
Fastmem read bandwidth, Blizzard 1260: ~35MB/s

You'll want to do all rendering to a temporary buffer in fastmem, and once that is done you c2p convert the result into chipmem. (You can do some improvements on the scheme, but that's the gist of it.)

Let's presume that you want to render 320x200 chunkypixels, at 1x1 pixelsize.

320x200x8bpl of graphics data = 64000 bytes of data.
Copying 64kB of data fast->chip takes roughly 15ms (i.e. 75% of a frame).
35MB/s read speed for fastmem translates into 700kB/frame. Considering that you will be reading & writing 64kB just for the *screen writes* (assumiung no overdraw), you are going to consume considerably more bandwidth than that on datacache misses for the texture accesses.

That's why you haven't seen a lot of really smooth 1x1 full-on 3d graphics in games on the miggy. [In demos it's easier, since there you can tweak the camera and the environment until the performance target has been achieved.]

[Steve]

Interestig stuff Kalms. Thats certainly worth reading a few times (till it has sunk in - still early in the morning).

I'm now wondering how many of the textured Amiga games are really true 3D environments. I think Alien Breed 3D II is but I'm not so sure about Gloom Deluxe and Breathless and all the other 'Doom clones'. Are these games using the same type of rendering technique as Wolfenstein 3D and Doom by basically cheating a 3D display?

How can you tell if a game is rendering a true 3D environment (like Quake does)?

What do you think is the difference in CPU expense between true 3D and fake 3D games?

[DDNI]

Steve, if its slooooooooow its full 3d, if it jerks rapidly its pseudo 3D...

[musashi5150]

Originally Posted by DDNI

Steve, if its slooooooooow its full 3d, if it jerks rapidly its pseudo 3D...

Nicely explained

[redblade]

hmm code a HAM update of FA-18 Interceptor

does any one know what the Flight simulator was that Jay Miner saw?

[Kalms]

Originally Posted by Steve

I'm now wondering how many of the textured Amiga games are really true 3D environments. I think Alien Breed 3D II is but I'm not so sure about Gloom Deluxe and Breathless and all the other 'Doom clones'. Are these games using the same type of rendering technique as Wolfenstein 3D and Doom by basically cheating a 3D display?

Doom supports:
* vertical walls, in any compass angle
* horizontal floors/ceilings, at varying heights

A Doom map, when seen from above, is a collection of 2d polygons. The edges are the walls. Each polygon has a floor/ceiling
height value associated with it.

Gloom Deluxe supports:
* vertical walls, in any compass angle
* one single horizontal floor/ceiling, at fixed height

I think Breathless supports a subset of Doom's functionality. Can't remember which right now.

AB3DII does most (all?) of what Doom does. It might also support overlapping polygons. Still, it is a 2.5D renderer.

Trapped II is the most technically advanced game I can remember for the Amiga. Written mainly by TTS/Oxyron? It is mainly a 2.5D renderer with hacks for sloped floors, and it also supports polygonal interior objects (such as monsters).

Originally Posted by Steve

How can you tell if a game is rendering a true 3D environment (like Quake does)?

If nearly all walls are vertical, and nearly all floors/ceilings are horizontal, then it probably is a 2.5D environment.

Originally Posted by Steve

What do you think is the difference in CPU expense between true 3D and fake 3D games?

I'd expect a full 3D environment to run at 1/2 the speed, or less, due to:
* less effective HSR (in the 2.5D case you can a portal solution in 2D)
* more cache misses during texture reads when rendering 'walls'
* more CPU work when rendering sloped surfaces with perspective correction
* smaller polygons (full 3D gives artists the ability to express themselves better, and so they will)

Trying to do a full 3d environment in 320x200 1x1 for anything less than 060 and have it look decent is IMO futile. 1x1 might be doable, but if you want to display something interesting in addition to the environment I suggest that you prepare yourself for running in 2x1/1x2 on the 060 as well.

[Kalms]

... I drop a bunch of facts and you all go quiet?

*sniff*

[musashi5150]

I guess we think you said it all Kalms Or perhaps we were all stunned into silence by the presence of an uber-coder in our forum

[spiff]

Originally Posted by Doc Mindie

In todays world, you just throw a faster processor into the system.....

While true there are still a lot of problems where even 10 doubling the processor/GPU speed won't solve the problem.. and needs some neat tricks to work. Esp now that we're starting to get some real programming on GPUs
http://www.beyond3d.com/articles/fastinvsqrt/

[Doc Mindie]

Well.... the Amiga's had the GPU programmed since 1985, hasn't it? I mean, the Blitter and copper is part of the GFX-processing co-processor, right?

It's "about bloody time" the PC-coders started to understand it's actually possible to take a few cycles of CPU-power away from the CPU itself, if you ask me

That said..... I still hold my view that on a computer with far less "raw horsepower" than modern day PC-architecture, coding tricks can still produce results that'll make PC-users go "WOW!!! I can't do that on my P-IV 4.5GHz quadcore"

Let's have an example.... Pinball Dreams. Runs flawless on a 7MHz A500 with 1MB mem, yes? Does it run just as good on a 486SX25 with 4MB RAM? Said PC has 3.5times the pure CPU power, and 4times the RAM.......

[Photon]

steve, it would be cool to look at some of those coming 3D demos You know where to announce them...

[Steve]

Originally Posted by Kalms

... I drop a bunch of facts and you all go quiet?

*sniff*

Hey Kalms!!



Sorry man! I missed your superb post. I've just read it and it is very interesting stuff! You certainly know your 3D from your 2.5D.

Really good explanation of the questions.

I wouldn't want to code a fully 3D game like Quake on the Amiga but something like Hunter or Zeewolf but with texturing. How would you classify these games as they're clearly both three-dimensional.

Anyway sorry for not responding sooner. I really appreciate your input!

Photon: I will work on some 2D ones first before I go anyway near 3D... once I've got my computer back!

[Kalms]

Hi again, Steve.

Doom/Quake/Descent etc are normally classified as indoor environments. Those lend themselves naturally to portal-based visibility determination algorithms, and aggressive visibility precomputations.

In indoor environments there is a lot of occlusion (when you're inside a room with no open doors, its walls occlude the rest of the world) and therefore most indoor visibility determination algorithms will start from where the camera is located, work its way away from the camera, incrementally adding geometry to the currently visible set until enough geometry has been collected to fill the entire screen. Indoor environments are also largely static (non-moving) and that helps when doing some precomputations.

In a sense, the incremental approach outlined above attempts to answer the question "what is visible from the camera's current location" by incrementally adding stuff until satisfied. The result is generally close to what an optimal HSR (hidden-surface removal) algorithm would produce.

The Quake world contains 2 types of geometry:

• The environment. A huge 3D mesh, which is rendered with a precise HSR algorithm (first PVS culling, then Active Edge Tables). It is a static, large object. Lots of visibility precomputations.
• Characters/bullets/etc. These are small and dynamic objects. They just get roughly culled against the visibility information obtained during world traversal, and are then composited into the environment using z-buffering.

Zeewolf, Hunter etc are normally classified as outdoor environments. The main identifying characteristic is that there is far less occlusion, and doing a good HSR is trickier.

You find 3 different types of geometry in those worlds:

• The environment. A 2D heightfield. Static, large object with close to no self-occlusion. It rarely occludes other objects either.
• Buildings. Small-to-medium sized static 3D objects. The interior is never visible when being outside the building, and vice versa.
• Characters/vehicles. Small dynamic 3D objects.

By implementing a specific renderer for each type of geometry, you can often save on CPU power and memory. For instance, the environment can usually be represented as a 2D array of heights rather than a general-purpose 3D mesh. Culling a heightmap against a 3D frustum is notably cheaper than culling a general-purpose 3D mesh against a frustum, for instance.

Since HSR is more difficult in the outdoors case (any precomputations which will give any significant results will cost you insane amounts of diskspace), a more conservative approach is usually employed:

1. Determine conservatively, "what is visible from the camera's current location" by culling the environment, buildings, and characters/vehicles against the current view frustum.
2. Determine, for your current visible set, "what is NOT visible from the camera's current location" by doing self-occlusion for all objects you picked up during step 1. For instance, this is where you might decide that the camera is outside of a building and the interior should therefore not be rendered.
3. Determine, for your current visible set, "what is NOT visible from the camera's current location" by doing occlusion between objects. This can be done by using "occluders", for instance.

Step 1 is the easiest whereas step 3 is the most difficult.

In practice you wouldn't implement it as 3 sequential passes; the logic, even while being implemented recursively, would follow those lines though. (i.e. first determine roughly which parts of the world are up for rendering, then as you iterate over each object you try to progressively reject more and more of it before it reaches the renderer.)


If I were to implement Zeewolf, then I would have:

• A 2D heightfield for the terrain
• One 2D grid which held references to the static objects
• One 2D grid which held references to the dynamic objects

Then, during render time:

• Slice out the correct bits of the heightfield which is within the current view frustum
• Slice out the correct squares in the static-object-grid and trivially accept those objects
• Slice out the correct squares in the dynamic-object-grid and trivially accept those objects

I wouldn't do any advanced culling because it probably wouldn't pay off in processing performance.


Oops, this became a bit wordier than I had intended. Oh well...

[Steve]

Originally Posted by Photon

steve, it would be cool to look at some of those coming 3D demos You know where to announce them...

Well, ok then, seeing as you asked nicely.

For the past year or two I have been secretly beavering away on my top secret project which is (wait for it)... a 3D remake of Eye of the Beholder. Woohoo! Ok, the project isn't for the Amiga (win32), but still its looking pretty good so far. Once the first level is finished (probably the end of the year at this rate) I will post it here for all to see and play with.

I'm coding it using C++ and OpenGL. There are no special effects yet and no monsters. All that will come later. The last thing I was working on was hidden surface removal and player-wall collision detection using bsp tree. That is one tough subject!

I've uploaded a small 3D demo I coded which was a test of my camera functions. You can control a dalek in a 3D environment with the keyboard or a joypad. No gameplay or collision checks as it was just a test demo. Don't blame me though if it melts your graphics card or something! lol.

Kalms: That was an awesome explanation. Still, I'll need to read it a few more times! lol. What 3D projects have you worked on? Anything Amiga related?

[Kalms]

Steve: Amiga related: All TBL demos since 2001. Other than those, I did the main body of work on the rendering engine for BF2:MC for PS2.
That's about it.

[Zetr0]

if its mentioned before its worth mentioning again...

for all things 3d you need nehe

http://nehe.gamedev.net/

its got a tutorial on colision detection based on the "on left rule" its worthy of much reading.... I have an unoffical mirror of all this LOL

Hi all,

back in 90's i had a superb (imho) idea for a pseudo texturemapper; by using blitters line-draw mode and toying with screen modulo I was able to draw some sort of chunky-images to screen just drawing vertical lines with different texture.
It worked fine (using AMOS and fixed simpleline-routine (from Hardware Ref. Manual) and even did scale nicely (using routine adobted from Bresenham's line algorithm) but I did not have any skills to optimize line-drawing routine to get most out of it.

That was years ago, but I'm still wondering if real coder(s) could have get even better results with that kind of routine (optimized vertical line, scale-routine using macros, etc.)?

I don't have any Amy (and skills) to even try to write that kind of thing anymore, so I'm asking if there's any volunteers to prove me that I've wasted most of my freetime back then. I still believe that i was creating some kind "state of the art"-technique ;-D

Sorry about my language; I'm stupid, ugly, old and finnish...

[keropi]

amiga and 3d .... what a pain....
not even a single 3D game I have played comes near to playable nowdays... gloom, ab3d and all are choppy .... sure they impressed us 10+ years ago, where there were no standards to compare, but now...

[Photon]

Originally Posted by keropi

amiga and 3d .... what a pain....
not even a single 3D game I have played comes near to playable nowdays... gloom, ab3d and all are choppy .... sure they impressed us 10+ years ago, where there were no standards to compare, but now...

Sure there were standards. The Amiga was the standard to compare to. And it did very well, until VGA and fast CPUs came. In essence, when Quake came for PC.

[Marcuz]

@Steve, just downloaded and watched your 2 images in the zone, for a non pro those looks the best i've seen on the net at a rpg like enviroment. they are indeed claustrophobic. cool!

I have recently implemented a fast chunky2planar and txture mapper for the amiga 500. The screen format is 4bpl 320x200 (2x2) copper stretched on th y axis and scrollregister streteched on the xaxis(blitter screen). The c2p is a one pass blitter c2p. The chunkybuffer is a scrambled nibble buffer, and for fast rendering I need two txtures. The txturemapper is a divsfree Selfmodified code mapper wich interpolates for each 8 pixel.
.
I plan to use this in a demo for the Assembly oldchool competition, but I am trying to finish something for Breakpoint 2007. Fullscreen txturemapped 3d scenes with few polys in 20-25fps. with the 7mhz Mc68000 ??? Can it be done?? :-D

Read more here:

http://ada.untergrund.net/forum/inde...um=4&topic=217
http://www.pouet.net/topic.php?which=3838

[kriz]

Cool, I will look forward to the Contraz release!! Breakpoint is soon now