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: Dan P. <ba...@al...> - 2005-11-20 04:25:17
|
On Nov 19, 2005, at 7:46 PM, Sam Steele wrote: > 99% finished with mine already. It's a generic drawable that > doesn't actually draw anything, just moves itself around according > to HID mouse events. It has 2 constructors, the default one will > subAdd() a pointerArrow which draws the arrow pointer from libc99 > in whatever getTint() you have. The other constructor takes a > drawable and subAdd()s it, so you can add a banner w/ a mouse > bitmap. I'm just cleaning it up and commenting it, and then I'll > commit it to SVN. > > I'm also going to clean up and comment the imageSet and menuList > drawables from DCBlap and add those to Tiki too. Awesome.. you guys are way too fast for me now. :D Every time I check my email there's 10 more commits :) FWIW, I just did a clean checkout of Tiki the other day to use it as a utility lib for loading textures and such in a Cocoa app I was tinkering with. Compiles great out of the box on Xcode 2.2, no issues. On that topic I've been developing some wrapper classes in Obj-C around some Tiki objects which are very nice to have around. Specifically I made a TikiTexture object that acts like a Cocoa object but wraps up a Tiki::GL::Texture using Obj-C++ (but Obj-C++ isn't required to interface with it in any way, from the outside). You can then do stuff like: TikiTexture * txr = [TikiTexture fromFile:@"foo.jpg"]; ... [txr select]; And it'll return an auto-released Obj-C object with that texture in it. The second line activates it in GL. You guys interested in this sort of stuff? I can check it in somewhere if so. |
|
From: Sam S. <sam...@gm...> - 2005-11-20 03:46:27
|
On Nov 19, 2005, at 10:38 PM, Dan Potter wrote: > Would you guys be ok with Tiki::GL::showCursor? I was thinking to > keep all the graphics stuff under there. > Sounds good. I'll rename it. > FWIW I did make a mouse cursor drawable way back when this stuff > was just part of FoF's guts. :) It has a built in bitmap based off > the Mac cursor. So if you guys want that to tinker with lemme know. > It's also probably in the FoF public source release. 99% finished with mine already. It's a generic drawable that doesn't actually draw anything, just moves itself around according to HID mouse events. It has 2 constructors, the default one will subAdd() a pointerArrow which draws the arrow pointer from libc99 in whatever getTint() you have. The other constructor takes a drawable and subAdd ()s it, so you can add a banner w/ a mouse bitmap. I'm just cleaning it up and commenting it, and then I'll commit it to SVN. I'm also going to clean up and comment the imageSet and menuList drawables from DCBlap and add those to Tiki too. -Sam |
|
From: Dan P. <ba...@al...> - 2005-11-20 03:39:08
|
On Nov 19, 2005, at 1:48 PM, Atani wrote: > How about Tiki::showCursor(boolean)? Would you guys be ok with Tiki::GL::showCursor? I was thinking to keep all the graphics stuff under there. > How about a generic Cursor drawable which you can bind by > Device::Type? FWIW I did make a mouse cursor drawable way back when this stuff was just part of FoF's guts. :) It has a built in bitmap based off the Mac cursor. So if you guys want that to tinker with lemme know. It's also probably in the FoF public source release. |
|
From: Atani <at...@at...> - 2005-11-19 23:25:17
|
On 11/19/2005, "Sam Steele" <sam...@gm...> wrote: >On Nov 19, 2005, at 4:48 PM, Atani wrote: >> Ok, I will look into it while fixing the Y invert. >> > >I think maybe we're looping through the events too quickly. If I add >a NSLog that outputs point.x and point.y, then the data comes through >fine, but if I remove the NSLog message then I just get garbage. Interesting... I have not had a chance to dig into it yet, I dont know when I will get to yet.. My son doesnt want to take a nap yet! If I can get him down I will try to get working on this.. >Done. I'll commit this in a few minutes for OSX. I wanted to re- >show the cursor when it leaves the window, but Tiki isn't receiving >mouseEntered / mouseExited. I added some code to mouseMoved to show/ >hide based on whether it's inside the window bounds, but it's kind of >quirky since the coordinates aren't working. There is an Event which we can receive for "enter" and "exit" I believe. I will check this out and see if I can get it working. As for showing/hiding in the move event, we should likely not do it there in favor of the enter/exit event. >I'll leave this part commented out, and just use the instant show/hide that = happens during >showCursor(bool) for now. > Fine by me :) I will work on fixing it up properly. >I'll play around with this. I initially thought to use an Anim so >that anything could be a pointer, but I suppose I could also have the >Cursor drawable see if it has any subdrawables attached, and only >draw a triangle if there's nothing else to draw. I would stick with a Drawable since it can contain multiple Drawable's each with their own positions which can be cool for "mouse trails" style effects (this can also be done with animations and chainanims). Mike |
|
From: Sam S. <sam...@gm...> - 2005-11-19 23:04:50
|
On Nov 19, 2005, at 4:48 PM, Atani wrote: > Ok, I will look into it while fixing the Y invert. > I think maybe we're looping through the events too quickly. If I add a NSLog that outputs point.x and point.y, then the data comes through fine, but if I remove the NSLog message then I just get garbage. > How about Tiki::showCursor(boolean)? > Done. I'll commit this in a few minutes for OSX. I wanted to re- show the cursor when it leaves the window, but Tiki isn't receiving mouseEntered / mouseExited. I added some code to mouseMoved to show/ hide based on whether it's inside the window bounds, but it's kind of quirky since the coordinates aren't working. I'll leave this part commented out, and just use the instant show/hide that happens during showCursor(bool) for now. > How about a generic Cursor drawable which you can bind by > Device::Type? > I'll play around with this. I initially thought to use an Anim so that anything could be a pointer, but I suppose I could also have the Cursor drawable see if it has any subdrawables attached, and only draw a triangle if there's nothing else to draw. -Sam |
|
From: Atani <at...@at...> - 2005-11-19 21:49:43
|
On 11/19/2005, "Sam Steele" <sam...@gm...> wrote: >I'll try this, but the values that come through the Evt object are >the same garbage that NSLog is outputting. Ok, I will look into it while fixing the Y invert. > >> Ok, that sounds fine, can we show/hide the cursor easily on OSX? I >> know >> on SDL we simply call SDL_Hide_Cursor() (i think). > >Yep, I have code to do this in DCSquares. I'll add it to Tiki this >evening, unless you get there first :) > How about Tiki::showCursor(boolean)? >> Cool, I will refresh and do some more adjustments to the mouse on OSX >> shortly. > >I'm thinking of making my mouse pointer function into a Drawable so >it can be more easily re-used. Can Anims receive HID events? Anything can hook the hid event system. Basically in the constructor you would hook the hid in the same fashion as genmenu does. Probably best to do this based on my next point... >I was thinking I could hook a followMouse Anim up to a mousePointer (or >Banner) Drawable and have an instant working mouse pointer. I'll >look into that this evening, too. How about a generic Cursor drawable which you can bind by Device::Type? Mike |
|
From: Sam S. <sam...@gm...> - 2005-11-19 21:31:52
|
On Nov 19, 2005, at 4:18 PM, Atani wrote: > Instead of flipping on Y it should probably just subtract the > window size from Y (640). Yes. > That also brings up another point, what about fullscreen modes for > OSX? These would be useful. I've looked around for info, to make a fullscreen version of DCSquares, but it was too awkward because I was using the Cocoa event loop for everything. This should be easier to do for Tiki since it has its own event loop, I'll look around again for info on how to do it. > This looks like the NSLog line is incorrect, I thought I had fixed > this > already. Change the %d to %f and it should give you decent > values. The > values in NSPoint are float not int. I'll try this, but the values that come through the Evt object are the same garbage that NSLog is outputting. > Ok, that sounds fine, can we show/hide the cursor easily on OSX? I > know > on SDL we simply call SDL_Hide_Cursor() (i think). Yep, I have code to do this in DCSquares. I'll add it to Tiki this evening, unless you get there first :) > Cool, I will refresh and do some more adjustments to the mouse on OSX > shortly. I'm thinking of making my mouse pointer function into a Drawable so it can be more easily re-used. Can Anims receive HID events? I was thinking I could hook a followMouse Anim up to a mousePointer (or Banner) Drawable and have an instant working mouse pointer. I'll look into that this evening, too. -Sam |
|
From: Atani <at...@at...> - 2005-11-19 21:22:05
|
On 11/19/2005, "Sam Steele" <sam...@gm...> wrote: > >This isn't changing anything that I can see on my Mac here. The >window title remains "window", the menu bar and dock icon tooltip >remain "TikiTest" even if I change the string in tiki_main(). I think there is a bug in the tiki_set_window_name() method in TikiMain.m. It also could be a calling order for the "name", I will do some digging :) Mike |
|
From: Atani <at...@at...> - 2005-11-19 21:20:14
|
On 11/19/2005, "Sam Steele" <sam...@gm...> wrote: > >It should probably get flipped in plathid.mm, since SDL, Windows, and >the Dreamcast use 0,0 as the top left, not the bottom left. I did not know that about OSX. Instead of flipping on Y it should probably just subtract the window size from Y (640). That also brings up another point, what about fullscreen modes for OSX? > Also, as an example of the garbage values I'm getting, I uncommented the N= SLog >line inside plathid.mm: > >2005-11-19 15:51:56.572 TikiTest[21215] maple: mouse move: >(-2147483648,551) This looks like the NSLog line is incorrect, I thought I had fixed this already. Change the %d to %f and it should give you decent values. The values in NSPoint are float not int. > >Even just a show/hide pointer function should be enough, so apps like >TikiTest that draw their own mouse pointer can choose to disable the >system pointer. Ok, that sounds fine, can we show/hide the cursor easily on OSX? I know on SDL we simply call SDL_Hide_Cursor() (i think). > >I committed my changes to OSX's TikiTest, so it's now mouse-enabled >like the Dreamcast version. > Cool, I will refresh and do some more adjustments to the mouse on OSX shortly. Mike |
|
From: Sam S. <sam...@gm...> - 2005-11-19 21:18:02
|
On Nov 19, 2005, at 6:11 AM, Dan Potter wrote: > A new revision has been checked into the Subversion repository. > > Revision 232: > Added setName(char *, char *) method to set window name. > This message was generated by SvnPush.py v1.0. > This isn't changing anything that I can see on my Mac here. The window title remains "window", the menu bar and dock icon tooltip remain "TikiTest" even if I change the string in tiki_main(). -Sam |
|
From: Dan P. <ba...@al...> - 2005-11-19 20:57:21
|
On Nov 19, 2005, at 11:04 AM, Sam Steele wrote: > Panther developers would need to have their own OpenAL framework > anyway, since it wasn't in the Tiki tree to begin with, unless I > missed it. I always just removed the broken OpenAL.framework > reference and replaced it with the one from /System. Yeah, true. > I guess including OpenAL in Tiki would be a good solution, but it > would mean universal builds will take even longer :) We have to do some munging somewhere anyway because Tiki doesn't depend on anything in Tiger per se, but if you make a universal binary with the default settings you'll get a Tiger-only binary. There are apparently some new settings in Xcode 2.2 that make it easier to mix and match versions. Seems like it'd be nice to have Panther compatibility out of the box (I'll certainly need it for any of my stuff...) Not a vital thing to worry about though. If I get around to needing it I can add it myself. |
|
From: Sam S. <sam...@gm...> - 2005-11-19 20:56:17
|
On Nov 19, 2005, at 3:39 PM, Atani wrote: > Right now the Y axis is only flipped for genmenu since we also apply > scene translate. Perhaps the Y should be flipped in the plathid.mm > file > instead? I will do some tests. > It should probably get flipped in plathid.mm, since SDL, Windows, and the Dreamcast use 0,0 as the top left, not the bottom left. Also, as an example of the garbage values I'm getting, I uncommented the NSLog line inside plathid.mm: 2005-11-19 15:51:56.572 TikiTest[21215] maple: mouse move: (-2147483648,551) 2005-11-19 15:51:56.585 TikiTest[21215] maple: mouse move: (-2147483648,552) 2005-11-19 15:51:56.612 TikiTest[21215] maple: mouse move: (-2147483648,555) > Instead of hide it we should probably add a method onto hid to > define a > mouse "cursor", if defined we can use that instead of the real > "cursor" where appropriate (SDL, OSX?). > Even just a show/hide pointer function should be enough, so apps like TikiTest that draw their own mouse pointer can choose to disable the system pointer. I committed my changes to OSX's TikiTest, so it's now mouse-enabled like the Dreamcast version. -Sam |
|
From: Atani <at...@at...> - 2005-11-19 20:40:44
|
On 11/19/2005, "Sam Steele" <sam...@gm...> wrote: >I'm getting garbage as the x axis value on my Mac here, and the y >axis needs to be flipped. Right now the Y axis is only flipped for genmenu since we also apply scene translate. Perhaps the Y should be flipped in the plathid.mm file instead? I will do some tests. > Also, I can't click on the red circle to >close the window anymore, it just passes my clicks onto Tiki. I will look into this. I probably need to add some sort of checks to the mouse event handler to pass those back on to the app. > >Also, a more general issue: device attach messages on the Mac happen >before tiki_main() can register its callback function, so I can't use >them to locate / count the mice like I did on the Dreamcast. Perhaps we should have some sort of "Device Registry" in the HID? > >Other than these, my mouseified TikiTest works on OSX too, and I'll >commit that in a few minutes. Btw, do we want to hide the mouse >cursor, since the Dreamcast doesn't have one? > Instead of hide it we should probably add a method onto hid to define a mouse "cursor", if defined we can use that instead of the real "cursor" where appropriate (SDL, OSX?). Mike |
|
From: Sam S. <sam...@gm...> - 2005-11-19 20:31:41
|
I'm getting garbage as the x axis value on my Mac here, and the y axis needs to be flipped. Also, I can't click on the red circle to close the window anymore, it just passes my clicks onto Tiki. Also, a more general issue: device attach messages on the Mac happen before tiki_main() can register its callback function, so I can't use them to locate / count the mice like I did on the Dreamcast. Other than these, my mouseified TikiTest works on OSX too, and I'll commit that in a few minutes. Btw, do we want to hide the mouse cursor, since the Dreamcast doesn't have one? -Sam On Nov 19, 2005, at 1:18 PM, atani wrote: > > Ok, this has been pushed out, bugs removed :) > > Note, any Mouse events which are sent will have the x/y values > relative to the scene in genmenu based menus. Otherwise the x/y > are relative to the window (ie: no translate done). > > Mike > > On Nov 19, 2005, at 9:29 AM, atani wrote: > >> I am working on adding Mouse support for OSX. So far it is slow >> going, but I have a mouse event handler which routes the mouse >> events into the Tiki Event handler, but genmenu is crapping out >> right now, not sure why yet. >> >> Mike >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today >> Register for a JBoss Training Course. Free Certification Exam >> for All Training Attendees Through End of 2005. For more info visit: >> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click >> _______________________________________________ >> cadcdev-tiki mailing list >> cad...@li... >> https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki >> >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki |
|
From: Sam S. <sam...@gm...> - 2005-11-19 20:00:20
|
I checked in a few updates to Tiki: * dc/src/plathid.cpp: Support the Dreamcast mouse * dc/TikiTest/src/test.cpp: Draw up to four pretty mouse pointers, change the direction the sphere rotate on mouse click, and display the names of devices as they attach and detach. -Sam |
|
From: Sam S. <sam...@gm...> - 2005-11-19 19:05:34
|
On Nov 19, 2005, at 1:45 PM, Dan Potter wrote: > This (the OpenAL thing) is actually going to break compiling on > anything but Tiger (not sure if we care... but it'll also make > extra steps to compile a Panther-compatible app). Panther developers would need to have their own OpenAL framework anyway, since it wasn't in the Tiki tree to begin with, unless I missed it. I always just removed the broken OpenAL.framework reference and replaced it with the one from /System. I guess including OpenAL in Tiki would be a good solution, but it would mean universal builds will take even longer :) -Sam |
|
From: Dan P. <ba...@al...> - 2005-11-19 18:45:18
|
This (the OpenAL thing) is actually going to break compiling on anything but Tiger (not sure if we care... but it'll also make extra steps to compile a Panther-compatible app). This is one of those things that is probably going to be hard to resolve without importing OpenAL to the tree and adding it to the build... Begin forwarded message: > A new revision has been checked into the Subversion repository. > > Revision 231: > Tiki:Made the OpenAL.framework link to /System/Libraries/Frameworks/ > OpenAL.framework > Tiki:Changed one more ref to relative > > This message was generated by SvnPush.py v1.0. |
|
From: atani <at...@at...> - 2005-11-19 18:19:04
|
Ok, this has been pushed out, bugs removed :) Note, any Mouse events which are sent will have the x/y values relative to the scene in genmenu based menus. Otherwise the x/y are relative to the window (ie: no translate done). Mike On Nov 19, 2005, at 9:29 AM, atani wrote: > I am working on adding Mouse support for OSX. So far it is slow > going, but I have a mouse event handler which routes the mouse > events into the Tiki Event handler, but genmenu is crapping out > right now, not sure why yet. > > Mike > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > > |
|
From: atani <at...@at...> - 2005-11-19 17:29:36
|
I am working on adding Mouse support for OSX. So far it is slow going, but I have a mouse event handler which routes the mouse events into the Tiki Event handler, but genmenu is crapping out right now, not sure why yet. Mike |
|
From: Dan P. <ba...@al...> - 2005-11-18 03:19:44
|
On Nov 17, 2005, at 5:43 PM, Sam Steele wrote: > I went ahead and committed some more changes to both KOS and Tiki > that will allow Tiki to build on KOS without fighting :) ... Awesome. Again I'm glad to see you guys hacking on this stuff, because I just don't have much time for it anymore. It'd be a shame for bit rot to set in :) |
|
From: Sam S. <sam...@gm...> - 2005-11-18 01:43:35
|
I went ahead and committed some more changes to both KOS and Tiki that will allow Tiki to build on KOS without fighting :) I checked out fresh copies of KOS and Tiki, and only made compilation- related fixes, no runtime changes. As of now, svn status says all the changes I made are checked in, and Tiki actually compiles :) I've adjusted Tiki to not include kos.h, just the parts it needs, so we no longer get conflicts with matrix.h or fmath.h. I also copied some headers in the kos-ports/lib* directories into the kos-ports/ include/* directories so that gcc can actually find them. Finally, I added a few #if's to loadjpg and loadpng so they #include <png/png.h> and #include <jpeg/libjpeg.h> for the Dreamcast so they can find the headers. And I prefixed all my commit messages with KOS and TIKI :) -Sam |
|
From: atani <at...@at...> - 2005-11-17 22:06:29
|
Dan Potter wrote: >BTW do you guys have any suggestions on the email notification for SVN check >ins? It wasn't a big deal when it was just KOS, but now that we have multiple >active projects in the one repo, it's starting to become confusing what the >commit messages mean without some context. We could prepend Tiki checkins >with "tiki:" (what I did in my internal repo, which is nice since it stays >with the history itself) or we could list changed files in the notification >emails, etc... or I could probably split the Tiki stuff into its own repo, >though that's a bit of a pain now that it's in the KOS one. > > If it is not much trouble adding the files would be useful. But certainly at a minimum prefixing the emails with the repos dir (kos: tiki: etc) would be a good idea as well. Mike |
|
From: Sam S. <sam...@gm...> - 2005-11-17 18:23:32
|
On 11/17/05, Dan Potter <ba...@al...> wrote: > > > Now that actually sounds like a bug (the assert thing). A header that > basic > shouldn't end up including so much. I'll tackle the header issues tonight. I'm going to check out a fresh copy of KOS and Tiki and I'll make sure a vanilla Tiki will compile with a vanilla KOS. I know there are a few more changes that need to be made to KOS, for example kos-ports/include/jpeg is missing some headers that need t= o be copied from kos-ports/libjpeg, and Tiki needs to include jpeg/jpeglib.j, not just jpeglib.h. I'll get these all sorted out tonight. BTW do you guys have any suggestions on the email notification for SVN chec= k > ins? I'm fine with prefixing "Tiki:" to my commit messages. -Sam |
|
From: Dan P. <ba...@al...> - 2005-11-17 17:09:22
|
On Nov 17, Sam Steele wrote: > The only problem is that pch.h is including kos.h, which includes dc/ > fmath.h before any other header files. Once those macros are > defined, you can't use them as a function name or gcc will barf. > xylogmover.cpp was the only cpp file that was calling the functions > as Tiki::Math:fsin() instead of using namespace Tiki::math; fsin(); The thing about it is that it makes a kind of inconsistent situation between the different ports. I guess if someone really wants DC support then it's not a huge burden... I seem to remember there being some conflict on one of the other platforms though. Like maybe their libc actually had functions called fsin(). > I considered removing kos.h from pch.h, and just including the > headers from KOS that are actually needed, but kos/include/assert.h > ends up including kos.h anyway, so it was kind of pointless. Now that actually sounds like a bug (the assert thing). A header that basic shouldn't end up including so much. BTW do you guys have any suggestions on the email notification for SVN check ins? It wasn't a big deal when it was just KOS, but now that we have multiple active projects in the one repo, it's starting to become confusing what the commit messages mean without some context. We could prepend Tiki checkins with "tiki:" (what I did in my internal repo, which is nice since it stays with the history itself) or we could list changed files in the notification emails, etc... or I could probably split the Tiki stuff into its own repo, though that's a bit of a pain now that it's in the KOS one. |
|
From: Sam S. <sam...@gm...> - 2005-11-17 12:27:10
|
On Nov 17, 2005, at 2:31 AM, Dan Potter wrote: > > Might be a better way to do this to 'using' them into the proper > namespace. Other places inside Tiki use these and could benefit > from the speed boost. I think there are non-macro functions you > could do this with. e.g. > The only problem is that pch.h is including kos.h, which includes dc/ fmath.h before any other header files. Once those macros are defined, you can't use them as a function name or gcc will barf. xylogmover.cpp was the only cpp file that was calling the functions as Tiki::Math:fsin() instead of using namespace Tiki::math; fsin(); I considered removing kos.h from pch.h, and just including the headers from KOS that are actually needed, but kos/include/assert.h ends up including kos.h anyway, so it was kind of pointless. -Sam |
2 messages has been excluded from this view by a project administrator.
