tuxmath-devel — TuxMath developer's mailing list.

Re: [Tuxmath-devel] "New" SVG art

[David B. <dav...@gm...>]

Hi Tim et al,

On Mon, Jul 19, 2010 at 8:19 PM, David Bruce <dav...@gm...> wrote:
> Anyway, it wouldn't be much
> work to redo the blinking with Inkscape.

Done and committed to both branches of tuxmath.

Best,

David

Re: [Tuxmath-devel] "New" SVG art

[David B. <dav...@gm...>]

Hi Tim,


> The tux/ directory also contains the "bigtux" files, of which one is pretty
> clearly an SVG "parent" file. David, from the history it looks like you
> contributed these files; do you have SVG versions for the remaining "bigtux"
> graphics (assuming they are used)?

No, I think I made the bigtux blinking animation pics with the GIMP
and exported them as pngs.  I think Brendan made the ones where tux
opens his mouth for the "Easter Egg".  Anyway, it wouldn't be much
work to redo the blinking with Inkscape.

btw, the "Roos_bigtux*.png" images were from a customized build I made
for Laura's school in Tampa, Roosevelt Elementary.  I was trying to
depict Tux as a Roosevelt Rough Rider (the school mascot).  It was
quite a hit with the kids there.  They aren't used in the official
program, but they have great nostalgic value.

Cheers,

David

Re: [Tuxmath-devel] Multithreading for rescaling title screen and menu items

[David B. <dav...@gm...>]

Hi Brendan, Wenyuan et al,

> Hmm... I think in that case we might as well use SDL_threads. We can
> just let SDL runtime to handle cross-platform issues. My code
> currently only uses quite basic functionality of pthreads. Let me
> check what changes need to be made.

If SDL threads do what we need, we might as well just go with that.
It will make our code cleaner if we can avoid a bunch of #ifdef
HAVE_PTHREADS or #ifdef WIN32 conditionals to handle cross-platform
differences.

