cadcdev-tiki

[cadcdev-tiki] TikiBlap Demo 0.1

[Sam S. <sam...@gm...>]

Windows quirks aside, I went ahead and archived up the first public  
demo of TikiBlap (which may or may not stay named DCBlap.. I guess I  
have to decide soon).  It's a little buggy, but playable, and even in  
its incomplete state it's miles ahead of the original DCBlap in terms  
of speed and stability :)

Binaries:
Windows + Dreamcast: http://www.c99.org/dc/dcblap/zip/tikiblap- 
demo-0.1.zip
Mac: http://www.c99.org/dc/dcblap/zip/tikiblap-demo-0.1-mac.zip

Source:
http://svn.c99.org/viewcvs/DCBlap/trunk/

Screenshots:
http://www.c99.org/dc/dcblap/pics/tikiblap/1.png
http://www.c99.org/dc/dcblap/pics/tikiblap/2.png
http://www.c99.org/dc/dcblap/pics/tikiblap/3.png
http://www.c99.org/dc/dcblap/pics/tikiblap/4.png
http://www.c99.org/dc/dcblap/pics/tikiblap/5.png

Have fun :)

-Sam

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[atani <at...@at...>]

Screenshots are pretty impressive...  Are you using an animation to  
move the "ball" around the screen?  In theory you could use the LogXY  
Mover to handle that.  I am downloading the mac version and will give  
it a shot on here :)

Since the download is still progressing i dont know this yet, is  
there a readme in the zip file giving the keyboard mappings?  The  
screenshots all show what appears to be the DC graphics for key  
mappings.  Should I dig into the sources to find this otherwise?

Mike


On Nov 26, 2005, at 7:32 PM, Sam Steele wrote:

> Windows quirks aside, I went ahead and archived up the first public  
> demo of TikiBlap (which may or may not stay named DCBlap.. I guess  
> I have to decide soon).  It's a little buggy, but playable, and  
> even in its incomplete state it's miles ahead of the original  
> DCBlap in terms of speed and stability :)
>
> Binaries:
> Windows + Dreamcast: http://www.c99.org/dc/dcblap/zip/tikiblap- 
> demo-0.1.zip
> Mac: http://www.c99.org/dc/dcblap/zip/tikiblap-demo-0.1-mac.zip
>
> Source:
> http://svn.c99.org/viewcvs/DCBlap/trunk/
>
> Screenshots:
> http://www.c99.org/dc/dcblap/pics/tikiblap/1.png
> http://www.c99.org/dc/dcblap/pics/tikiblap/2.png
> http://www.c99.org/dc/dcblap/pics/tikiblap/3.png
> http://www.c99.org/dc/dcblap/pics/tikiblap/4.png
> http://www.c99.org/dc/dcblap/pics/tikiblap/5.png
>
> Have fun :)
>
> -Sam
>

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[Sam S. <sam...@gm...>]

On Nov 27, 2005, at 11:00 AM, atani wrote:

>
> Screenshots are pretty impressive...  Are you using an animation to  
> move the "ball" around the screen?  In theory you could use the  
> LogXY Mover to handle that.  I am downloading the mac version and  
> will give it a shot on here :)
>

The actual game is still handled by OpenGL and my own C-based object  
system (structs with pointers to functions, yay!).  It looks like the  
Tiki object system could be a good replacement, but I'm not familiar  
enough with C++ syntax to make it work just yet.

> Since the download is still progressing i dont know this yet, is  
> there a readme in the zip file giving the keyboard mappings?  The  
> screenshots all show what appears to be the DC graphics for key  
> mappings.  Should I dig into the sources to find this otherwise?
>

