- Hi all. I am porting Black and White to the Gameboy and I was just wondering, does a regular 3-D engine display intersected primitives properly? I assumed you just found the corners and then drew the bitmap inside the corners, but it *seems* like I''ve seen games that (either in various cheat modes or bugs) would draw intersected primitives properly, , -and yet I''m not seeing how it would be done. -Because if you''re drawing each primitive at a time, no two can be shown to intersect because even if they "should" that is, if you wanted them to,,, in the end one would just overlay the other. -I know I''ve seen CAD programs that could do it, but that would seem to involve finding the X-Y-Z of every pixel and that sounds like something that would run very not fast. -Unless there''s some really great way I''m unaware of. - Lubb

Black and White on the Gameboy? Bring it on! Erm... About your collision problem... you don''t often get overlaps in games, but I know that say in Quake if you make a level with two planes intersecting at right angles it works. I''m not sure how to do it, but I''m pretty sure I''ve seen it.

Just my 2 cents. I think the Z-buffer takes care of that one. The z-buffer calculates the distance from the camera to every pixel of the primitive (z - value), and compares it with the z of previous drawn pixels from other primitives.


I dont know anything about Gameboy, so I dont know weather it has Z buffer..


Edited by - Diodor on May 25, 2001 9:02:17 PM

- I am starting out trying to write a 3-D modeling tool to use and eventually convert into a simple 3-D game. The modeling tool is to run without DirectX at all. The problem I have is that I have not found a complete book anywhere that explains all the aspecs of a 3-D engine. For instance, why find the Z-distance of every pixel?
Imagining my own project, I am supposing several things:
1. The models I use will have no intersecting primitives.
2. Each on-screen object (the player, bots and shots) is an entity with a non-visible collision box defined around it. If any primitive points of any foreign object are detected within this box (in any direction), then [with some extra checking] the distance between the two is to be found, and apropriate actions taken. Otherwise, all foreign objects are too far away to collide, and there''s no reason to check in detail.
3. The world/background has to be drawn first from the rear to the front, and then all the on-screen objects are sorted farthest to nearest the player, and then drawn in that order. Using a Z-buffer frees you from this sorting, but I have trouble seeing how it''s faster to find the Z of every pixel than it is to set up an easy system for estimating the distances of what is usually a relatively small number of on-screen objects.
~
In the last couple years I''ve casually looked, I haven''t been able to find any good books on actually coding all aspects of a 3-D game. The best book I have is an out-of-date book telling and explaining how to write a 2.5-D game using WinG. It tells you how and why to code everything (whic is nice) because WinG didn''t really do that much for you (so this book had to explain everything), but some of the info is usable and some is not; for instance it uses an X-Y floor position for all collision detection with square walls laid out on a square grid: think "Castle Wolfenstein". Ugh.
-
I realize there is probably more than one way to write a typical 3-D engine, but if I use the above concept for an engine, what functions will I not be able to implement with it, besides not being able to draw intersected primitives properly? How does it differ from other common systems? Does DirectX "require" that it be done any particular way? -I can see how I could set up models that would cause this system to fail, but it would require a very odd situation to occur.
+++If there''s a good book that goes into all this, feel free to mention it. - Lubb