As it stands now, the tuxmath LAN server preferentially runs in a
thread using pthreads on Linux, whereas on Windows it only works as a
standalone executable (not that I've actually gotten a win32 release
out with LAN support :-(   ).  So that ought to be converted to SDL
threads as well.

This may be a bit analogous to how we used SDL_net last summer instead
of straight BSD sockets for the network stuff.

Best,

David

Re: [Tuxmath-devel] Multithreading for rescaling title screen and menu items

[Wenyuan G. <guo...@gm...>]

Hi Brendan,


> I'm sure SDL_thread.h doesn't expose all the functionality you can get
> from pthreads, but it the important stuff. Instead of a pthread_join,
> you'd use SDL_WaitThread, etc.

Hmm... I think in that case we might as well use SDL_threads. We can
just let SDL runtime to handle cross-platform issues. My code
currently only uses quite basic functionality of pthreads. Let me
check what changes need to be made.

Cheers
Wenyuan

Re: [Tuxmath-devel] Multithreading for rescaling title screen and menu items

[Brendan L. <bm...@ri...>]

Wenyuan,

I'm sure SDL_thread.h doesn't expose all the functionality you can get
from pthreads, but it the important stuff. Instead of a pthread_join,
you'd use SDL_WaitThread, etc.

> I remember that POSIX threads are fully supported by Windows too? Have
> you tried to compile it under windows?

I googled quickly and it looks like you're right--what a nice surprise!
http://sourceware.org/pthreads-win32/

I'll try this first.

-Brendan

Re: [Tuxmath-devel] Multithreading for rescaling title screen and menu items

[Wenyuan G. <guo...@gm...>]

Hi Brendan,

> Just updated my branch with the threading--looks nice! For the sake of
> portability (actually, just me and my broken Windows environment) would you
> mind if I changed the calls to use the SDL_Thread API instead of pthreads?
> AFAIK it's just a wrapper around pthreads on most environments, so the
> implementation/performance should be identical. Let me know if you see any
> problems with changing.

Ouch! I didn't think of that issue. Thanks for pointing it out. But
has SDL_Thread library got all the other pthread functions like
"join"?

I remember that POSIX threads are fully supported by Windows too? Have
you tried to compile it under windows?

Cheers
Wenyuan

Re: [Tuxmath-devel] Multithreading for rescaling title screen and menu items

[Brendan L. <bm...@ri...>]

Hi Wenyuan,

Just updated my branch with the threading--looks nice! For the sake of
portability (actually, just me and my broken Windows environment) would you
mind if I changed the calls to use the SDL_Thread API instead of pthreads?
AFAIK it's just a wrapper around pthreads on most environments, so the
implementation/performance should be identical. Let me know if you see any
problems with changing.

Cheers,
Brendan

On Mon, Jul 19, 2010 at 7:42 AM, Tim Holy <ho...@wu...> wrote:

> Dear Wenyuan,
>
> On Monday, July 19, 2010 04:02:00 am Wenyuan Guo wrote:
> > But it should not be problem here for the latest version: hard
> > disk cache for modern OS is smart enough so that only the first read
> > of each file incurs the mechanical delay. It used to be a problem in
> > the earlier versions without SVG cache though, because the bottleneck
> > was CPU bound then, and loading and rescaling the same sprite more
> > than once add to that delay.
>
> Good point. Presumably if the cache got filled up we'd see a performance
> hit,
> but for almost any machine that can run tuxmath I doubt this will be a
> problem.
>
> > > 6. Use David's suggestion that we (at least optionally) always have
> both
> > > the --fullscreen and the --windowed resolution graphics available in
> > > memory.
>
> > After thinking over these options for a while, I think I will give 6 a
> > try: in particular, we can load all cached sprites of all resolutions
> > at the startup, possibly in a separate thread. Later resolution
> > switches will not incur the hard disk delay this way. If my theory
> > that the current 2s is mainly hard disk bound is correct, it should
> > give substantial improvement for all F10 presses in-menu.
> >
> > Now going back to some happy coding! I will update you once the
> > feature is implemented and is ready for testing.
>
> Exciting!
>
> --Tim
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>

[Tuxmath-devel] "New" SVG art

[Tim H. <ho...@wu...>]

Hi everyone (esp. Wenyuan, David, Jesus, and Jérémy),

I just committed a bunch of "new" SVG art. It was material that was in a file 
my daughters and I created called "composite.svg"; all I did was split it out 
into individual graphics files, with the hope that this can help promote the 
switch to SVG art in the comets game, too.

This should be "complete" for the igloos/ and penguins/ directories, with the 
exception of "worried" which I seemingly forgot to save in composite.svg. That 
could be pretty easily redrawn.

I believe the comets/ directory is also covered already; the comet.svg file, 
for example, contains all 3 comets (I'm not sure how this gets handled in 
terms of use during the game, but if needed it could be split into 3 files). 
The comet.svg file was kindly contributed by Jérémy Laumon, who also described 
how he did it (message pasted below for the benefit of those who were not 
subscribed to the list back then).

So for the comets game, it would seem that the major frontier is the tux/ 
directory. I tried Jérémy's method and converted the tux-console1.png file. 
It's clearly going to take a fair amount of manual tweaking to get the images 
right, but it's certainly a viable option.

The tux/ directory also contains the "bigtux" files, of which one is pretty 
clearly an SVG "parent" file. David, from the history it looks like you 
contributed these files; do you have SVG versions for the remaining "bigtux" 
graphics (assuming they are used)?

Finally, I also notice there's a "comp.svg" file in the factoroids/ directory, 
so presumably something similar would be pretty easy to do with factoroids, 
although it doesn't seem to be complete. Any thoughts on this, Jesus?

But overall I think we can make the leap to full SVG in the not-too-distant 
future.

Best,
--Tim

> Hi Tim,
> 
> Here are the basics steps I followed to make SVG comets from PNG files :
> (Inkscape is in french on my computer, I tried to translate button names
> but there may be mistakes)
> 
> First, I import the png file (Ctrl+i) and then, I adjust the page size to
> the selection (Maj+Ctrl+d, then click on adjust). Secondly, I trace the
> bitmap (Maj+Alt+b) using "Multiple scans" tool with "Color" selection and
> 3 "scans" ("Remove background" option should be ticked). Thirdly, I color
> the outline of the newly created SVG using the selection tool (F2) and the
> bucket tool (Maj+F7). And Finally, I change colors and add gradients using
> the "Fill and Strokes" tool (Maj+Ctrl+f)
> 
> It's not a perfect method. Some elements may need to be resized and/or
> deformed.
> 
> Regards,
> Jeremy Laumon

Re: [Tuxmath-devel] Multithreading for rescaling title screen and menu items

[Tim H. <ho...@wu...>]

Dear Wenyuan,

On Monday, July 19, 2010 04:02:00 am Wenyuan Guo wrote:
> But it should not be problem here for the latest version: hard
> disk cache for modern OS is smart enough so that only the first read
> of each file incurs the mechanical delay. It used to be a problem in
> the earlier versions without SVG cache though, because the bottleneck
> was CPU bound then, and loading and rescaling the same sprite more
> than once add to that delay.

Good point. Presumably if the cache got filled up we'd see a performance hit, 
but for almost any machine that can run tuxmath I doubt this will be a 
problem.

> > 6. Use David's suggestion that we (at least optionally) always have both
> > the --fullscreen and the --windowed resolution graphics available in
> > memory.

> After thinking over these options for a while, I think I will give 6 a
> try: in particular, we can load all cached sprites of all resolutions
> at the startup, possibly in a separate thread. Later resolution
> switches will not incur the hard disk delay this way. If my theory
> that the current 2s is mainly hard disk bound is correct, it should
> give substantial improvement for all F10 presses in-menu.
> 
> Now going back to some happy coding! I will update you once the
> feature is implemented and is ready for testing.

Exciting!

--Tim

Re: [Tuxmath-devel] Multithreading for rescaling title screen and menu items

[Wenyuan G. <guo...@gm...>]

Hi Tim,

Thanks for helping with testing and the detailed remarks!

On Sun, Jul 18, 2010 at 6:53 PM, Tim Holy <ho...@wu...> wrote:
> Hi Wenyuan,

>
> I ran this with --debug-menu and did notice one oddity: if the debug output is
> to be believed, it looks like the "goldstar" and "no_goldstar" files may be
> loading once for each lesson item (i.e., a total of about 57 file-loading
> operations), rather than just once for each unique graphic (a total of 2 file-
> loading operations). If this is true, it might be possible to reduce that 2s
> delay.

I actually observed this behavior in the earlier versions too, and not
restricted to "goldstar" and "no_goldstar" files either! Many sprites
are loaded several times for different instances of them in the menu
tree. But it should not be problem here for the latest version: hard
disk cache for modern OS is smart enough so that only the first read
of each file incurs the mechanical delay. It used to be a problem in
the earlier versions without SVG cache though, because the bottleneck
was CPU bound then, and loading and rescaling the same sprite more
than once add to that delay.

>
> Do you have thoughts on whether we should do something this? I see several
> options:
> 1. Just leave it like it is now
> 2. Display a message, "Changing resolution, please wait..."
> 3. Temporarily progress with the "current" icons, clipping or displaying
> smaller than they should be depending on whether it is an increase or decrease
> in resolution. Once the new icons are ready, start using them.
> 4. Call rotozoom for a quick (?) scaling, and use those until the new ones are
> ready.
> 5. See whether the loading time can be further reduced, perhaps by caching as
> a single big file rather than individual graphics files.
> 6. Use David's suggestion that we (at least optionally) always have both the
> --fullscreen and the --windowed resolution graphics available in memory. One
> thing I only just noticed is that the "--windowed" window is not resizable (I
> had been assuming it was), so that means we can rely on the size of the --
> windowed graphics never changing. In our previous discussion I had been under
> the mistaken impression that this was not an option.

After thinking over these options for a while, I think I will give 6 a
try: in particular, we can load all cached sprites of all resolutions
at the startup, possibly in a separate thread. Later resolution
switches will not incur the hard disk delay this way. If my theory
that the current 2s is mainly hard disk bound is correct, it should
give substantial improvement for all F10 presses in-menu.

Now going back to some happy coding! I will update you once the
feature is implemented and is ready for testing.

Cheers
Wenyuan

Re: [Tuxmath-devel] Multithreading for rescaling title screen and menu items

[Tim H. <ho...@wu...>]

Hi Wenyuan,

On Sunday, July 18, 2010 03:11:12 am Wenyuan Guo wrote:
> Hi all,
> > As promised, I have coded a new feature that enables multithreading
> when it rescales title and menu during an in-game resolution change.
> As before, the game changes to the new resolution (either fullscreen
> or windowed) instantly. But when the user quits to the menu, it is
> usually instantaneous too, provided the worker thread has gotten
> enough time to finish (usually 2s).
> 
> However, resolution change when in-menu still inevitably takes 2s, due
> to the serial nature of the process.
> 
> The git repository has been updated. Please feel free to try it out!

I just did---it's very nice! This work is really making the graphics look far 
more professional.

I ran this with --debug-menu and did notice one oddity: if the debug output is 
to be believed, it looks like the "goldstar" and "no_goldstar" files may be 
loading once for each lesson item (i.e., a total of about 57 file-loading 
operations), rather than just once for each unique graphic (a total of 2 file-
loading operations). If this is true, it might be possible to reduce that 2s 
delay.

Also, as far as I can tell this currently applies only to the menu code. So as 
we transition to using more SVG during game play, the same delay currently 
seen only when in-menu will also appear during the game. And indeed the delay 
will increase because we are loading more files. Presumably we could first load 
the files for whatever "activity" the user is currently engaged with, allow the 
user to continue with what they were doing, and then using your nifty new 
threaded code pre-load the rest of the graphics. So the delay will not 
necessarily need to increase, but there will always be a delay.

Do you have thoughts on whether we should do something this? I see several 
options:
1. Just leave it like it is now
2. Display a message, "Changing resolution, please wait..."
3. Temporarily progress with the "current" icons, clipping or displaying 
smaller than they should be depending on whether it is an increase or decrease 
in resolution. Once the new icons are ready, start using them.
4. Call rotozoom for a quick (?) scaling, and use those until the new ones are 
ready.
5. See whether the loading time can be further reduced, perhaps by caching as 
a single big file rather than individual graphics files.
6. Use David's suggestion that we (at least optionally) always have both the 
--fullscreen and the --windowed resolution graphics available in memory. One 
thing I only just noticed is that the "--windowed" window is not resizable (I 
had been assuming it was), so that means we can rely on the size of the --
windowed graphics never changing. In our previous discussion I had been under 
the mistaken impression that this was not an option.

Best,
--Tim

[Tuxmath-devel] Multithreading for rescaling title screen and menu items

[Wenyuan G. <guo...@gm...>]

Hi all,

As promised, I have coded a new feature that enables multithreading
when it rescales title and menu during an in-game resolution change.
As before, the game changes to the new resolution (either fullscreen
or windowed) instantly. But when the user quits to the menu, it is
usually instantaneous too, provided the worker thread has gotten
enough time to finish (usually 2s).

However, resolution change when in-menu still inevitably takes 2s, due
to the serial nature of the process.

The git repository has been updated. Please feel free to try it out!

Cheers
Wenyuan

Re: [Tuxmath-devel] [Tux4kids-tuxtype-dev] libt4k_common migration status

[David B. <dav...@gm...>]

Hi Brendan,

On Thu, Jul 15, 2010 at 7:29 PM, Brendan Luchen <che...@gm...> wrote:
> All,
>
> More comments from the cookie factory :) I've currently got TuxMath and
> TuxType using (as best I can tell) no local versions of T4K_Functions; in
> other words, every function available in the library is being used where
> directly applicable. In still other words, for every T4K_FunctionName in
> t4k_common.h, all references to FunctionName have been replaced by one to
> T4K_FunctionName via a dumb Perl script.