Arrow keys are the D-Pad, Enter is start, and Esc is B.  I'm going to  
do a separate set of backgrounds for the PC versions with PC keys on  
them, as well as higher resolution (512x512 looks kinda blurry on the  
PC, but 1024x1024 fills the PVR's RAM up quickly).

I posted a list of errata over on dcemulation, I'll post it here too:

All:
* After finishing a round, press ESC or B to return to the main menu,  
not Start.
* There are no Addons or Options menus.
* The list of levels doesn't scroll yet, so there's one extra level  
in the BlapOut section just floating.

Dreamcast:
* Contrary to what the menus say, you can only use Start to advance  
through the menus -- A and B aren't hooked up yet.
* No sound

Windows:
* To exit, select "quit" from the main menu, and then close the  
window. Sometimes the app wont quit by itself if you just close the  
window. You can also end its task if it keeps running in the background.

Mac:
* Occasionally the app will open and then crash instantly. Just try  
to run it again and it usually works. Not sure what's causing this yet.

-Sam

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[atani <at...@at...>]

On Nov 27, 2005, at 8:18 AM, Sam Steele wrote:
>
> The actual game is still handled by OpenGL and my own C-based  
> object system (structs with pointers to functions, yay!).  It looks  
> like the Tiki object system could be a good replacement, but I'm  
> not familiar enough with C++ syntax to make it work just yet.
>

Neat :)  Using the Tiki Objects system should be relatively simple to  
use.  Basically you would just need to override the draw() method (if  
required) and the constructor to setup the object.

>
> Arrow keys are the D-Pad, Enter is start, and Esc is B.  I'm going  
> to do a separate set of backgrounds for the PC versions with PC  
> keys on them, as well as higher resolution (512x512 looks kinda  
> blurry on the PC, but 1024x1024 fills the PVR's RAM up quickly).
>

Ok, pretty simple to use :)  Also note that ESC does map correctly.

> Mac:
> * Occasionally the app will open and then crash instantly. Just try  
> to run it again and it usually works. Not sure what's causing this  
> yet.

Add to this short list, When you run out of balls and it kicks you  
back to the menus (hitting either ESC or "Start") when you attempt to  
go into a new game the board says "out of bounds" and the "blocks" do  
not fall down into place as they normally do and you get to throw the  
ball around without hitting anything...  The only way I found to fix  
this is to restart the app again.

Mike

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[Sam S. <sam...@gm...>]

On Nov 27, 2005, at 11:29 AM, atani wrote:

> Neat :)  Using the Tiki Objects system should be relatively simple  
> to use.  Basically you would just need to override the draw()  
> method (if required) and the constructor to setup the object.
>

That part I get, I'm just a little shakey with sticking them all into  
a list together, I'll have to look at how the drawables go in a list  
even though they're different types.  I was also trying to think of  
how to avoid

if(type=="ball")
	add(new Ball);
else if(type=="paddle")
	add(new Paddle);
else...

for all the different object types in DCBlap.  Right now I have a  
linked list of "templates" that get copied over into the new object  
when it's created, which was the advantage to copying function  
pointers around.

> when you attempt to go into a new game the board says "out of bounds"

Eek!  Damn you, global variables!  TikiBlap started with an older  
copy of the DCBlap tree, and then over the weekend I found an archive  
with a much newer tree.  I merged in the "out of bounds" stuff from  
the newer tree, but forgot to reset the world dimensions when you  
start a new map.  The ball can sometimes get pushed outside of the  
world if a powerup spawns too close to the edge (like at the top of a  
breakout map), so the out of bounds message resets the board as kind  
of a do-over.

-Sam

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[Sam S. <sam...@gm...>]

On Nov 27, 2005, at 1:09 PM, Sam Steele wrote:

> Eek!  Damn you, global variables!

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 :)

-Sam

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).

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[Sam S. <sam...@gm...>]

On Nov 27, 2005, at 3:52 PM, Dan Potter wrote:

> - The graphics are really nice looking

Thanks.  The new theme only took me a few hours with Inkscape, it's a  
really nice OSS app.  The SVG images are checked into subversion if  
you're curious.

> - 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).

