English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 30 November 2006, 05:04   #21
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 224
Quote:
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).

Quote:
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.

Quote:
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 is offline  
Old 14 December 2006, 05:24   #22
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 224
... I drop a bunch of facts and you all go quiet?

*sniff*
Kalms is offline  
Old 14 December 2006, 10:18   #23
musashi5150
move.w #$4489,$dff07e
musashi5150's Avatar
 
Join Date: Sep 2005
Location: Norfolk, UK
Age: 38
Posts: 2,302
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
musashi5150 is offline  
Old 14 December 2006, 19:18   #24
spiff
Oh noes!
spiff's Avatar
 
Join Date: Mar 2003
Location: Neverland
Posts: 714
Quote:
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/
spiff is offline  
Old 15 December 2006, 18:47   #25
Doc Mindie
In deep Trouble
 
Join Date: Sep 2004
Location: Manchester, Made in Norway
Age: 47
Posts: 834
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.......
Doc Mindie is offline  
Old 17 December 2006, 02:34   #26
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,818
steve, it would be cool to look at some of those coming 3D demos You know where to announce them...
Photon is offline  
Old 10 January 2007, 18:43   #27
Steve
You are Fake News!
Steve's Avatar
 
Join Date: Jul 2001
Location: UK
Age: 41
Posts: 2,288
Thumbs up

Quote:
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!
Steve is offline  
Old 11 January 2007, 15:08   #28
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 224
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...

Last edited by Kalms; 11 January 2007 at 17:42.
Kalms is offline  
Old 18 January 2007, 18:34   #29
Steve
You are Fake News!
Steve's Avatar
 
Join Date: Jul 2001
Location: UK
Age: 41
Posts: 2,288
Floppy disk

Quote:
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?

Last edited by Steve; 18 January 2007 at 18:43.
Steve is offline  
Old 19 January 2007, 04:48   #30
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 224
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.

Last edited by Kalms; 19 January 2007 at 10:56.
Kalms is offline  
Old 19 January 2007, 07:13   #31
Zetr0
Ya' like it Retr0?
Zetr0's Avatar
 
Join Date: Jul 2005
Location: United Kingdom
Age: 45
Posts: 9,768
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
Zetr0 is offline  
Old 19 January 2007, 09:29   #32
slin
 
Posts: n/a
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...
 
Old 19 January 2007, 09:40   #33
keropi
.
 
Join Date: Oct 2004
Location: Ioannina/Greece
Posts: 5,040
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...
keropi is offline  
Old 22 January 2007, 17:54   #34
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,818
Quote:
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.
Photon is offline  
Old 22 January 2007, 18:51   #35
Marcuz
Wurk???
Marcuz's Avatar
 
Join Date: Jun 2002
Location: .
Age: 44
Posts: 5,260
@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!
Marcuz is offline  
Old 20 March 2007, 17:08   #36
sp_
 
Posts: n/a
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
 
Old 20 March 2007, 19:11   #37
kriz
Junior Member
kriz's Avatar
 
Join Date: Sep 2001
Location: No(R)Way
Age: 37
Posts: 2,488
Cool, I will look forward to the Contraz release!! Breakpoint is soon now
kriz is offline  
Old 17 June 2013, 23:15   #38
Lonewolf10
AMOS Extensions Developer
Lonewolf10's Avatar
 
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 40
Posts: 1,923
Quote:
Originally Posted by Galahad/FLT View Post
One of the reasons why so many Amiga demo coders were snapped up to write on SNES and Megadrive
Resurrecting an old thread to add this comment:

a couple of Amiga demo coders were snapped up by Sega to create games on the Sega Saturn. Whilst the console didn't do particularly well (I have it, and still love it), the two games they created (Amok and Scorcher) were pretty damn good for the time.
Lonewolf10 is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Programming a Simple A500-Compatible Game (Beginner) - Any Advice? Oktai-Wanda Coders. General 11 28 July 2013 01:26
Game Programming for Teens, 3rd Edition Book Amiga Forever MarketPlace 3 28 February 2011 21:19
Andre Lamothe's Tricks of the 3d game programming gurus Anding Coders. General 1 18 December 2010 11:58
The wrong attitude over bedroom programming and legendary game developers! manicx Retrogaming General Discussion 51 10 January 2004 15:09
GBA Game Programming Project CHiEF Retrogaming General Discussion 6 15 November 2002 01:15

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 17:20.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.19325 seconds with 13 queries