That's a big step forward, nonetheless.

> At the moment, I'm ironing out some segfaults in TuxType brought on by the
> "dumb" migration; it looks like titlescreen.c wants to load a sprite named
> "easy" (among others) that isn't actually in the repository. Any hints on
> what might be wrong? I'm not really familiar with TuxType's codebase (at
> least, the parts that differ from TuxMath) so I might need some pointers as
> I hack on it.

TuxMath used to load all the images at startup in one big array,
whereas TuxType loaded them as needed for each screen or activity with
the functions from loaders.c.  These functions then got moved into
TuxMath along with other TuxType-derived code like TitleScreen.c.

Anyway, I don't remember offhand a sprite called "easy" - I'll build
from the current git and take a look.

Regards,

David

[Tuxmath-devel] libt4k_common migration status

[Brendan L. <che...@gm...>]

All,

More comments from the cookie factory :) I've currently got TuxMath and
TuxType using (as best I can tell) no local versions of T4K_Functions; in
other words, every function available in the library is being used where
directly applicable. In still other words, for every T4K_FunctionName in
t4k_common.h, all references to FunctionName have been replaced by one to
T4K_FunctionName via a dumb Perl script.

That doesn't mean that everything is migrated, though; more complex
functionality, such as Bolek's menu system, has a different interface that
needs to be found and changed by hand, and might need rewrites of large code
sections or other messy changes. Besides that, I'm sure there are similar
reusable items in TM, TT, or both that we haven't found yet, although that's
really more of an ongoing task.