Yeah, that's been a glaring bug for years.  The ideal solution would  
be to mimic real Breakout / Pong and have the ball stick to the  
paddle so that you can release it when you're ready.

> - 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.

I debated using lots of drawables instead of one giant background  
texture, but I can't find any really decent TXF fonts to use for the  
help text / titles.  I suppose I could convert Bitstream Vera Sans  
into a TXF and use that.  Is the greyscale TXF stuff working in Tiki,  
and does the ttf -> txf converter output them?

>
> - And about Drawables in lists...:
>

It's something I'll have to spend a weekend on sometime.  My object  
system is very C, but it works well enough for now.  Though, it would  
be nice to have member variables with meaningful names, instead of  
generic arg1, arg2, ..., arg8 like my struct has now :)  That's  
actually a carry-over from DreamZZT, because of the way objects are  
stored in the zzt files.  In DreamZZT, I have some things like  
"#define PLAYER_AMMO arg2" in the headers, so I can reference player- 
 >PLAYER_AMMO but that's just ugly from a C++ perspective.

> Also speaking of large textures... the texture handling in Tiki is  
> really crappy right now

Actually, texture management is one of the huge reasons I moved the  
code base over to Tiki (well, that and genmenu).  My own texture  
manager doesn't properly free textures, and I gave up trying to fix  
it.  So if you change themes too many times in DCSquares, you'll  
start to see texture corruption, and if you try to play more than 3  
consecutive games in the original DCBlap you'll run out of VRAM and  
it'll crash.

However, yes it's very heavy on RAM and VRAM.  Trying to load a  
1024x1024 image at all makes KOS panic that it's out of RAM :)

-Sam

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[Sam S. <sam...@gm...>]

On Nov 27, 2005, at 4:20 PM, Sam Steele wrote:

> I suppose I could convert Bitstream Vera Sans into a TXF and use  
> that.  Is the greyscale TXF stuff working in Tiki, and does the ttf  
> -> txf converter output them?
>

Now they work, and they look great.  It looks like Jim's patch from  
http://sourceforge.net/mailarchive/message.php?msg_id=10196955 never  
made it into KOS.  Was there a reason, or did it just get lost in the  
shuffle?  I applied it to Tiki, and the difference in font quality is  
like night and day.  I'll apply it to KOS and commit it too if  
there's no objections.

-Sam

Re: [cadcdev-tiki] TikiBlap Demo 0.1

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

On Nov 27, 2005, at 2:08 PM, Sam Steele wrote:

> Now they work, and they look great.  It looks like Jim's patch from  
> http://sourceforge.net/mailarchive/message.php?msg_id=10196955  
> never made it into KOS.  Was there a reason, or did it just get  
> lost in the shuffle?  I applied it to Tiki, and the difference in  
> font quality is like night and day.  I'll apply it to KOS and  
> commit it too if there's no objections.

As I've probably mentioned many times before, there's a reason I was  
trying to get some extra maintainers on KOS. ^_^;; It's been sitting  
in my "flagged" folder in Mail for a loooong time now. Just never did  
it yet.

Thanks for doing that.

Also something that never got implemented, though this is a little  
bigger, is the CDDA reading that Thierry Vermeylen sent in. That's a  
little less pressing though...

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[atani <at...@at...>]

On Nov 27, 2005, at 12:52 PM, Dan Potter wrote:
>
> 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.

I am thinking of taking advantage of the fact that we store the  
"original" texture data as well as the VRAM version.  The way I am  
thinking of using this is for the palette based textures.  Something  
along the lines of old DOS mode 13 graphics (256 color, etc).  I have  
most of these changes in an older version of Tiki already but need to  
promote them to the latest.

> 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).

If it is wasting space on the PC it will waste space on the DC likely  
as well.

Mike

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[Sam S. <sam...@gm...>]

On 11/28/05, atani <at...@at...> wrote:

