Re: [glob2-devel] Longer Release Candidate, soon!

[Kai Antweiler]

> Before we go anywhere near the hyped 1.0, there *must* be a released Alpha
> 24.

I'd prefer glob2-0.9
There were serious changes in glob2 and our users should be able to see this in
our version number.  Continuing with 0.8.x is not good.


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

OK, branches are cheep.


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

Good job.


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

Isn't the number of your units on the screen sufficient?


>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

Can't we let the graphic card handle this?

I propose that we make that we make a more detailed graphics menu.
Instead of switching between low and high graphics, let the user decide for
every graphic feature whether he wants it and whether his cpu or graphic card
is fast enough for it.

-- 
Kai Antweiler