Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014) - Page 2

Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10223
Joined: 24 Jan 2006, 21:12

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by PicassoCT » 10 Aug 2014, 21:38

Code: Select all

[f=0000000] Error: LuaRules::RunCallIn: error = 2, Initialize, [Internal Lua error: Call failure] error = 2, LuaGadgets/gadgets.lua, [string "lups/ParticleClasses/unitpiecelight.lua"]:356: bad argument #1 to 'CreateTexture' (Texture Size must be greater than zero!)
stack traceback:
	[C]: in function 'Include'
	[string "LuaRules/draw.lua"]:1: in main chunk
[f=0000000] Error: LuaRules::RunCallIn: error = 2, Shutdown, [Internal Lua error: Call failure] [string "lups/lups.lua"]:1068: bad argument #1 to 'pairs' (table expected, got nil)
stack traceback:
	[C]: in function 'pairs'
	[string "lups/lups.lua"]:1068: in function 'Shutdown'
	[string "LuaGadgets/gadgets.lua"]:831: in function <[string "LuaGadgets/gadgets.lua"]:829>
	(tail call): ?
[f=0000000] Loading LuaGaia
[f=0000000] Loading LuaUI
[f=0000000] LuaSocketEnabled: yes
[f=0000000] Using LUAUI_DIRNAME = LuaUI/
[f=0000000] Reloaded ctrlpanel from file: LuaUI/ctrlpanel.txt
[f=0000000] LuaUI: bound F11 to the widget selector
[f=0000000] LuaUI: bound CTRL+F11 to tweak mode
[f=0000000] Journeywar: Deactivated Tutorial - you can reactivate with F11
[f=0000000] [widgets.lua] Error: Error in Shutdown()
[f=0000000] [widgets.lua] Error: false
[f=0000000] [widgets.lua] Error: Error in Shutdown(): [string "lups/lups.lua"]:1068: bad argument #1 to 'pairs' (table expected, got nil)
[f=0000000] [widgets.lua] Error: Removed widget: Lups
[f=0000000] [widgets.lua] Error: false
[f=0000000] [widgets.lua] Error: Error in Initialize(): [string "lups/ParticleClasses/unitpiecelight.lua"]:356: bad argument #1 to 'CreateTexture' (Texture Size must be greater than zero!)
[f=0000000] [widgets.lua]Error: Removed widget: Lups
Were to grab a Lups that works with 97?
0 x

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by smoth » 10 Aug 2014, 22:11

no idea

so far my ribbons work but I am getting constant spam about nano spray. I don't even use nano spray.
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by jK » 11 Aug 2014, 01:58

0 x

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by smoth » 11 Aug 2014, 02:31

I am probably running that version of lups but I can try again tonight.
0 x

User avatar
Beherith
Moderator
Posts: 4934
Joined: 26 Oct 2007, 16:21

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Beherith » 11 Aug 2014, 11:24

PicassoCT wrote:

Code: Select all

[f=0000000] Error: LuaRules::RunCallIn: error = 2, Initialize, [Internal Lua error: Call failure] error = 2, LuaGadgets/gadgets.lua, [string "lups/ParticleClasses/unitpiecelight.lua"]:356: bad argument #1 to 'CreateTexture' (Texture Size must be greater than zero!)
stack traceback:
	[C]: in function 'Include'
	[string "LuaRules/draw.lua"]:1: in main chunk
[f=0000000] Error: LuaRules::RunCallIn: error = 2, Shutdown, [Internal Lua error: Call failure] [string "lups/lups.lua"]:1068: bad argument #1 to 'pairs' (table expected, got nil)
stack traceback:
	[C]: in function 'pairs'
	[string "lups/lups.lua"]:1068: in function 'Shutdown'
	[string "LuaGadgets/gadgets.lua"]:831: in function <[string "LuaGadgets/gadgets.lua"]:829>
	(tail call): ?