>  I am thinking of taking advantage of the fact that we store the
> "original" texture data as well as the VRAM version.  The way I am thinki=
ng
> of using this is for the palette based textures.  Something along the lin=
es
> of old DOS mode 13 graphics (256 color, etc).  I have most of these chang=
es
> in an older version of Tiki already but need to promote them to the lates=
t.
>

We can probably copy the data out of VRAM and back into the texture object
when you lock the canvas, and copy it back in / release the RAM when you
unlock it.

-Sam

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[atani <at...@at...>]

On Nov 28, 2005, at 7:35 AM, Sam Steele wrote:
>
> We can probably copy the data out of VRAM and back into the texture  
> object when you lock the canvas, and copy it back in / release the  
> RAM when you unlock it.

I am not sure the copy is needed.  Currently we have two blocks of  
memory allocated for a texture, one in the original form (as loaded  
from image file) and one in ARGB8888 form.  Both of these are in RAM  
not VRAM.  Currently in lock/unlock we use the "original" texture  
data and reconvert it to ARGB8888 on unlock.

For Palette based textures though, the original form is required to  
ensure proper color mapping.  It would be very slow to process the  
ARGB8888 data back to palette data and then diff it to "current  
palette" to get the new values.

Mike

Re: [cadcdev-tiki] TikiBlap Demo 0.1

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

On Nov 28, 2005, at 7:58 AM, atani wrote:

> I am not sure the copy is needed.  Currently we have two blocks of  
> memory allocated for a texture, one in the original form (as loaded  
> from image file) and one in ARGB8888 form.  Both of these are in  
> RAM not VRAM.  Currently in lock/unlock we use the "original"  
> texture data and reconvert it to ARGB8888 on unlock.

If that's true, I think the ARGB8888 data is totally unnecessary. A  
good first step might be to free that up as soon as it's loaded with GL.

The reason I have it set up the way it's currently set up is because  
of exactly what Mike's talking about. I had some stuff that would  
stuff a new generated texture in each frame. What might be nicer is  
to specify somewhere that the texture will be used for that sort of  
purpose, and to keep the original form around. We can then move to GL- 
only textures for about 99% of the texture data and (especially on  
the DC) shortcut all those transforms and wasted memory. On those  
textures, lock()/unlock() would just fail.

> For Palette based textures though, the original form is required to  
> ensure proper color mapping.  It would be very slow to process the  
> ARGB8888 data back to palette data and then diff it to "current  
> palette" to get the new values.

Keep in mind too that the DC has hardware paletted texture support.  
So there might be something clever to be done there too.

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[Sam S. <sam...@gm...>]

On 11/28/05, Dan Potter <ba...@al...> wrote:
>
> If that's true, I think the ARGB8888 data is totally unnecessary. A
> good first step might be to free that up as soon as it's loaded with GL.


The Dreamcast bypasses this step, since ARGB8888 isn't supported by the
PVR.  I'm converting the original image into ARGB4444 or RGB565 depending o=
n
whether transparency is requested, and not using the second buffer at all (=
I
don't think it's even allocated).

-Sam

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[atani <at...@at...>]

On Nov 28, 2005, at 10:06 AM, Dan Potter wrote:
>
> If that's true, I think the ARGB8888 data is totally unnecessary. A  
> good first step might be to free that up as soon as it's loaded  
> with GL.
>

This is the current allocations that I can spot in the code:
Texture::loadFromFile(...):
   m_ptr contains the "raw" image data
   m_txrdata contains the ARGB8888 data used in the glTexImage2D call

m_ptr can equal m_txrdata if the image file is in ARGB8888 format.   
If not, m_ptr is allocated and the "raw" image data is memcpy into  
it.  Ideally this can be avoided by moving "img" from being a method  
variable to a class member variable and then m_ptr can be destroyed  
(maybe).

Here is what I suggest :)

