tuxmath-devel — TuxMath developer's mailing list.

Re: [Tuxmath-devel] Prerendered PNG cache for SVG sprites

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

Hi Brendan,

Taking a quick look at the GDB output I noticed this:

#6  0x08069ca0 in do_png_save (fi=0x0, fname=0xbfffd28c
"/usr/local/share/tuxmath/images/comets/cometd--1--1-cache.png",
surf=0x84c8970)
    at /home/cheezmeister/code/c/tuxmath/src/loaders.c:788

It seems the problem is: the argument "fi" passed to do_png_save is
supposed to be an opened file (FILE*) where the surface is to be
saved. It is initialized with an earlier call of "fopen" requesting
write access. Since it is NULL, it is clear that the "fopen" failed.
Do you have write access to your tuxmath install directory (in my
case, /usr/local/share/tuxmath) and whether there is enough disk
space? The caching PNG files will be written to the same directories
where the original SVG sprites are located.

Wenyuan

On Thu, Jun 10, 2010 at 11:40 PM, Brendan Luchen <bm...@ri...> wrote:
>
> Wenyuan,
>
> > Actually, only SVG based sprites are cached in PNGs. If the sprites are
> > loaded from PNGs, they are not affected at all. Cheers!
>
> Well, I meant in the event a cached PNG version is found and loaded,
> it would immediately be saved out again, but I'm just eyeballing the
> source code. In any case, you said the performance is good; that's
> what matters :)
>
> I'm getting a segfault when I attempt to run tuxmath, and I can't nail
> it down. The fault is somewhere inside our call to png_write_info(),
> but it looks like a valid call, or at least not passing in any NULLs.
> I'm attaching my GDB session with 'tuxmath -w' and the program output
> from 'tuxmath --debug-all' in case it makes any sense to you :)
>
> @Tim: Wow! Wherever you are, it sounds fun. I guess, welcome to the
> mile-high club of free software (?)
>
> -Brendan

[Tuxmath-devel] Including libxml2-devel library

[Vikas S. <vik...@gm...>]

Hi
I have a program parse_xmlLesson.c which parses XML files which I want to
include in Tuxmath source.
But this requires libxml2-devel library and compiles by following -

$gcc -g -Wall `xml2-config --cflags --libs` `gnome-config --cflags --libs
gnome gnomeui xml` -o parse_xmlLesson parse_xmlLesson.c

How to compile Tuxmath source, so that this library does not produce an
error ?


-- 
Vikas Singh

Re: [Tuxmath-devel] Prerendered PNG cache for SVG sprites

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

Wenyuan,

> Actually, only SVG based sprites are cached in PNGs. If the sprites are
> loaded from PNGs, they are not affected at all. Cheers!

Well, I meant in the event a cached PNG version is found and loaded,
it would immediately be saved out again, but I'm just eyeballing the
source code. In any case, you said the performance is good; that's
what matters :)

I'm getting a segfault when I attempt to run tuxmath, and I can't nail
it down. The fault is somewhere inside our call to png_write_info(),
but it looks like a valid call, or at least not passing in any NULLs.
I'm attaching my GDB session with 'tuxmath -w' and the program output
from 'tuxmath --debug-all' in case it makes any sense to you :)

@Tim: Wow! Wherever you are, it sounds fun. I guess, welcome to the
mile-high club of free software (?)

-Brendan

Re: [Tuxmath-devel] Prerendered PNG cache for SVG sprites

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

Hi Wenyuan,

That's great! I really look forward to checking it out, when I return to more 
convenient internet access in late June. (This was written from 2.4km 
elevation.)

Best,
--Tim


On Wednesday, June 09, 2010 02:19:19 am Wenyuan Guo wrote:
> Hi all,
> 
> I have updated our Git repository, master branch with an improved version
> of SVG sprite loader. It caches prerendered PNG versions of SVG sprites on
> harddisk, and I'm happy to report that it greatly improves the initial
> loading time as well as delay in switching between fullscreen and windowed
> mode in-game! No new cache files will be generated as long as the user
> doesn't change the resolution of his/her desktop. Please try it out if you
> have time!
> 
> The modification is entirely transparent to other parts of the program and
> the function signatures and usages are completely unchanged.
> 
> One difficulty I had was I had intended to use BMP files as cache, since
> SDL has native "save" functions into that format. But it turns out that
> SDL's saveBMP doesn't support alpha transparency, causing scrambled
> sprites. After a good amount of googling, to my surprise, tuxpaint has a
> function to save SDL surfaces into PNG format! So in my implementation I
> have "borrowed" that function (after modifying it a bit to support alpha
> channel) and
> everything's fine :D! Maybe that part can eventually to be factored out in
> the common?
> 
> Cheers
> Wenyuan

