Engine Testing - 29. May 2012 (88.0.1-264-g89ee3b2)

[Godde]

Ships can get pushed up on land pretty badly.

If you FPS them you can "drive" down into the sea again.





Land units might drive down too steep slopes. If you FPS a tank you can just drive down a too steep slope easily. Just need to make em fly and we can have Big air competions or something. Would be cool if units could drive down bigger slopes than they could climb like this but how to make them not drive down holes they can't get out of is beyond me.

[Forboding Angel]

Dunno if someone mantised it, but QTPFS still fails at units getting stuck in factory. It happens only when unit's footprint is equal (I assume and larger than, but couldn't test it due to game design) to factory construction lane size and more often if the factory was built on rough terrain (that had to be autoleveled) or rotated to any direction than south.

Doesn't this just make sense? What kind of silly gamedev has units being built in his factory that are larger than the exit lane? That's just ignant.

[Johannes]

- add 'allowUnitCollisionOverlap' (def=true)

Does changing this basically mean units won't get inside each other anymore? And if so does it affect buildings too?

yes/no

This is just speculation, but would extending it to buildings get rid of the bouncing effect? Or from another point, is there a reason not to make buildings completely un-overlappable with units?

[Deadnight Warrior]

I haven't noticed this commit till today: https://github.com/spring/spring/commit ... bab536f434
The commit was never put in a changelog and it happend around 0.82.3

While the rationale behind it isn't questionable, since then there where many other performance improvements with much greather impact than this. Can it be reverted? As there are a lot of unit scripts that where designed with SmoothAnim in mind and rewriting them isn't really an option.

[Beherith]

Deadnight, I can write you a python script that does the same. Deal?

[hoijui]

without having much knowledge about the topic, it seems to me that to write a sort of source2source converter, as Tobi suggested it there, would make more sense then reverting this.
.. just needs someone to do that... but if i read his words correctly, then it could be a relatively simple AWK script, for example.

[Google_Frog]

That was a year ago and it can be fixed game side. I think those with working games have either fixed it since then or don't care, old games don't necessarily work with the new engine.

Anyway it only works for cob which frankly should not be used for new things.

[FLOZi]

I could never see any real difference anyway.

[zwzsg]

It's not like it would break any games anyway. At worse, a few animations would be reverted to be as choppy as they were originally designed.

[Beherith]

http://imolarpg.dyndns.org/trac/balates ... othanim.py

Source to source anim smoother.

[jamerlan]

From changelog:

- explicit disable all CPU extensions except SSE1
This means that Spring will not use many optimizations? Sounds sad.

- on multicore systems set scheduler to SCHED_BATCH (semi-solves the core hoping issue)
What is it? Linux distribs will have this option disabled by default? This means that it's better to compile spring from sources?

I think this change needs more detailed description:
- improved behaviour of builder masses
sounds interesting but I can't understand what it means

[jK]

- explicit disable all CPU extensions except SSE1
This means that Spring will not use many optimizations? Sounds sad.

Else it won't sync in online gaming ...
Before it just set march=i686 & relied on gcc not enabling such extensions and in case of linux 64bit compiles it was a very optimistic `hope` that it will sync (some march's strangely did, with other it didn't).

- on multicore systems set scheduler to SCHED_BATCH (semi-solves the core hoping issue)
What is it? Linux distribs will have this option disabled by default? This means that it's better to compile spring from sources?

What?
It doesn't tell anything about distros.
And @what it is, it's a different thread scheduler (how the kernel distribute cpu time for the thread). Also it is something like a `hack`, SCHED_BATCH is by design _slower_, but in case of a 100% cpu usage thread & free cores it will be _faster_ cause it won't shuffle the thread across the CPUs anymore. I detected >>10core switches per second, also none core was ever running at full speed cause this way they were never running at 80% usage. It's a very critical _bug_ in the linux kernel (or I am just running it with wrong param?), and I would really like to speak about this with a linux kernel dev some time.

I think this change needs more detailed description:
- improved behaviour of builder masses
sounds interesting but I can't understand what it means

It's how builders check if their building was already started (and finished) by another unit, before they always travelled to the buildpos and then checked if the job was already done. Now they already check on their way if it is done.

[jamerlan]

>It doesn't tell anything about distros.
Sorry, I misunderstand description. I though it compilation time option. So I thought maintainers will not use this option. TY for explanation!

[FLOZi]

http://springrts.com/mantis/view.php?id=2877 is still a problem. I know cob scripts are old fashioned at this point, but S44 has a lot of cob still active (specifically infantry scripts) because porting them is going to be a ~150-hour project minimum.

More specifically, SET MAX_SPEED from cob side only takes effect for one frame. After that they're free to move again. To see: grab spring1944.net/files/Build/S44v159_PreMorgenroteTRI.sdz and any map, plug it into 88+. /cheat /give germg42 /give 10 gerhqengineer.

Order the MG42 to fire at the ground near the engineers. they'll dive to the ground, yellow starts will appear indicating suppression (move only while crawling). after a few seconds, red stars will appear, showing pinned status (no moving, no firing). However, if you give the pinned dudes a move order, they'll scoot off.

Edit: otherwise, so far so good. I specced a ~15 minute 1v1 S44 game using the test build and didn't spot any problems.

Still unresolved afaik - and a Big Issue (TM) for us.

[abma]

Next try:
http://springrts.com/phpbb/viewtopic.php?f=12&t=28375 (new engine testing version)

[SpliFF]

There's a serious crash with EAX reverb under ALSA. This feature has always been buggy (caused corrupt sound effects since 0.82) but now it segfaults outright.

There is a known workaround which is to disable eaxreverb in ~/alsoftrc however I've been digging around in EFX.cpp looking for a better way.

I have patched this file to make UseEFX = 0 actually work. It is currently being checked AFTER the reverb filters are added which is completely wrong.

I'm now looking at a way to set UseEFX = 0 automatically on devices that report as "OpenAL renderer string: OpenAL Soft" (which is basically all onboard audio chipsets).

I know we're keen to get 89.0 out but I think this patch deserves high priority since it's a showstopper for most linux users. I should have these patches up on my github repo within the hour.

UPDATE: Patched Spring (develop) pushed to https://github.com/SpliFF/spring/tree/efxpatch

[jK]

I have patched this file to make UseEFX = 0 actually work. It is currently being checked AFTER the reverb filters are added which is completely wrong.

Mr. Smart: creating a OpenAL filter/effect != binding it and using it!

[SpliFF]

That's semantics. The point is i've fixed UseEFX and EFX in general under OpenAL Soft. I could mess around with trying to work out why the filter segfaults and is generally shitty but I'm going to put that down to software trying to do hardwares job (like software opengl).