1) Take current Texture class and rename it to DynamicTexture and  
remove the support for loading image files.  This in effect would  
become the "palette" based Texture class.
2) Create a new ImageTexture class that supports only loading from a  
file.  Remove support for getPtr(), canvasLock(), canvasUnlock().
3) Move "common" bits to a new pure virtual Texture class so we can  
still bind a Texture to Banner, etc.  Using a pure virtual class  
would be good in this case since it can be treated as an "interface"  
of sorts rather than a normal class.  However, a normal class which  
we extend to add "extra" functionality would also work, similar to  
Object.

>
> Keep in mind too that the DC has hardware paletted texture support.  
> So there might be something clever to be done there too.

True, the DC does have paletted textures, but IIRC the texture data  
must be twiddled so we will need to keep that in mind as well.

Mike

Re: [cadcdev-tiki] TikiBlap Demo 0.1

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

On Nov 28, 2005, at 1:00 PM, atani wrote:

> This is the current allocations that I can spot in the code:
> Texture::loadFromFile(...):
>   m_ptr contains the "raw" image data
>   m_txrdata contains the ARGB8888 data used in the glTexImage2D call
>
> m_ptr can equal m_txrdata if the image file is in ARGB8888 format.   
> If not, m_ptr is allocated and the "raw" image data is memcpy into  
> it.  Ideally this can be avoided by moving "img" from being a  
> method variable to a class member variable and then m_ptr can be  
> destroyed (maybe).

Yeah, that sounds right.

> Here is what I suggest :)
>
> 1) Take current Texture class and rename it to DynamicTexture and  
> remove the support for loading image files.  This in effect would  
> become the "palette" based Texture class.
> 2) Create a new ImageTexture class that supports only loading from  
> a file.  Remove support for getPtr(), canvasLock(), canvasUnlock().
> 3) Move "common" bits to a new pure virtual Texture class so we can  
> still bind a Texture to Banner, etc.  Using a pure virtual class  
> would be good in this case since it can be treated as an  
> "interface" of sorts rather than a normal class.  However, a normal  
> class which we extend to add "extra" functionality would also work,  
> similar to Object.

That's not a bad plan. We've been discussing a lot of this design  
pattern stuff at work, re C++ commonly accepted practice. So I may  
take a shot at this soon. Maybe I'll actually have some time on it  
tonight if my wife doesn't lock her keys in the car again ;)

> True, the DC does have paletted textures, but IIRC the texture data  
> must be twiddled so we will need to keep that in mind as well.

Yeah, true. It might be nice to have some platform-specific support  
for pre-twiddled textures in there too, to avoid doing that  
processing at runtime if it's possible. Similar things could be done  
for DXT(?) encoded textures on GL platforms.

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[atani <at...@at...>]

On Nov 29, 2005, at 9:34 AM, Dan Potter wrote:
> That's not a bad plan. We've been discussing a lot of this design  
> pattern stuff at work, re C++ commonly accepted practice. So I may  
> take a shot at this soon. Maybe I'll actually have some time on it  
> tonight if my wife doesn't lock her keys in the car again ;)
>

Cool :)  In m y day job I mostly work in Java now so my C++ gets a  
bit of influence from that nowadays..

>
> Yeah, true. It might be nice to have some platform-specific support  
> for pre-twiddled textures in there too, to avoid doing that  
> processing at runtime if it's possible. Similar things could be  
> done for DXT(?) encoded textures on GL platforms.

Perhaps having an enum on Texture which we can add these as "flags"?   
That way we can have a unified "base" which returns something like  
"not implemented" for things like VQ/twiddle and then on the DC port  
we can override this with a proper implementation.

Another thing to consider could be usage of exceptions within Tiki?

Mike

Re: [cadcdev-tiki] TikiBlap Demo 0.1

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

On Nov 29, atani wrote:

> Cool :)  In m y day job I mostly work in Java now so my C++ gets a  
> bit of influence from that nowadays..

