Well first off, I'm not a mathemetician, and I haven't
been doing 2600 development very long, but I have done
some 3D stuff in DOS in the past...
To start with, I'm pretty sure any kind of 'real' 3-d
graphics, in the sense that they would involve
rotation in the 3-d space, would be impossible on the
2600. Each rotation on an axis, as you may be aware,
requires using trigonometry to calculate where points
in the 'static' object space go in the 'camera' object
space. That, of course, would require not only
floating point math, but also multiplication,
division, and of course, trigonometric functions...all
things which could in theory be implemented in
software, but would probably take far too long as far
as execution time goes.
What might actually be possible is a program which
does 3-d graphics, but without any kind of rotation at
all. If an enemy's position could is given in x,y,z
coordinates, and you just wanted to use a 90 degree
field of forward view, then the horizontal position
on-screen would just be calculated like this:
Multiply x by half of the horizontal resolution,
divide the result by Z...and then add half your
horizontal resolution to that result so that something
at 0,0 in the coordinate space would appear in the
very middle of the screen. Vertical would be done
similarly. Figuring out which enemies are in sight
just depends on looking at x / z and y / z to
determine if either one is less than one (within
sight) or greater than one (not in sight). Obviously
nothing with Z <= 0 will ever be in sight, too.
Even this would be hard, though. For one, it involves
multiplication and division of non-power-of-2 numbers,
and values that won't fit in 8 bits...and that's just
the beginning...
Ben
(BTW...if 'Ronald Gershwin' shows up as the name on
this post, that's just my yahoo alias, since I don't
like giving out my real name. :) )
--- cybergoth@xxxxxxxx wrote:
> Hi there!
>
> I think some of you might remember that I first
> started doing a game called "Star Fire", when
> joining
> the list. After some tries I stopped it and
> thought doing something *simpler* first, which
> resulted in Gunfight.
>
> With that almost done, I started thinking
> again about doing Star Fire now.
>
> I already told you about my 2D pseudo approach, but
> now I'd just like to know how *real* 3D would work.
>
> So this are more some philosophical "Can it be done"
> thoughts. I tell you how far I am with my thoughts,
> and maybe the mathematicians here can add things or
> correct me where I'm wrong :-)
>
> Ok. First I thought I'd have a 'space cube' with
> 256*256*256 possible coordinates.
>
> Now, when any object in the cube would go farther
> than 255 it'd reappear at position 0, thus
> having all objects *trapped* within
> this cubeshaped *void*
>
> This'd make three byte per object.
>
> Now, I'd need more information about all these
> objects (I call them atoms from now on)
>
> Any atom would've a direction vector and a speed.
> I tought I'd do it simple again.
>
> I have Two bytes for all this information.
> It is encoded like this
>
> First Byte:
>
> 1. Bit + or - movement on the X-Axxis
> 2-3. Bit speed 0 - 3 on the X-Axxis
> 4. Bit + or - movement on the Y-Axxis
> 5-6. Bit speed 0 - 3 on the Y-Axxis
>
> Second Byte
>
> 1. Bit + or - movement on the Z-Axxis
> 2-3. Bit speed 0 - 3 on the Z-Axxis
> (4-6. Bit encodes the # & position of atom copies,
> we might need that later :-))
>
>
> This leaves 4 Bits unused at the moment,
> Maybe they'd be of use for something...
>
> So in summ I'd have 5 Byte per atom in my
> space cube.
>
> (I'd need another 5 Byte for each enemy shot,
> if I'd track it with this sytem for example)
>
> Now, from here on I'd need help:
> (Here's your homework for the weekend: :-))
>
> (All these questions are related to 8-Bit processing
> with our 6507, I'm _not_ asking how this'd be done
> _normally_ :-))
>
> Would I put the (0/0/0) Spot in the absolute center
> (i.e. the coordinates would range from -127 to +128)
> or in one of the corners (As said above with linear
> coordinates from 0 - 255)?
>
> Would I put my own ship at (0/0/0) or would it float
> around as an atom as well?
>
> Can anybody give me some math theory in what'd be
> the
> easiest way to calculate which enemies are in sight
> and how far they are (based on the above
> descissions)
> (I'd need three extra bytes here, for the
> screen x-y coordinates and the size as well I
> assume?
> That'd make 8 bytes per enemie in eye-sight and 5
> for any
> enemie behind me, right? Phew...)
>
> Ok, that's it for a start. I didn't say that I'm
> gonna
> do it in real 3D, I'd just like to learn how it
> would be
> done. So all of this is a theoretically brain-thing,
> just in case :-)
>
> Feel free to post any thoughts, math, 6507 code
> whatever
> that might give any deeper insisight *how* this
> stuff
> would work. Ultra-Quick algrithms, tricks,
> shortcuts,
> ideas to make anything simpler... just contribute
> and/or tell me what you think about this 'problem'.
>
> To encourage you more I state here:
>
> "It can't be done!"
>
> (In comp.sys.cbm that works always :-))
>
> Greetings,
> have a nice weekend,
> Manuel
>
>
>
>
-----------------------------------------------------------------------
> Knaller, Schnäppchen & Specials finden Sie beim
> Nexgo-Shopping!
> http://www.nexgo.de/c/pub/redir.php/shop1
>
-----------------------------------------------------------------------
>
>
> -
> Archives (includes files) at
> http://www.biglist.com/lists/stella/archives/
> Unsub & more at http://www.biglist.com/lists/stella/
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
