- --- - -----------------------------------------------------------------------
Some hints for 3D coding
--------------------------------------------------------------------- - --- ---
This shouldn't be a complex tutorial or anything, simply I've got an idea to
write some of my experiences I got in my beginnings. In other words, the
lamers' area starts here =)
Structures
==========
Believe or not, but the amount of time you'll spend with improving your 3D
engine directly depends on structuring your data. A typical example is a cube;
you wont write 4 points for every face (24 points) but only 8 points and your
basic structure will look:
face1: dc.l p1,p2,p3,p4
face2: dc.l p2,p5,p6,p3 ... etc This lead us to
Pointers
========
I've seen a lot of C sources where structures are used, but only as parameters
by calling a poly routine for example and then using "direct" values. Sorting
by y-coordinates was done by simple 3-compares swapping. This is no problem for
flat-shaded poly for example, but if you're coding a texture mapper, your face
looks like:
face1: dc.l p1,p2,p3,p4,t_p1,t_p2,t_p3,t_p4
Yeah ppl, I've even seen source which swaps x, y, tx, ty values for every point
! Best solution is to load only y-values into registers and swap pointers to
texture coordinates. As I wrote: better structure = less complications in
future (no one says this is that structure :-))
Clipping
========
You know that - you have working rotation of 3D object, but you aren't free to
set any parameters you want, you have to be careful about the size of projected
picture becoz of videoram limits. But hey, we aren't owners of stupid PC
machines! Imagine the meaning of "clipping": you have some big scene and small
window (our screen) you are looking through. Clipping algorithms do in most
cases two things:
1) if a whole polygon is in/out of screen - skip it
2) if some part of a polygon is on boundary, clip it
And this clipping is done using brutal methods (if you ever tried to code
simple line clipper, you know what I'm talking about)
Please note that word "window" in my explanation: it's similar to the human eye
- if you see something, you see it. If not, you don't see it (logical :-)) And
why we can't do it on our Falcon, too? Hey, we can do it ! Simply if a whole
polygon is out of screen, you don't draw it. And if it lies on a boundary, we
leave it as it is ! More concretely - if you reserve some space "around" the
screen ram area, you can drop any clipping and start to show this cool
advantage to PC coders :)) Top and bottom areas aren't problem. In horizontal
direction you need to increase number of words per line (using $ffff820e
register) and here you are - clipped picture without any clipping :)
Sorting
=======
Another big mystery in 3D coding. We are in need of sorting faces if you rotate
inconvex objects, here face killing by dot product isn't enough. Most simple is
the bubble sort. It's nice, small and slow. Then comes sort-algorithms like
insert, merge or quicksort. I can code none of these algorithms :))) Some
months ago I found very nice sort-algorithm called Radix sort. It's based on
the idea numbers aren't sorted but they are used as indexes. Ofcourse your
number should be positive and <256 (in the simplest case). So you have to
allocate 256*n words in memory, where n is number of entries. Here you are,
some C lame code:
int radix (int *array, int entries) {
int *low_radix_stack[256];
int hash_entry [256];
int i, j, k;
/* init part */
for (i=0; i<256; i++) {
hash_entry [i] = 0;
low_radix_stack[i] = (int *)malloc (entries*sizeof(int));
if (low_radix_stack[i] == NULL) {
printf ("\nNo memory");
return (1);
}
}
/* "sorting" */
for (i=0; i result can be max $7fff ! It's very hard to discover
since CPU continues to the next instruction without any problem (numbers aren't
divided), only V flag is set.. be careful !
segments
~~~~~~~~
be very careful if you're using source includes (famous include 'code.s')
file1.s:
text
nop
data
dc.l -1
include 'file2.s'
file2.s:
lea label,a0 ;a0 = label
nop
moveq #0,d0
lea (label,pc,d0.w),a1 ;a0 != a1 ???
nop
bss
label ds.l 1
This bug made me crazy :-) What's wrong? I forgot to write 'section text' in
the begin of the file2.s So, the file is included into data segment and all PC
relative modes work strange ! Devpac ignores this in case of data segment, it
only writes an error with the bss.
memory
~~~~~~
Devpac is a very strange program :-) Its strange and not-so-system GUI doesn't
care about memory limits. In better case, you type one more line to your source
code and during assembling you will see TENS of errors without any reason... in
the worst case scenario, you wont see any errors and your binary file will be
corrupted (tos error #35) And my favourite: no errors, no tos error, but your
data will be corrupted ! Double-click on foo.prg, code is running..... bang !
strange gfx data or even worse, bombs, system halted etc... I really love this
tool :-)
OK, this is about all I can remember... I know, not such cool article as you
expected (???), but I promised Grey this one, so here you are :)
-------------------------------------------------------------------------------
MiKRO XE/XL/MegaSTE/Falcon/CT60 mikro.atari.org
-------------------------------------------------------------------------------
|