At the moment, I'm ironing out some segfaults in TuxType brought on by the
"dumb" migration; it looks like titlescreen.c wants to load a sprite named
"easy" (among others) that isn't actually in the repository. Any hints on
what might be wrong? I'm not really familiar with TuxType's codebase (at
least, the parts that differ from TuxMath) so I might need some pointers as
I hack on it.

@Bolek, it looks like TuxMath's menu code is mostly similar to t4k_common's
but there are some small differences. Any chance you can easily recall what
the main changes are? If I could save the trouble of searching, that would
be great. If not, no big deal.

Cheers,
Brendan

Re: [Tuxmath-devel] Midterm Update: libt4k_common

[Tim H. <ho...@wu...>]

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

Re: [Tuxmath-devel] Midterm Update: libt4k_common

[Brendan L. <bm...@ri...>]

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

Re: [Tuxmath-devel] Midterm Update: libt4k_common

[Holger L. <ho...@la...>]

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

Re: [Tuxmath-devel] Midterm Update: libt4k_common

[Tim H. <ho...@wu...>]

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

[Tuxmath-devel] Midterm Update: libt4k_common

[Brendan L. <che...@gm...>]

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

[Tuxmath-devel] GSOC TuxHistory Progress Update

[Jesus M. <fo...@gm...>]

