[Kde-games-devel] Bugs (showstoppers?) in KGoldrunner

[Ian Wadham]

On Thu, 29 Nov 2007 08:25 pm, Luciano Montanaro wrote:
> Il Thursday 29 November 2007 05:37:41 Ian Wadham ha scritto:
> Here is the console log of a session of KGoldrunner:
> --------------
Any chance of a backtrace, Luciano?

> <snip> 0 msec.  New
> Theme - "/usr/lib/kde4/share/kde4/apps/kgoldrunner/themes/kgr_geek.desktop"
> kgoldrunner(7631) KGrTheme::load: New
> Theme - "/usr/lib/kde4/share/kde4/apps/kgoldrunner/themes/kgr_geek.desktop"
> 250 msec.  Finish loading new theme.
> KGrCanvas::resizeEvent: 1 QSize(640,507)
> Resize pending? true
>
In this case, the resizeEvent returns immediately and does nothing.  KGr waits
for further events, supposedly a second resize event, when QMainWindow
and KXMLGuiWhatever decide what size to make the central widget.

> ASSERT: "m_tileset" in
> file /build/buildd/kdegames-kde4-3.96.0/kgoldrunner/src/kgrplayfield.cpp,
> line 39
> KCrash: crashing... crashRecursionCounter = 2
>
So how does KGr ever get into this Q_ASSERT?  Some other event
must trigger that code before the second resize happens, maybe?

> Now the ASSERT up there is due to a Q_ASSERT macro I added there to trace
> the problem. It's just a warning.
> But m_tileset is not the only unset variable; at least m_tileSprites is not
> initialised, and the crash is really due to Qt trying to access
> non-existent pixmaps a few lines below. However, if I workaround that
> problem too, the program still crashes.
>
Naturellement.  The tile set and sprites are not supposed to be set until
QMainWindow tells KGr what size to make the play area, from which it
can calculate the required size of the tile and runner pixmaps.

I think, maybe, the libraries have changed at the last minute and there
is now no second resize event and so KGr now goes down some
uninitialised track triggered by some other event (what does the
backtrace show?).  If this hypothesis is correct, other games that used
the "pending" trick to avoid rendering everything twice would also be
affected.  And *nobody* would be able to play KGoldrunner in the current
KDE tag.

What do other players find?

Some support for this idea ... I just SVN-updated and re-built the KGr
source - but with KDE/Qt libraries a month or so old - and it works fine.
I get two resize events during startup and everything goes as planned.
However, when I searched the Trolltech website, I could not find any 
significant changes since my last library build.  I am currently on Qt 4.3.2.

What happens in your setup, Luciano, if you comment out the code that
ignores the first resize event, thus making sure that drawTheScene()
gets called when the first resize event happens?  That might clinch it.
Also, do you still get a log of a *second* resize event?

Perhaps, even, QMainWindow and friends handle resizes differently
in a 64-bit environment.

> > > The other problem is less critical, but annoying. Many keyboard
> > > shortcuts do not seem to work for me. 
> >
Sorry, I cannot offer any further suggestions on that one.

> > Heh, you must be a masochist, Luciano ... :-)  Don't you use the mouse?
>
> With drawing programs, mostly. And with some game too, but it looks like it
> does not work for me in KGoldrunner. I don't use a mouse on the laptop, so
> that may make things worse for me in this case. All things considered, I
> feel I have a better control of our hero with the keyboard.
>
Maybe I need to dream up a finger-pad emulation of a joystick for 4.1.

> One thing that I may find annoying is having the pointer on the game
> scheme.
>
Luciano, I am not sure what you mean by "game scheme".  Where is
the pointer and where would you prefer it to be?

All the best, Ian W.