Menu
▾
▴
cadcdev-tiki — Discussion about the Tiki cross-platform toolkit
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(131) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(4) |
Feb
(16) |
Mar
|
Apr
(15) |
May
(18) |
Jun
(25) |
Jul
(13) |
Aug
|
Sep
(3) |
Oct
|
Nov
(7) |
Dec
|
| 2007 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(11) |
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Atani <at...@at...> - 2005-11-22 23:08:38
|
On 11/21/2005, "Dan Potter" <ba...@al...> wrote: > >That'd be great. Also feel free to loot the parallax/tsunami samples in >the KOS examples tree; they're pretty easy to convert. I started on porting over the banner sample, its almost working but is having some issues. I should have it ready to check in this evening and perhaps another test tomorrow in between prepping food for thurs. Mike |
|
From: Atani <at...@at...> - 2005-11-22 23:05:47
|
Thanks the code below seems to have solved the problem. I added it to
TikiTest as well since it was showing the same problems.
Perhaps we should consider having a common "main" package?
Mike
On 11/21/2005, "Sam Steele" <sam...@gm...> wrote:
>
>On Nov 21, 2005, at 8:12 PM, atani wrote:
>
>> When you hit the window close icon (red blob) the window closes
>> properly but the app doesnt!
>
>That's normal behavior on OS X if you don't have this method in your
>window controller:
>
>-(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication
>*)theApplication
>{
>=09return YES;
>}
>
>I was referring to the menu item / command + Q not working, which
>works properly in TikiTest so I probably broke TikiBlap.
>
>-Sam
|
|
From: Sam S. <sam...@gm...> - 2005-11-22 01:20:50
|
On Nov 21, 2005, at 8:12 PM, atani wrote:
> When you hit the window close icon (red blob) the window closes
> properly but the app doesnt!
That's normal behavior on OS X if you don't have this method in your
window controller:
-(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication
*)theApplication
{
return YES;
}
I was referring to the menu item / command + Q not working, which
works properly in TikiTest so I probably broke TikiBlap.
-Sam
|
|
From: atani <at...@at...> - 2005-11-22 01:12:55
|
On Nov 21, 2005, at 4:48 PM, Sam Steele wrote: > > On Nov 21, 2005, at 7:44 PM, Sam Steele wrote: > > >> However, the Quit event doesn't seem to be handled anymore.. I'm >> not sure when that got lost. >> > > Actually, it still works in TikiTest, so I probably broke something > in TikiBlap. I tried it in TikiTest and also in CS, both show the same behavior. When you hit the window close icon (red blob) the window closes properly but the app doesnt! I am also not sure when/how this got broken. I will do some digging into Tiki and see if I can find it. Mike |
|
From: Sam S. <sam...@gm...> - 2005-11-22 00:48:29
|
On Nov 21, 2005, at 7:44 PM, Sam Steele wrote: > However, the Quit event doesn't seem to be handled anymore.. I'm > not sure when that got lost. Actually, it still works in TikiTest, so I probably broke something in TikiBlap. -Sam |
|
From: Sam S. <sam...@gm...> - 2005-11-22 00:44:34
|
I was digging through the DCSquares source and I found the line to enable the enter / exit events: [self addTrackingRect:[self bounds] owner:self userData:nil assumeInside:true]; I've added it to Tiki and it seems to work! However, the Quit event doesn't seem to be handled anymore.. I'm not sure when that got lost. -Sam |
|
From: Dan P. <ba...@al...> - 2005-11-22 00:11:42
|
On Nov 21, atani wrote: > Dan, can you look at the Win32 TikiTest and see if it can be merged > easily into the new example tree? Sure. Probably can't do it today but I was actually planning on using Tiki for something in Win32 tomorrow, so I'll test it then. > I am also thinking of adding a few more example programs to show off > some basic features of the GenericMenu class. That'd be great. Also feel free to loot the parallax/tsunami samples in the KOS examples tree; they're pretty easy to convert. |
|
From: Dan P. <ba...@al...> - 2005-11-22 00:10:27
|
On Nov 21, Sam Steele wrote:
> In the header file or the cpp file? I was following Banner / Label
> as an example, which use "using namespace" in the cpp file. My local
> copy of the header uses "namespace Tiki {..."
>
> I've never worked with namespaces before, so it's all greek to me :)
Apparently it's considered bad practice now to "using namespace" anywhere.
You can probably guess from the Tiki code so far that I don't necessarily
agree with that view. ;) My practice so far has been to try to minimize the
impact that including any given header will have on other code.
In general it seems like namespaces are something that are handled
differently by each project.
I guess some other practices I encouraged in the namespace setup are
considered bad too, but whatever... For example I like the idea of having a
mega Tiki namespace that has everything inside it, and then 'using
namespace Tiki' and subsequently doing GL::Foo instead of Tiki::GL::Foo. Or
for something that works extensively inside Tiki::GL, just "using namespace
Tiki::GL" at the top of the cpp file.
The big thing I think is to avoid doing anything like that in a header
file. Also be very careful with 'using' decls inside a namespace or class,
because that can have global effects.
(Sorry if this sounds only moderately coherent.. listening to a work
meeting too.. :)
|
|
From: atani <at...@at...> - 2005-11-22 00:01:15
|
On Nov 21, 2005, at 3:52 PM, Sam Steele wrote:
>
> In the header file or the cpp file? I was following Banner / Label
> as an example, which use "using namespace" in the cpp file. My
> local copy of the header uses "namespace Tiki {..."
I missed the update to the header somehow... I have done some
minimal testing using the new z preserving code, it works mostly. I
think I have some z-order issue in CS that is stomping the cursor,
but it looks good otherwise :)
Mike
|
|
From: Sam S. <sam...@gm...> - 2005-11-21 23:52:49
|
On Nov 21, 2005, at 6:45 PM, atani wrote:
> This makes TikiCursor "in" the namespace rather than a consumer of
> the namespace.
>
In the header file or the cpp file? I was following Banner / Label
as an example, which use "using namespace" in the cpp file. My local
copy of the header uses "namespace Tiki {..."
I've never worked with namespaces before, so it's all greek to me :)
-Sam
|
|
From: atani <at...@at...> - 2005-11-21 23:47:55
|
On Nov 21, 2005, at 3:42 PM, Sam Steele wrote: > > I committed fixes for both of these. Also: the window height > you're subtracting from the mouse coordinates doesn't seem to take > the titlebar into consideration, so the cursor is still slightly > too low when compared to the OS X cursor, but when the OS X cursor > is hidden you shouldn't really notice it. I will see what I can find to account for that as well. Mike |
|
From: atani <at...@at...> - 2005-11-21 23:46:09
|
I just saw the batch of updated come in :)
I forgot one more minor update, please update TikiCursor namespace
declarations, instead of:
using namespace Tiki;
please use:
namespace Tiki {
}
This makes TikiCursor "in" the namespace rather than a consumer of
the namespace.
Mike
On Nov 21, 2005, at 1:13 PM, Sam Steele wrote:
> On 11/21/05, atani <at...@at...> wrote:
> Sam,
> I used the TikiCursor class to add a mouse cursor to CS and
> having some problems...
>
> I'll address these two issues when I get home from work.
>
>
> // Set screen center
> m_scene->setTranslate(Vector( 320, 240,10 ));
>
> Translating the scene will affect the mouse pointer's position.
> When I was doing testing, my scene was at 0,0. I will try to
> address this after work too.
>
> -Sam
>
|
|
From: Sam S. <sam...@gm...> - 2005-11-21 23:43:12
|
On Nov 21, 2005, at 1:52 PM, atani wrote: > Sam, > I used the TikiCursor class to add a mouse cursor to CS and > having some problems... I committed fixes for both of these. Also: the window height you're subtracting from the mouse coordinates doesn't seem to take the titlebar into consideration, so the cursor is still slightly too low when compared to the OS X cursor, but when the OS X cursor is hidden you shouldn't really notice it. -Sam |
|
From: atani <at...@at...> - 2005-11-21 23:16:58
|
I moved the OSX TikiTest to a new examples tree and updated the project file accordingly. I also removed the DC and SDL specific versions as they are now merged into the "generic" TikiTest. Dan, can you look at the Win32 TikiTest and see if it can be merged easily into the new example tree? I am also thinking of adding a few more example programs to show off some basic features of the GenericMenu class. Mike |
|
From: Dan P. <ba...@al...> - 2005-11-21 21:42:01
|
On Nov 21, atani wrote: > Go ahead and remove them from loadjpg.cpp, I will fix the SDL build this > evening. I remember having to add those around the jpeglib.h file for one > reason or another, but since we are using the 3rdparty directory for most > of the depends, I will go in and update SDL to use that as well vs locally > install versions. Oh I see, the default jpeg lib headers don't have anything? That kinda sucks. Using the 3rdparty jpeg sources is probably an ok solution. |
|
From: atani <at...@at...> - 2005-11-21 21:34:21
|
On Nov 21, 2005, at 12:18 PM, Dan Potter wrote: > I think some conflicting work was done here. :) I went to compile > this on > Win32 just to see if it was still functional today, definitely > isn't.. but > I've got it fixed up. > Go ahead and remove them from loadjpg.cpp, I will fix the SDL build this evening. I remember having to add those around the jpeglib.h file for one reason or another, but since we are using the 3rdparty directory for most of the depends, I will go in and update SDL to use that as well vs locally install versions. > > Oh and there's a psycho, crazy number of warnings in the Vorbis > code on win32. > So I may need to look at either #pragma turning off some warnings > or just > lowering the warning level in the vcproj (I don't plan to actually go > fix them, though we could try updating to a new version of libvorbis). newer version might be the right course of action, as well as the pragmas.. Mike |
|
From: Sam S. <sam...@gm...> - 2005-11-21 21:13:56
|
On 11/21/05, atani <at...@at...> wrote: > Sam, I used the TikiCursor class to add a mouse cursor to CS and having > some problems... > I'll address these two issues when I get home from work. // Set screen center > m_scene->setTranslate(Vector(320,240,10)); > Translating the scene will affect the mouse pointer's position. When I was doing testing, my scene was at 0,0. I will try to address this after work too. -Sam |
|
From: Dan P. <ba...@al...> - 2005-11-21 20:26:06
|
I think some conflicting work was done here. :) I went to compile this on Win32 just to see if it was still functional today, definitely isn't.. but I've got it fixed up. One small problem though: loadjpg.cpp has __BEGIN_DECLS and __END_DECLS in the actual cpp file (looks like change 211 did it?) and jpeglib.h *also* has the extern "C" stuff in the top. This apparently works fine on GCC but not on MSVC. Is there a reason we need it in the cpp file, or was that just you guys independently ending up doing the same thing? :) Oh and there's a psycho, crazy number of warnings in the Vorbis code on win32. So I may need to look at either #pragma turning off some warnings or just lowering the warning level in the vcproj (I don't plan to actually go fix them, though we could try updating to a new version of libvorbis). |
|
From: atani <at...@at...> - 2005-11-21 18:52:15
|
Sam,
I used the TikiCursor class to add a mouse cursor to CS and
having some problems...
1) TikiCursor should accept a z value.
2) pointerArrow should be named PointerArrow to be consistent in
naming conventions.
I have not debugged into it much yet, but the TikiCursor does not
seem to work right (even after working around issue #1 above), I am
using it as follows:
MainMenu::MainMenu()
{
// Set screen center
m_scene->setTranslate(Vector(320,240,10));
... snip ...
m_scene->subAdd(new TikiCursor());
}
Can you do some testing on this?
Mike |
|
From: Sam S. <sam...@gm...> - 2005-11-21 12:21:03
|
On Nov 21, 2005, at 1:56 AM, Atani wrote: > A bit verbose, but its a big improvement over the single line > description > of the changes. We now know what was changed and how... I agree, the new email notifications are much better. Though, Mail thought it was junk, so I guess it disagrees. -Sam |
|
From: Atani <at...@at...> - 2005-11-21 07:15:02
|
On 11/20/2005, "Dan Potter" <ba...@al...> 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?
>Basically in Marbol I got to the point where I was manually managing
>all this really nasty time based code. The standard animations and
>triggers weren't cutting it anymore because they were too fixed. What
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.
>I had in mind a system (eventually) where you can just instantiate a
>bunch of objects, maybe even through XML and not C++ at all, and
>connect up their slots and signals (think Qt and Obj-C/IB here). So
>that's why some weird classes are derived from Object instead of RefCnt.
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:
<scene>
<background>
<image>data/bg.png</image>
<slideshow>
<position x=3D"0.0" y=3D"0.0" z=3D"0.10" />
<content>
<image>data/slide01.png</image>
<image>data/slide02.png</image>
<image>data/slide03.png</image>
<image>data/slide04.png</image>
<image>data/slide05.png</image>
</content>
</slideshow>
</background>
<lightbarMenu>
<option id=3D"start">Start Game</option>
<option id=3D"scores">High Scores</option>
<option id=3D"quit">Quit</option>
</lightbarMenu>
</scene>
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.
Mike
|
|
From: Atani <at...@at...> - 2005-11-21 06:57:49
|
A bit verbose, but its a big improvement over the single line description of the changes. We now know what was changed and how... Thanks for updating it to this :) Mike |
|
From: Dan P. <ba...@al...> - 2005-11-21 02:23:05
|
Ok, I installed the Perl-based SVN notifier as a post-commit hook on the cadcdev SVN repo. We'll see how it works out. :) If the output turns out to be too verbose/yucky for people on the commit list, send an email and I'll try to tune it down a bit. |
|
From: Dan P. <ba...@al...> - 2005-11-21 02:11:45
|
On Nov 19, 2005, at 9:37 PM, Atani wrote: > http://docs.codehaus.org/display/HAUS/How+to+Send+Subversion+Commit > +Logs+to+Email > > A quick google :) Thanks. That was Dan-Speak for "I'm too lazy" :D This page shows using some Perl scripts to do it, but it'd require installation of stuff on the server for either. At this point after the server death a few days ago due to upgrading stuff, I'm a little skittish about doing any updates. I might look at adapting svnpush to just be an email notifier though. |
|
From: Dan P. <ba...@al...> - 2005-11-21 02:09:55
|
On Nov 20, 2005, at 10:30 AM, atani wrote: > Also very cool, a Slideshow would be a good addition. Also you can > take advantage of the Sleep animation and a Trigger callback which > increments the "slide". Yeah.. though at the time I wrote it, I don't think I'd even written the Delay and all that. So it just handles it internally. > Yup, just saw it. The format is decent enough for me. Perhaps > once the cmd line tool is checked in I can take a look at it and > integrate support for asciidoc type tags Cool. I'll have to warn you though, it's very minimal. :) Those tags just represent basic state changes, and it's got its own parser built in (no boost or anything). > I can imaging. This would probably be a good use for the Object > event handling I have planned. Until then though we can use a flag > in the inputEvent method to detect if we are in the "popup" or in > the "game". Speaking of Object event handling, I never really discussed why that was in there. :D It might be interesting... Basically in Marbol I got to the point where I was manually managing all this really nasty time based code. The standard animations and triggers weren't cutting it anymore because they were too fixed. What I wanted instead was something more like Flash (actually it was inspired entirely by Flash) where you can have a global timeline and movable events that can fire any random method to do stuff. It's meant for more high level things like gameplay mechanics than just regular animations, though it could be used for whatever. An example: in Marbol whenever you drop a piece down on the board, it needs to check to see if there are matching marbles around it to form a group. When you drop the piece, it uses the standard drawable/ animation stuff to make the visual piece fall. It then checks for pieces around it, and if it finds them, it schedules a removal event in N millis (whatever it was). So the player has a moment to see what's being removed. There's another event for dropping a new game piece into the board, and that event is simply moved forward any time a new animation needs to happen, so that new pieces aren't still falling while stuff at the bottom is being removed. Events can be rescheduled or forked indefinitely, or let go as they happen. I had in mind a system (eventually) where you can just instantiate a bunch of objects, maybe even through XML and not C++ at all, and connect up their slots and signals (think Qt and Obj-C/IB here). So that's why some weird classes are derived from Object instead of RefCnt. You guys can make of that (or not) as you will :) |
2 messages has been excluded from this view by a project administrator.