Hi all!

The midterm evaluation is here, and the summer seems very short :p .
In this first stage TuxHistory is growing in his fundamental elements.
If anyone want check the actual state of the game the browsable code
base is on http://git.debian.org/?p=tux4kids/tuxhistory.git and can be
accessed by git using git clone
git+ssh://YOU...@gi.../git/tux4kids/tuxhistory.git
.  The TuxHistory code is based on TuxMath. At a first step I aisled
the general code from the tuxmath specific one, so I could begin with
the concrete work on the game.
On a second step I prepared media files to be included in the game and
in the make process, so the whole  game can use it.
The game data structures are ready, so the core of the game is close
to finished. The XML reading process of the map file is also ready,
the game can now load xml files with map information and load it into
the game data structures, so the game can render this map to screen.

What is not done?
* TuxHistory hasn't at this moment a Campaing reader. I need finish
first the AI functions, and the LUA scripting functionalities. If This
functionalities are ready I will use zlib to load the campaing ziped
files.
* Interactions with the user. The MouseMapper, that identify the tile
to select in screen is not ready, also the A*  and Dijkstra Algorithm
to move the units in screen.

Feel free to use also the wiki http://wiki.debian.org/Games/Tux4Kids

-- 
Jesus Mager
[www.h1n1-al.blogspot.com]