Re: [Tuxmath-devel] Prerendered PNG cache for SVG sprites

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

Hi Brendan,

Actually, only SVG based sprites are cached in PNGs. If the sprites are
loaded from PNGs, they are not affected at all. Cheers!

Wenyuan

On Thu, Jun 10, 2010 at 1:04 PM, Brendan Luchen <bm...@ri...> wrote:

> Hey Wenyuan,
>
> > I have updated our Git repository, master branch with an improved version
> of
> > SVG sprite loader. It caches prerendered PNG versions of SVG sprites on
> > harddisk, and I'm happy to report that it greatly improves the initial
> > loading time as well as delay in switching between fullscreen and
> windowed
> > mode in-game!
>
> Cool! It looks like the image is always saved out to PNG, even if it
> was just loaded from the same PNG file--is that correct? Might want to
> do the save only if we just loaded from SVG.
>
> > to my surprise, tuxpaint has a function to save
> > SDL surfaces into PNG format! So in my implementation I have "borrowed"
> that
> > function (after modifying it a bit to support alpha channel) and
> > everything's fine :D! Maybe that part can eventually to be factored out
> in
> > the common?
>
> Yes, I think that would be a good idea.
>
> Cheers,
> Brendan
>

Re: [Tuxmath-devel] Prerendered PNG cache for SVG sprites

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

Hey Wenyuan,

> I have updated our Git repository, master branch with an improved version of
> SVG sprite loader. It caches prerendered PNG versions of SVG sprites on
> harddisk, and I'm happy to report that it greatly improves the initial
> loading time as well as delay in switching between fullscreen and windowed
> mode in-game!

Cool! It looks like the image is always saved out to PNG, even if it
was just loaded from the same PNG file--is that correct? Might want to
do the save only if we just loaded from SVG.

> to my surprise, tuxpaint has a function to save
> SDL surfaces into PNG format! So in my implementation I have "borrowed" that
> function (after modifying it a bit to support alpha channel) and
> everything's fine :D! Maybe that part can eventually to be factored out in
> the common?

Yes, I think that would be a good idea.

Cheers,
Brendan

[Tuxmath-devel] Prerendered PNG cache for SVG sprites

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

Hi all,

I have updated our Git repository, master branch with an improved version of
SVG sprite loader. It caches prerendered PNG versions of SVG sprites on
harddisk, and I'm happy to report that it greatly improves the initial
loading time as well as delay in switching between fullscreen and windowed
mode in-game! No new cache files will be generated as long as the user
doesn't change the resolution of his/her desktop. Please try it out if you
have time!

The modification is entirely transparent to other parts of the program and
the function signatures and usages are completely unchanged.

One difficulty I had was I had intended to use BMP files as cache, since SDL
has native "save" functions into that format. But it turns out that SDL's
saveBMP doesn't support alpha transparency, causing scrambled sprites. After
a good amount of googling, to my surprise, tuxpaint has a function to save
SDL surfaces into PNG format! So in my implementation I have "borrowed" that
function (after modifying it a bit to support alpha channel) and
everything's fine :D! Maybe that part can eventually to be factored out in
the common?

Cheers
Wenyuan

Re: [Tuxmath-devel] TuxMath + libt4kcommon maiden linkage

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

Hi David,

>> So, if we are going to be changing the names, I vote for
>> "t4k_common.h".
>
> I just went ahead and changed the names in that fashion and pushed it
> to git.  From a quick look at /usr/include on this machine, I saw 15
> files with underscores in the names ("foo_bar.h") and only 2 with
> hyphens ("foo-bar.h"), so I think "t4k_common.h" would be more
> conventional.

Sounds good! Pulled without a hitch.

> Using CMake, I still run into the error about missing "T4K_Sugar".

D'oh! I knew it. It's pushed now. This is the same module that's in
the Tuxmath tree. Right then, I'll go play with the autotools build.

Best,
Brendan

Re: [Tuxmath-devel] TuxMath + libt4kcommon maiden linkage

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

Hi Brendan,

> So, if we are going to be changing the names, I vote for
> "t4k_common.h".

I just went ahead and changed the names in that fashion and pushed it
to git.  From a quick look at /usr/include on this machine, I saw 15
files with underscores in the names ("foo_bar.h") and only 2 with
hyphens ("foo-bar.h"), so I think "t4k_common.h" would be more
conventional.

Using the "commonification" branch of tuxmath in git, now autotools
works fine - just do the usual "autoreconf -i; ./configure; make; sudo
make install" for t4kcommon, then the same for tuxmath, and the
program builds, links, and runs successfully using t4kcommon as a
shared lib.

(Note that autoreconf now complains about my most recent configure.ac
syntax, but it works fine if you just run it a second time.  Will
investigate).

Using CMake, I still run into the error about missing "T4K_Sugar".

Best,

David

Re: [Tuxmath-devel] TuxMath + libt4kcommon maiden linkage

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

Hi Brendan,

On Tue, Jun 8, 2010 at 12:12 AM, Brendan Luchen <che...@gm...> wrote:
> Hi all,
>
> It's been a great day of hacking for a change, and libt4kcommon is
> looking good. I spent today getting it to link, but only with TuxMath,
> using CMake, under Linux (and technically MinGW too, but that's an act
> of masochism as usual). More delightful combinations to come with
> TuxType, autotools and OSX...as soon as I wrap my head around libtool,
> that is.

With CMake, I'm running into an error with the latest t4kcommon from git:

dbruce@dbruce-laptop:/usr/local/src/git/t4kcommon/build_cm$ cmake ..--
The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for include files CMAKE_HAVE_PTHREAD_H
-- Looking for include files CMAKE_HAVE_PTHREAD_H - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- checking for module 'librsvg-2.0'
--   found librsvg-2.0, version 2.26.2
-- checking for module 'cairo'
--   found cairo, version 1.8.10
SDL_Pango:  YES
CMake Error at src/CMakeLists.txt:6 (include):
  include could not find load file:

    T4K_Sugar


CMake Error at src/CMakeLists.txt:30 (t4k_include_definition):
  Unknown CMake command "t4k_include_definition".


-- Configuring incomplete, errors occurred!



Are you sure you have pushed everything from your machine back into git?


> Some remarks:
> The T4K_FuncName() prefix - These have been added to all functions
> that have so far made it into the library.

I think it is a good idea, at least for the transition period - it
makes it easy to grep for places where the new functions are being

> Tux4Kids-common vs. T4k-common vs. t4kcommon - a relatively minor
> issue, but one that's causing a few problems. For example, the CMake
> installation step currently takes t4k-common.h and renames it to
> t4kcommon.h when copied over.

Yes, the autotools build fails because tuxmath is looking for
t4kcommon.h, but t4k-common.h is what gets installed.  I think we
could use the "t4kcommon.h" convention, or possibly "t4k_common.h"
(which I think is a bit easier to read).  Automake doesn't allow
hyphens within the makefile variables for names of programs or
libraries, although it has no problems with file names with hyphens.
So, if we are going to be changing the names, I vote for
"t4k_common.h".

Cheers,

David

[Tuxmath-devel] TuxMath + libt4kcommon maiden linkage

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

Hi all,

It's been a great day of hacking for a change, and libt4kcommon is
looking good. I spent today getting it to link, but only with TuxMath,
using CMake, under Linux (and technically MinGW too, but that's an act
of masochism as usual). More delightful combinations to come with
TuxType, autotools and OSX...as soon as I wrap my head around libtool,
that is.

Here's how to try out linking with t4kcommon:
git clone git://git.debian.org/git/tux4kids/t4kcommon.git && cd t4kcommon
mkdir build && cd build
cmake ..
make
sudo make install

For TuxMath
git clone git://git.debian.org/git/tux4kids/tuxmath.git && cd t4kcommon
git checkout commonification
mkdir build && cd build
cmake .. #ensure libt4kcommon is found - should show up in config.h
make
sudo make install
tuxmath

Bam! libt4kcommon linkage, like magic. You can't exactly tell, because
the game runs just as normal, but it's there, using the shiny new
T4K_DrawButton() instead of DrawButton(). If you have any doubt, try
running the game after removing the library, and it should complain.