[f=0000000] Loading LuaGaia
[f=0000000] Loading LuaUI
[f=0000000] LuaSocketEnabled: yes
[f=0000000] Using LUAUI_DIRNAME = LuaUI/
[f=0000000] Reloaded ctrlpanel from file: LuaUI/ctrlpanel.txt
[f=0000000] LuaUI: bound F11 to the widget selector
[f=0000000] LuaUI: bound CTRL+F11 to tweak mode
[f=0000000] Journeywar: Deactivated Tutorial - you can reactivate with F11
[f=0000000] [widgets.lua] Error: Error in Shutdown()
[f=0000000] [widgets.lua] Error: false
[f=0000000] [widgets.lua] Error: Error in Shutdown(): [string "lups/lups.lua"]:1068: bad argument #1 to 'pairs' (table expected, got nil)
[f=0000000] [widgets.lua] Error: Removed widget: Lups
[f=0000000] [widgets.lua] Error: false
[f=0000000] [widgets.lua] Error: Error in Initialize(): [string "lups/ParticleClasses/unitpiecelight.lua"]:356: bad argument #1 to 'CreateTexture' (Texture Size must be greater than zero!)
[f=0000000] [widgets.lua]Error: Removed widget: Lups
Were to grab a Lups that works with 97?
Picasso, that is easily fixable, just open the file with CreateTexture, and instead of passing it a size of 0,0 pass it 1,1
0 x

Google_Frog
Moderator
Posts: 2434
Joined: 12 Oct 2007, 09:24

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Google_Frog » 12 Aug 2014, 06:19

I managed some real battle tests. This engine still has very poor performance.
0 x

raaar
Metal Factions Developer
Posts: 813
Joined: 20 Feb 2010, 12:17

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by raaar » 13 Aug 2014, 18:28

i played vs AI on my game and it worked.