Yeah, we're doing a lot of C# these days. I did Java earlier, the two are
kind of surprisingly similar (or not very suprising when you consider why
MS built C# :)

> Perhaps having an enum on Texture which we can add these as "flags"?   
> That way we can have a unified "base" which returns something like  
> "not implemented" for things like VQ/twiddle and then on the DC port  
> we can override this with a proper implementation.

Right. Or maybe down in Image since it has flags already and source
images would probably get loaded that way most of the time. Texture
could make use of the flags in Image also.

> Another thing to consider could be usage of exceptions within Tiki?

We've also been doing more of this at work. It's funny, these guys started
working with C++ when it was first coming out, basically just a
preprocessor around C. The attitudes from that time more or less got stuck,
so we have a lot of weird and gross stuff in the code base from the dawn of
time. Then we hired a bunch of new people who've studied modern C++
standards, design patterns, etc. Their influence is starting to cause us to
use things like exceptions finally. Well, that and MS building a *working*
C++ compiler :)

I'm somewhere in between. I like the plain bare-bones C++, especially in
an embedded situation, but I'm starting to like exceptions and RTTI a lot
more after using them in Java and C#.

Exceptions would sure beat some of the dumb 'assert' statements I have
scattered around in some inappropriate places ;)

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[Sam S. <sam...@gm...>]

On Nov 27, 2005, at 3:52 PM, Dan Potter wrote:

> - And about Drawables in lists...:
>

R.I.P 2001 - 2005 entity.h, callback.h / callback.cc, collide.h /  
collide.cc, and a host of other files related to AOE, the core of  
DreamZZT and DCBlap (and the misc 3D demos that use the DCBlap  
engine).  I took the plunge and practically rewrote DCBlap using Tiki  
Drawables!

To be honest, it wasn't as difficult as I thought, though it requires  
changing your mindset around going from C-style programming to C++  
OOP (load_world() doesn't load the objects anymore, it creates an  
object and the object loads itself from the file, etc.).  Now the  
entire game world is packed neatly into a genmenu scene, using Tiki  
selectors for messaging.

> 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.
>

Right now I'm keeping my own std::list<Entity *> of Entity pointers  
so I don't lose them when they turn into Drawables in the list, but  
I'm guessing RTTI would let me enumerate genmenu's m_scene to find  
Entity-derived objects, and cast them from a Drawable pointer to an  
Entity pointer to use the Entity-specific functions?

> The type switch on creation is pretty ugly but there's no really  
> good way around that in C++
>

Yeah, I opted for the giant if/else function for now.  I figure I can  
just generate it with a shell script, like the old object-template  
creation function was.  I actually have two of them, because of what  
I assume is another C++ "feature":

create_object("Paddle") returns an Entity* which is pointing to a  
Paddle*.  If I then call ent->loadFromFile(), then  
Entity::loadFromFile() gets called, but not Paddle::loadFromFile().   
I think that's what the virtual keyword is for?  Anyway, for now I  
just have a second giant if/else called load_object() that calls  
loadFromFile before the object gets cast to an Entity*.

As for the menus, I went and recreated them as a bunch of drawables  
-- the help text is now a few labels and banners for the controller  
icons.  It looks much better, and it's easier to swap the icons out  
for PC keyboard images on the PC (though, drawing a D-Pad was a lot  
easier than drawing the arrow keys on a PC.. grr).

I've still got a long way to go with writing the new object classes,  
so nothing playable this week -- right now it's been reduced to a  
paddle that kind-of responds to the keyboard, and a ball that makes  
drawables turn red with setTint when it collides with them.

-Sam

Re: [cadcdev-tiki] TikiBlap Demo 0.1

[Sam S. <sam...@gm...>]

One more C++ thing I noticed:

I have a class called Light that's derived from Entity, in the  
default constructor I have:

Light::Light() {
   m_light=create_light();
}

Now, in the constructor that takes a Tiki::File, I didn't want to  
duplicate the above line, so I tried:

Light::Light(Tiki::File f) {
   Light();
   loadFromFile(f);
}