Some remarks:
The T4K_FuncName() prefix - These have been added to all functions
that have so far made it into the library. I was a bit hesitant to do
this mainly because it's a *lot* of renaming, but upon reflection, I
think using them will not only be "good form," but also make the
eventual transition period (where the functionality in question will
be split between TuxMath, TuxType and libt4kcommon) a little less
nightmarish: fewer name clashes, at the very least. Does anyone have
strong feelings to the contrary?

Tux4Kids-common vs. T4k-common vs. t4kcommon - a relatively minor
issue, but one that's causing a few problems. For example, the CMake
installation step currently takes t4k-common.h and renames it to
t4kcommon.h when copied over. It seems to me we should stick with the
first and third options--the first for things like titles and package
naming, the third for files and shorthand. Not sure what kind of
standards are in place here, or whether it matters at all, besides
aesthetics. Any strong feelings either way?

Build stability - hahaha! It's very flaky right now, both in terms of
building libt4kcommon and linking to it from TuxMath. I have the
feeling that builds on other environments will be still quite
temperamental. Hopefully, by following the steps above, folks can help
uncover a few things I've overlooked. (If not, though, I won't
complain!) Thanks, and apologies for the long message.

Best,
Brendan

Re: [Tuxmath-devel] Problem with downloading Tux Math and Tux Typing

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

Hi,

On Mon, Jun 7, 2010 at 7:38 PM, Bill Kendrick <nb...@so...> wrote:
>
> I'm guessing Marius's software is blocking access, and not letting him
> ignore the warning (as one would do in a web browser like Firefox or
> Konqueror, when a certificate warning comes up).
>
> I wonder if there's an alternate location the files are hosted in that
> we can direct him to...?

Oh yes, I also post the builds at sourceforge.net, which doesn't have
that problem.  The tuxmath build (1.7.2) is the same as that on
Alioth.  SF.net's tuxtype build is 1.8.0, which is one version behind
the current 1.8.1, but the differences aren't that great.  I'll put
the current one up on SF.net tonight anyway.

Regards,

David Bruce

Re: [Tuxmath-devel] Problem with downloading Tux Math and Tux Typing

[Bill K. <nb...@so...>]

I'm guessing Marius's software is blocking access, and not letting him
ignore the warning (as one would do in a web browser like Firefox or
Konqueror, when a certificate warning comes up).

I wonder if there's an alternate location the files are hosted in that
we can direct him to...?

-bill!

On Mon, Jun 07, 2010 at 07:35:41PM -0500, David Bruce wrote:
> Hello Marius,
> 
> >>    I tried downloading the two programs but my security programs are blocking
> >>    both download sites.
> >>
> >>    The block is due to "an invalid security certificate".
> >>
> >>    I use: Avira Premium, Windows Defender and Windows Firewall (Vista SP2)
> 
> This occurs because Alioth uses a self-signed ssl certificate.  I did
> some googling, and apparently there are three certificates involved
> and they get presented in the wrong order, or some such thing.  I
> believe the Alioth admins are aware of this issue, and hopefully it
> will get resolved at some point.  However, I know it has been this way
> for at least two years.
<snip>

Re: [Tuxmath-devel] Problem with downloading Tux Math and Tux Typing

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

Hello Marius,

>>    I tried downloading the two programs but my security programs are blocking
>>    both download sites.
>>
>>    The block is due to "an invalid security certificate".
>>
>>    I use: Avira Premium, Windows Defender and Windows Firewall (Vista SP2)

This occurs because Alioth uses a self-signed ssl certificate.  I did
some googling, and apparently there are three certificates involved
and they get presented in the wrong order, or some such thing.  I
believe the Alioth admins are aware of this issue, and hopefully it
will get resolved at some point.  However, I know it has been this way
for at least two years.

Anyway, if you have the option, it is OK to just ignore the warnings
and download the programs anyway.  I personally cross-built all the
windows builds on a Linux box, and can assure you they contain no
malware.

I wouldn't do online banking through a site that uses a self-signed
certificate, but I can't quite see why it should be a big deal for
something like tux4kids.  I guess conceivably some attacker could
maliciously redirect folks to a bogus build of tuxmath that has a
keylogger or something, but that seems really far-fetched.  Also, you
must trust us in the first place if you want to use our software - a
recognized certificate doesn't prove anything about whether the
software itself is malicious.

I'd sure like to see this resolved, because I bet lots of folks have
been scared away from our games by these warnings.

David Bruce

