A85: At the risk of losing you...


[Prev][Next][Index][Thread]

A85: At the risk of losing you...




-*-*-*-*-*-*-*-
Disclaimer:  I have most currently taken precalc/trig in high school, so just
tell me to shut up if I'm not in my league here.  The information here is most
likely to be considered "jumbled" (at best) by the reader, so read at your own
risk, and help me at (even more of) your own risk.  Once I get helped, I'm
likely to bug you. ;-D
-*-*-*-*-*-*-*-

The problems I'm having here are mostly made of ways of implementing planar
geometry in a 3d program for ti-asm.  But, out of a keen sense of
progressiveness, I'm a' gonna start with the more basic of what I NEED to
know.  Tell me if I'm wrong, PLEASE.  If you have any ideas on any ways to
optimize the data structures I'm using for polygons, TELL me(cuz a square
takes up 48 bytes o' memory in 3d for me as of right now).

Here's problem number one, data storage:
Ok, in any given object, I'm going to have a little bit of a hierarchy. As a
general rule this SEEMS to save me memory, b/c the hierarchy starts to take up
a lot of memory, but then proportionately starts conserving it.  For example:

Here's a cube in predefined memory at the end of my program:
-----------
CubeVertices:
.dw 8		;there are 8 vertices in a cube, and I REQUIRE a word b/c I want the
				;possibility of having more than 255 vertices in an object.
V1:
.db 1, 1, 1	;x, y, z (The limit of x, y, or z being no greater than 255 should
be easy 			;		to remedy, right?)
V2:
.db ...
-----------
and so on until I have the complete vertices of a cube in x, y, and z space.
The next part of defining the cube would be the edges in the form of line
segments:
-----------
CubeEdges:
E1:
.dw V1, V2	;<--adresses of two vertices that make a line
E2:
.dw ... and so on...
-----------
Finally, IF I want to implement this, I can go up one more step and make a
list of sides (I don't think I should do this b/c I can work with edges just
fine.  Tell me if I'm wrong.):
-------------
CubeSides:
.db 6	;how many sides(no WAY there're gonna be more than 255), thus the .db
.db 4	;number of edges for the first side
.dw E1, E2, E3, E4
.db 3	;number of edges on the second side
.dw E2, E1, E4
-------------
...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

God durn, I'm tired.  I'll continue this later today. :-D  The next topic will
be planar geometry in ASM, I need help with things like "view volume" for
camera angles and things of that sort.  It deals with matrix math, but using
matrices in ASM is about as foreign a concept as watching Martha Stuart give
sexual favors to Gilbert Godfreid... remember, "It's a good thing." lmao.  See
you all later. :-)

Peace-
 Dork


Follow-Ups: