Re: A85: At the risk of losing you...
[Prev][Next][Index][Thread]
Re: A85: At the risk of losing you...
If I were doing the 3d, first I'd assign points, then assign numbers
representing either pixel, line, plane, etc. For example, if you wanted
a wire-frame cube, this would contain 8 points with 12 lines.
The points are encoded in x,y,z format (each only 1 byte since 256 is a
well enough number, but you would use 65536 if you want). First you
would have .db 8 for the number of points, then following that have
x,y,z. Let me just show you I guess, it's much easier that way.
Let's say we had a wireframe cube with vertices in 3d space at (0,0,0),
(0,0,10), (0,10,0), (0,10,10), (10,0,0), (10,0,10), (10,10,0),
(10,10,10). As you can see we have 8 points, so we'd store the first
part of the cube like so:
.db 8,0,0,0,0,0,10,0,10,0,0,10,10,10,0,0,10,0,10,10,10,0,10,10,10
#,p0---,p1----,p2----,p3-----,p4----,p5-----,p6-----,p7------
For the second part we wouldn't just put any order of the lines, you
would work around the origin point in a clockwise fashion. This is so
that when you have a solid block the back of it is drawn first and then
the front (to erase the back, so you can't see it--used for reality).
So, let's begin. p0-p2, p0-p1, p2-p3, p1-p3, p1-p5, p3-p7, p5-p7,
p5-p4, p7-p6, p4-p6, p4-p0, p6-p2. 12 lines with a 2 number pare
(spelling?). So the second part would be:
.db 1,12,0,2,0,1,2,3,1,3,1,5,3,7,5,7,5,4,7,6,4,6,4,0,6,2
s,# ,l0-,l1-,l2-,l3-,l4-,l5-,l6-,l7-,l8-,l9-,l10,l11
s=1 for wireframe, You can take this out if it's always going to be
wireframe, but I'm just showing you how I'd do it...I'd use 2 for
blocked (1 solid color), 3 for shaded block, 4 for image (image
following code), and 5-255 for upgrades (other things that I didn't
mention).
If you want you can compress it by stating the maximum number you are
going to use (10) for the cube, and then follow it with a compressed
string. Since 16 is the only number that will support 10 in binary (for
compression), you would have to use 4 bits at a time for each number
(and use 0 as a buffer at the end if necessary):
used to be:
.db 8,0,0,0,0,0,10,0,10,0,0,10,10,10,0,0,10,0,10,10,10,0,10,10,10
now:
.db 8,10,0,0,10,10,0,170,160,10,10,170,10,170
compression of ~56%
the 10 means that's the maximum, and use 4 bits to decode
If you knew that you were using only 8 points (0-7) then you could
actually compress the second part using only 3 bits for each part. You
would come out to the following:
used to be:
.db 1,12,0,2,0,1,2,3,1,3,1,5,3,7,5,7,5,4,7,6,4,6,4,0,6,2
now:
.db 1,12,8,20,203,26,251,236,250,104,50
compression of ~42%
the files need to be separated and contain a header to know if it's a
compressed file or a raw file, so don't get that mixed up. I'm not
programming here, so don't get on my case like "db doesn't work" or
something because that's all I've used, here's the final copy:
.db 8, 0, 0, 0, 0, 0, 10, 0, 10, 0, 0, 10, 10, 10, 0, 0, 10, 0, 10, 10,
10, 0, 10, 10, 10, 1, 12, 0, 2, 0, 1, 2, 3, 1, 3, 1, 5, 3, 7, 5, 7, 5,
4, 7, 6, 4, 6, 4, 0, 6, 2
for the raw (total of 51 bytes) or
.db 8, 10, 0, 0, 10, 10, 0, 170, 160, 10, 10, 170, 10, 170, 1, 12, 8,
20, 203, 26, 251, 236, 250, 104, 50
for the compressed (total of 25 bytes)
compression of total is about 50%
-Rob
ICQ:9188921 "No Sol to kill"
e-mail1:rc_ware@hotmail.com
e-mail2:rc_ware@yahoo.com
e-mail3:rc_ware@geocities.com
webpage:http://www.geocities.com/SiliconValley/Haven/4049/index.html
{{is there some reason why you can't keep the vertices stored in their
original location? i would think that you could make a routine the
takes the address of the number of vertices followed by a list of
vertices (say in hl) and does the vector math (rotation, translation,
etc) to those points. then, for drawing the faces, i guess you would
need to convert the x,y,z coordinates into x,y coordinates that can
then be drawn with a line routine or polygon routine. you could use a
static area of memory for x1,y1 and x2,y2 if you are using a line
routine to draw each line individually. but if you are going to use a
polygon drawing routine, you would need to have enough space for that
polygon in memory.
-mike pearce
<snip>
>-------------
>...and so on. But the problem to be encountered here is how I
manipulate the
>data accompanying the object's hierarchy. All I would ever NEED to
manipulate
>would be the .db's containing the x, y, and z coords of the object.
How do I
>go about doing this?? Do I reserve memory before the end of the VAT?
Or
>should I reserve memory at the end of my program with .db's equal to
the
>number of bytes per object I need? Am I understood? Or not? :-D
>
<snip>}}
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Follow-Ups: