New widget: Enemy Spotter

[TradeMark]

i would like to see the % speed difference between your optimized version VS mine... i dont think its that much, that it would matter. few if's optimized out yay...

[Argh]

Then do it. Or go see what mine's like in P.U.R.E., where it's not something I even worried about for 1.3, other than the WG speedup which I applied to everything that gets visible stuff

I mean, seriously... I know you're new to this. But I've already answered your questions about the "why" and provided some time writing most of what you could use to make a fix. Just apply that and get it done.

[TradeMark]

im kind of lazy to fix something that doesnt really need fixing

unless someone can prove my script is 50% slower, then i could fix it for the heck of extra speed...

this is the only widget i use, so i dont much care

[AF]

You dont need proof that it is broken, you have plenty of people telling you its broken coupled with fixes..... Surely it would be better to make the changes provided and shut them up?

[TradeMark]

yeah do the changes, i dont much care really

[Niobium]

So I went and tested it out of curiosity.

Pre-built table of radii wins hands down, 8 seconds vs 25 for weird radius function call. And it also does it with less spring calls, less functions, less code, etc...

Code: Select all

local radiusDefs = {}
for uDefID, uDef in pairs(UnitDefs) do
   radiusDefs[uDefID] = uDef.radius
end

You don't even have to add Widget:Initialize, you can just put that code beside the widget locals.

I can't believe you are defending your function method.

[Argh]

Only 300% speed difference, you say?

I think we can get more than that, if performance was making people cry before. But, as I said, that's the obvious stuff. No creation of locals in the loop. All data about stuff like the radii is pre-built, period. Cutting out an if-->then, if safety permits it.

Here's something a bit less obvious (since somebody's actually testing what I'm saying): write a function that gets the VisibleUnits only once every 10 gameframes or so, and stores those UnitIDs in a table. Then use that table, instead of doing a full inventory of VisibleUnits every drawframe. Betcha you see some big improvements in speed again. Something about avoiding a callout to Spring and rebuilding that data only 3 times a second, rather than 60+

Oh, and I put it in Initialize() mainly for readability, and to be explicit about when it's supposed to operate.

Because, who knows, maybe somebody's done something odd to their Unit loader in their game, or Spring's changed and stuff that's outside Initialize is actually getting executed before valid unitDefs exist, whatever. It's very unlikely that Initialize() will be changed, so it's probably the safest place to build data, imo.

That, and with fancier stuff (for example, using shaders) you need to do that kind of thing in Initialize() so that you can crash the Widget gracefully (hopefully with an error-catcher), instead of trashing the whole UI. There are other ways to develop error-handling, not going to argue about that one- I just think that's the cleanest way, and the easiest to read, flow-wise.

And if you're testing stuff... one last small suggestion: try a textured quad. Since they're, uh, so much slower than drawing circles with lots of polygons.

Here's source for it, should be obvious where to plug it in:

Code: Select all

	SimpleCircle = glCreateList(function()
	    glBeginEnd(GL_QUADS, function()
			glTexCoord(0.04,0.04)
			glVertex(-1,10,-1)
			glTexCoord(0.96,0.04)
			glVertex(1,10,-1)
			glTexCoord(0.96,0.96)
			glVertex(1,10,1)
			glTexCoord(0.04,0.96)
			glVertex(-1,10,1)
	    end)
	end)

Then just define a texture with alpha, etc., in the locals you define at the start of the program:

Code: Select all

local myCircle = "bitmaps/myCircle.tga"

And at the very start of the draw operations:

Code: Select all

glBlending(GL_SRC_ALPHA, GL_ONE)
glDepthTest(GL_LEQUAL)
glTexture(myCircle)

Note that all of that assumes you've localized your OpenGL stuff. I.E.:

Code: Select all

local glBlending = gl.Blending
local GL_SRC_ALPHA = GL.SRC_ALPHA

...etc.

[Niobium]

Yeah, I run my own modified team platter widget. Uses something like 40% of the resources of the original one, with 90%+ of that being the unavoidable drawing.

I'll try that textured quad thing out sometime, I do think it will be faster, not to mention the ability to make much more complex 'platters' for free. Is there a reason for the texcoords being set 4% in?

[TradeMark]

Pre-built table of radii wins hands down, 8 seconds vs 25 for weird radius function call. And it also does it with less spring calls, less functions, less code, etc...

show me your testing code or it didnt happen.

I'll try that textured quad thing out sometime, I do think it will be faster, not to mention the ability to make much more complex 'platters' for free.

idiot, its not "free" >_> it will be even slower.

real life example: complosion smoke, i get 1fps when zoomed in there. now change it with no texture... not even nearly as much lag.

[Argh]

Is there a reason for the texcoords being set 4% in?

It was a fix for clipping on the edges of the quad.

show me your testing code or it didnt happen. --> idiot, its not "free"

