Re: [Tuxmath-devel] Migration chugging along nicely

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

Hi Brendan,

After checking through t4kcommon, I found,

1. t4k_menu.c: when user press F10, you need to resize both the title
screen and menu items. Currently "T4K_PrerenderAll" doesn't seem to
resize title screen. You probably need to hook up with the appropriate
function in "titlescreen.c" (or your equivalent in t4kcommon).

2. t4k_loaders.c: you don't seem to have SVG sprites prerender code
yet. Just for your reference, this feature is implemented in
"load_sprite" function of "loaders.c" in tuxmath. Migrating it ought
not to be an issue.

3. I couldn't find your version of "game.c" of tuxmath yet: there was
also a bug I fixed in that file, i.e. when user presses F10, only the
game itself but not the title screen and menu items were resized,
leading to clipped screen when user returned to menu. You might want
to check that one out when converting it to your common lib.

The others seem to be in order. This integration stuff is pretty nasty
job. Please feel free to ask away if you need clarification!

Cheers
Wenyuan

On Thu, Jul 29, 2010 at 6:06 AM, Brendan Luchen <che...@gm...> wrote:
> Hi all,
> After migrating (hopefully) the last few duplicate functions in TuxMath,
> I've jumped into the more messy work. I've been bringing in Wenyuan's
> work--by hand, unfortunately, since I don't see a way to apply diffs from
> one repo into the other, and if there were, it probably wouldn't work
> correctly anyway. Basically, I'm reading through his diffs in TuxMath and
> making appropriate changes in libt4k_common. Wenyuan, would you mind looking
> through my recent commits[0] and making sure I didn't miss something of
> yours?
> As I work through the SVG stuff, I'm adapting things here and there and
> fixing some small issues I come across. The bigger issues, I'm not even
> touching. One such big issue (I don't remember whether I've mentioned
> before) is the fact that T4K_RunMenu handles the event loop and resolution
> switches, but allows the game to affect the run via several callbacks, such
> as drawing and handling events. What's missing is a callback for when
> resolution changes--for now, there's a hack in the event callback that
> checks for a F_10 keypress, assumes (correctly) that the switch is taken
> care of already, and proceeds to recalculate the size and position for Tux
> and other game-specific things.
> I'm thick into testing at this moment. Everything behaves on Ubuntu; On
> Fedora, gdb reports that something is funky with relocation, but is able to
> recover; under MinGW, there are a whole bunch of unpredictable behaviors
> that I believe stem from extern'd variables that are defined in both the
> library and TuxMath--for example, the infamous "SDL_Surface* screen". So
> TuxMath-centric code may accidentally access libt4k_common variables, and
> vice versa. This is particularly hard to debug because AFAIK there's no way
> to tell which module a symbol is coming from, other than educated guesses.
> I'm trying not to be too invasive with my changes in TuxMath, but I fear in
> order to do this "the right way" most of the variables in question will have
> to be removed from TuxMath and the routines that use them largely rewritten.
> More on this story as it develops.
>
> As soon as it's stable, I'd like to do one more testing push before focusing
> on merging. I don't want to recklessly jump into it, but at the same time,
> I'm anxious (even with git) that the longer it waits, the more painful it
> will be.
>
> One thing I'd forgotten is that after the dust has settled, I wanted to put
> some sort of utility in place to automate factoring out functions into the
> library The rationale is that down the road, even if we're no longer sharing
> code directly between TM and TT, it might be too easy to let duplicate
> functionality build up if it's a chore to add new exciting things to
> libt4k_common. Then whenever someone does undertake to do the refactoring,
> things break and there is weeping and gnashing of teeth.
> Phew! Sorry for the long-winded rambling, but it's been a busy few days. If
> any of this is unclear, I'll happily elucidate. I'm just excited to be
> actually coding again :)
>
> [0] http://git.debian.org/?p=tux4kids/t4kcommon.git;a=summary
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>
>