Re: [cadcdev-tiki] TikiBlap Demo 0.1

[Dan P. <ba...@al...>]

On Nov 27, 2005, at 11:02 AM, Sam Steele wrote:

> On closer inspection, it was the move from frame-based timing to  
> clock-based timing.  I forgot to reset the game clock after the  
> first game, so it was jumping an astronomical amount of time the  
> first time it updated the world :)

I had problems with that in Marbol too. :) I'm happy now I can just  
avoid frame-based animation in the future.. it's such a pain to move  
it over and anything other than a fixed platform is going to have  
consistency issues.

Random comments:

- The graphics are really nice looking

- Whenever you die and get a new ball, the paddle resets to the  
center. I'm not expecting this, so usually whenever I lose a ball it  
equates to two or three lost balls (I have to make myself stop moving  
the paddle to let it reset).

- If you want to avoid the huge textures issue, build up the screen  
from several drawables. I had to do this a lot in FoF (e.g. building  
up the borders from about 8 opaques instead of just one translucent).  
You can probably use full-res textures on both platforms then.

- And about Drawables in lists...:

Sorry if this is overly basic but I'm not 100% sure what all you know  
and don't know. :)

The lists in Tiki are templated wrappers for the old sys/queue  
macros. So you can set the type that is stored in each list. In the  
case of sub-drawables, the type is Drawable. The list classes assume  
that you'll be wrapping a RefCnt object, so the pointer is implicit  
(i.e. they're really storing "Drawable *"). All drawable objects are  
subclasses of Drawable, so you can store any Drawable-derived object  
into a list of Drawables. Each of those can also have sub-drawables,  
which are offset by the parent's coordinates.

If we turn on RTTI (I think it might work on the DC now, and might be  
a good thing to have overall) then you can also use dynamic_cast to  
check to make sure that a particular pointer is the class you think  
it is, if you need to do that.

The type switch on creation is pretty ugly but there's no really good  
way around that in C++ besides functors or something similar. That's  
one awesome thing about Obj-C -- all the object lifetime stuff is  
encapsulated inside code, and classes are first-class objects  
themselves. So you could make a lookup table from names to classes,  
and then [[foo alloc] init] on it without knowing what it is. :)


Also speaking of large textures... the texture handling in Tiki is  
really crappy right now. :D I wrote it up as a quick hack to get  
things moving, but it wastes a ton of VRAM and regular RAM. I think  
it keeps a copy of the original texture in regular RAM, and then it  
converts it to ARGB8888 and stuffs it into VRAM like that. That's  
probably especially bad on the DC unless you guys put in some hacks  
to deal with it. We might want to hit that up if any texture RAM  
optimizations are needed (which they assuredly will be on a PC with  
less than 32MB of VRAM, especially Macs).