Current issues in Master

[Argh]

I know that some of these things are probably known, but a few of these things are probably ATi-specific, and so I thought it might be a good time to bring this up.

1. In the current master, the minute I select a Unit and issue an Attack command, or any other command that involves a line drawn, Spring's rendering system breaks down.

Problems include Unit geometry being displaced (gl.UnitRaw() on the Lua side borks, while gl.Unit() is functioning correctly), all Unit drawing involving the (new, stock, not-my-shader) GLSL turns white (not being sent the the textures), etc.

It appears that there's a really fundamental bork involving lines still in the code, basically.

However... I've just tested my rain shader using GL.LINES, and it functions perfectly.

It isn't lines, folks. My guess is that it's a texture issue, and it cascades through the whole rendering system, causing errors everywhere. Based on what I see, it's happening at or after the map pass- maybe there's a texture that isn't getting cleared.

2. The way resources works seems to have been arbitrarily changed without anybody bothering to say anything. The "automagical" resources.lua script FLOZi built is not working at all in current Spring. Given that this is kind've important, I'd like to know where we're going with this.

Are we just going to abandon resources.lua entirely, and just do what the "automagical" script does, so that all mods / maps load resources into the CEG texture atlas automatically, if they're in the appropriate archives? That would be the ideal situation, imo- maintaining resources files has always been an arbitrary pain in the buttocks.

That said, I don't have the impression that this was done on purpose, because nothing has been said. I'll test to figure out how to get resources working again.

3. Despite offering quite loudly to put time into writing fixes for ATi, there still isn't any support that would allow me to debug water4 to run on all GLSL-capable hardware. This takes what, 3 lines of code or so, to give me the GLSL error dump in the console? Get it done, please- I want to help, but I can't help if I don't have the tools.

4. Shadows are completely broken on ATi atm. I am suspecting it's related to problem no. 1 at this point.

5. The new nifty map rendering system isn't shadow-aware, and assumes they're on. I've written a "fixed" fragment program that prevents it from borking (see appropriate thread), since I can't run shadows correctly on ATi, but really we need to send a uniform to the GLSL to tell it when shadows are on.

6. I'm still seeing "lua stack check" errors every time a COB requests a CEG. I have confirmed that's what causes the error state, in test after test. This is a major bug, it will effect every game on the engine, and it needs to get fixed pronto.

[Argh]

I've just tested the current build.

1. The "units quit rendering immediately on death" feature is very nice, but I'd like to have some control over that.

In fact, I'd just like to be able to turn it off manually via Lua based on an event or condition- turn off DrawUnit() passes, not gl.Unit() in DrawWorld, basically. Yes, I could do that via Lua in the old code, but atm it's forcing it into an off state on death.

I have complex death animations for a few things, and it seems pretty silly to have to have to write a whole new unit-drawing / shader setup just to handle that, which is the only alternative right now.

2. Spring invariably crashes when I exit the program atm.

3. Still seeing Lua "stack check" warnings, i.e.:

Code: Select all

[    806] Giving 1 fusion to team 0
[    870] WARNING: LuaRules stack check: top = 4
[    872] WARNING: LuaRules stack check: top = 4
[    873] WARNING: LuaRules stack check: top = 4
[    874] WARNING: LuaRules stack check: top = 4
[    886] WARNING: LuaRules stack check: top = 4
[    888] WARNING: LuaRules stack check: top = 4
[    889] WARNING: LuaRules stack check: top = 4
[    890] WARNING: LuaRules stack check: top = 4

This is the result of this COB:

Code: Select all

	play-sound("argh_bombdrop",15);

	move body to y-axis [32] speed [1500];
	wait-for-move body along y-axis;
	
	play-sound("argh_plasmabomb",15);	
	emit-sfx BUILDING_COMPLETE from buildflare1;
	emit-sfx BUILDING_COMPLETE from buildflare2;
	emit-sfx BUILDING_COMPLETE from buildflare3;
	emit-sfx BUILDING_COMPLETE from buildflare4;
	emit-sfx BUILDING_SMALL_COMPLETE from buildflare1;
	emit-sfx BUILDING_SMALL_COMPLETE from buildflare2;
	emit-sfx BUILDING_SMALL_COMPLETE from buildflare3;
	emit-sfx BUILDING_SMALL_COMPLETE from buildflare4;		
	sleep 150;	

And it can *also* trigger the Unit geometry-displacement problem- i.e., it starts happening after this series of errors. Needless to say, neither this Lua error nor these displacement problems were happening in the last release build of Spring. Note that there isn't any Lua callout stuff going on here at all.

