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

[Luciano Montanaro]

Il Thursday 29 November 2007 13:12:37 Ian Wadham ha scritto:
> 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?

I sent the backtrace separately because it's rather long...
Maybe I have a debug Qt instead of a production one?
It aborts at the invocation of m_tileSprites->at() method.


>
> > <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.
>

Yes, but then, something is calling setTile() independently, without 
setTiles() being called. Maybe KGrGame::setBlankLevel()? I dont't have the 
time to test right now, I'll do some more investigations this evening.

> > 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?

Yes, see above... I think it's the setBlankLevel, called in the KGrGame 
constructor.

>
> > 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?
>

Yes, there are two resize events...

> 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?
>

Sorry, I meant the game playfield. Well, I prefer the pointer out of the view 
entirely, actually, there is not much you can do about that! :)

Ciao,
Luciano