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...> - 2006-11-23 19:55:45
|
On Nov 18, 2006, at 11:24 AM, Sam Steele wrote: > I just found this out the hard way: ALUT is deprecated in OpenAL 1.1, > and Mac OS X 10.4.7 (and the latest XCode update) upgrade the OpenAL > framework to 1.1, removing ALUT. This makes all the sound code > unbuildable and unusable on the latest OS X / XCode :-/ Whoops... :( Is there some sort of replacement for it? I haven't looked in the code for quite a while so I dunno how much we rely on it... |
|
From: Sam S. <sam...@gm...> - 2006-11-18 19:24:48
|
I just found this out the hard way: ALUT is deprecated in OpenAL 1.1, and Mac OS X 10.4.7 (and the latest XCode update) upgrade the OpenAL framework to 1.1, removing ALUT. This makes all the sound code unbuildable and unusable on the latest OS X / XCode :-/ -Sam |
|
From: Dan P. <ba...@al...> - 2006-09-17 20:18:15
|
On Sep 17, 2006, at 12:24 PM, Sam Steele wrote: > Feel free to remove the legacy keyboard stuff from the DC's joystick > driver. The DC was the first tiki platform that had a non-keyboard > input device, so I put those in so the legacy Windows/Mac stuff would > still work. Since Tiki's got more non-keyboard platforms now, it's > fine to push handing the joystick events as well as the keyboard > events onto the app. That sounds good to me. Though it still seems like a nice idea in a lot of ways... but if we keep it, it should probably be something you turn on at the first of your program, or something like that. |
|
From: Sam S. <sam...@gm...> - 2006-09-17 19:24:24
|
On Sep 17, 2006, at 3:17 PM, Dan Potter wrote: > There's some seriously funky stuff going on with the key mappings on > the DC. I'm thinking maybe we need to figure a better way to handle > compatibility stuff. > Feel free to remove the legacy keyboard stuff from the DC's joystick driver. The DC was the first tiki platform that had a non-keyboard input device, so I put those in so the legacy Windows/Mac stuff would still work. Since Tiki's got more non-keyboard platforms now, it's fine to push handing the joystick events as well as the keyboard events onto the app. -Sam |
|
From: Dan P. <ba...@al...> - 2006-09-17 19:17:40
|
There's some seriously funky stuff going on with the key mappings on the DC. I'm thinking maybe we need to figure a better way to handle compatibility stuff. The GOAT Games menu has a "Press Start" screen which, when you press a key, goes on to the main part of the menu. It then waits for you to hit KeySelect on a game to start it. This is all fine, except that what happens is Tiki interprets Start as both BtnStart and key '\r' (and sends both events). I'm not 100% sure of the chain of events, but my menu ends up eating the first, then genmenu eats the second and creates a synthetic KeySelect event (since the user "hit enter"). My menu then eats this event and takes it as a selection of a game. I guess at the very least we probably need to have some sort of configurable "legacy" mappings for stuff like this. Like where you can enable/configure that hitting BtnStart generates a second key '\r' event. Another thing we could do is put a 'synthetic' bit in the Event struct that specifies that it was generated from an earlier event. Perhaps assign each event an incrementing integer ID so that you can see that multiple events are really the same event. Yet another possibility would be to put an "alternatives" array in the Event struct so that all these alternative interpretations can be included with the Event, and the consumer can choose which one they want to use. You guys have any ideas? If nothing else I don't think hitting start should end up being interpreted as KeySelect ;) |
|
From: Sam S. <sam...@gm...> - 2006-07-22 23:43:56
|
Does anyone have any suggestions for troubleshooting memory issues on win32? My heap seems to get corrupted before the app even starts.. my tiki_main has been stripped down to essentially: (tiki init stuff) GenericMenu *ts = new GenericMenu(); delete ts; Using the debug CRT, it'll report a heap corruption during the destructor, and using the release CRT it'll throw an exception during the constructor. This doesn't happen in any of my other Tiki projects, just DCSquares, and it only seems to happen on win32. I've tried recreating the project from scratch to see if I had set some weird build options, and even upgraded to Visual Studio 2005 (the free version is pretty sweet). I think I must have a global variable with a constructor or something that's screwing up the heap before tiki_main() gets run, but I can't figure it out. I'm almost at the point of discontinuing the win32 version of DCSquares and just sticking with Mac / Linux. Also, when tracing through the constructor with the VS debugger, assigning of values doesn't seem to do anything.. ex. m_usebgm = false; when the debugger steps over that, the value of this->m_usebgm should change from true (the default) to false, but it just stays true in the inspector. Even if I attempt to change the value manually in the inspector, it flips itself back to true again :-/ -Sam |
|
From: Atani <at...@at...> - 2006-07-10 06:34:27
|
Great. Now with the two of us working on it maybe we can get it working somewhat :) >From where I have it on my local tree it should now initialize basic functionality as well as enter 3D mode. I have not started on sound at all. I am also still thinking that we might want to consider restructuring the build methods a bit now that we are using the makefiles for more than just SDL/linux and DC platforms. It might make sense to centralize them somewhat and migrate to something like the scons (python based make system used by some of the other cross-platform projects out there). I know that the XMMS2 project uses one which works pretty well. I will need to do some digging but we should be able to migrate most of the "common" pieces to a single "common" tree (ie: pthread impls) while still retaining the other pieces which are required for the various ports. Mike On 7/7/2006, "Sam Steele" <sam...@gm...> wrote: >I checked in some fixes to the NDS port and added stub classes for >Audio, and TikiTest now compiles and links without errors -- of >course, it still doesn't do anything yet, but we're further along :) > >-Sam |
|
From: Atani <at...@at...> - 2006-07-10 06:28:00
|
Its actually very similar, on linux you can specify where to install things and typically they end up under /usr/local/.... someplace In my case it all lives under /usr/local/gba with the devkitpro directory under there. In either case we should likely use devkitarm and have a seperate macro for the NDSLIB stuff, at one point I had considered checking it in as I did for the GP2x OGL-ES libs. Mike On 7/7/2006, "Sam Steele" <sam...@gm...> wrote: >D'oh, I didn't mean to check in the change from $(DEVKITPRO) to $ >(DEVKITARM) when I checked in the other things. > >On OS X, the installer sets up the following directory layout: > >/opt/local/devkitpro >/opt/local/devkitpro/devkitARM >/opt/local/devkitpro/libnds >/opt/local/devkitpro/libgba > >So I set DEVKITPRO=3D/opt/local/devkitpro and DEVKITARM=3D/opt/local/ >devkitpro/devkitARM > >What is the typical layout on linux? > >-Sam > >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easie= r >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D12= 1642 >_______________________________________________ >cadcdev-tiki mailing list >cad...@li... >https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
|
From: Sam S. <sam...@gm...> - 2006-07-08 15:15:15
|
D'oh, I didn't mean to check in the change from $(DEVKITPRO) to $ (DEVKITARM) when I checked in the other things. On OS X, the installer sets up the following directory layout: /opt/local/devkitpro /opt/local/devkitpro/devkitARM /opt/local/devkitpro/libnds /opt/local/devkitpro/libgba So I set DEVKITPRO=/opt/local/devkitpro and DEVKITARM=/opt/local/ devkitpro/devkitARM What is the typical layout on linux? -Sam |
|
From: Sam S. <sam...@gm...> - 2006-07-08 01:59:29
|
I checked in some fixes to the NDS port and added stub classes for Audio, and TikiTest now compiles and links without errors -- of course, it still doesn't do anything yet, but we're further along :) -Sam |
|
From: Sam S. <sam...@gm...> - 2006-07-08 00:26:21
|
On Jul 7, 2006, at 5:00 AM, Atani wrote: > Have you tried the latest NV drivers? > Yeah I've tried a few different versions with the same results. I could probably wipe the whole thing and start over, but I don't use Windows on there enough to make it worthwhile. I only use it for compiling Windows builds of my games, and for occasionally using MS Money. On the DS front, my flash cart came today (and I learned the hard way that RS-MMC and mini-SD are different.. so off I went to pick up a mini-SD card too :P ) and I have devkitARM and ndslib up and running on my Mac. I got the tiki nds port to compile, but I had to change $ (DEVKITPRO) to $(DEVKITARM) in Makefile.rules to match my installation. ndslib comes with enough examples to keep me busy for a little while :) -Sam |
|
From: Atani <at...@at...> - 2006-07-07 16:14:56
|
On 7/6/2006, "Sam Steele" <sam...@gm...> wrote: > >The nvidia drivers conflict with the via chipset in my windows box, >so I can't use hardware opengl otherwise windows hangs after a few >seconds. If I don't use the nvidia drivers, then I can't go above >800x600, which makes VS.NET impossible to use. It's a lose-lose >situation :-/ Do the emulators run under wine? What a bad possition to be in :( Have you tried the latest NV drivers? As for running under Wine, well, Wine doesnt do too well when you run apps that make use of OpenGL (or anything that is graphically intense really). That is just my experience on it, but your mileage might vary. Mike |
|
From: Sam S. <sam...@gm...> - 2006-07-06 22:49:21
|
On Jul 6, 2006, at 10:38 AM, Atani wrote: > go for windows, there are more options! I have yet to get iDeaS to > work > on linux. The nvidia drivers conflict with the via chipset in my windows box, so I can't use hardware opengl otherwise windows hangs after a few seconds. If I don't use the nvidia drivers, then I can't go above 800x600, which makes VS.NET impossible to use. It's a lose-lose situation :-/ Do the emulators run under wine? -Sam |
|
From: Atani <at...@at...> - 2006-07-06 19:21:19
|
Step 1 for NDS port has been committed... it compiles tiki, tikitest has issues compiling though :( I will continue to investigate the current compilation failures and get them fixed.. I also need to implement various missing pieces of Tiki for NDS (like init DS/GL, setup input handlers). One thing I have not found a replacement for yet is threading support, not sure there is any for the NDS so currently all of the NDS thread methods throw errors (return false, etc). Mike On 7/5/2006, "Atani" <at...@at...> wrote: >Not yet, still fighting with the toolchains and getting them to compile >cleanly under GCC 4.1 (default with SUSE 10.1). > >As you have seen, I finally got compilation working for the DC targets so >now I have a sane build environment (maybe?). > >Also, I still need to test the audio stuff using this version of GCC on >the DC, but that is not critical to me. I am also thinking of creating >a new directory under the KOS tree for building the toolchain and >including the various patch files as well. > >Mike > >On 7/5/2006, "Sam Steele" <sam...@gm...> wrote: > >> >>On Jun 15, 2006, at 1:03 PM, atani wrote: >> >>> >>> The DS is pretty straight forward as well. Once I get my system >>> rebuilt using SUSE 10.1 (this weekend maybe) I will get the NDS port >>> checked in. >> >>Any news on the DS port? My flash cart should be arriving any day >>now and I'm itching to start playing around with it :) >> >>-Sam >> >> >> >>Using Tomcat but need to do more? Need to support web services, security? >>Get stuff done quickly with pre-integrated technology to make your job easi= er >>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >>http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D1= 21642 >>_______________________________________________ >>cadcdev-tiki mailing list >>cad...@li... >>https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki >> > >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easie= r >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D12= 1642 >_______________________________________________ >cadcdev-tiki mailing list >cad...@li... >https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
|
From: Atani <at...@at...> - 2006-07-06 15:19:48
|
Not yet, still fighting with the toolchains and getting them to compile cleanly under GCC 4.1 (default with SUSE 10.1). As you have seen, I finally got compilation working for the DC targets so now I have a sane build environment (maybe?). Also, I still need to test the audio stuff using this version of GCC on the DC, but that is not critical to me. I am also thinking of creating a new directory under the KOS tree for building the toolchain and including the various patch files as well. Mike On 7/5/2006, "Sam Steele" <sam...@gm...> wrote: > >On Jun 15, 2006, at 1:03 PM, atani wrote: > >> >> The DS is pretty straight forward as well. Once I get my system >> rebuilt using SUSE 10.1 (this weekend maybe) I will get the NDS port >> checked in. > >Any news on the DS port? My flash cart should be arriving any day >now and I'm itching to start playing around with it :) > >-Sam > > > >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easie= r >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D12= 1642 >_______________________________________________ >cadcdev-tiki mailing list >cad...@li... >https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
|
From: Sam S. <sam...@gm...> - 2006-07-06 01:45:13
|
On Jun 15, 2006, at 1:03 PM, atani wrote: > > The DS is pretty straight forward as well. Once I get my system > rebuilt using SUSE 10.1 (this weekend maybe) I will get the NDS port > checked in. Any news on the DS port? My flash cart should be arriving any day now and I'm itching to start playing around with it :) -Sam |
|
From: Sam S. <sam...@gm...> - 2006-06-18 16:08:20
|
I resized my GL window to match the NDS's dimensions and set up two viewports, the result is kind of interesting: http://raz0r.c99.org/~sam/ndsconcept.png I'm not sure whether I'll render the whole board on the top screen, or just the HUD.. the game gets a bit more challenging if you can't see the whole board at once, though it would make some of the larger puzzles very difficult. If I hide the HUD and just stretch the game board across the whole top screen, the terrain patterns create horrible moire patterns across the screen 'cause they lose their aspect ratio :-/ -Sam |
|
From: atani <at...@at...> - 2006-06-16 17:33:28
|
yup, it appears that ndslib does support that, and most of the OpenGL calls! http://sf.net/projects/ndslib/ Mike On Jun 16, 2006, at 8:53 AM, Sam Steele wrote: > Does the DS support glViewport()? I could render the scene twice > with different viewports, which would be the easiest way. > > -Sam > > > On 6/16/06, atani <at...@at...> wrote: > On Jun 15, 2006, at 11:13 AM, Sam Steele wrote: > > > > Sweet! I think the Opera approach would work pretty well with > > DreamZZT, display the entire game board on the top screen and a > > zoomed in view on the bottom. I'd really love to get TikiBlap > > running on the handhelds though, and the NDS touch screen is pretty > > much perfect for TikiSquares :) > > How would you be doing the zoomed screen? Render the scene twice? > > It might be a cool feature to be able to take a snapshot of the scene > and render it as another object in the scene, or another scene... > > Mike > > > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki |
|
From: Sam S. <sam...@gm...> - 2006-06-16 15:53:34
|
Does the DS support glViewport()? I could render the scene twice with different viewports, which would be the easiest way. -Sam On 6/16/06, atani <at...@at...> wrote: > > On Jun 15, 2006, at 11:13 AM, Sam Steele wrote: > > > > Sweet! I think the Opera approach would work pretty well with > > DreamZZT, display the entire game board on the top screen and a > > zoomed in view on the bottom. I'd really love to get TikiBlap > > running on the handhelds though, and the NDS touch screen is pretty > > much perfect for TikiSquares :) > > How would you be doing the zoomed screen? Render the scene twice? > > It might be a cool feature to be able to take a snapshot of the scene > and render it as another object in the scene, or another scene... > > Mike > > > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
|
From: atani <at...@at...> - 2006-06-16 15:48:52
|
On Jun 15, 2006, at 11:13 AM, Sam Steele wrote: > > Sweet! I think the Opera approach would work pretty well with > DreamZZT, display the entire game board on the top screen and a > zoomed in view on the bottom. I'd really love to get TikiBlap > running on the handhelds though, and the NDS touch screen is pretty > much perfect for TikiSquares :) How would you be doing the zoomed screen? Render the scene twice? It might be a cool feature to be able to take a snapshot of the scene and render it as another object in the scene, or another scene... Mike |
|
From: Sam S. <sam...@gm...> - 2006-06-15 18:13:55
|
On Jun 15, 2006, at 1:03 PM, atani wrote: > > The DS is pretty straight forward as well. Once I get my system > rebuilt using SUSE 10.1 (this weekend maybe) I will get the NDS port > checked in. I have a copy of the NEHE 04 example ported to NDS using > the opensource SDK. About the only thing unfortunate about the NDS > is the screen size (approx 200 pixels square or something close to > that). > Sweet! I think the Opera approach would work pretty well with DreamZZT, display the entire game board on the top screen and a zoomed in view on the bottom. I'd really love to get TikiBlap running on the handhelds though, and the NDS touch screen is pretty much perfect for TikiSquares :) -Sam |
|
From: atani <at...@at...> - 2006-06-15 17:11:30
|
Recently Dan was asking about where to store "common" pieces for the ports which are not "common" to all ports.. Well, more discussion is still needed on that as well as on general structure of the tree. The current source tree is getting pretty full in the root with the "core" Tiki piece(s) and the ports pieces. I suggest restructuring the tree as follows: <ROOT> -> examples -> src -> include -> notes -> 3rdparty -> ports -> common -> osx -> sdl -> dc -> gp2x -> ... other ports ... -> utils In addition to this I would like to make the build system closer to the one that KOS uses, and then also have project files for the various IDEs etc. What do you guys think? Mike |
|
From: atani <at...@at...> - 2006-06-15 17:04:23
|
The DS is pretty straight forward as well. Once I get my system rebuilt using SUSE 10.1 (this weekend maybe) I will get the NDS port checked in. I have a copy of the NEHE 04 example ported to NDS using the opensource SDK. About the only thing unfortunate about the NDS is the screen size (approx 200 pixels square or something close to that). Mike On Jun 15, 2006, at 10:00 AM, Sam Steele wrote: > Sweet, a handheld! I was actually thinking about porting Tiki to > the Nintendo DS, but I haven't had a chance to check out their dev > kit stuff yet. Picked up a DS Lite over the weekend, gotta get a > flash cartridge for it now :) > > -Sam > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki |
|
From: atani <at...@at...> - 2006-06-15 17:02:47
|
All, Tiki has been ported now to the GP2x handheld system. Essentially this device is a Linux device using a framebuffer interface. GamePark Holdings has recently released a modified version of SDL which works on this system. Unfortunately the only OpenGL implementation does not use this library, but hopefully this should be easily resolved with some minor work to the Vincent OpenGL-ES library. I have not had a chance to do in depth testing yet, but since it is based on a known Linux version (2.4.x) it should work with only minimal changes. Currently what is not implemented is input or sound. I doubt that the OpenAL library will work on the GP2x since it does not use ALSA/ OSS, but it may. I still need to do some more testing on that front with an actual device. If you know anyone who is willing to test this out on a real device let me know. I will supply all binaries and assistance to get it working on the GP2x. Now I just need to get the PSP port more functional and get it committed as well, but that will wait a bit... Mike |
|
From: Sam S. <sam...@gm...> - 2006-06-15 17:00:16
|
Sweet, a handheld! I was actually thinking about porting Tiki to the Nintendo DS, but I haven't had a chance to check out their dev kit stuff yet. Picked up a DS Lite over the weekend, gotta get a flash cartridge for it now :) -Sam |
2 messages has been excluded from this view by a project administrator.
