Menu
▾
▴
tuxmath-devel
|
From: Brendan L. <che...@gm...> - 2010-07-12 19:58:54
|
Hi everyone, Tthings have been rather uneventful since my last update. A week in Boston for the 4th of July didn't leave as much time for coding as I'd hoped, but I managed to replace most of the relevant function calls in TuxType with calls to T4K_Functions. I'm now doing the same for TuxMath. There are also now Doxygen comments in t4k_common.h . Many of these comments are just stubs, though. By the end of the week, I want to turn my attention to the Mac, then do another round of testing across the three platforms. As for the big picture, things are certainly moving along, albeit slowly. Since the start of coding, I've shaken the dust off of the library, renamed it and the functions therein, gotten it to build and install as a shared library and gotten TuxMath and TuxType to use it--all more or less automatically--on several Linux- and Windows-based computers. Remaining items include: removing the older built-in versions of functions and structures, which are effectively dead code in TM and TT; fleshing out the documentation (I guess this should be posted as HTML somewhere); and extensive testing in preparation for the two merges back into master. I haven't hit any enormous brick walls, so far, but there have been plenty of small ones to impede progress. More than that, because this project is less about producing code and more about moving things around and gluing things together across several repositories (and, in this case, several machines), things tend to get messy quickly, and I find myself often taking a step back to make sure, e.g. I'm in the right directory, which slows things down considerably. I underestimated the importance of visible progress to motivation--my measure of success has been seeing the game launch and behave as it should during gameplay, which, well, isn't all that exciting, and leads to distractions. It's one thing to do a less-glorified job, but it's quite another to find *myself* losing focus when the program does the same thing for the twentieth time. So, I'm personally disappointed with how long this is taking, but I'm clinging to schedule. There's a light at the end of the tunnel, and I'm looking forward to a great benefit to TuxMath, -Type (and -History?) when this is through. Best, Brendan |
|
From: Tim H. <ho...@wu...> - 2010-07-12 20:14:43
|
Hi Brendan, On the topic of t4k_common, I was noticing the other day that Holger has long had a wish-list item (http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=490115): implement support for changing locale via a "-- lang" flag. TuxPaint has some nice code to do this. I thought about stealing it and wiring it into TuxMath (thanks, Bill!), but then I realized that t4k_common was probably the right place to put it, so that TuxType would also benefit. Any interest in adding this challenge to your own TODO pile? At least it would give you some new functionality to implement and test... Best, --Tim On Monday, July 12, 2010 02:58:46 pm Brendan Luchen wrote: > Hi everyone, > > Tthings have been rather uneventful since my last update. A week in Boston > for the 4th of July didn't leave as much time for coding as I'd hoped, but > I managed to replace most of the relevant function calls in TuxType with > calls to T4K_Functions. I'm now doing the same for TuxMath. There are also > now Doxygen comments in t4k_common.h . Many of these comments are just > stubs, though. By the end of the week, I want to turn my attention to the > Mac, then do another round of testing across the three platforms. > > As for the big picture, things are certainly moving along, albeit slowly. > Since the start of coding, I've shaken the dust off of the library, renamed > it and the functions therein, gotten it to build and install as a shared > library and gotten TuxMath and TuxType to use it--all more or less > automatically--on several Linux- and Windows-based computers. Remaining > items include: removing the older built-in versions of functions and > structures, which are effectively dead code in TM and TT; fleshing out the > documentation (I guess this should be posted as HTML somewhere); and > extensive testing in preparation for the two merges back into master. > > I haven't hit any enormous brick walls, so far, but there have been plenty > of small ones to impede progress. More than that, because this project is > less about producing code and more about moving things around and gluing > things together across several repositories (and, in this case, several > machines), things tend to get messy quickly, and I find myself often taking > a step back to make sure, e.g. I'm in the right directory, which slows > things down considerably. I underestimated the importance of visible > progress to motivation--my measure of success has been seeing the game > launch and behave as it should during gameplay, which, well, isn't all that > exciting, and leads to distractions. It's one thing to do a less-glorified > job, but it's quite another to find *myself* losing focus when the program > does the same thing for the twentieth time. > > So, I'm personally disappointed with how long this is taking, but I'm > clinging to schedule. There's a light at the end of the tunnel, and I'm > looking forward to a great benefit to TuxMath, -Type (and -History?) when > this is through. > > Best, > Brendan |
|
From: Holger L. <ho...@la...> - 2010-07-13 07:39:31
|
Hi, On Montag, 12. Juli 2010, Tim Holy wrote: > On the topic of t4k_common, I was noticing the other day that Holger has > long had a wish-list item (http://bugs.debian.org/cgi- > bin/bugreport.cgi?bug=490115): implement support for changing locale via a > "-- lang" flag. TuxPaint has some nice code to do this. I thought about > stealing it and wiring it into TuxMath (thanks, Bill!), but then I realized > that t4k_common was probably the right place to put it, so that TuxType > would also benefit. > > Any interest in adding this challenge to your own TODO pile? At least it > would give you some new functionality to implement and test... Thanks for digging this up :) Actually, a --lang switch would be great, but equally great would be to read the environment variables being set, to automatically select the right language. cheers, Holger |
|
From: Brendan L. <bm...@ri...> - 2010-07-13 17:29:36
|
Hi Tim, Holger, > > Any interest in adding this challenge to your own TODO pile? At least it > > would give you some new functionality to implement and test... > > Certainly! Of course, the boring stuff needs to be finished first... > Actually, a --lang switch would be great, but equally great would be to > read > the environment variables being set, to automatically select the right > language. > Well, I guess the switch would override the EV...that's simple enough. What I'm not sure of is: how to accomplish this with gettext and friends at runtime. Actually, I don't even know what else is affected by i18n in the games, other than translated strings. Time to do some reading :) While we're sort-of on the subject, one thing I'm noticing is that only --debug-xxx flags are actually handled by libt4k_common; other common things like --windowed, --nosound and such are all handled separately. Even worse is that some of the key events, like F10 to switch resolution, are being handled in 5 or so different places. I think it'd be a good idea to centralize some of these eventually, too. Best, Brendan |
|
From: Tim H. <ho...@wu...> - 2010-07-13 17:51:03
|
Hi Brendan, On Tuesday, July 13, 2010 12:29:29 pm Brendan Luchen wrote: > While we're sort-of on the subject, one thing I'm noticing is that only > --debug-xxx flags are actually handled by libt4k_common; other common > things like --windowed, --nosound and such are all handled separately. > Even worse is that some of the key events, like F10 to switch resolution, > are being handled in 5 or so different places. I think it'd be a good idea > to centralize some of these eventually, too. Hmm, good point. I recently improved "master"'s handling of those command line debug flags, but did not centralize things in the way you are suggesting. Best, --Tim |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X