[glob2-devel] Longer Release Candidate, soon!

[Bradley Arsenault]

Before we go anywhere near the hyped 1.0, there *must* be a released Alpha 24. It is critical that we reach an audience with the new YOG, in order to both test its functioning on a wider scale. Also, the massive number of internal changes have introduced new bugs (mostly by me), so these need to be identified and taken down, which means we need to do, at the very least, one more Alpha. Another big change is scons, which, while it seems perfect right now, needs some more widespread testing.

Before we do so, I would like to do a longer release candidate. Rather than actually doing a release, we will do the announcements (webpage, glob2-announce etc) about how to obtain and compile the code (updates on the wiki). The release candidate changes can be merged back into the master, but we do need a branch for the release candidate, as to keep new master features from leaking in. Its also important that at the end of our release candidate, we put together the new tar balls and then make a new release.

I've been gardually working through the bugs in the bug-system and in the 1.0.0 "Things to do list". Most of the bugs are old, and while we have "requested more info" we won't ever recieve any, so I've cleared a few of these out that I was certain wheren't doing any good. I have however solved numerous bugs that where existing, including the feature to be able to disable the scroll wheel that Joe had requested.

Also, this

• Make the other three overlays take advantage of the multi core cpu threads because without it, they make the game really slow when the game gets larger!

On the wiki is a moot point. First of all the other three overlays must be done in sync since they depend on the changing state of the game. Secondly, the computation of these isn't a cpu hog in the slightest. They all scale not with map size but with number of units on a team, which is irrelevant to the size of the map. Thirdly, all of the cpu time consumed by these is done due to drawing them, and there isn't anything I can do about this. When in high quality mode, these draw with 4x4 sub-sections to each square on the map in order to provide more "smoothness" of the resulting values. Thats allot of sections that are drawn with varying alpha so its understandable that it takes up a bit of CPU. Turning on "low quality" remedies the problem because the system doesn't draw any sub-sections, just one color for each square

I will be prepared to do the release candidate within a couple of days, after I clear up all known bugs.

-- Really. I'm not lieing. Bradley Arsenault