Spring RTS Engine

Hi!

So when having a look at Spring's latest changes & features I came up with a couple of questions in regards of how to make a game compatible with the latest engine version and how to make the most out of the newly available features...

1.) .fbi vs .lua
I guess it would be a good idea to deprecate the old .fbi unit definitions and switch them to .lua definitions? Is .fbi totally abandoned or would it simply lack some features like the collision volume tags? When looking at BA and its .lua definitions I also noticed very long floating point numbers. So does a fbi -> lua conversion script of some kind exist that is responsible for those numbers?

2.) collision volumes
Does any new intel exist on this matter that didn't make it into the wiki yet? I'm especially talking about the performance issue in spherical vs box / cylindric. Did anyone observe sensible performance losses with the non-spherical type or did things indeed turn out to be negligible?

3.) s3o vs. Assimp
Do any real pros or cons exist here? I read about normal maps for models integrated via Assimp - is this also possible for s3o?

4.) pathfinder
Can anyone please sum up the current situation of heatmaps and the quadtree pathfinder? Is there anything a game developer can do to improve the results?

5.) mipmap levels
Just out of curiostiy: Does some control about the mipmapping levels exist? A certain disadvantage of the s3o models always was that the detail level went down too fast resulting in blurry looking units when zooming out. Has this issue been resolved / is there now some control of when OpenGL wants to switch to a lower level of (texture) detail?

6.) projectile fx for weapons
Is it now possible to use e.g. bitmaps as visual representation of a (projectile) weapon? What I mean is the idea of basically using something like THIS to be the visual representation of the particle which would be done as trees often are done by using two orthogonal planes with the bitmap (+ transparency) on them. The only way to do this when I last tried was to use CEGs. The problem here is that they only can get spawned every xxx seconds and thus provide only a stuttering but no fluent representation of the particle while flying around. Is there now some way to attach a bitmap to a particle which gets its position updated fluently?

Master-Athmos wrote:Hi!

So when having a look at Spring's latest changes & features I came up with a couple of questions in regards of how to make a game compatible with the latest engine version and how to make the most out of the newly available features...

1.) .fbi vs .lua
I guess it would be a good idea to deprecate the old .fbi unit definitions and switch them to .lua definitions? Is .fbi totally abandoned or would it simply lack some features like the collision volume tags? When looking at BA and its .lua definitions I also noticed very long floating point numbers. So does a fbi -> lua conversion script of some kind exist that is responsible for those numbers?

You can use fbi with 100% the same tags as lua, lua just gives the extra ease of a real scripting language.

2.) collision volumes
Does any new intel exist on this matter that didn't make it into the wiki yet? I'm especially talking about the performance issue in spherical vs box / cylindric. Did anyone observe sensible performance losses with the non-spherical type or did things indeed turn out to be negligible?

No performance issues.

3.) s3o vs. Assimp
Do any real pros or cons exist here? I read about normal maps for models integrated via Assimp - is this also possible for s3o?

Assimp isn't fully mature yet, so you might experience more bugs, but, you can avoid using Upspring. Normal mapping is done with a gadget and will work for either.

4.) pathfinder
Can anyone please sum up the current situation of heatmaps and the quadtree pathfinder? Is there anything a game developer can do to improve the results?

Ask kloot.

5.) mipmap levels
Just out of curiostiy: Does some control about the mipmapping levels exist? A certain disadvantage of the s3o models always was that the detail level went down too fast resulting in blurry looking units when zooming out. Has this issue been resolved / is there now some control of when OpenGL wants to switch to a lower level of (texture) detail?

This is primarily due to settings when creating a dds texture. Search forum for posts by beherith about sinc filter.

6.) projectile fx for weapons
Is it now possible to use e.g. bitmaps as visual representation of a (projectile) weapon? What I mean is the idea of basically using something like THIS to be the visual representation of the particle which would be done as trees often are done by using two orthogonal planes with the bitmap (+ transparency) on them. The only way to do this when I last tried was to use CEGs. The problem here is that they only can get spawned every xxx seconds and thus provide only a stuttering but no fluent representation of the particle while flying around. Is there now some way to attach a bitmap to a particle which gets its position updated fluently?

You can lua the whole drawing of projectiles if there is not a simpler way (there may be).

1.) FBI2LUA: http://code.google.com/p/zero-k/source/ ... %2FFBI2Lua
And all known tags should be accessible via fbi

2.) http://springrts.com/wiki/Gamedev:Main -> http://springrts.com/wiki/Unit_collision_volumes (not complete)

3.) Not all Assimp exposed properties are used, so no auto normalmaps yet. Still in future likely more features will be used and it already allows to use a 2nd texcoord, loads a few texture filenames from the model, ...
But Spring<->Assimp had to fight with a severe rotation problem, so S3O is more proven.

4.) ...

5.) 1. OpenGL knows at best what level it uses 2. there is TextureLODBias, but it might heavily decrease performance when used, cause as said driver knows best ... 3. as FLOZi said your dds likely used wrong downsample filter, e.g. with nvtexure tools you can increase contrast of mipmaps and making them so much sharper.

6.) tl'dr

4) The default pathfinder works well right now and is mostly the one being used. The QuadTree pathfinder also works well but my (possibly outdated) memory is that it has a bigger perf hit, so it's suitable for huge battles. I don't know of anything gamedevs can (or need to) do to help either.

6) Yes, with a lua gadget - use the synced part to do the positioning and the unsynced part to do the rendering, using gl and the new projectile callins. Make sure you use glLists properly and limit your push/pop matrix calls etc etc if you do this alot.

Allright thanks to all of you - that was quite helpful...

jk wrote:2.) http://springrts.com/wiki/Gamedev:Main -> http://springrts.com/wiki/Unit_collision_volumes (not complete)

Yes I did see that and actually asked the question because of the ...

Cylinders and boxes require more math and so are slower. How much does it really matter? No idea.

... paragraph.

FLOZi wrote: This is primarily due to settings when creating a dds texture. Search forum for posts by beherith about sinc filter.

http://springrts.com/phpbb/viewtopic.ph ... hilit=sinc

&

http://springrts.com/phpbb/viewtopic.ph ... nc#p423882