Spring RTS Engine

1v0ry_k1ng wrote:yeah but it'd look horrible if the wheels and propellers didnt move

Not really, if you're zoomed out to a playable scale.

Maybe we should release two versions of 1944, a "hi-def" version with all the bells and whistles, and a "low-def" version with adequate but with potentially less of a "wow" effect.

Ever think about using "CREW" units, basically engineer units that can only heal, for manning fixed defensive weapons? You could make fixed weapons have virtually zero sight and make them rely on the crew unit to both spot targets in the area and maintain the unit as it takes damage.

Just an idea.

While I'm not sure about doing something like that, one possibility if the ability to tell units to get into transports ever arrives is having towed guns that depend on their crew to continue firing/moving. So in theory one could kill the crew and leave the gun intact for your own use later on. I'm not sure how that would end up working with spherical collision though.

However, that ups the micro time needed to use guns by a good dea, and so is potentially a bad thing.

As for the laggy builds, ALL the infantry animations are written inefficiently - when compared to nanoblobs, our infantry models have fewer polies, fewer model objects, and more efficient texture use (one 512x512 shared among all the infantry of a given side) - and yet Nanoblobs can reach the ~200 unit per side threshold without lagging as horribly as 1944. Thus, it comes down to our scripts - nanoblobs has VERY clean scripts, and we have very ugly ones.

Once they're rewritten, I expect the FPS drag will drop by a good deal. Hopefully. If the lag is still overpowering, its time to scale down a bit, and maybe remove some of the unneeded gimicks (upgrades..)

Nemo wrote:Once they're rewritten, I expect the FPS drag will drop by a good deal. Hopefully. If the lag is still overpowering, its time to scale down a bit, and maybe remove some of the unneeded gimicks (upgrades..)

Quoted for truth. Upgrades are, to put it bluntly, a waste of resources. They add absolutely nothing to the game.

not entirely true - they let us stick more weapons ingame, reward those who pay attention and care for their infantry, ect, ect. Plus, I coded it, so I like it. <_<

However, its certainly not game altering, and so would be easy to remove without screwing other things up.

Nemo wrote:not entirely true - they let us stick more weapons ingame,

Unless you're an Ayn Rand fan, you make the game to make the players' experience superlative, not yours.

reward those who pay attention and care for their infantry,

Upgrade is not worth the extra micro to actually utilize upgraded infantry separately from regular.

ect, ect. Plus, I coded it, so I like it. <_<

However, its certainly not game altering, and so would be easy to remove without screwing other things up.

Good. It should be removed. If the extra weapons are necessary, make them available from the barracks. If not, take them out.

I can garauntee you that your unit and weapon counts are going to play havoc with frame rates. I bet if you only test with units AND weapons from one side in the mod you'll have much improved frames. Its just the way it is when you add complexity to a mod.

A few smallish notes about efficiency:

1. Cleaning up the scripts can really clean up your mod. Using OTA-style animations (move NOW, sleep, repeat) is the worst possible thing to do. It involves hundreds of lines, is very hard to maintain, and is generally the worst way to code animations possible.

2. Cleaning up the models to have the fewest number of Pieces possible can help a bit, but not nearly as much as scripts.

3. The minimum size for an object in Spring, that does not path inefficiently, is a 1X1 footprint, which is 8 units in radius in UpSpring.

4. Ditto for collisions with weapon fire.

5. Using non-square footprints is bad.

6. Scripting that requires a constant check in the background needs to run fairly infrequently- as much time as you can get away with. With stuff like the Experience system, I'd say 5 seconds or more. With stuff that is visually sensitive, you can probably get away with 0.5 to 0.25 seconds.

7. Using radii for units or for explosions that aren't powers of 2 is bad. Best results, I have found, are multiples of 8, because that works out to a grid of 1X1. The best possible results for the quadtree search, I think, would be to use powers of 8, but using odd multiples is still pretty efficient.

8. Some things cause a lot more lag than others. Guided weapons are one of the biggest offenders, for example- they cause far more CPU usage than projectiles using gravity, due to the complexity of their calculations having to do with mesh deformation during flight.

While polycount and smaller texture sizes can help somewhat, Spring rarely chokes on pure framerate, unless all the bells and whistles are on. The bigger issues are all CPU-side. That does NOT mean that you can have uber-detailed models and the framerate will not suffer... trust me, it will, once you get past a threshhold of 20-40K tris onscreen, depending on a lot of other factors. But I got NanoBlobs working as well as it does largely because of cleaning up CPU-side stuff, not GPU-side stuff. Other than transitioning to DDS textures months ago, almost all the optimizations have been on the CPU side...

Mesh Deformation


...
Whats that?

Keep in mind that our infantry are 500 tris each... meaning that 500 of them = 250k tris. Also I tested the models out with empty scripts devoid of anything whatsoever and it still lagged considerably.

Well, THANK YOU Argh.

