[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 3D objects
On Wed, 10 Jun 1998 Thomas.Much@stud.uni-karlsruhe.de wrote:
> >Many of MagiC's 3D-objects are smaller than the ones
> >in all other AESes
>
> MagiC's 3D objects are of excactly the same size as they are under
> old TOS versions without any 3D fx.
The outside border is, the usable area isn't.
> Now, read my first posting again and then read the definition of
> objc_sysvar() - and guess, what subroutine #6 is for... *If* you
> really want everyone to write "clean" software that works on
> all systems, then please use all the functions that have already
> been defined. And objc_sysvar() has been defined in *MultiTOS*
> long ago.
If you really want to consider the 3D-borders, then you must expect that
they can be any size. This means that all trees must be scanned for 3D
objects, and check that they don't overlap. If they do, they must be
relocated.
This might sound nice at first, but when you start to look into what's
needed you'll see that it's impossible (almost) to do properly with the
object-trees we have today. What if you have a box with tree buttons and
tree texts, like this...
+-----------------------+
|Text1 Text2 Text3 |
|Button1 Button2 Button2|
+-----------------------+
You discover that the buttons overlap each other and the texts, and starts
moving them:
+---------------------+
|Text1 Text2 Text3|
| |
+Button1 Button2 Button3
Oops... OK, so you resize the frame, but that will probably introduce
similar problems with it's siblings. You'll probably end up by modifying
the entire tree. But making room for these objects isn't a problem, the
real problem is that any object is only placed relative to it's parent,
and not it's siblings. This means that it's impossible to align objects
relative to it's siblings. So while you can move and resize objects,
you'll loose alignment.
+-------------------------+
|Text1 Text2 Text3 |
| |
|Button1 Button2 Button3|
+-------------------------+
It can ofcourse be done with some clever programming, but it's not
something that's defined in the OBJECT-structure. And some RSC might even
have intentionally overlapping objects, what about them?
As I said in a previous mail, the only cure for this problem is to design
the RSC properly in the first place, which unfortunelately quite a few
programmers (MagiC-users) doesn't (probably not because they're mean,
they're just not aware of the problem).
/*
** Jo Even Skarstein http://www.stud.ntnu.no/~josk/
**
** beer - maria mckee - atari falcon - babylon 5
*/
- References:
- 3D objects
- From: Thomas.Much@stud.uni-karlsruhe.de