Re: [Tuxmath-devel] Some updates

[Wenyuan G. <guo...@gm...>]

Hi Brendan,

Thanks for the detailed remarks! What you have said about 1-5 are
correct and is exactly what is happening within the latest code.

The "rendering thread" we've been talking about are not relevant to 2
and 4. It is pertaining to 5 only. The purpose of that thread is for
the program to reload all the menu sprites already cached as PNG
concurrently while the user continues to play the game after pressing
F10. We also discussed a bit about multithreading for startup, i.e.
step 3. But our experiments showed that it is not really helpful, as
currently the program locks the user at startup for a minimum of 2s no
matter what, which is shorter or comparable to the time needed to do
the loading of cached PNG sprites.

As far as I know, game sprites are loaded in the same manner as menu
ones. Because the caching mechanism is implemented in the common
loading functions, it should apply to both types.

Cheerz
Wenyuan

On Fri, Jul 9, 2010 at 11:36 PM, Brendan Luchen <bm...@ri...> wrote:
> Hi all,
> Two small remarks. FWIW, with the latest code, I get a ~5-second delay on my
> somewhat-dated laptop when starting the game, and when switching
> resolutions. Second, if a "rendering thread" is an option, why not simply
> invoke it immediately when the game runs? The menu runs responsively in the
> first place, and everything is prepared for future resolution switches.
> I've been just skimming the conversation (been away for the past week) but
> things sound like they're getting complicated. As I understand it, things
> currently work like this:
> 1. TuxMath is distributed with SVG "source" images*
> 2. When first run, the SVGs are loaded, scaled, cached and saved as PNG at
> the user's custom resolution.
> 3. On future runs, the PNG images are found and can be loaded directly.
> 4. The first time resolution is changed to something else**, we again have
> to load, scale, cache and save the images from scratch
> 5. If both "sets" of user-tailored images are available, resolution can
> switch on the fly by loading PNGs from disk
> *This is a naive assumption, since IIRC lots of PNG art still hasn't been
> replaced.
> **Presumably this is because you hit F10, but could also come about from a
> system resolution change.
> I think 2 and 4 both take the same amount of time (~5s) but only need to be
> done once each. 3 and 5 take a palatable ~2s, with the important difference
> that 3 is done on startup, which is fine, but 5 is done in-game, and should
> be immediate from the user's point of view.
> Did I miss anything? And maybe this is a stupid question, but are menu
> sprites handled differently somehow from gameplay sprites?
> Best,
> Brendan

Re: [Tuxmath-devel] Some updates

[Brendan L. <bm...@ri...>]

Hi all,

Two small remarks. FWIW, with the latest code, I get a ~5-second delay on my
somewhat-dated laptop when starting the game, and when switching
resolutions. Second, if a "rendering thread" is an option, why not simply
invoke it immediately when the game runs? The menu runs responsively in the
first place, and everything is prepared for future resolution switches.

I've been just skimming the conversation (been away for the past week) but
things sound like they're getting complicated. As I understand it, things
currently work like this:

1. TuxMath is distributed with SVG "source" images*
2. When first run, the SVGs are loaded, scaled, cached and saved as PNG at
the user's custom resolution.
3. On future runs, the PNG images are found and can be loaded directly.
4. The first time resolution is changed to something else**, we again have
to load, scale, cache and save the images from scratch
5. If both "sets" of user-tailored images are available, resolution can
switch on the fly by loading PNGs from disk

*This is a naive assumption, since IIRC lots of PNG art still hasn't been
replaced.
**Presumably this is because you hit F10, but could also come about from a
system resolution change.

I think 2 and 4 both take the same amount of time (~5s) but only need to be
done once each. 3 and 5 take a palatable ~2s, with the important difference
that 3 is done on startup, which is fine, but 5 is done in-game, and should
be immediate from the user's point of view.

Did I miss anything? And maybe this is a stupid question, but are menu
sprites handled differently somehow from gameplay sprites?

Best,
Brendan

Re: [Tuxmath-devel] Some updates