I'll go through and make those changes as soon as I can. IE in a week or so...college applications own my soul.

Spiked, I'm really pretty confidant that once we go through the checklist that Argh posted, in combination with the cleaner scripts, we'll help the issue a lot.


Again, thanks a ton Argh, that's really helpful stuff. Should probably be stickied somewhere, actually.

Edit: 500 is a bit extreme, don't you think? 200-250 is a more realistic upper range, in my opinion.

SpikedHelmet wrote:Keep in mind that our infantry are 500 tris each... meaning that 500 of them = 250k tris. Also I tested the models out with empty scripts devoid of anything whatsoever and it still lagged considerably.

Do yourself a favor and eliminate the possibility its simply an issue with the raw number of units and weapons. Spring is laid out nearly identically to how TA handled the damage tables for weapons and also how it handled unit files, which means as the number increases there is a direct somewhat linear relationship in real-time it takes to manipulate that data.

Give every unit a single simple form and a nearly blank cob script and try that. If lag continues then you know its not the tris count.

@Spiked: Er, it's not the 250K tricount. Really. Just follow my simple list of directions (simple, but hard to actually do). It works.

@MadRat: Trust me... it is not the length of the list of weapons/units. If that were the case, then AA and XTA would lag the most, and NanoBlobs the least Really, it's about the number of objects on the playing field, and how they interact with the totality of the engine. They could just build soldiers with boxes for Pieces, and have the same results. Their mod is, essentially, very poorly optimized at this point. Optimizing it will require, at a guess, a couple of months of steady work. They would do best to design a walk cycle for their infantry that used the new methods that zswyg was nice enough to show us- that would help a lot as a starting-point, and be easier to maintain to boot

Just thought I'd chuck in a shameless "hah, told you so!" regarding the upgrades.

Otherwise, Argh is a Spring guru, and you're advised to listen to him. He's done heaps of work with engine, so I'm inclined to trust pretty much anything he says.

@Spiked: If 500 of them just sitting still is lagging your FPS... I dunno what to tell you, without seeing your test conditions, because that many Sheep in NanoBlobs will make FPS drop, but not much, while sitting still.

Are they all armed? Still using cloaking? Etc.? I'm going to be using Seismic a lot in the next version of NanoBlobs- and guess what? If your infantry (or even better yet, a specialized unit- "scout" or somesuch) had a Seismic sensor, then you could make it have a very large radius, have tanks/vehicles show up that way, and infantry would only show up visually... taking away the need for cloaking for most units. Simply have an "ambush" unit that can serve as a spotter... make the non-ambush weapons have a much longer range than the sight radius... and voila... ambushes would be entirely realistic in behavior, and it'd be a lot more efficient than other approaches CPU-wise- the "ambush" units would spot the incoming infantry, the defensive infantry would fire from well out of sight radius of the attackers, and the attackers would be at a realistic disadvantage, just as they are in a real ambush.

Warlord Zsinj wrote:Just thought I'd chuck in a shameless "hah, told you so!" regarding the upgrades.

Pfft. No told you-soing going on here. We'll see how it plays once balance has been refined a bit more, and I reduce the checking repitition to more reasonable levels.

Argh: the only units that cloak are infantry, because they're the only units that would be able to be 'hidden' while moving, so seismic for tanks and such isn't really needed. I'm planning on using seismic for minefields, actually.

All infantry minus engineers are armed, but with lasers, which are close to the least demanding projectile I'd imagine - no guidance, no gravity, just point and shoot.

I don't quite understand what you're proposing Argh, but it might just be fatigue on my part. As far as I know, seismic detection doesn't trigger firing orders - that is, units don't shoot at a seismic detection, unlike radar, where they shoot even though they'll miss.

Thankfully, we're finding these optimization problems early - when only about 35 units are ingame, rather than later on when we'd have to revamp the entire game. I imagine that sorting them all out will only take a week or so of dedicated work.

Edit: Ayn Rand...gaaah, Atlas Shrugged...80 page+ monologues...my mind.

Christ that book was painful to read. More so because it made its point abundantly clear by page 150ish, but continued to page ~1080.

Felix the Cat wrote: Unless you're an Ayn Rand fan, you make the game to make the players' experience superlative, not yours.

However, its certainly not game altering, and so would be easy to remove without screwing other things up.

Oh, Ayn Rand. Her ideas are very skewed...

I like the upgrades, personally. Something new!

Argh wrote:A few smallish notes about efficiency:

1. Cleaning up the scripts can really clean up your mod. Using OTA-style animations (move NOW, sleep, repeat) is the worst possible thing to do. It involves hundreds of lines, is very hard to maintain, and is generally the worst way to code animations possible.

What is the alternative ?
How should I script running soldier then ?

His answer will inevitably akin to "Download NanoBlobs and look at scripts in there"

I guess I could enter the humanoid competition, then make a script that would just happen to be appropriate