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


All times are UTC + 1 hour


Post new topic Reply to topic  [ 58 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: 08 Jun 2012, 01:29 

Joined: 29 Mar 2010, 16:54
Ships can get pushed up on land pretty badly.
Image
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.
Image
Top
 Offline Profile  
 
PostPosted: 08 Jun 2012, 08:47 
Evolution RTS Developer
User avatar

Joined: 17 Nov 2005, 02:43
Deadnight Warrior wrote:
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.
Top
 Offline Profile  
 
PostPosted: 08 Jun 2012, 14:08 
User avatar

Joined: 17 Sep 2010, 14:49
Johannes wrote:
Quote:
- 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?

Kloot wrote:
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?
Top
 Offline Profile  
 
PostPosted: 11 Jun 2012, 10:10 
User avatar

Joined: 08 Jun 2009, 16:59
Location: Croatistan
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.
Top
 Offline Profile  
 
PostPosted: 11 Jun 2012, 11:07 
Moderator
User avatar

Joined: 26 Oct 2007, 15:21
Deadnight, I can write you a python script that does the same. Deal?
Top
 Offline Profile  
 
PostPosted: 11 Jun 2012, 11:09 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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.
Top
 Offline Profile  
 
PostPosted: 11 Jun 2012, 16:34 
Moderator

Joined: 12 Oct 2007, 08:24
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.
Top
 Offline Profile  
 
PostPosted: 11 Jun 2012, 17:58 
MC: Legacy & Spring 1944 Developer
User avatar

Joined: 29 Apr 2005, 00:14
Location: #moddev - join it!
I could never see any real difference anyway.
Top
 Offline Profile  
 
PostPosted: 11 Jun 2012, 18:51 
Kernel Panic Co-Developer
User avatar

Joined: 16 Nov 2004, 13:08
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.
Top
 Offline Profile  
 
PostPosted: 12 Jun 2012, 20:19 
Moderator
User avatar

Joined: 26 Oct 2007, 15:21
http://imolarpg.dyndns.org/trac/balatest/browser/etc/Tools/AnimationSmoother/smoothanim.py

Source to source anim smoother.
Top
 Offline Profile  
 
PostPosted: 28 Jun 2012, 14:20 

Joined: 20 Oct 2009, 12:04
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
Top
 Offline Profile  
 
PostPosted: 28 Jun 2012, 14:50 
Spring Developer
User avatar

Joined: 28 Jun 2007, 06:30
jamerlan wrote:
- 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).

jamerlan wrote:
- 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.

jamerlan wrote:
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.
Top
 Offline Profile  
 
PostPosted: 28 Jun 2012, 15:45 

Joined: 20 Oct 2009, 12:04
>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!
Top
 Offline Profile  
 
PostPosted: 04 Jul 2012, 22:45 
MC: Legacy & Spring 1944 Developer
User avatar

Joined: 29 Apr 2005, 00:14
Location: #moddev - join it!
Nemo wrote:
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.
Top
 Offline Profile  
 
PostPosted: 08 Jul 2012, 17:25 
Spring Developer

Joined: 31 May 2009, 23:08
Next try:
viewtopic.php?f=12&t=28375 (new engine testing version)
Top
 Offline Profile  
 
PostPosted: 12 Jul 2012, 12:52 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
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


Last edited by SpliFF on 12 Jul 2012, 13:24, edited 1 time in total.
Top
 Offline Profile  
 
PostPosted: 12 Jul 2012, 13:13 
Spring Developer
User avatar

Joined: 28 Jun 2007, 06:30
SpliFF wrote:
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!
Top
 Offline Profile  
 
PostPosted: 12 Jul 2012, 13:27 
User avatar

Joined: 28 Jul 2008, 05:51
Location: Australia
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).
Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 58 posts ]  Go to page Previous  1, 2, 3

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Site layout created by Roflcopter et al.