home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Hack-Phreak Scene Programs
/
cleanhpvac.zip
/
cleanhpvac
/
CIS_GAME.ARJ
/
QWOLF1.THD
< prev
next >
Wrap
Text File
|
1993-07-01
|
11KB
|
229 lines
-------------------------------------------------------------------------
this comes before WOLF3D.THD already in the library
-------------------------------------------------------------------------
______________________ Subj: How Wolfenstein 3-D Works ______________________
Fm: Mark Betz/GD SL 76605,2346 # 172255
To: Ed. Mueller 70441,3720 Date: 28-May-92 09:27:58
Hi, Ed. Since Id's techniques are there own property, and haven't been
published, the best we can do is speculate. I asked Id during the conference
if they were mapping to a rotated wireframe, and they replied that they were
not, and that the engine was "image-based". That tells me that they are not
using a 3D model of the castle, but rather faking it by scaling and
foreshortening bitmaps before tiling them to the screen. One method that I've
thought of would involve the use of a perspective template, a collection of
lines of perspective that would allow you to decide the shape of a bitmap
based on it's position and distance relative to the viewer.
As for how they got such good performance, I think there are a couple of
aspects to it. One, they certainly wrote some highly optimized assembler.
Two, there's not much going on in the background of the game, so they
probably had a lot of cycles to devote to the animation.
The thing that really caught my interest at the CO was the statement that
this technology was "way surpassed" already.
--Mark
...........................................................................
Fm: Karl R Corritore 70243,1110 # 172580
To: Karl R Corritore 70243,1110 (X) Date: 29-May-92 13:26:24
Now that I got the game, I can tell you what I DO know about how they do the
screens. They have 3 different pages that they switch between for the
animation, to make it smoother.. They have 1 page which has a lot of
different groups of colors..these look like what they use to put the 'bad
guys' together,possibly 4 pixels at a time.
As they show you one screen, they write to a hidden page by first
writing, 4 pixels at a time, the top and bottom sections of the screen( the
ceiling and the floor), which meet at the middle of the page.(Therefore
making 2 solid color sections) Then they write the walls and stuff going
downwards, not left to right, because this way lessens the amount of times
you have to do OUT's to the ports(I use this for my own animation). The
lights and the spots in the floor are put in next, I guess. Then the 'bad
guys' are put in last..I could not tell you how they figure out the walls in
3d though.
_Karl
...........................................................................
Fm: guardian 76307,1643 # 315446
To: Christopher P. Kucsera 71303,3441 (X) Date: 17-Mar-93 14:16:48
Chris:
I'm almost exactly where you are, with the SAME questions! This is not much
help, but here's the little bit that I know...
A) There are several types of "objects" used in Wolf3D, and it helps to think
of them in the following types:
- wall objects, which are actually geometric cubes with graphics displayed on
them - impassable
-"actor" objects, displayed as a flat "billboard" on the playing field,
always perpendicular to your P.O.V., and graphics determined by some type of
direction variable.
-"object" object, displayed as a flat billboard same as the actors, sometimes
passable, sometimes not.
-goodie object, passable, disappears on contact
-door object, displays parallel to direction picked, moves graphic "door"
when activated
You get the idea. If you don't yet have Bill Kirby's Map Editor, get it. It
will help you think of the game in terms of these objects.
B) Check out a book called POWER GRAPHICS IN TURBO C++, available at Barnes &
Noble bookstores. I plan to buy it when I can afford it ($24.95), as it
covers things like handling PCXs & GIFs in Turbo C++ code.
C) Check out in these libraries a game called KEN'S LABYRINTH. It is a
decent WOLF clone written by a high school age guy. The code can't be THAT
hard if he could write it! (By the way, he has sold the game to Epic
Megagames
...........................................................................
Fm: Jaimi McEntire 71700,1202 # 315758
To: guardian 76307,1643 (X) Date: 17-Mar-93 21:58:25
I talked to the guy who wrote Kens labyrinth, and he claimed to have done it
with a 2-d type of ray tracing routine - i.e. scanning out from your point of
view for each line until you hit an object, determining its distance, and
then drawing that particular vertical line. the distance from the object that
you hit is proportional to the size of the line. you do this for each
vertical line in your window. All in all not too wierd if you just think of
it backwards.
Jaimi
...........................................................................
Fm: KGliner 70363,3672 # 315839
To: Jaimi McEntire 71700,1202 (X) Date: 18-Mar-93 02:11:10
Jaimi-- I never understood how the raytrace method could be made to work fast
enough. It just seemed like there were too many calculations to be done. I
mean, scanning out from the point of view until you hit an object must be
slow, no? Maybe if you have the images fixed at 90 degree angles like Wolf3d
and Lab3d it would be easier...
Well, if that's the approach used by Ken Silverman, he obviously got it to
run quick enough. Not that it's the only way to do 3d (I use an object based
method), but I'd still be very curious to hear more specifically how he did
it...
Kevin
...........................................................................
Fm: KGliner 70363,3672 # 315838
To: Bruce Nehlsen 76535,2466 (X) Date: 18-Mar-93 02:11:05
One thing that can help is to do all your bitmap scalings/renderings/
whatever to a buffer in ram and then just blitting the buffer when you're
through.
Kevin
...........................................................................
Fm: Jaimi McEntire 71700,1202 # 316047
To: Bruce Nehlsen 76535,2466 (X) Date: 18-Mar-93 13:43:20
You could scal to an off screen buffer and then transfer each bitplane at one
time. that would only mean 4 plane changes, and increase the speed
considerably.
Jaimi
-------------------------------------------------------------------------
this covers the thread break in WOLF3D.THD
-------------------------------------------------------------------------
__________________________ Subj: How Wolf3D Works __________________________
Fm: Epic MegaGames 70451,633 # 320015
To: KGliner 70363,3672 Date: 24-Mar-93 22:46:12
Kevin, the purpose of raycasting is to figure out, for each vertical column
of pixels, the exact location where the ray intersects with a wall tile.
Once you find this out, you draw a vertical column of pixels from the wall's
bitmap.
I guess this really isn't a very explainable technique. So, sit down with
Wolfenstein for a few hours and look at exactly how the screen appears, and
the concept will sort of burn itself into your brain. :-)
Same with the Doom screen shots. The incredible thing about Doom is the
light sourcing that's apparent in the screens. That's not a difficult thing
to do, but I can't imagine coding it to run at even one frame per second on a
486/50, cause the calculations are massive. There's a sheer genius over
there at Id Software. I can't wait to play that game!
Tim
...........................................................................
Fm: Bruce Nehlsen 76535,2466 # 319193
To: Epic MegaGames 70451,633 (X) Date: 23-Mar-93 19:01:26
Tim -
Thanks, I'm getting the concept.
Next Question: What is a workable structure for representing the levels of a
3D building interior (like in Wolf3D)? I've started using "blocks", each of
which is a position block which has links to any adjacent existing blocks.
This is OK, but now iterating through the links to see what to draw is a big,
leafy mess. I followed your note on raycasting; how would the floor be laid
out with that method of rendering?
Once again, thanks, from me and many lurkers.
...........................................................................
Fm: Epic MegaGames 70451,633 # 320017
To: Bruce Nehlsen 76535,2466 Date: 24-Mar-93 22:46:16
No, no, no, don't worry about links or anything like that. Wolfenstein 3D
is a simple 2D tile map.
Here is all the ingenuity that goes into storing a Wolfenstein level:
#define numtiles 255 #define tile_x_size 64 #define tile_y_size 64 #define
level_x_size 64 #define level_y_size 64
unsigned char WolfLevel[level_x_size][level_y_size]; unsigned char
TileBitMaps[numtiles][tile_x_size][tile_y_size];
That's all. Wolf3D, Doom, and Comanche Maximum Overkill are all entirely
TWO-DIMENSIONAL GAMES which draw the screen in such a clever way that it
looks 3D. The 3D appearance comes entirely from the routine which draws the
screen. All internal data structures are entirely 2D!
Tim
...........................................................................
Fm: KGliner 70363,3672 # 320083
To: Epic MegaGames 70451,633 (X) Date: 25-Mar-93 00:54:30
Tim-- What I was trying to get at was how many calculations have to be done
for each vertical line on the screen (ie. find the intersection with the wall
tile, find which vertical line in the bitmap for that wall to draw, deal with
any clipping, etc.). I guess it just doesn't strike me as being much faster
than an object-based approach (which is what I have used to a high degree of
success).
Btw- do you happen to know the frame rates for Wolf3d on some of the low
end machines (like 386sx16 or 386dx16)? Or how about Lab3d, since you are
distributing that now.
Light sourcing isn't that hard...all it amounts to is 1 additional asm
instruction in the inner loop of the vertical line drawing routine (and some
setup code earlier in the program). In my version that would amount to no
more than a 10% reduction in speed (although in my game it would look kinda
funny to have all the walls light sourced but the floor and ceiling still a
single solid color). I imagine it would have even less impact on any sort of
floor texture mapping because those have more instructions at their core.
Kevin
...........................................................................