[Wenyuan G. <guo...@gm...>]

Hi Tim,

I just fixed the bug that caused clipped screen, if the user switches
to windowed mode in-game, and then return to the menu. The cause was
that the program did not re-render title background and menu items
unless the resolution switch happens at the menu itself. The behavior
is correct now.

Specifically, menu re-rendering is not invoked immediately so as not
to break the flow of the game (that is, the switch is instantaneous
in-game as before). It happens only when the user finishes/aborts the
game and is about to return to the menu. This, of course, gives a 2s
delay even with SVG caching. But I think your suggestion is very good:
we can use a second worker thread to do the menu rendering while the
user is still playing the game after the switch; by the time he quits
the game, the menu would be ready and there's no delay. This of course
doesn't apply to the case where the resolution switch happens at the
menu itself, because multithreading or not, we just have to wait for
menu sprites to be ready. I will implement this feature as the next
step.

cheerz
Wenyuan

On Thu, Jul 8, 2010 at 12:24 AM, Tim Holy <ho...@wu...> wrote:
> Hi Wenyuan and David,
>
> On Wednesday, July 07, 2010 09:35:58 am David Bruce wrote:
>> > Pressing F10 will require scaling of all menu sprites to the new
>> > resolution. It used to take like 5s without caching. Now it roughly
>> > takes 1-2s. But you have spotted a bug too! I tested the program and
>> > indeed it is instantaneous when switching in-game. The reason is that
>> > it doesn't scale the menu items. As a result, if you then quit the
>> > game and return to the menu, all sprites will still be as big as in
>> > fullscreen mode, resulted in a clipped screen. I suspect this bug was
>> > present in the older versions too, i.e. before SVG caching was
>> > introduced. I will look into it.
>
> Great! I think fixing bugs is even more important than the speed optimizations
> I'll be discussing below.
>
>> So now, if someone presses F10 when the menus are displayed, what
>> happens?  Are the sprites already scaled and cached at the new
>> resolution, so the program just has to read them from disk? Or do they
>> have to be scaled?  If the latter, it might be a good job for a
>> secondary thread to scale and cache the sprites at the "other"
>> resolution (either 640x480 or fullscreen) once they have been prepared
>> for the current resolution.
>> We also might consider keeping both sets of sprites in memory, at
>> least optionally depending on the amount of system memory.
>
> Given that 640x480 is probably about half the # of pixels along each axis of a
> typical monitor in full-screen, they would take up only 1/4 of the memory; so
> caching both doesn't seem crazy.
>
> That said, if the user resizes the window away from 640x480, then this becomes
> impractical as a strategy. So overall I think it's probably not worth
> it---640x480 now is just a special case and not some default we can fall back
> on.
>
> If seeks, etc, really are the main part of the time for loading pre-rendered
> icons from disk, then perhaps we could consider writing all cached images as
> one big file. Thoughts? This would probably only worth it if it would get it
> down to a fraction of a second.
>
> Alternatively or additionally: because the 5s black screen may be undesirable,
> what about the following as a strategy:
> 1. After a resize, a second thread is launched that either re-loads or re-
> creates the sprites at the appropriate resolution. I think this is firmly
> within Wenyuan's current plans.
> 2. The existing sprites are used to immediately re-render the window (rather
> than having a black screen). As necessary, we clip images, or expand them, or
> plot them smaller than ideal, or whatever to make each fit in the desired space
> (rather than the space given the native size).
> 3. Once "real" sprites are available, re-render the window. For simplicity I
> would say one could just wait until they are all ready, rather than trying to
> update each one as it is prepared. So the "rescale thread," once finished,
> could notify tuxmath that a re-rendering is needed.
>
> If it's a fair amount of code this rendering-twice approach, or if users will
> think it's a bug that the icons look so weird for a few seconds, then perhaps
> it's better to live with the delay when hitting F10. At least with caching it
> is a much shorter delay! Thanks to you, Wenyuan! And we could display a
> message on the screen: "Re-rendering images at new resolution" or something
> like that.
>
> Best,
> --Tim
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>

