glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] my final release candidate testing feedback


From: Joe Wells
Subject: Re: [glob2-devel] my final release candidate testing feedback
Date: Tue, 14 Aug 2007 13:00:03 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

"Bradley Arsenault" <address@hidden> writes:

> On 8/13/07, Joe Wells <address@hidden> wrote:
>
>     Okay, I'm really stopping after this.  :-)  No more time for testing.
>
>     • BUG:I got a segmentation violation when pressing right mouse
>       button to switch the contents of the right panel.  The game was
>       paused at the time, so I can be pretty sure that the crash resulted
>       from switching the panel.  Of course, there is no core dump file, so
>       I can't help figure out why.
>
> I can't reproduce this bug/

Neither can I, which is why I wish it had left a core dump file.

>     • BUG: The game got into a state where most of the commands were being
>       delayed by about 15 seconds.  Things that were delayed: pausing (the
>       "p" key), quitting (from the menu), adjusting number of requested
>       globules or radius on a flag.  Things that still worked instantly:
>       moving the viewport with mouse or keyboard, dragging flags.  The
>       game was almost over so I didn't get much more experience with this.
>
> Most likely due to excessive use of scroll wheel. Quitting, pausing are queued
> through the game engine. Scroll wheel bug is fixed. 

I don't think it was connected to the scroll wheel bug.  With the
scroll wheel bug, if you waited long enough, it caught up and then
everything was normal afterward.  With this, even after things had
caught up completely, there would still be a 15 second delay on any
new commands.

>     • BUG:The fertility map sometimes completely does not work (nothing
>       shows anywhere).  But sometimes (later in the same game) it works
>       fine.
>
> Not sure what causes this. The computation thread automatically spawns at 4
> seconds in, and it takes another 4 seconds to complete. 

Additional information:  The situation I reported was long after the
game had started.

>     • BUG (old, I think):The damage map is not working.  It doesn't show
>       anything, despite lots of damaged globules.
>
> Fixed. 

Yay!

>     • When glob2 is run the very first time (and there is no ~/.glob2
>       directory yet), it prints this error message:
>
>         Settings::load("preferences.txt") : error, can't open file.
>
>  Fixed.

Yay!

>     • It would be better if the fertility map did not highlight areas with
>       stone on them, given that nothing can ever grow where there is
>       stone.
>
> When I did this before, I noticed that it created very ugly holes in the
> gradient, even though it was more accurrate, it was less asphetic.

I would rather see the less misleading data.  I think that would be
better for most users.

"Bradley Arsenault" <address@hidden> writes:

> On 8/12/07, Joe Wells <address@hidden> wrote:
>
>     • Bug:I'm seeing this error message:
>
>         StringTable::getString("[wheat], -1") : error, no such key.
>
>       I don't notice any problem at run-time connected with this.  (But I
>       know all the messages already so maybe I wouldn't notice anyway.)
>
> Fixed.

Yay!

>     • Bug (or merely extreme annoyance?):There are dots above a
>       building/flag indicating how many globules are requested.  The
>       updating of the number of these dots can fall way behind (by entire
>       minutes!) the adjustments, if you make a large number of adjustments
>       very quickly.  To see this, select a building, and then use the
>       scroll wheel (or control-scroll-wheel if you have turned off
>       unmodified scroll wheel) to quickly increase the number of requested
>       globules to the maximum, then decrease the number to zero, and
>       repeat this 20 times.  On my machine, it then takes about a minute
>       for all of the changes to be drawn to the dots.  In contrast, the
>       indication of the number of requested workers in the status area is
>       always instantly correct.
>
> Fixed. And the result of the bug is because you can roll the scroll wheel
> faster than the engine can process events. The fix is to compound scroll wheel
> events that occur in the same frame.

Yay!

>     • Bug:If you create a new map, then edit it by creating a new hive
>       and deleting the original hive, when you play the map, the area
>       around the original hive is revealed as seen as though the original
>       hive existed for a moment at the beginning of the game.
>
> Fixed, the map editor didn't update the discovery map when stuff is deleted.

Yay!

(Anyway, shouldn't the map editor compute the discovery map as part of
writing the map file?)

>     • It would be better if map files and saved game files were
>       compressed.  I have discovered by testing that gzip compression
>       reduces the size of saved game and map files by 90% (sometimes even
>       more).  (Anyway, I thought glob2 was being switched to use a
>       zip-based structure for maps and games.  That would have solved this
>       issue.)
>
> I actually implemented this at one point, believing the same thing you did 
> (see
> the new ZlibStreamBackend in the code). Unfortenetly, this caused very poor
> performance for map previews.

Were you using a zip-structured file or using gzip for the entire
thing?  A zip-structured file should allow quick random access to all
parts, while using gzip could require uncompressing all of the data.
It ought to be enough to store a map preview image as a separate
component.

> Also, it required that the entire game save be
> written to the memory buffer, then compressed. This also cost performance. 
> This
> was mandatory due to the fact that the game uses random-acces streams (it will
> write the map header, then go back and write over it with the in-file offset 
> of
> the map code, for faster map preview generation, for example), which zlib did
> not support at all. I conlcuded that the maps aren't *huge* so we can suffer
> with a few more kilobytes on the hard disc, in tradeoff with  better
> performance.

I think the random-access issues could be dealt with by using
zip-structured files.  gzip compression doesn't support this well, but
zip does.

I hope these comments are helpful.

-- 
Joe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]