Re: [Tuxmath-devel] Hi

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

Hi Batkhuu,

On Mon, Jun 7, 2010 at 12:53 AM, Batkhuu Ichinkhorloo
<bat...@ya...> wrote:
> Hi
> Dear David Bruce.
> I'm translating mongolian mn.po and mn.mo of TuxMath. I'm attaching these files.

Great - I have added your translation to tuxmath's git repository.

>Now the TuxMath activity used the new translations mn.po for XO. Good work. But not >working on Windows. So  I’m don’t know, what to greate Win32 Application. How to compiling >from debian C source project to .exe for Win32 Application.

All the Win32 releases have been cross-built on a Debian host with the
mingw compiler tools.  The old cross-build environment was very
laborious to set up, although the build itself was very easy once
everything was set.

We are switching to the mingw-cross-env project
(http://nongnu.org/mingw-cross-env) to make Win32 builds for tuxmath
and tuxtype.  It is almost completely automated, and the most recent
source releases for tuxmath (1.8.0) and tuxtype (1.8.1) have complete
instructions.

The new builds do have some remaining problems, however:
1. Even though the builds succeed with SDL_Pango enabled, the
resultant programs don't actually display any text.  I don't know if
any other project is using SDL_Pango from mingw-cross-env yet.  So,
for now we still use SDL_ttf rather than SDL_Pango.
2. Tuxmath now optionally uses SDL_net, but the crossbuild fails
unless SDL_net is disabled.  This probably only requires a better test
in our configure.ac.
3. If I build tuxmath without either SDL_net or SDL_Pango, I get a
working build, but it freezes most of the time when the high score
name entry is displayed.

For these reasons, we don't yet have a public release of tuxmath-1.8.0
for Windows.  Hopefully we can change that soon.

Regards,

David Bruce

[Tuxmath-devel] Parsing XML file

[Vikas S. <vik...@gm...>]

Hello

What are the different ways can a XML file be parsed other than the method
by which they are
in Tuxtype ?

Is it possible with the help of a library availble for C or any other
method ?


-- 
Regards ,
Vikas Singh

Re: [Tuxmath-devel] Similarity in code of Tuxmath/Tuxtype

[Vikas S. <vik...@gm...>]

Hello

On Sat, May 29, 2010 at 7:42 AM, Brendan Luchen <bm...@ri...> wrote:
>
>
> By conflicts, do you mean name clashes, or duplication, or something
> else? I'm thinking of adding a prefix to all routines, e.g.
> T4K_CheckFile() to avoid naming conflicts until later in the summer,
> when it's time to permanently switch over TuxMath and TuxType to use
> the library instead of internal implementations. Then, it will be a
> choice between adding the T4K_ prefix to all function calls (ouch) or
> using macros to patch things up. But that's mostly my problem.
>
> My problem was to consider libt4k-common for my code or not.
So , as David pointed out that it would be better to go without considering
libt4k-admin
I also decide to go with that.


> >If I Recall Correctly, Vikas, you're working on the admin tool?


My work will aslo involves changes in Tuxmath and Tuxtype.


> If so then I expect there will not be *too much* overlap between what
> you're
> writing and what is already in libt4kcommon. I will try to keep an eye
> on your stuff, and when it is almost complete, I think we should then
> move it into the library.


Yes, that will be fine.



-- 
Regards ,
Vikas Singh

Re: [Tuxmath-devel] Similarity in code of Tuxmath/Tuxtype

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

Vikas,

There are a few (not too many) file-operations routines in t4kcommon, e.g.

int CheckFile(const char* file)
char* find_file(const char* base_name)
SDL_Surface* LoadImage(const char* file_name, int mode)

By conflicts, do you mean name clashes, or duplication, or something
else? I'm thinking of adding a prefix to all routines, e.g.
T4K_CheckFile() to avoid naming conflicts until later in the summer,
when it's time to permanently switch over TuxMath and TuxType to use
the library instead of internal implementations. Then, it will be a
choice between adding the T4K_ prefix to all function calls (ouch) or
using macros to patch things up. But that's mostly my problem.

If I Recall Correctly, Vikas, you're working on the admin tool? If so
then I expect there will not be *too much* overlap between what you're
writing and what is already in libt4kcommon. I will try to keep an eye
on your stuff, and when it is almost complete, I think we should then
move it into the library. You might have more "fun" with syncing your
code between TuxMath and TuxType while you're developing it. Any
ideas?

Best,
Brendan

Re: [Tuxmath-devel] Factoroids game customization and reporting

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

I like all three ideas.

The collision detection might work best in the form of a "cloaking" power-up.

Custom key-mapping is very desirable if the control scheme gets much
more complicated, and nice to have in general. Sounds like a good
feature for libt4kcommon!

Starting with 2 and working up might actually be better educationally,
since, practically speaking, it's more useful to know your
multiples/powers of 2 and 3 than, say, 13 or 17. Anyone know 17^4
offhand ;)?

