cadcdev-tiki — Discussion about the Tiki cross-platform toolkit

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] SVN movage

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

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

> Huh... I actually didn't move anything. It's all sitting on the  
> same place on my server, same auth setup and all. I just added an  
> alias to svn.allusion.net and configured the web server to answer  
> to it. I was able to sync but I haven't tried checking anything in.  
> I'll do that in a bit.
>

D'oh, I was just mistyping my password.  Works now.  I committed Jim  
Ursetto's ARGB4444 font patch for parallax to Tiki, and now fonts  
converted with ttf2txf don't look like ass :)

-Sam

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] Mouse Events on OSX

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

Ok, I'm FINALLY gonna get around to answering this :D

(I'm so bad about email...)

On Nov 20, 2005, at 11:13 PM, Atani wrote:

>> Speaking of Object event handling, I never really discussed why that
>> was in there. :D It might be interesting...
>
> I have been meaning to ask you what you were thinking of doing with  
> that
> stuff :)
>
> I am thinking it would be a good way to implement the Object
> notifications perhaps?

What exactly did you mean by Object notifications? I think that  
already exists unless I'm misunderstanding.

> I am quickly getting to the point where the current animations/etc are
> not quite enough for Chain Reaction.  I need a similar style of event
> handling.  If I come up with anything that is reasonably decent I will
> promote it from CR into Tiki so others can use it as well.  Something
> that might be useful is completing the Timeline classes which are in
> Tiki now, these could (based on docs) support the style of events that
> CR and Marbol needs.

Yeah, this ought to work already too. I'm actually using them in the  
latest version of Marbol (I think the public 1.0 release didn't have  
it, but my SVN version does). I can try to boil down some examples  
from the code, but it's a pretty nasty mix of old and new styles (and  
I more or less quit working on it after that).

> Actually that would be a good idea to have somehow... I am not sure  
> how
> we would go about doing game logic, unless you include lua into the  
> mix.
>  lua is not out of the question for a "game framework" which makes use
> of an "uncompiled" definition file.  I can certainly see this as a
> good way to export the visible bits out of the code though.  It would
> take a bit of work perhaps to integrate the callbacks, but that should
> be doable too, most everything, including animations and "side shows"
> can be done via the XML (using Slideshow and similar background  
> effects).
>
> This could be a way to describe a lightbar menu:
...
> Basically this could define a scene with a static background image
> (data/bg.png), a slideshow with 5 slides in it, and a simple lightbar
> menu with three options in it all having a unique id assigned in the
> XML.  The id attribute values could be used as the "return value" from
> the scene.  Of course this is only an example and does not contain
> enough attributes to be very useful.

Yeah, that's just the sort of thing I had in mind. It would save a  
crapload of time that's currently spent doing things like loading up  
textures, creating Drawables, setting animations and triggers, etc. I  
could have, e.g., written all of the setup code for Reverie as a big  
XML file if we'd had a way to go from a string in the XML to a class  
to instantiate (and that was a lot :). Might be another interesting  
thing to look into, re Sam's message about Drawable creation.

And especially with the string-based Object event slots, we could  
probably do a system where as long as you write any custom code you  
need in C++ and wrap it up with something where it can be created via  
a string lookup, you probably wouldn't need any sort of scripting  
language.

Like I mentioned there, functors would probably be a good thing to do  
that with. If you guys don't know about 'em, they're basically  
objects that have an operator(), so you can call them as a function.  
e.g.:

class Foo {
public:
	void operator() { printf("Hello!\n"); }
};

void bar() {
	Foo foo;
	foo();
}

Will result in "Hello!" being printed out. There's some neat stuff in  
the boost library for doing partially bound functions and lambda-type  
functions using that stuff. We could import some of that if you guys  
are interested, since it's about 90% template headers and not  
dependent on the rest of boost anyway.

Re: [cadcdev-tiki] SVN movage

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

Atani wrote:

> What hosting company are you switching to?  I am thinking of moving  
> my site over to 1&1 and still open for other options that are decent..

It's Dreamhost. I've heard both good and bad things about them, but  
they're tough to beat price-wise and it has gone pretty smoothly so  
far. From what I've read they basically seem to have some turkey tech  
support people, and some really good ones, but what else is new... :)  
But overall they seem pretty geeky, which is a good thing in my book  
(e.g. unofficial SVN support).


On Nov 27, 2005, at 10:14 AM, Sam Steele wrote:

> After the svn switch, I can't authenticate anymore.  Did you copy  
> our credentials over?