Re: [Tuxmath-devel] Some updates

[Tim H. <ho...@wu...>]

Hi Wenyuan and David,

On Wednesday, July 07, 2010 09:35:58 am David Bruce wrote:
> > Pressing F10 will require scaling of all menu sprites to the new
> > resolution. It used to take like 5s without caching. Now it roughly
> > takes 1-2s. But you have spotted a bug too! I tested the program and
> > indeed it is instantaneous when switching in-game. The reason is that
> > it doesn't scale the menu items. As a result, if you then quit the
> > game and return to the menu, all sprites will still be as big as in
> > fullscreen mode, resulted in a clipped screen. I suspect this bug was
> > present in the older versions too, i.e. before SVG caching was
> > introduced. I will look into it.

Great! I think fixing bugs is even more important than the speed optimizations 
I'll be discussing below.

> So now, if someone presses F10 when the menus are displayed, what
> happens?  Are the sprites already scaled and cached at the new
> resolution, so the program just has to read them from disk? Or do they
> have to be scaled?  If the latter, it might be a good job for a
> secondary thread to scale and cache the sprites at the "other"
> resolution (either 640x480 or fullscreen) once they have been prepared
> for the current resolution.
> We also might consider keeping both sets of sprites in memory, at
> least optionally depending on the amount of system memory.

Given that 640x480 is probably about half the # of pixels along each axis of a 
typical monitor in full-screen, they would take up only 1/4 of the memory; so 
caching both doesn't seem crazy.

That said, if the user resizes the window away from 640x480, then this becomes 
impractical as a strategy. So overall I think it's probably not worth 
it---640x480 now is just a special case and not some default we can fall back 
on.

If seeks, etc, really are the main part of the time for loading pre-rendered 
icons from disk, then perhaps we could consider writing all cached images as 
one big file. Thoughts? This would probably only worth it if it would get it 
down to a fraction of a second.

Alternatively or additionally: because the 5s black screen may be undesirable, 
what about the following as a strategy:
1. After a resize, a second thread is launched that either re-loads or re-
creates the sprites at the appropriate resolution. I think this is firmly 
within Wenyuan's current plans.
2. The existing sprites are used to immediately re-render the window (rather 
than having a black screen). As necessary, we clip images, or expand them, or 
plot them smaller than ideal, or whatever to make each fit in the desired space 
(rather than the space given the native size).
3. Once "real" sprites are available, re-render the window. For simplicity I 
would say one could just wait until they are all ready, rather than trying to 
update each one as it is prepared. So the "rescale thread," once finished, 
could notify tuxmath that a re-rendering is needed.

If it's a fair amount of code this rendering-twice approach, or if users will 
think it's a bug that the icons look so weird for a few seconds, then perhaps 
it's better to live with the delay when hitting F10. At least with caching it 
is a much shorter delay! Thanks to you, Wenyuan! And we could display a 
message on the screen: "Re-rendering images at new resolution" or something 
like that.

Best,
--Tim

Re: [Tuxmath-devel] Some updates

[David B. <dav...@gm...>]

Hi Wenyuan,

>
> Pressing F10 will require scaling of all menu sprites to the new
> resolution. It used to take like 5s without caching. Now it roughly
> takes 1-2s. But you have spotted a bug too! I tested the program and
> indeed it is instantaneous when switching in-game. The reason is that
> it doesn't scale the menu items. As a result, if you then quit the
> game and return to the menu, all sprites will still be as big as in
> fullscreen mode, resulted in a clipped screen. I suspect this bug was
> present in the older versions too, i.e. before SVG caching was
> introduced. I will look into it.

So now, if someone presses F10 when the menus are displayed, what
happens?  Are the sprites already scaled and cached at the new
resolution, so the program just has to read them from disk? Or do they
have to be scaled?  If the latter, it might be a good job for a
secondary thread to scale and cache the sprites at the "other"
resolution (either 640x480 or fullscreen) once they have been prepared
for the current resolution.

We also might consider keeping both sets of sprites in memory, at
least optionally depending on the amount of system memory.

Regards,

David