<tangent>
I had another idea for a factoring game that I'll throw out here
before I forget it--each number is represented as a connected set of
squares, sort of like Tetris blocks. For example 6 would look like
[6|6|6|6|6|6]

The player would break down the blocks by clicking on the boundaries
between blocks (the '|' here) until it's separated into a set of
same-size sections. I feel this would visually drive home the concept
behind factorization, which is something that many kids have trouble
grasping. The idea might be extended to square numbers (represented by
squares, of course, with similar mechanics for break-down), and
perhaps more exotic things like triangular numbers.

</tangent>
Thoughts?

-Brendan

2010/5/28 David Bruce <dav...@gm...>:
> Hi,
>
>>
>> My idea is to make it possible to turn off collision detection,
>> so that kids concentrate more on math than on steering the
>> spaceship.
>
> Sounds great!
>
> How about this? I was just chatting with my sixth-grade daughter, and
> we came up with the idea of adding one prime factor with each level:
>
> e.g. - on the first level, Tux only has the "2 Gun", and all the rocks
> are powers of 2.
>       - for the second level, Tux additionally has the "3 Gun", and
> the rocks are 2^n * 3^m.
> and so forth for a few more primes.
>
> (we were again thinking about FPS-type games, where a big part of the
> reward for progress is the unlocking of additional "weapons").
>
> I think that would make it quite a bit more educational, and fun.
>
> Cheers,
>
> David
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>

Re: [Tuxmath-devel] Factoroids game customization and reporting

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

Hi,

>
> My idea is to make it possible to turn off collision detection,
> so that kids concentrate more on math than on steering the
> spaceship.

Sounds great!

How about this? I was just chatting with my sixth-grade daughter, and
we came up with the idea of adding one prime factor with each level:

e.g. - on the first level, Tux only has the "2 Gun", and all the rocks
are powers of 2.
       - for the second level, Tux additionally has the "3 Gun", and
the rocks are 2^n * 3^m.
and so forth for a few more primes.

(we were again thinking about FPS-type games, where a big part of the
reward for progress is the unlocking of additional "weapons").

I think that would make it quite a bit more educational, and fun.

Cheers,

David

Re: [Tuxmath-devel] Factoroids game customization and reporting

[Michał Ś. <tux...@sw...>]

---- On Fri, 28 May 2010 22:01:51 +0200 David Bruce <dav...@gm...> wrote ---- 

>Hi, 
> 
>I've also been thinking of tinkering with Factoroids. At the last 
>GSoC Mentor Summit, I had a chance to chat with Sam Lantinga (the 
>creator of SDL) for a while. Sam loved the idea of Factoroids and had 
>a suggestion for an enhancement that sounds really cool - instead of 
>having to type in the "factor" separately before each shot, make each 
>small prime factor a different "weapon" a la Quake. So, if the player 
>enters "2", Tux loads up the "2 Gun" at the console, and similarly for 
>3, 5, 7, 11, and however many primes we want to support. We could 
>modify the "laser" function to show the tux ship shooting a "2" 
>numeral at the asteroid, and perhaps even flash the corresponding 
>equation (e.g. " 12 = 2 x 6") for correct hits. 

Haha cool!

My idea is to make it possible to turn off collision detection, 
so that kids concentrate more on math than on steering the 
spaceship. 

Regards,
Michał

Re: [Tuxmath-devel] Factoroids game customization and reporting

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

Hi,

I've also been thinking of tinkering with Factoroids.  At the last
GSoC Mentor Summit, I had a chance to chat with Sam Lantinga (the
creator of SDL) for a while. Sam loved the idea of Factoroids and had
a suggestion for an enhancement that sounds really cool - instead of
having to type in the "factor" separately before each shot, make each
small prime factor a different "weapon" a la Quake.  So, if the player
enters "2", Tux loads up the "2 Gun" at the console, and similarly for
3, 5, 7, 11, and however many primes we want to support.  We could
modify the "laser" function to show the tux ship shooting a "2"
numeral at the asteroid, and perhaps even flash the corresponding
equation (e.g. " 12 = 2 x 6") for correct hits.