Huh... I actually didn't move anything. It's all sitting on the same  
place on my server, same auth setup and all. I just added an alias to  
svn.allusion.net and configured the web server to answer to it. I was  
able to sync but I haven't tried checking anything in. I'll do that  
in a bit.

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 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] SVN movage

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

On Nov 27, 2005, at 12:04 AM, Dan Potter wrote:

> Ok everyone who uses SVN, listen up! :)
>

*listens*

> The new repo URL is:
>
> http://svn.allusion.net/svn/kos/
>

After the svn switch, I can't authenticate anymore.  Did you copy our  
credentials over?

-Sam

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] SVN movage

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

What hosting company are you switching to?  I am thinking of moving  
my site over to 1&1 and still open for other options that are decent..

Mike


On Nov 26, 2005, at 9:04 PM, Dan Potter wrote:

> Ok everyone who uses SVN, listen up! :)
>
> I'm moving my hosting over to a new web provider right now. They  
> seem to have some unofficial SVN support but I haven't investigated  
> it yet, so I'm keeping that on my own servers for now. But you'll  
> need to change the hostname your repo points to before your DNS  
> cache expires if you want to keep using it.
>
> The new repo URL is:
>
> http://svn.allusion.net/svn/kos/
>
> The simplest way to fix this is to go to your repo's root and do this:
>
> svn switch --relocate http://www.allusion.net/svn/kos/ http:// 
> svn.allusion.net/svn/kos/
>
> That ought to switch it all over with no loss of data.
>
> Yell back if you have any troubles, and please pass on the word to  
> anyone who'd need it.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> cadcdev-tiki mailing list
> cad...@li...
> https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki
>
>

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

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
>

[cadcdev-tiki] SVN movage

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

Ok everyone who uses SVN, listen up! :)

I'm moving my hosting over to a new web provider right now. They seem  
to have some unofficial SVN support but I haven't investigated it  
yet, so I'm keeping that on my own servers for now. But you'll need  
to change the hostname your repo points to before your DNS cache  
expires if you want to keep using it.

The new repo URL is:

http://svn.allusion.net/svn/kos/

The simplest way to fix this is to go to your repo's root and do this:

svn switch --relocate http://www.allusion.net/svn/kos/ http:// 
svn.allusion.net/svn/kos/

That ought to switch it all over with no loss of data.

Yell back if you have any troubles, and please pass on the word to  
anyone who'd need it.

[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] Sound

[Atani <at...@at...>]

On 11/26/2005, "Sam Steele" <sam...@gm...> wrote:
>I noticed another quirk on win32:
>
>If I close the window, my app doesn't quit, and if I quit my app, the
>window doesn't close.  Any ideas?

That sounds like the message loop is not properly exiting when the
WM_QUIT message is received.  Also make sure that all events are
properly dispatched.  I have not done much raw win32 programming in a
bit so i am a bit rusty on it...