So, is this maybe related to whatever broke FLOZi's resources.lua?

Moreover, it appears that calls to Lua from COB aren't all working correctly vs. previously. Calls to my lighting system, for example, work, but calls to P.O.P.S. now fail... in some cases. I will try and investigate what is the crucial difference that's causing this, as it's obviously something very particular.

[AF]

4. Shadows are completely broken on ATi atm. I am suspecting it's related to problem no. 1 at this point.

I remember seeing a commit fix that unbinded shadows at a stage of map drawing, hmmm

[Argh]

Well, it may have fixed the issue related to lines, I haven't seen it with Attack commands since.

The Lua "stack check" bug seems to also cause it, though. IDK whether it's related to /give yet, I guess I need to test that now.

[AF]

i doubt the lua stack check causes, it rather it just happens to also be there.

If you notice, there are lua stack check messages in the current release, not as many as you have listed but they are there.

[Argh]

Hmm. After further testing, the geometry-displacement bug appears to be related to changes in camera position while Units are being built.

If I start building something, and zoom out, everything borks while that Unit is being built, and stays borked until the Unit is built. Then it's fixed.

If you notice, there are lua stack check messages in the current release, not as many as you have listed but they are there.

I'd never seen one before recent builds, so I guess I'll just have to take your word on that.

[Argh]

Hmm. It's related to the gl.Unit callout in the lighting code in some way.

Also I can see Units getting displaced incorrectly (very briefly) if I zoom in and out, even if no gl.Unit calls are occurring via Lua. They "jump" upwards and leftwards, exactly like the errors I see with them otherwise.

To make sure it wasn't something in particular about the lighting code, I replicated the error with the standard x-ray shader Widget:


That's what happens, if you activate that code and then zoom in and out. The x-ray'd geometry is in the correct position.

[zerver]

1. The "units quit rendering immediately on death" feature is very nice, but I'd like to have some control over that.

Yeah, maybe we should keep rendering until the unit is actually deleted.

[Argh]

Well, I'd prefer to control it, really, but I can do that via UnitRendering.

Speaking of which, I don't suppose anybody has a clue why DrawUnit() unit passes are being displaced like that when gl.Unit is being used yet? Kind've breaks everything in my game

[Argh]

Current as of build spring_0.81.0-653-g44caa57.exe:

1. The DrawUnit displacement bug is no longer happening, I think. I will be doing further tests. Thanks to whoever fixed that

2. There's an oddity with Unit Pieces being translated (moved) twice as far as usual. This just seems to affect translation, rotations seem to be fine. It's not happening in every situation, either- I've seen it happen with Activate() events, but not with firing. Very odd.

3. Spring is still crashing on exit, every time I close it. IDK whether I've mentioned that lately, but on this hardware it happens every time.

In addition, something that happens during loading causes the ATi "VPU recover" screen to fire up. The application continues normally afterwards, with no real change in performance observed.

This happens with a fairly large number of OpenGL applications, so I'm inclined to just let it ride for now, it's probably going to get addressed in a new Catalyst.

4. Units no longer report their position if they've been killed but haven't finished their death animations. This is probably going to break a fair number of Widgets.

5. SSMF still isn't shadow-aware. So long as shadows remain completely broken for Unit geometry on ATi, this needs to be fixed, as few ATi users will want to run shadows, and ofc there are lots of people wanting to run without shadows.

If somebody will just change the current code to send a shadow on/off uniform over, I will be more than happy to edit the GLSL end. I have been poking at the GLSL code for this anyhow.

6. Resources is still broken to some extent. Most weapon shots do not get the right graphics assigned. Explosions seem to be working.

[zerver]

The commanders don't seem to spawn after game start. Tried both with "Commanders" start script and a real game via dedicated server.

[BrainDamage]

The commanders don't seem to spawn after game start. Tried both with "Commanders" start script and a real game via dedicated server.

did you read this?
http://springrts.com/phpbb/viewtopic.ph ... 83&start=0

[zerver]

Thanks!

[hoijui]

3. Spring is still crashing on exit, every time I close it. IDK whether I've mentioned that lately, but on this hardware it happens every time.

In addition, something that happens during loading causes the ATi "VPU recover" screen to fire up. The application continues normally afterwards, with no real change in performance observed.

i can confirm this. It happens for me too, under Linux with nvidia.
the crash log does not contain any spring sources, only libc and nvidia stuff. it looks like it tries to free memory from an address it should not. can not see how one could read out more info there, but here is the console output of spring:
http://pastebin.com/nBgjaYW3
spring locks up, can only get rid of it with kill -9