I think kids would enjoy something like that.  It would also make the
game a little less awkward to play - as it stands now, it is a little
hard to jump back and forth between the arrow keys and the number
keys.  As a further mod, we perhaps might want to support custom key
mapping for anyone who might conceivably take the game seriously.

Just a few thoughts -

David

Re: [Tuxmath-devel] 1.8.0 Cross compiling trouble

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

Hi,

On Fri, May 28, 2010 at 2:12 AM, Jesus Mager <fo...@gm...> wrote:
> Hi all!
>
> Thanks brendan and david! it seems that the the main() must be in
> source file named as the executable/unix name. (I suppose this is
> obvious for a good autotool guy??) (Is this conclusion true??)

No, I don't think that is true.  In fact, tuxtype has  main() in
main.c, so I am sure that is not a requirement.  You must have fixed
something else.  At any rate, I'm glad you got the build working.

David

Re: [Tuxmath-devel] Tuxmath sprite loading issues

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

Pushed to the central repository master branch!

Cheers
Wenyuan

On Thu, May 27, 2010 at 8:44 PM, David Bruce <dav...@gm...>wrote:

> Hi Wenyuan,
>
>
> > I propose to solve the problem by associating one font size for each
> level
> > of menu. This way the algorithm computing font size for a particular menu
> > will consistently return the same result even after more menus are loaded
> in
> > later phases, a more reasonable behavior I think. I have done the
> > modification and the patch file is attached (it only touches menu.c).
> >
> > What do you think about this solution?
>
> Sounds great. Can you just commit it and push it into git?
>
> David
>

Re: [Tuxmath-devel] 1.8.0 Cross compiling trouble

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

Hi all!

Thanks brendan and david! it seems that the the main() must be in
source file named as the executable/unix name. (I suppose this is
obvious for a good autotool guy??) (Is this conclusion true??) Anyway,
in TuxHistory I got a cool automated make, and in my school project is
worked it around using the TuxHistory executable name... But I still
can understand this completely.

Again; thanks!