Now, m_light gets assigned a pointer in a linked list of where lights  
are located (to make finding them as fast as possible for vertex  
lighting).  Anyway, it gets a value inside of Light();, but as soon  
as it returns from that call, it goes back to being NULL again before  
loadFromFile gets called.  Is there another way I'm supposed to call  
the default constructor from another constructor?

-Sam

Re: [cadcdev-tiki] TikiBlap Demo 0.1

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

On Dec 4, 2005, at 8:21 AM, Sam Steele wrote:

> Right now I'm keeping my own std::list<Entity *> of Entity pointers  
> so I don't lose them when they turn into Drawables in the list, but  
> I'm guessing RTTI would let me enumerate genmenu's m_scene to find  
> Entity-derived objects, and cast them from a Drawable pointer to an  
> Entity pointer to use the Entity-specific functions?

Yes. You can take any pointer and try to upcast it to any other  
pointer, and if it's possible it'll give you the new pointer;  
otherwise it'll return NULL. If you do the same with an object or a  
reference, it'll throw an exception if it fails.

One thing to be clear about, dynamic_cast is most useful for  
upcasting or cross-casting (which I think is what you want to do  
here). For example:

A -> B -> C
X -> Y /

What my bad ASCII art there is saying is that B derives from A, Y  
derives from X, and C derives from B and Y. In this case, you ought  
to be able to cast a C to any of those things without any RTTI  
voodoo. You can also take an A* which is actually a C, and up-cast it  
to a C; RTTI lets you do this safely, if you don't know the A is a C  
already. Similarly if you have an X* which is actually a C, you can  
use RTTI to upcast to C, and I think you might be able to cross-cast  
to A or B (maybe with an intermediate C* cast), but again that's not  
too safe without using RTTI to check.

> create_object("Paddle") returns an Entity* which is pointing to a  
> Paddle*.  If I then call ent->loadFromFile(), then  
> Entity::loadFromFile() gets called, but not Paddle::loadFromFile 
> ().  I think that's what the virtual keyword is for?  Anyway, for  
> now I just have a second giant if/else called load_object() that  
> calls loadFromFile before the object gets cast to an Entity*.

If I'm understanding correctly, it sounds like one way or another the  
compiler isn't seeing the virtual applying to what you're applying it  
to. That's the behavior you'd get if you had some method in both  
classes without 'virtual'. Another way this can happen is if you try  
to use it from the constructor. Calling virtuals from the constructor  
is a bad idea (ditto with the destructor). If you think about it for  
a minute you can see why. :) They made the language patch up the  
vtable at each step of construction/destruction to make this not as  
bad as it could be, but IMO they should've just made it illegal...

Also the base class must be called explicitly from the derived  
method. This lets you wholly override functionality from a base class  
and also have better control over when the base class method gets  
called (before or after, etc). Unfortunately there's no smart way in C 
++ to address the base class. So somewhere in your  
Paddle::loadFromFile() you need to have something like  
"Entity::loadFromFile()".

> Now, m_light gets assigned a pointer in a linked list of where  
> lights are located (to make finding them as fast as possible for  
> vertex lighting).  Anyway, it gets a value inside of Light();, but  
> as soon as it returns from that call, it goes back to being NULL  
> again before loadFromFile gets called.  Is there another way I'm  
> supposed to call the default constructor from another constructor?

AFAIK you can't call another constructor on the same object directly  
(someone correct me here if I'm wrong, because I'm a little fuzzy on  
this point). The standard idiom is this:

class Foo {
public:
	Foo();
	Foo(int a);
	Foo(int a, int b);

private:
	void init(int a, int b);
};

Foo::Foo() {
	init(defa, defb);
}

Foo::Foo(int a) {
	init(a, defb);
}

Foo::Foo(int a, int b) {
	init(a, b);
}

void Foo::init(int a, int b) {
	// Real constructor guts
}