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
address@hidden
http://lists.nongnu.org/mailman/listinfo/glob2-devel