2010/5/27 Brendan Luchen <che...@gm...>:
> Jesus,
>
> What I meant was that, usually you give the linker some object files,
> like "factoroids.o", but I don't see any in the command you
> posted--just a whole bunch of libraries. Could that be why no main
> function is found?
>
> Best,
> Brendan
>
> On Thu, May 27, 2010 at 1:31 AM, Jesus Mager <fo...@gm...> wrote:
>> Hi Brendan
>>
>> It is a asteroid game (freeasteroids) using my code in tuxmath (and
>> the whole TuxMath)  that id did for school project. On the way I
>> deleted all files that i didnt need, as in TuxHistory. The every
>> extraneous thing is: TuxHistory branch are cross compiling well.
>> (Freeasteroids/TuxHistory difference is mainly the inclusion of
>> factoroids.c/h)
>>
>> If you want (and of course have some time and interest) you can take a look on:
>> http://sourceforge.net/projects/freeasteroids/develop
>> or via svn:
>> svn co https://freeasteroids.svn.sourceforge.net/svnroot/freeasteroids
>> freeasteroids
>>
>> And of course (very initial) TuxHistory sources!
>> http://git.debian.org/?p=tux4kids/tuxhistory.git
>> git clone git+ssh://YOU...@gi.../git/tux4kids/tuxhistory.git
>>
>> Chears!
>>
>> 2010/5/26 Brendan Luchen <che...@gm...>:
>>> Hey Jesus,
>>>
>>> It looks like the error is with SDLmain, not SDL itself....
>>> I see -lSDLmain is in there several times, not sure what that means....
>>> I don't see any object files, what sources are being compiled?
>>>
>>> -Brendan
>>>
>>> On Thu, May 27, 2010 at 12:19 AM, Jesus Mager <fo...@gm...> wrote:
>>>> Hi all,
>>>>
>>>> I am setting up the cross compiling environment with
>>>> mingw32-cross-env, I used the tuxmath INSTALL instructions, but it
>>>> seems I did someting wrong, or may me a am missing something...
>>>>
>>>> My mingw instalation is in /opt/mingw-cross-env from mercurial
>>>> repository, like the default path in buildw32/cross-configuration,
>>>> with the following command: make sdl sdl_mixer sdl_image sdl_net
>>>> sdl_ttf sdl_pango librsvg. and the respective ./tmwin.sh on a clean
>>>> copy.
>>>>
>>>> But I get a linking error to the libsdl. But in configure it seems all
>>>> OK, any idea?
>>>>
>>>> ./cross-configure.sh --host=i686-pc-mingw32
>>>> checking build system type... x86_64-pc-linux-gnu
>>>> checking host system type... i686-pc-mingw32
>>>> checking target system type... i686-pc-mingw32
>>>> ....
>>>> checking for SDL... yes
>>>> checking for SDL_IMAGE... yes
>>>> checking for SDL_MIXER... yes
>>>> checking for TTF_Init in -lSDL_ttf... yes
>>>> checking for RSVG... yes
>>>> checking for CAIRO... yes
>>>>
>>>> make
>>>> ....
>>>>
>>>> i686-pc-mingw32-gcc -Wall -g -DDATA_PREFIX=\"data\" -DDEBUG -DSOUND -g
>>>> -O2 -D_GNU_SOURCE=1 -Dmain=SDL_main
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL
>>>> -D_GNU_SOURCE=1 -Dmain=SDL_main
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14
>>>> -D_GNU_SOURCE=1 -Dmain=SDL_main
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include   -mms-bitfields
>>>> -DLIBXML_STATIC
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/librsvg-2
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/glib-2.0
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/lib/glib-2.0/include
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/gtk-2.0
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/cairo
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libgsf-1
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pango-1.0
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libcroco-0.6
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pixman-1
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/freetype2
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libxml2
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/cairo
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pixman-1
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/freetype2
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include
>>>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14
>>>> -D__GW32__  -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -o
>>>> FreeAsteroids.exe
>>>> /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libintl.a
>>>> /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libiconv.a
>>>> ../linebreak/liblinebreak.a -lm -lSDL_ttf -lfreetype  -mwindows
>>>> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lmingw32 -lSDLmain
>>>> -lSDL -liconv -lm -luser32 -lgdi32 -lwinmm -ldxguid   -mwindows
>>>> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lSDL_image -ltiff
>>>> -ljpeg -lmingw32 -lSDLmain -lSDL -liconv -lm -luser32 -lgdi32 -lwinmm
>>>> -ldxguid -lpng14 -lz   -mwindows
>>>> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lSDL_mixer -lmikmod
>>>> -lpthread -lsmpeg -lstdc++ -lmingw32 -lSDLmain -lSDL -liconv -luser32
>>>> -lgdi32 -lwinmm -ldxguid -lvorbisfile -lvorbis -lm -logg
>>>> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lrsvg-2
>>>> -lgdk_pixbuf-2.0 -ltiff -lpng -ljasper -ljpeg -lgsf-1 -lbz2
>>>> -lpangocairo-1.0 -lcroco-0.6 -lgio-2.0 -lcairo -lmsimg32
>>>> -lpangoft2-1.0 -lpangowin32-1.0 -lgdi32 -lpixman-1 -lpng14
>>>> -lfontconfig -lexpat -lfreetype -lpango-1.0 -lm -lgobject-2.0
>>>> -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lole32 -lshlwapi -lpcre -lintl
>>>> -lxml2 -lz -liconv -lws2_32
>>>> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lcairo -lmsimg32
>>>> -lgdi32 -lm -lpixman-1 -lfontconfig -lexpat -lfreetype -liconv -lpng14
>>>> -lz   -luuid -lole32 -lwsock32 -mwindows
>>>> /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libSDLmain.a(SDL_win32_main.o):
>>>> In function `console_main':
>>>> /opt/mingw-cross-env/tmp-sdl/SDL-1.2.14/./src/main/win32/SDL_win32_main.c:315:
>>>> undefined reference to `_SDL_main'
>>>> collect2: ld returned 1 exit status
>>>>
>>>>
>>>> --
>>>> Jesus Mager
>>>> [www.h1n1-al.blogspot.com]
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Tuxmath-devel mailing list
>>>> Tux...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>>>>
>>>
>>
>>
>>
>> --
>> Jesus Mager
>> [www.h1n1-al.blogspot.com]
>>
>



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