=DChel kenal p=E4eval (reede, 27. august 2004 18:31) kirjutas Andreas Bec=
> On Monday 23 August 2004 21:19, Rivo Laks wrote:
> > =DChel kenal p=E4eval (neljap=E4ev, 19. august 2004 03:42) kirjutas A=
> > > - make the map larger, 100x100 maybe (ok, since the editor doesn't
> > > support that, you would make a new map then, but anyway)
> > > Yeah, I know I could do that, but I am a lazy bastard and my boson
> > > binary is already being recompiled again :)
> > Size of maps: personally I _love_ big maps, even though boson doesn't
> > support them very well atm :-(
Well, until recently we didn't have any lod for terrain. Now we do, so it=
lot better, but some things are still lacking:
* LOD is not very good. It should take terrain's shape and textures into=20
account. That said, current lod is still better than nothing, so thank yo=
for that :-)
* Minimap. You can't scale it atm and it doesn't show which part of the m=
you're viewing either. Once I'll get more urgent things done (BoTexture a=
fixing moving code), I may look at it, but no promises.
* Something else? Maybe too little unit ranges?
> > So, I think perhaps we should replace the old maps, such as basic* (b=
> > do we really need _three_ versions of those?)
> Why not? More maps is always good in my opinion. We just should give th=
> other names than always "basic" :-)
Yep. But we should give them some unique content, too. It isn't very fun =
have 3 similar-looking maps, even if their names are all different ;-)
> > by bigger and better new maps.
> > And yes, maybe I can create a few myself, too...
> > That said, here are few things concerning maps that I'd like to be
> > changed in boson:
> > * Fog of war. Fog of war for terrain _sucks_ imho, especially
> > technically.
> I disagree.
> The only technical problem that I can see is that fogged cells are alwa=
> > Lots of modern games use fog of war for units only, terrain is always
> > 100% revealed.
> Well, then I probably don't know many "modern" games. However I think i=
> a bad habit if you dictate the scenario designer how the scenario shoul=
> look like.
Two games that don't use fow for terrain are D-Day and Ground Control 2. =
(windows) demos are freely available, in case anyone's interested.
> > It also makes sense in modern combat imho, because these days you
> > have satellites, you usually know what the terrain is like.
> I don't think so. There are many fractions that don't have access to
> satellites for example.
> Also our units don't really look like being _that_ modern.
> > Also, from
> > technical side, I believe removing it could make things faster. E.g. =
> I disagree.
> > when rendering cells, we have to check for each cell whether it's fog=
> > or not.
> What's the problem? That's a single if check per cell, that is very fas=
> You could get a minor speed improvement only if you'd skip that and loo=
> at the amount of time that is spent in cell rendering (especially after=
> LOD patch), I believe it isn't worth it.
> > Same for water. If we'd remove fow, we could group cells into 10x10 o=
> > so sectors and then render them using vertex arrays or vbos.
> We cannot easily group to sectors, you should know that. For example
> G G
> G W
> With G=3DGrass and W=3DWater, we _have_ render every cell separately.
> Otherwise we would have to group these 4 cells into a 2x2 sector of gra=
> (i.e. no water).
> You have complained about that looking bad in my LOD patch, so I think =
> should know that :-)
You'd find out which textures are used in each sector and then render all=
cells in sector once per every used texture.
> Another way would be to group the cells into sectors and render every c=
> in that sector separately. The only advantage of the sector would be to=
> vertex arrays then. Well, many many profiling hours have shown to me pr=
> clearly that vertex arrays give a very small performance gain only. It
> certainly isn't worth removing features for them.
Actually vertex arrays can give quite a big gain. You've probably profile=
with units. If that's the case, you should keep some things about units i=
* Our current units use insane amounts of meshes and textures per model. =
would be optimal if each unit would use only single texture which is=20
specifically made for that unit (I know it can be pain for the artist, bu=
that's not the point here). Current units use so many textures that lot o=
time is already spent binding textures. E.g. on Storm map, with all units=
visible and unit lod on, I have 663 texture binds per frame. If I turn lo=
off, I get more than 3800 binds. For terrain, you'd be able to do n textu=
binds, where n is number of textures that terrain uses.
* AFAIK, you gain more with vertex arrays if you use large chunks of geom=
Again, with our current models, you have quite small number of faces per=20
mesh, so you render lots of small vertex arrays.
> So I basically disagree with you. I don't think that FOW sucks and I do=
> want it to be removed.
> However there is a single thing that I would like to have extended (I
> wanted that since 0.5 or so already):
> Most games use 2 kinds of fog of war.
> The first one is what we have currently - the "fog" that simply hides t=
> entire terrain. I don't know how this is usually named in games (I don'=
> know it in english at least)
> The other one is what is usually named "fog of war", I believe. It is s=
> kind of "real" fog that doesn't hide the terrain, but only the units th=
> are on it.
> I would like to have that 2nd kind of FOW one day, too.
Yes. Me too. But I'd like to have only this kind of fog...
> > * Range of units. IMHO we could make range of units about 2 times big=
> > This would also make battles more "open", so that units wouldn't be a=
> > so close to each other. Of course, this would also require bigger map=
> Yeah, agreed. And sight range really has to be increased, too.
> Well, I had hoped some non-coder would do such things, as these are rea=
> trivial changes in the index.unit files. Well, I will continue hoping s=
Yeah, well, unless anyone else volunteers, I'm going to do this myself.
> > * Accuracy for weapons, this should be done together with bigger rang=
> > The longer the distance between shooter and target, the less accurate=
> > shot will be. Then units could fire from longer distance, but they co=
> > miss then. That would be even more realistic and better :-)
> > * Some kind of "physical" model for shooting. E.g. so that every weap=
> > fires with certain force and gravity would affect the bullets (or
> > whatever you shoot with). Then the lower the target is, the more away=
> > could shoot it from (I hope you understand). That would add some grea=
> > tactical advantage to higher grounds.
> That is indeed an intersting topic, but not so much a feature for me :)
Perhaps I should some day send another mail about it then...
/me wants more tactics in boson, not just=20
build-many-units-and-send-them-to-enemy-base type gameplay ;-)
Or... maybe I should just go ahead and implement it myself (I don't see a=
else willing to do that anyway...) :-)