I beg your pardon? Somebody tests things, shows a 300% improvement with just one fix, I give you another way to get a lot of speed out of your code, and you're still griping? I mean... hello, if we release the code fixed, you haven't actually learned anything here, and after all this effort, you'd think you'd at least, IDK, give what we're talking about a try, since we already wrote it for you.

As for the "free", no, it's not free. For each major variant, you have to pay the price of uploading a texture to the GPU, once per draw cycle. Ideally, you'd put all the textures onto an atlas, and have each quad variant's texture coordinates match sections of the atlas, but I didn't do that at the time, because I wasn't aware that that was another place I could save on cycles.

real life example: complosion smoke, i get 1fps when zoomed in there. now change it with no texture... not even nearly as much lag

Welcome to Confusionville, population: you. Look, man, that's lots and lots and lots of quads, you're zoomed in, so fillrate is an issue. That's kinda night and day here, and there are all sorts of optimizations, including just using gl.AlphaTest. But seriously... this is not a major source of GPU load, ever. When compared to CEG or LUPS or Unit shaders or drawing the map, it's nothing. Really.

[TradeMark]

you win nothing by texture... thats what im saying

few extra triangles wont make it any slower, rendering a texture is fucking slow compared to just 1 color rendering, and no, i dont mean uploading texture, i mean DRAWING. (they even laughed at me at #lua when i said im reducing the tri count to 8 instead of 32 >_> "AHHAHAHA IT WONT MAKE IT ANY FASTER!!!!!! DOESNT MATTER HOW MUCH YOU MAKE TRIS GPUS CAN HANDLE BILLIONS TRILLIONS OF TRIS!!!!").

[Argh]

On the one hand, they're (kinda, with some provisions) right. A texture isn't free, neither is loading a display list. You have do certain things to draw, CPU-side, it's just part of doing business.

However, if you think that has much to do with why your code's so slow, you're completely wrong.

Drawing a textured quad with depthtest and alpha is very low cost, if fillrate isn't an issue (which in this case, it's not). You're very confused about how all this works, basically. It is not the textured quad that's causing the problems, it's the very poorly optimized code on the CPU side. Anything that draws has many potential bottlenecks- CPU-side setup / data-gathering costs, transfer costs moving data across the bus, and GPU costs, drawing it. As I've pointed out here, most of what's wrong is CPU-side.

[TradeMark]

youre texture is slower... thats where i am right

[Argh]

Well... no, it's not that simple. But, let's say you're right, for the sake of argument. Let's say that mine draws 200% slower than yours, because of the texture reads at every texel.

It still has ZERO to do with why your Widget runs so slowly. The problem is on the CPU, not the GPU. Hence why the fixes that I've pointed out are CPU-side optimization steps. The less time a Widget spends setting up data and getting to the process of drawing, the better perceived performance will usually be, because Spring is usually CPU-bound, not GPU-bound.

IOW, fix it, and you could easily use 1000 triangles or more, make the circles look fairly round. At that point, it would be considerably slower than a textured quad, though, which is why I don't do that

[TradeMark]

what if you wrote a patch in Spring engine which optimizes the read of visible units? o.o because its made in silly way atm

[Argh]

I will probably regret asking, but what do you think is "silly" about it?

[TradeMark]

think what would be the best way to do it... then you'll know

[Niobium]

More testing: Widget using single-textured-quad method uses 50-75% of resource of filled polys.

Tested with some 64x64 gradient texture. So case closed as far as I'm concerned, that it is faster to use texture. Keep in mind that is with a constant amount of widget overhead added to each.

Also by 'free' I meant that if you wanted something more complex than a circle, it's just a different texture, same cost. Whereas for more complex things with poly method, you need to add more polys, which is going to up the cost.

[Argh]

I'm surprised by the result, tbh. I would have thought it maybe achieved 110%, certainly not 75%. I never really tested it that thoroughly, tbh, it was "fast enough".

But I'm sure there's room for improvement there. Makes me wonder if I shouldn't be trying to push that farther with a shader at some point.

Anyhow, thanks for testing.

think what would be the best way to do it... then you'll know

I don't really have time to play guessing-games of that sort. If you see a general improvement that could be made, please let us all know. Defending a strategy is, imo, a healthy thing.

I usually explain my strategy when I'm building something public here, so I know what it's like, having to admit that hey, I came up with something stupid- it's just part of the process, at least for me. Coding's a very iterative process, where I expect to fail a lot before I succeed. Just part of the cost of doing things, tbh.

[TradeMark]

rofl, he just keeps posting his results with no evidence at all. gj man

i just tested my version is 900% faster than yours, wow, i never thought it could be that fast, nice results, GJ ME!

I don't really have time to play guessing-games of that sort. If you see a general improvement that could be made, please let us all know.

hey i dont need to tell you anything anymore, you already defined me as idiot noob, whatever i say its bullshit to you.

i find it funny that Argh is praising anything that Niobium says with no question in his methods at all, just because hes supporting Argh's opinion, lol. "whatever you say, if you agree with me, i thank you"

Oh and btw, you dont need to guess anything, just think hard and make up the best solution.