As for sound on other platforms...  On linux using SDL I have yet to get
any output from OpenAL using either SDL output handler or the
"default" handler.  I did finally get it working on OSX finally but it
does not seem to work on any other platforms so far :(

Its entirely possible that there is some code missing from the sdl/dc
directories for sound.  The DC version though is more or less just a
thin wrapper on top of the standard KOS sound functions.

Mike

Re: [cadcdev-tiki] Linux on the Desktop

[Atani <at...@at...>]

On 11/26/2005, "Sam Steele" <sam...@gm...> wrote:
>Kind of curious if anyone here has any preferences about distributing
>software for Linux.  For DCSquares, offering a source tarball wasn't
>an option, because of the high score code, so I distribute it using
>the Loki installer.  Does anyone have any major likes or dislikes of
>loki_setup?

I have not used the Loki tools myself but they should be fine to use.=20
Another alternative to sending a full source tarball is to provide an
libfoo.a type file for the bits you do not want to distribute the code
for, just be sure to use non-debug compilation flags and strip any debug
flags from the archive.

>
>With TikiBlap, it will be possible to offer a source tarball that
>people can configure / make / make install, but should I also offer a
>loki_setup archive?  Generating deb or tgz packages for the millions
>of flavors of linux is out of the question -- the most I can generate
>here are Ubuntu and Slackware.

Make sure you create an RPM file and make it "generic" to the platforms
if you can.  This will allow you to cover most, if not all, available
linux distributions.

Mike

Re: [cadcdev-tiki] Sound

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

I noticed another quirk on win32:

If I close the window, my app doesn't quit, and if I quit my app, the  
window doesn't close.  Any ideas?

-Sam

Re: [cadcdev-tiki] Sound

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

On Nov 26, 2005, at 7:41 PM, Dan Potter wrote:

> Yeah, this is due to a bone-headed decision they made in the Win32  
> API (one of many :) that top-level window sizes would include the  
> decorations.

AdjustWindowRect() does the trick, I'll commit this shortly.

-Sam

Re: [cadcdev-tiki] Sound

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

On Nov 26, 2005, at 2:39 PM, Sam Steele wrote:

> Ah, I forgot to include wrap_oal.dll.  Speaking of Win32, it looks  
> like the window size isn't right -- there's a small bit of empty  
> space around the top / right of my genmenu.  I'll look into this  
> more later -- Windows and I aren't speaking right now, I need a  
> break from its buggy drivers causing reboots :P

Yeah, this is due to a bone-headed decision they made in the Win32  
API (one of many :) that top-level window sizes would include the  
decorations. And of course the size of the decorations differs per OS  
and sometimes per theme. So I think we have to go in and query for  
all that crud and add it in somewhere.

Re: [cadcdev-tiki] Sound

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

On Nov 26, 2005, at 5:19 PM, Dan Potter wrote:

> Looks like (looking in the zip) it was OpenAL32.dll and wrap_oal.dll.
>

Ah, I forgot to include wrap_oal.dll.  Speaking of Win32, it looks  
like the window size isn't right -- there's a small bit of empty  
space around the top / right of my genmenu.  I'll look into this more  
later -- Windows and I aren't speaking right now, I need a break from  
its buggy drivers causing reboots :P

-Sam

Re: [cadcdev-tiki] Sound

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

On Nov 26, 2005, at 2:05 PM, Sam Steele wrote:

> Does anyone have sound working on anything besides OS X?  I've  
> compiled win32 and Dreamcast versions of TikiBlap and I can't get  
> any sound from any of them.
>
> On Windows, the sounds load up fine, and oggvorbis shows me the  
> title / author of the ogg file, but there's no sound.  I'm using  
> the Creative SDK.

I made a Win32 version of Marbol with no issues (Marbol was why I  
worked with Brian on the port to begin with). I noticed that you had  
to have two OpenAL DLLs with the EXE to make it work but once I got  
that far I didn't try very hard to go farther. It seemed to work on  
everyone's machines we tried it on. I was also using the Creative SDK.

Looks like (looking in the zip) it was OpenAL32.dll and wrap_oal.dll.

[cadcdev-tiki] Linux on the Desktop

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

Kind of curious if anyone here has any preferences about distributing  
software for Linux.  For DCSquares, offering a source tarball wasn't  
an option, because of the high score code, so I distribute it using  
the Loki installer.  Does anyone have any major likes or dislikes of  
loki_setup?

With TikiBlap, it will be possible to offer a source tarball that  
people can configure / make / make install, but should I also offer a  
loki_setup archive?  Generating deb or tgz packages for the millions  
of flavors of linux is out of the question -- the most I can generate  
here are Ubuntu and Slackware.

-Sam

[cadcdev-tiki] Sound

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

Does anyone have sound working on anything besides OS X?  I've  
compiled win32 and Dreamcast versions of TikiBlap and I can't get any  
sound from any of them.

On Windows, the sounds load up fine, and oggvorbis shows me the  
title / author of the ogg file, but there's no sound.  I'm using the  
Creative SDK.

On the DC, loading wav files crashes (I already knew about this and  
will look into it), but I'm also having the same problem as Windows  
with sndoggvorbis -- the files load, but nothing is played.

For Linux, I can't get OpenAL to compile.  What version of OpenAL are  
you using?  I'm using Ubuntu, and it complains that the autoconf  
files are out of date -- is there an archive with configure already  
generated?

Sound issues aside, TikiBlap is progressing pretty well, and I hope  
to have a public demo available soon.

-Sam

Re: [cadcdev-tiki] Mouse Events on OSX

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

On Nov 22, 2005, at 3:04 PM, Atani wrote:

> Perhaps we should consider having a common "main" package?

I'm cool with that as long as it's not mandatory somehow. Also BTW  
since I last worked on the OSX stuff in Tiki I've figured out how to  
properly open a window without hijacking an IB one. I need to try it  
again.. last time I tried it was having issues with not having a  
shadow. That'd be better than having to make a new window, plop a  
custom view in it, subclass crud, etc, etc..