On 8/12/07, Joe Wells <[EMAIL PROTECTED]> wrote:
>
> Here is my final release candidate testing feedback. I'm going to
> have to put glob2 away for a while now, so you probably won't see any
> more comments from me soon (unless I am weak). Hopefully all serious
> bugs in the release candidate have been discovered already.
>
> Here are the remaining issues:
>
> • 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.
• 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.
• 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.
• 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. 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.
> • glob2 is quite a bit slower on a 512 × 512 map against two Nicowar
> opponents. In this case, it is almost unusably slow. The slowdown
> from smaller maps is quite noticable. What is glob2 doing that
> costs so much on a per-map-cell basis?
There are many per-map-cell algorithms. Pathfinding goes right to the 256
square limit, Nicowars (Echo's) gradients push right up till their 65533
limit, which are part of Nicowars (Echos) building-placement algorithm which
is also per-map-cell. When a building needs constructed, it will update the
required gradients, one per every 2 frames untill they are up to date, then
it calls the placement algorithm itself.
• Nicowar is an extremely weak opponent on 512x512 maps. It is very
> difficult to defeat an opponent on such large maps without building
> inns/hospitals near the opponent's territory. Nicowar doesn't do
> this.
Heh, its optimized for the maps that are distributed with the game.
• It would be nice to be able to randomize the assignment of colors to
> teams, just to be able to see different colors. Right now you have
> to use the colors assigned when the map was created.
Add this to the wishlist.
• It would be nice to be able to randomize the assignment of players
> to teams, just to be able to play different map positions.
Add this to the wishlist.
I hope these comments are helpful.
>
> --
> Joe
>
> "The parties' assertions as to the importance of this issue may reflect
> a
> certain amount of hyberbole. For example, Sprint states: 'It is
> estimated
> that 32 billion viewers throughout the world will watch the games.' This
> is indeed an extraordinary assertion given the current estimation of a
> world population of only 5 1/2 billion, and no reliably verified
> evidence
> of interplanetary travel."
> -- U.S. District Judge John Martin Jr.
>
>
> _______________________________________________
> glob2-devel mailing list
> [email protected]
> http://lists.nongnu.org/mailman/listinfo/glob2-devel
>
--
Extra cheese comes at a cost. Bradley Arsenault.
_______________________________________________
glob2-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/glob2-devel