when i press alt-b, GameController:Draw and the ShadowHandler:CreateShadows are shown taking up 99% cpu and 87% cpu respectively, even at the start of the game (doesn't seem to grow as the unit numbers increase). Is this normal? Why?

i may be off, but maybe there's some threads using polling instead of blocking until needed or sleeping for a few ms each cycle.

i'm running the portable version, so it's likely using the default settings.

happens in xta 9.74 as well, not a game issue.
0 x

User avatar
Jools
XTA Developer
Posts: 2804
Joined: 23 Feb 2009, 16:29

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Jools » 13 Aug 2014, 19:29

raaar wrote: happens in xta 9.74 as well, not a game issue.
But isn't metal factions very similar to xta? Just thought that if it is, then the two tests are not linearly independent...
0 x

raaar
Metal Factions Developer
Posts: 813
Joined: 20 Feb 2010, 12:17

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by raaar » 14 Aug 2014, 02:58

Jools wrote:
raaar wrote: happens in xta 9.74 as well, not a game issue.
But isn't metal factions very similar to xta? Just thought that if it is, then the two tests are not linearly independent...
It isn't supposed to be rigorous testing, just thought i'd throw this around here to see if anyone else adds feedback.

Tried evo 7.44, same thing, every time i start a game, press alt-n (hotkey is different, for some reason). GameController:Draw 96%

Then i tested my game again, it seems that even if i disable the fog of war (L key), the GameController:Draw still shows 100%, even though the GroundDrawer:UpdateExtraTexture drops to 0% from 35%. Same thing if i disable shadows.
0 x

User avatar
AntiAllez
Posts: 105
Joined: 06 Mar 2012, 18:22

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by AntiAllez » 16 Aug 2014, 10:13

97.0.1-206-g8576ee8 is still release candidate? Some ATI AMD gpu users have trouble with tiling on map. There are also some issues with resistant settings like fullscreen to zero, had to paste a line into .cfg. That springlobby(v0.196) inside ignore every path change of .exe and unitsync(remains empty), same on v0.197.


Image
0 x

abma
Spring Developer
Posts: 3548
Joined: 01 Jun 2009, 00:08

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by abma » 16 Aug 2014, 15:28

AntiAllez wrote:some issues with resistant settings like fullscreen to zero
you can't set fullscreen via edit menu any more as spring stores the current used setting: type /fullscreen ingame to switch mode. (=feature request, switch mode when fullscreen is changed via edit settings)
0 x

User avatar
Silentwings
Moderator
Posts: 3585
Joined: 25 Oct 2008, 00:23

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Silentwings » 17 Aug 2014, 00:03

Here's what happens when I try to run one of my wip BAR missions with 97.0.1-250.
Image
The PFS-updates queue is sent very high by spawning <50 units on the map at GameStart, and Spring then tries so aggressively to reduce them that the mission becomes unplayable for about 15 seconds.

I haven't yet managed to reproduce something this bad outside of my missions (which unfortunately are not yet easily portable), but has anyone else had similar issues?

edit: It's the map! See post below.
Last edited by Silentwings on 17 Aug 2014, 12:57, edited 1 time in total.
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by jK » 17 Aug 2014, 06:16

where did you got the 85k PF queued updates from? (50 units aren't issuing such many)
0 x

User avatar
Silentwings
Moderator
Posts: 3585
Joined: 25 Oct 2008, 00:23

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Silentwings » 17 Aug 2014, 09:28

I didn't know when I made the post above but I think I've worked it out now. The map GRTS_Rocky_Glacier010 (http://springfiles.com/spring/spring-ma ... ckyglacier) creates a large number of trees on init using (I think) Spring.CreateFeature/Spring.CreateUnit and these are behind the PFS-updates. You can just run that map with e.g. BA 8.00 and have /debug on when the coms spawn to see it happen.

I haven't tested other maps, but I do know that there are several other maps (typically modern nice looking ones) which create their features in this way. I have other missions on various maps which spawn upwards of 500 units in GameStart; I think its a reasonable amount for a mission to create.

Maybe a simple band-aid-over-wound style workaround would be no PFS-updates for units/features created before GameStart, but without spending some time checking code idk if thats a feasible thing. And it wouldn't help the result of a game dev doing a /give all (which is something that I at least do alot while working on BAR).

Sidenote: It doesn't cover this case but, in general, I think its natural to allow the PF to get worse when there are very large numbers of units around. At some level it becomes reasonable to assume that players care more that the game stays running at reasonable speed than about finesse in the PF. I guess 96.0 effectively does this by not trying much to reduce its PFS-update queue, but idk how to test this theory out & idk if -250 has some other mechanism for it.
0 x

User avatar
Silentwings
Moderator
Posts: 3585
Joined: 25 Oct 2008, 00:23

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Silentwings » 25 Aug 2014, 13:33

This (and some other things) are now fixed - in fact, even better than before with showering heaps of kudos for jK. New testing release pls!
0 x

abma
Spring Developer
Posts: 3548
Joined: 01 Jun 2009, 00:08

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by abma » 25 Aug 2014, 16:21

imo at least http://springrts.com/mantis/view.php?id=4519 should be fixed first.
0 x

User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by SpliFF » 26 Aug 2014, 06:27

I was experimenting about a year ago with the possibility of running games with thousands of units instead of hundreds.

I wrote a map script to spawn 5,000 - 10,000 units then used the (alt-b) interface and some C++ profiling tools to try and see where the CPU was being hit hardest, particularly during movement of large groups.

My experiment also included disabling some normal rendering and pathing calls in the engine source so I could focus on particular issues (pathing, collisions and movement primarily) without worrying about GFX lag (or network lag, I was only testing with SP).

I never made any specific or useful conclusions, only general observations and I put it all on hold after zerver announced his MT fork to see whether threading would resolve some of the bottlenecks.

I did notice huge speedups when disabling some move code related to sliding (on slopes) and bouncing (on objects). It appeared that, particularly in large groups, ground units would often end up in long cycles of repeated bouncing/sliding between slopes, other units and features. My suspicion was that the move code would create chain reactions in certain areas where the number of unit-unit, unit-terrain or unit-feature collisions grow exponentially as units jiggle around trying to find clear level ground. That's probably still happening.

I've been waiting to see where the pathing system is going, particularly multithreaded pathing. One day i'll need to revisit it and see what I can optimise and/or sacrifice to allow such high unit numbers to be practical - at least for a single-PC/LAN game (at the moment even SP is a lag-fest on a high-end system once you go above about 2K units).

I like the added flexibility of the adjustable update rate but I'm curious whether changing it on a per-game basis could really provide any tangible benefits. If anything I would have thought the optimum update rate would be fluid value depending on the number and type of units, map properties like size and features and your available CPU time. In other words it seems more like something the engine could manage better itself based on real-time game data than something that should be locked in by the game author in advance.

This is even more true if the values being set in future games are guesswork based on the developers playing style (likes/hates to spam units?) and personal hardware configuration (developer has an old or uncommon PC setup) or copied unchanged from other mods without consideration of the actual desired/undesired effects as they apply to the new game. You could argue developers shouldn't do that but since the alternative option seems to be painstaking trial-and-error with different values I suspect it will happen a lot.
0 x

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by smoth » 26 Aug 2014, 06:38

can we disable pushing again? I liked it before, with pushing units can be wedged into areas that they cannot escape and as you say, they kinda pinball around in large pools.
0 x

User avatar
SpliFF
Posts: 1224
Joined: 28 Jul 2008, 06:51

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by SpliFF » 27 Aug 2014, 03:23

The problem with the push code is that, like explosions, it ignores most of the regular movement rules and applies a basic physical impulse to the unit. This is realistic and efficient but the catch is any unit moved via an impulse can only return to its original position via another impulse in the opposite direction or by following a valid path (compatible with its movectrl). If the units' new location has no valid path to return to its goal (or anywhere else) then it's going to be stuck.

I can only think of a few solutions but they are mostly tradeoffs between performance and realism. Maybe they could be implemented as mod options:

1.) Check for a legal movectrl path between B and A before pushing a unit from A to B. This would prevent units being unable to return to their original position after an impulse but it could reduce realism and increase CPU costs of explosions and pushing. It also wouldn't work for spawned units.

2.) Disable or limit the power of impulses (pushing and explosions) to prevent a unit moving out of its current PF cell. This way pushed units would not require a pathing update and could continue following the current path. The downside is you wouldn't have units being thrown across the map by explosions and that's a fairly iconic TA effect.

3.) Stuck units self-destruct / teleport. A bit aggressive but a game could probably detect stuck units and either destroy them or respawn them in a better spot. This wouldn't really fix anything but it would at least remove battlefield clutter.

4.) Like teleporting but stuck units could be temporarily allowed to "ghost". A ghosted unit might be temporarily given a less restrictive movectrl and collision radius/footprint which it could use to move through/over small nearby neutral* terrain/feature blockages to a better path. (*neutral as in not an enemy unit, building or wall).

These should all be doable in theory but I don't know how much work would be involved or how serious the tradeoffs would be in practice. They also mostly share the interesting problem of needing to define precisely what "stuck" actually means to the engine. In other words, how long must a unit be unable to reach its next goal before the PF gives up or cheats. Also how close to a goal is "close enough"?
0 x

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by smoth » 27 Aug 2014, 04:59

That is what I ended up doing. Nothing has impulse and units have pushResistant. Still there have been times in the past where large moving groups still pushed other units into features and they were stuck.I don't know if the current push resistant can still prevent units getting shoved into places they cannot leave.

I also know in the past, when I gave doms more sliding they would slide into impassible terrain.

There is no real easy solution. Maybe store the direct they were moving in and reverse them out of their stuck spot?

Does push resistant reduce or improve performance? or did you never investigate that tag?
0 x

Locked

Return to “Engine”