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-06-12 05:23:05
|
On Jun 11, 2006, at 4:58 PM, Sam Steele wrote: > Aha! Having the input thread fire off while drawing / updating has > been driving me crazy! Thanks for putting this in (and pointing > out the existence of EventCollector). Yeah, I was scratching my head on this one for a bit. :) I was getting an assert for a usage of a null RefPtr, but it wasn't happening at a predictable point in the code when tracing through with the debugger. "It's like it's in a different thread or something..." ..... light bulb illuminates :) The amusing thing is that I had the exact same crash at basically the exact same point while running on the DC. How's that for consistency? 'Course that also led me to realize there's a race condition in the EventCollector, even with the mutex objects. That one's a tough nut to crack. We had a similar problem at work with DCOM callbacks happening after someone unregisters for them. I'll definitely take suggestions on that one if someone has an idea! |
|
From: Sam S. <sam...@gm...> - 2006-06-11 23:58:56
|
On Jun 11, 2006, at 7:35 PM, ba...@us... wrote: > Log Message: > ----------- > tiki: process genmenu input events in main thread, to make standard > Tsunami-style input/drawable interactions simpler Aha! Having the input thread fire off while drawing / updating has been driving me crazy! Thanks for putting this in (and pointing out the existence of EventCollector). -Sam |
|
From: Dan P. <ba...@al...> - 2006-06-08 03:14:44
|
On Jun 05, Sam Steele wrote: > Since everything is running on top of OpenGL anyway (even on the DC, > through KGL) my vote is to go with OpenGL directly instead of plxcompat. > I'm itching to use GL_QUADS in ConsoleText so it actually works on the DC > :) There's a pretty good argument to be made that plx and KGL are about 90% the same thing anyway. The plx calls just make things a little more compact for stuff like setting a texture and color on each vert (and reduce the call and memory write overhead a little bit). For any sort of optimized usage where you absolutely have to have the speed, it's probably still no problem to have a specialized DC vertex submitter. For 99% of the stuff out there (you guys like how I pull these numbers out of my rear? :) there's probably no real speed difference anyway. 20k polys/sec? 50k? 100k? 2M? Whatever... So I feel sorta like this makes the most sense at this point: - Convert all the internal plx usage to straight GL calls. - Leave the plxcompat wrappers for non-DC platforms so that direct plx calls on a DC port will still compile on a PC for testing/debug. - If you have the Need for Speed(tm), then use plx and get the advantage on the DC. Otherwise go straight GL. After all even with the built-in Tiki drawables, one can always override the draw method and make it use plx for optimization's sake. Does that sound like a pretty OK plan? Oh, and to not get completely off track from the original thread subject :) I was thinking of making some place to put code shared among multiple platforms. E.g. OSX, Linux, and DC can all make use of the pthreads impl of the threading. OSX, Linux, and Win32 can all make use of the OpenAL impl of audio and textures, etc. Any thoughts on a good dir tree structure for that? |
|
From: Sam S. <sam...@gm...> - 2006-06-07 20:59:34
|
On 6/3/06, atani <at...@at...> wrote: > > Another area which we can improve upon would be the plxcompat. > Inside Tiki I think we should not use it, instead converting to a > comparable Tiki method or to standard OpenGL calls. If we do want to > keep it we should make the DC port use the real parallax lib instead. Since everything is running on top of OpenGL anyway (even on the DC, through KGL) my vote is to go with OpenGL directly instead of plxcompat. I'm itching to use GL_QUADS in ConsoleText so it actually works on the DC :) -Sam |
|
From: Sam S. <sam...@gm...> - 2006-06-07 20:01:47
|
On Jun 5, 2006, at 10:55 PM, Dan Potter wrote: > Haven't hit audio at all yet. I'm attaching my unfinished KOS stream patch if you want to take a look at it. Stereo separation doesn't work (commented out), and the VorbisStream crashes when trying to pre-fill the buffers, but it's a start. The mono sound from ZZTMusicStream seems to work, though. I don't really know enough about what goes on under the hood in the KOS audio stuff to really get much further. The declaration for the thread will need to be updated for the change you just checked in, this was written against the previous thread definition. -Sam |
|
From: Dan P. <ba...@al...> - 2006-06-07 00:06:46
|
On Jun 06, Atani wrote: > I havent seen any information on this one yet... But cool that you are > still working on DC stuff sometimes :) Off and on. http://www.cagames.com/phpBB2/viewtopic.php?t=579&start=25 > >Haven't hit audio at all yet. > > Good luck with that, it still needs a bit of work in Tiki for anything > but OSX from my experiences so far :( So I've heard. I'll probably have to hit that up next. > Sure, thats why I posted it here, see what people think of consolidating > the plx_* calls into a more Tiki like call, which can be platform > overriden (specifically DC) ... > Thats exactly what I was after :) Cool. I might look into doing that. It's a little bit wacky to have all that indirection (plx emu -> Tiki prims -> plx real -> pvr ~:). On second though what might be better is to just move everything over to GL calls and then if you have something that really needs the speed, you can optimize it at the app level for the DC. Which I think was the other thing you were suggesting. :) |
|
From: Atani <at...@at...> - 2006-06-06 15:16:45
|
On 6/5/2006, "Dan Potter" <ba...@al...> wrote: >It's one of the announced ones: Donk. I've been working on it under >Tiki/OSX for the most part, and just ported it over to the DC. The >biggest problem I had actually was the lack of frame rate throttling >(I had it running at 30fps on OSX). Doesn't matter so much in the >long run since I'm planning to fix it so it runs at 60fps. It's very >old code and has some issues with animation vs frame rates. I havent seen any information on this one yet... But cool that you are still working on DC stuff sometimes :) > >I was actually kinda surprised at first that the hodge-podge all >worked. :D I mean we've got Tiki, running on top of KGL, running on >top of the PVR functions, with a messy mix of Newlib/pthreads and Yeah it is nice that it just works :) > >Haven't hit audio at all yet. Good luck with that, it still needs a bit of work in Tiki for anything but OSX from my experiences so far :( > >I would like to keep plxcompat personally. I have a *lot* of code >that makes use of plx_* calls that I'd like to keep around. I think Sure, thats why I posted it here, see what people think of consolidating the plx_* calls into a more Tiki like call, which can be platform overriden (specifically DC) >it's also nice because it's very raw (and on the DC, very fast) but >still platform agnostic. We could rename the plx_* calls into Tiki >calls somewhere, and then make plxcompat just aliases for those. On >the DC it could all call down into parallax still. I think maybe >that's what you were implying above, right? Thats exactly what I was after :) Mike |
|
From: Dan P. <ba...@al...> - 2006-06-06 03:25:04
|
On Jun 3, 2006, at 9:41 AM, atani wrote: > Sorry for not getting back to you sooner for this... > > Please add "atani" to the commit list for SVN so I can continue to > work on Tiki :) Heh, I wasn't sure what your SF username would be so I figured I'd just let you email me about it. It's done. From my own experiences with this authentication crud it may take a day or so for it to actually let you commit stuff. |
|
From: Dan P. <ba...@al...> - 2006-06-06 02:56:11
|
On Jun 3, 2006, at 9:46 AM, atani wrote: > Great!!! That means that we can now have a single unified API > again :) Yes :) I'll try to get that checked in soon. Even if we hadn't gotten pthreads working, I probably would've changed it to have a shim function to provide a compatible interface. It just defeats the purpose of having the shared API if you have to ifdef a bunch of stuff. > Great. I had it mostly working when I committed the initial version > but Sam did a lot of work on it further to make it actually > usable... Glad to hear that you had only minor issues to fix to make > it playable on the DC. > > Any hints to what the project is? It's one of the announced ones: Donk. I've been working on it under Tiki/OSX for the most part, and just ported it over to the DC. The biggest problem I had actually was the lack of frame rate throttling (I had it running at 30fps on OSX). Doesn't matter so much in the long run since I'm planning to fix it so it runs at 60fps. It's very old code and has some issues with animation vs frame rates. I was actually kinda surprised at first that the hodge-podge all worked. :D I mean we've got Tiki, running on top of KGL, running on top of the PVR functions, with a messy mix of Newlib/pthreads and other junk thrown in there. Yet it all pretty much compiled and worked right off the bat. The biggest problem I had was that I was double-initializing the PVR stuff to get a different mix of buffers, and that I was submitting verts outside of the Frame::begin/end calls. Once those were resolved I had perfectly working video. I had to resolve an issue with Time::sleep(0) hanging forever under KOS as well, but after that the input worked as well. Haven't hit audio at all yet. > Currently the DC Tiki stuff is kinda like that red-headed stepchild > compared to the "PC" ports. I know there are a lot of optimizations > we can do for each platform but I think there are a few areas which > may need some more abstraction (Tiki::GL::Texture for example) where > each port maintains its own "optimized" version. Right... Texture is probably a good candidate for such a thing. The GL implementations can pretty much all share a Texture class, but the DC e.g. really needs a custom one with a bunch of code ripped from Tsunami. It really seriously needs improvement for Donk too, because of the way I've been accelerating it. Donk has a bunch of discrete sprites that used to be drawn by just blitting them to an off-screen buffer. I changed it so that it calls down into an accelerated blit, which caches the target sprite into a texture and then submits verts for it. Works nicely but it sure eats up RAM and time with all the texture data shuffling. > Another area which we can improve upon would be the plxcompat. > Inside Tiki I think we should not use it, instead converting to a > comparable Tiki method or to standard OpenGL calls. If we do want to > keep it we should make the DC port use the real parallax lib instead. I would like to keep plxcompat personally. I have a *lot* of code that makes use of plx_* calls that I'd like to keep around. I think it's also nice because it's very raw (and on the DC, very fast) but still platform agnostic. We could rename the plx_* calls into Tiki calls somewhere, and then make plxcompat just aliases for those. On the DC it could all call down into parallax still. I think maybe that's what you were implying above, right? |
|
From: atani <at...@at...> - 2006-06-03 16:46:25
|
On Jun 2, 2006, at 2:55 PM, Dan Potter wrote: > On Jun 2, 2006, at 7:02 AM, Atani wrote: >> >> If you do remove it check that it still compiles cleanly against >> KOS, if >> it does then I am all for the clean up. > > Yeah, it does seem to work fine now. Great!!! That means that we can now have a single unified API again :) > > I've been working on a project for Dan Loosen with Tiki and I'm > trying to get it ported over to the DC today. You guys have done some > amazing work on this stuff... I think I only spent about an hour or > two from start to playable on the DC. Great. I had it mostly working when I committed the initial version but Sam did a lot of work on it further to make it actually usable... Glad to hear that you had only minor issues to fix to make it playable on the DC. Any hints to what the project is? > There are a number of optimizations I'd like to make on the DC end > eventually. One of the biggest is eliminating all the texture > overhead. It'd be nice for it to internalize everything as RGB565 or > ARGB1555/ARGB4444 for cases where a "canvas" texture isn't needed. Currently the DC Tiki stuff is kinda like that red-headed stepchild compared to the "PC" ports. I know there are a lot of optimizations we can do for each platform but I think there are a few areas which may need some more abstraction (Tiki::GL::Texture for example) where each port maintains its own "optimized" version. Another area which we can improve upon would be the plxcompat. Inside Tiki I think we should not use it, instead converting to a comparable Tiki method or to standard OpenGL calls. If we do want to keep it we should make the DC port use the real parallax lib instead. Mike |
|
From: atani <at...@at...> - 2006-06-03 16:41:16
|
Hi, Sorry for not getting back to you sooner for this... Please add "atani" to the commit list for SVN so I can continue to work on Tiki :) Mike On Jun 2, 2006, at 3:21 PM, Dan Potter wrote: > On May 24, 2006, at 7:24 PM, Dan Potter wrote: > >> Looking over the SF perms for cadcdev, there are a lot of people >> listed as members of the project who are not really active anymore. >> So again if you want SVN perms or any other sort of admin role in KOS >> or Tiki, please email me in the next week or so. Whoever hasn't >> emailed me after that will get removed; if you want to get added back >> later, just email me again. > > Ok, I did this. The only people left now are c99koder and ljsebald. > If anyone else wants back on, please email me. > > > > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
|
From: Dan P. <ba...@al...> - 2006-06-02 22:21:37
|
On May 24, 2006, at 7:24 PM, Dan Potter wrote: > Looking over the SF perms for cadcdev, there are a lot of people > listed as members of the project who are not really active anymore. > So again if you want SVN perms or any other sort of admin role in KOS > or Tiki, please email me in the next week or so. Whoever hasn't > emailed me after that will get removed; if you want to get added back > later, just email me again. Ok, I did this. The only people left now are c99koder and ljsebald. If anyone else wants back on, please email me. |
|
From: Dan P. <ba...@al...> - 2006-06-02 21:56:18
|
On Jun 2, 2006, at 7:02 AM, Atani wrote: > The main reason for this was the KOS headers were declaring the return > type different then pthread (even in latest version from my last > checks > sometime ago). > > If you do remove it check that it still compiles cleanly against > KOS, if > it does then I am all for the clean up. Yeah, it does seem to work fine now. I'm trying to commit some stuff and SF is denying me. ;\ I guess I hadn't actually given myself SVN perms (whoops :). So when that finally works I'll check this in as well as a couple of other random things I ran into. I've been working on a project for Dan Loosen with Tiki and I'm trying to get it ported over to the DC today. You guys have done some amazing work on this stuff... I think I only spent about an hour or two from start to playable on the DC. There are a number of optimizations I'd like to make on the DC end eventually. One of the biggest is eliminating all the texture overhead. It'd be nice for it to internalize everything as RGB565 or ARGB1555/ARGB4444 for cases where a "canvas" texture isn't needed. |
|
From: Atani <at...@at...> - 2006-06-02 21:18:26
|
On 6/2/2006, "Dan Potter" <ba...@al...> wrote: >Is there some reason for this, or can we get rid of it now? > >#if TIKI_PLAT =3D=3D TIKI_DC >bool create(thread_t * hndout, void (*func)(void *), void * param); >#else >bool create(thread_t * hndout, void * (*func)(void *), void * param); >#endif > >In the most modern KOSes pthreads are mostly available, so we should >probably switch off to using them. If no one complains I'm going to >make that change some time soon... The main reason for this was the KOS headers were declaring the return type different then pthread (even in latest version from my last checks sometime ago). If you do remove it check that it still compiles cleanly against KOS, if it does then I am all for the clean up. Mike |
|
From: Sam S. <sam...@gm...> - 2006-06-02 21:16:56
|
I was actually going to look into fixing this, it needs to be the same on all platforms, otherwise GCC on the DC complains when you create threads. I ran into that when I was working on the KOS streaming class. If you fix it (or if I do), I'll try to finish up the Stream class for the DC so we can have working sound on there. I'll also check in my old-school tone generator Stream class to go along with ConsoleText so we can have hardcore oldschool fun! It takes a BASIC-ish string of notes and outputs them in a very PC-speakery way. I'll also add a method to play arbitrary frequencies for arbitrary durations, for people that are into that sort of thing. -Sam On 6/2/06, Dan Potter <ba...@al...> wrote: > > Is there some reason for this, or can we get rid of it now? > > #if TIKI_PLAT == TIKI_DC > bool create(thread_t * hndout, void (*func)(void *), void * param); > #else > bool create(thread_t * hndout, void * (*func)(void *), void * param); > #endif > > In the most modern KOSes pthreads are mostly available, so we should > probably switch off to using them. If no one complains I'm going to > make that change some time soon... > > > > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
|
From: Dan P. <ba...@al...> - 2006-06-02 19:48:08
|
Is there some reason for this, or can we get rid of it now? #if TIKI_PLAT == TIKI_DC bool create(thread_t * hndout, void (*func)(void *), void * param); #else bool create(thread_t * hndout, void * (*func)(void *), void * param); #endif In the most modern KOSes pthreads are mostly available, so we should probably switch off to using them. If no one complains I'm going to make that change some time soon... |
|
From: Sam S. <sam...@gm...> - 2006-05-25 21:34:54
|
Hmm, I didn't even see the notification. I think gmail is eating my messages from the list, I guess I should add the email address to my address book or something. -Sam On May 25, 2006, at 12:11 PM, Dan Potter wrote: > Awww, no diff highlighting anymore? I guess it figures if SF is > hosting it :) > >> Revision: 328 >> Author: c99koder >> Date: 2006-05-25 05:34:19 -0700 (Thu, 25 May 2006) >> ViewCVS: http://svn.sourceforge.net/cadcdev/?rev=328&view=rev >> >> Log Message: >> ----------- >> Tiki: Add an additional output operator to Console >> >> Modified Paths: >> -------------- >> tiki/include/Tiki/drawables/console.h >> Modified: tiki/include/Tiki/drawables/console.h >> =================================================================== >> --- tiki/include/Tiki/drawables/console.h 2006-05-25 01:25:04 UTC >> (rev 327) >> +++ tiki/include/Tiki/drawables/console.h 2006-05-25 12:34:19 UTC >> (rev 328) >> @@ -92,6 +92,12 @@ >> m_colorData[(y*m_cols) + x] = attr; >> } >> >> + ConsoleText& operator <<(std::string input) { >> + printf("%s",input.c_str()); >> + >> + return *this; >> + } >> + >> ConsoleText& operator <<(const char *input) { >> printf("%s",input); >> >> >> >> This was sent by the SourceForge.net collaborative development >> platform, the world's largest Open Source development site. >> >> >> >> _______________________________________________ >> cadcdev-svn-commits mailing list >> cad...@li... >> https://lists.sourceforge.net/lists/listinfo/cadcdev-svn-commits >> > > > > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki |
|
From: Dan P. <ba...@al...> - 2006-05-25 16:12:32
|
Awww, no diff highlighting anymore? I guess it figures if SF is hosting it :) > Revision: 328 > Author: c99koder > Date: 2006-05-25 05:34:19 -0700 (Thu, 25 May 2006) > ViewCVS: http://svn.sourceforge.net/cadcdev/?rev=328&view=rev > > Log Message: > ----------- > Tiki: Add an additional output operator to Console > > Modified Paths: > -------------- > tiki/include/Tiki/drawables/console.h > Modified: tiki/include/Tiki/drawables/console.h > =================================================================== > --- tiki/include/Tiki/drawables/console.h 2006-05-25 01:25:04 UTC > (rev 327) > +++ tiki/include/Tiki/drawables/console.h 2006-05-25 12:34:19 UTC > (rev 328) > @@ -92,6 +92,12 @@ > m_colorData[(y*m_cols) + x] = attr; > } > > + ConsoleText& operator <<(std::string input) { > + printf("%s",input.c_str()); > + > + return *this; > + } > + > ConsoleText& operator <<(const char *input) { > printf("%s",input); > > > > This was sent by the SourceForge.net collaborative development > platform, the world's largest Open Source development site. > > > > _______________________________________________ > cadcdev-svn-commits mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-svn-commits > |
|
From: Dan P. <ba...@al...> - 2006-05-25 02:25:10
|
On May 24, 2006, at 6:35 PM, Dan Potter wrote: > For people who are committing, you'll also need to use --username to > set to your SF username instead of the svn.allusion.net one. I'm not > sure who all is still committing on a regular basis, but if you are > doing so email me with your SF username and I'll go take care of that. Looking over the SF perms for cadcdev, there are a lot of people listed as members of the project who are not really active anymore. So again if you want SVN perms or any other sort of admin role in KOS or Tiki, please email me in the next week or so. Whoever hasn't emailed me after that will get removed; if you want to get added back later, just email me again. |
|
From: Dan P. <ba...@al...> - 2006-05-25 01:36:24
|
On May 7, 2006, at 2:39 PM, Torsten Giebl wrote: > Hello ! > > > Is there a place where i can download the latest > Snapshot from KOS ? > > Sorry to say it but for me KOS looks > really scary. Some parts are on the Sourceforge Page. > Some parts are on the Allusion.net Page. The SVN Repo. > to get the latest Source is down. > > For People new to KOS this is really confusing. Yeah, sorry about that. The SVN repo actually moved to svn.allusion.net, but it should now be imported to SourceForge. So here is the new URL: https://svn.sourceforge.net/svnroot/cadcdev For people who already have an SVN repo you'll need to migrate once again. It looks something like this: svn switch --relocate http://svn.allusion.net/svn/kos https:// svn.sourceforge.net/svnroot/cadcdev For people who are committing, you'll also need to use --username to set to your SF username instead of the svn.allusion.net one. I'm not sure who all is still committing on a regular basis, but if you are doing so email me with your SF username and I'll go take care of that. I've also moved everything remaining in CVS into SVN -- the dcload, ps2, and navi trees. |
|
From: Dan P. <ba...@al...> - 2006-05-25 01:00:28
|
I'm going to go ahead and migrate the SVN repo over to SF now. So you guys should probably hold off on any commits for a little while. :) |
|
From: Sam S. <sam...@gm...> - 2006-05-16 12:56:45
|
On May 14, 2006, at 11:37 AM, Dan Potter wrote: > Not real sure... I will say that I haven't used it that way myself. > What I usually do is use the stream objects as a one-shot and get a > new one when I want to start a new song. So there might be bugs in > it for the other usage. You might want to just step through it with > Xcode and see what is going on. Not sure if sourceforge or gmail ate my messages for so long, but I finally got your reply this morning. I managed to get it working, by returning GDSuccess with silence when the stream first runs out of data, then on the next request for data I return GDEOS. That seems to let OpenAL empty its buffer out before it deletes the source (though occasionally it'll assert() and bring the app down, but most of the time it works). I also made an effort to port KOS's stream.c into the new streaming class (Atani's code is just a stub). It kinda works, I can get sound out of my tone generator, though it's a little choppy, and eventually the DC hangs up. It also crashes when trying to use the oggvorbis player (it wont even pre-fill the buffer...). I'm not very familiar with the streaming API, so I'm kind of shooting in the dark with this. If I check in what I have so far, is anyone else interested in troubleshooting it / finishing it? It'd be nice to have sound on the DC :) -Sam |
|
From: Dan P. <ba...@al...> - 2006-05-14 15:38:07
|
On May 13, 2006, at 11:16 PM, Sam Steele wrote: > I'm running into some trouble with the Stream API. I wrote a > little tone generator to use with DreamZZT, it seems to work fine > the first time it plays a tune, but once the tune is over I can't > get it to play anything else (I just get static or silence). Is > there something I have to do to reset something after the tune is > done, so the object can be reused? I'm returning GDEOS when the > tune is finished, but that seems to get the object into a state > where it wont play anything else. Not real sure... I will say that I haven't used it that way myself. What I usually do is use the stream objects as a one-shot and get a new one when I want to start a new song. So there might be bugs in it for the other usage. You might want to just step through it with Xcode and see what is going on. |
|
From: Sam S. <sam...@gm...> - 2006-05-14 06:16:56
|
I'm running into some trouble with the Stream API. I wrote a little tone generator to use with DreamZZT, it seems to work fine the first time it plays a tune, but once the tune is over I can't get it to play anything else (I just get static or silence). Is there something I have to do to reset something after the tune is done, so the object can be reused? I'm returning GDEOS when the tune is finished, but that seems to get the object into a state where it wont play anything else. For reference, the source files are: http://svn.c99.org/svn/DreamZZT/trunk/include/sound.h http://svn.c99.org/svn/DreamZZT/trunk/src/sound.cpp -Sam |
|
From: Sam S. <sam...@gm...> - 2006-05-13 19:33:53
|
Just checked in the console drawable (which now supports ANSI using atani's code), as well as the snake example. I didn't update the win32 build files, just the Mac project and a Makefile for the snake example. It doesn't look like TikiTest has a win32 project file anymore either, so if I get around to it I'll create project files for both of them. ANSI support is disabled by default, it needs to be enabled at runtime with ->setANSI(true);. I'm going to write a few more examples that are less complex than the snake game (hello world, hello ANSI, etc.) at some point, too, unless someone beats me to it. -Sam |
2 messages has been excluded from this view by a project administrator.
