QA. A Rant.

[quantum]

As I keep saying, replace Spring.exe by a Lua interpreter, or better yet, a readme.txt that says: "Write your own stuff!" and yes, there'll be less engine bugs... but a ton more bug in the mod side of code! So an overall decrease of quality.

Lua features would probably have fewer bugs because of a faster test-fix-deploy cycle. Also the pool of people who can fix those bugs would be larger.

[zwzsg]

Lua features would probably have fewer bugs because of a faster test-fix-deploy cycle.

Not true. When was the last release of THIS? of GRTS? Of E&E? Of Pure? Of Eternal Struggle?

Even an actively maintained mod like Kernel Panic has a slower test-fix-deploy cycle than the engine.

Also the pool of people who can fix those bugs would be larger.

So would be the pool of people who add bugs.

• Bugs would be added in greater numbers because most mod devs aren't as good programmers as the engine devs.
• Bugs would take much longer to find because each mod player base is way smaller than the spring player base.
• Bugs would linger alot longer after they've found, because they'd have to be corrected in the thousand mods that derived the same piece of lua instead of once in Spring source. In fact, bugs in Lua are already impossible to eradicate: When I found one bug in one gadget that I know is used in many mods, I have no way to update them.

And you're not addressing the main point, which is that suddently all the talented artists that aren't too good with coding would be excluded from making Spring games. The barrier entry to making a Spring game is raised everytime you move some functionality from the engine to Lua.

[quantum]

Features that replace engine functionality would go in springcontent.sdz (like it's being done now). Non-coders would not see the difference.

You only need one fast cycle mod to fix bugs in springcontent.sdz for everyone.

[zwzsg]

Well, if it's in /base/springcontent.sd, from a modder point of view, it's like it's in engine: C or Lua, it would still be handled by engine devs, and still something modders wouldn't have to worry about.

[MidKnight]

The best way to test the worth of your arguments is via implementation and direct comparison.

[Argh]

I haven't had time to catch up on this discussion, but I have had time to finish most of the initial work on the map rendering concept.

This is just a WIP thrown together to show the different textures blending, lighting, etc., with 131,000 triangles, running at 170FPS:



Anyhow, I'll work on a more polished demo when I'm done verifying that various things are working correctly and can spend some time on developing something prettier, but it's pretty close to working now

[EDIT]I haven't had time to catch up with all of the arguments, but basically, if we're talking about allowing mod developers to contribute "general purpose" code projects that do things the engine developers don't have time / interest in, but can be done with Lua / OpenGL and would be useful for everybody, I would welcome that and would be happy to submit a number of things. We'd need to write a mod-side Gadget controller, though, so that if you don't want LUPS or POPS or the lighting system or whatever, you don't have to use it- in all three cases, they aren't free to have "doing nothing", due to the way they operate (all but POPS is really cheap, though).

As for the "it'd be buggier than the engine code", that really depends on whether the code's been tested by a wide audience or not. I mean... eh... jK's code on LUPS went through a huge amount of bug-fixing and testing, it's not like he's an infallible god and it worked perfectly the first time he presented it. Spring's code in general has been through many, many, many testing cycles, both public and private, and today's glaring bug often becomes tomorrow's shining victory. I think it's a big mistake to presume things like that, frankly.

I'll bet anybody here a dollar that we'd see some really polished stuff in a real hurry, if Spring included a couple of tech demos for these technology projects in every release, packaged as user toys, and then told people about them and asked them to test it and let us know how it worked for them.[/EDIT]

[EDIT2]OK, so what we're arguing about is whether to get Spring as much out of the "game" side of things as possible, not just utility code. Again, yes, I would like to see that happen. The engine's been moving that way in bits and pieces, in terms of data and a lot of the UI- most of the polished games are using little / nothing of Spring's default UI, other than the buttons code. I'd absolutely love it if weapon behaviors were Lua, if Unit sub-AI was Lua.

Most importantly, in terms of low-hanging fruit, I think that all of the drawing of various types of game objects (trees, Features, Units, and Projectiles) should be handled by Lua OpenGL. It's really a pain in the ass that I can draw my Units with unitRendering (which has some annoying issues that I need to talk to somebody about btw when the map renderer is done) but I can't draw projectiles, Features or Trees this way, and they're all going through different processes, most of which I can't touch at all. I'd have done stuff like my timed vertex-shader for foliage simulation for Spring's trees by now if that wasn't using engine-generated geometry and an ARB shader that I can't do anything useful with.

Anyhow, I'm 100% in support of getting Spring largely out of the "being a game" business and mainly into "being an engine" business. I think it would be a lot less frustrating for the developers in the long run, as they wouldn't have to maintain support for bazillions of hacks that are used by only one or two projects, and I would participate in that in areas that I could- unlike C++, it's a language I know and am comfortable with already.[/EDIT2]

[Argh]

OK, it's ready. I'll try to make time for a demo video, maybe Thursday, to demonstrate reflectivity and lighting, as this scene is just the basics. It's running at > 300 FPS in overhead view, about 180 here, and this is static geometry, we could almost certainly get a lot better performance w/ ROAM. Click to enlarge, and you can see the normalmaps (it's subtle here because I've turned reflectivity to zero in this experiment). And yeah, the detail level is whatever, just like SM3, except that it's running at about twice the speed atm.

IDK what's wrong with map rendering on this engine, but there is definitely something wrong, because I'm no genius and my crappy orkish demo code, which is doing all sorts of Things That Shall Not Be Named (seriously, it's almost Cthulu-esque evil, awful hacks)... is running twice as fast as the best thing built in atm, and looks better than either SSMF or SM3- and again, I haven't even built the impress-the-neighbors demo map yet.

Are we all in agreement yet?



Too bad shadows are broken, it'd look pretty nice, and this is with crap tiles that I had sitting around, not a set developed for this technique

[Forboding Angel]

jK's code on LUPS went through a huge amount of bug-fixing and testing, it's not like he's an infallible god and it worked perfectly the first time he presented it.

BLASPHEMY! SHUN THE NON-BELIEVER! SSHHHHHUUUUUUUUUUUNNNNNNNN!

On a serious note: @screenshot, you have my attention.

[Argh]

I appreciate the vote of confidence.

You do NOT want this as it currently is, though.

It's... well, it's a proof of concept. I could use it for production, but I'd have to kill bunnies or something, because it's so evil and nasty. But the shader's solid and I have a pretty good idea of what we should probably be doing now- I explored this and multi-pass stuff (multi-pass in OpenGL comes with extra evil <shudder>).

[Beherith]

and looks better than either SSMF or SM3- and again, I haven't even built the impress-the-neighbors demo map yet.

Are we all in agreement yet?

Look at any of the following: Blindside_v2, Moor_v2, Mescaline_v2.
When you get something that looks at least on par with those, feel free to tell me. Until then, cease the hand waving.

[Argh]

You'll see it.

This is just the basics.

I'd also like to point out that this is less than 8MB compressed.

And when SSMF has these performance numbers, you'll still have that problem.

Anyhow... I'm tired and grouchy now, and I am not trying to pick a fight. If anything, I want you to help make this something everybody can use, not something that is effectively proprietary. I have a plan, I'll talk about it when the demo's ready. I am pretty sure that it will be pretty convincing.

I think we can turn this into a system that allows realtime editing in the engine.

That is why I wanted help with whatever is fubar'd in the lambert when I displace verts- I did experiments, and a vertex shader displacement is almost as cheap as static. IOW, people could edit in-engine, see exactly what players will see, edit in realtime- we can't have all the glorious bells and whistles of StarCraft II's map editor (which you should go look at videos for, because it's brilliant) but we can get a lot closer with one major piece of tech.

Instead of third-party tools, we can even do stuff like erosion sims with Lua.

IOW, endgame for performance issues, beauty issues, compatibility problems (this will run on GLSL 1.x-capable hardware) and most of all map size for distribution of projects. I am actually pretty hopeful that this can meet the goals SM3 attempted to get to. And of course, in no way, shape or form am I advocating that we remove SMF, or anything like that.

[Forboding Angel]

Well what you're working on looks as though it could be a proper sm3 replacement, which is interesting to say the least.

[AF]

I would like to see code, hackish kludges or not hackish kludges, I want to see how you've done it.

My suggestion is that you would need to reimplement shadows, and disable the engine shadowing. The engine shadow implementation is an almighty kludge. SJ didn't understand what he was doing at the time and did something wrong only to find it magically worked. Since then nobody has touched it for fear of breaking things, or being pressured into the eventual shadow rewrite.

[Argh]

Maybe after the demo.

As for shadows, I think the solution's pretty obvious. Everything needs to be in a scenegraph, and shadows would get computed in a single pass. The way it's done now is a mess- nearly half a dozen shaders, all operating slightly differently, for different objects, all using different matrices. We need to handle all non-specialized geometry in a uniform way.

OpenSceneGraph (where I think we need to go, because it's already there and done): http://www.openscenegraph.org/documenta ... 00661.html

Various stuff about deferred handling of shadows via scene graphs (that g-buffer idea in the first is actually mentioned in the killzone slideshow):

http://hacksoflife.blogspot.com/2008/08 ... -maps.html

http://www.slideshare.net/ozlael/deferr ... killzone-2

https://goblinxna.svn.codeplex.com/svn/ ... pShader.cs

And something badass- perhaps somebody here should talk to these people:

http://gamma.cs.unc.edu/LOGPSM/

[Argh]

OK, been kind've busy and away from the 'net for a few days, but I wanted to make some important announcements:

1. I made a breakthrough with jK's shader framework. I think I will be able to make the map rendering system and all the work put into the unit shaders available within the framework. IOW, I have some pretty cool stuff to give out now; getting a decent facsimile of what I got working with Kloot's shader working within jK's framework and getting jK's stuff to compile on ATi was a big step forward in terms of providing people with a general material system. JK, FYI, it's pretty much that last set of fixes I sent you many months ago, except for the new shaders. Pretty excited about this.

2. I've got shadowmaps working on my hardware, including in the shaders. Turned out that Units weren't casting shadows because they were using my version of Kloot's code, which had a number of clunky hacks in place to avoid other issues. I found this out by accident while playing around with porting it over to the framework; basically, this means that I'm going to have it all working 100%, in terms of rendering

3. I've built version one of the demo map; still not 100% happy with it, but I'll get more done tomorrow evening, and then maybe I can add some bells and whistles.

4. The one major feature for the map renderer that doesn't work is ground-flashes, because I'm not drawing the map. Anybody have a way around this issue? About the only idea I've had is to use a cut-to-nothing SSMF where it just ftransform() --> discard, and uses 100% tiling with alpha set to zero, for minimal CPU, no drawing, but would allow these things to render normally. Dunno whether it'll work (alpha-mask issues) or whether it'll be slow (it'll be a good test for one of my theories about why it's slow, though).

Anyhow, I'm guessing it'll be at least another couple of days; now that I'm fairly confident that I'll be able to present multiple Unit shader variants in one package, I'm very excited about this, it could be useful for a lot of people, even if nobody uses the map stuff... which I have gradually gotten from the total-kludge stage to almost-a-science stage, but it uses a technique that is probably not going to be easy to replicate with other modeling setups due to scalar issues (meh, I'll explain that later, if I ever bother documenting it).

Very excited though, I've been working on all of this stuff a long time, and haven't had a good way to package it for people to use, and now it's all falling into place.

[KaiserJ]

looks pretty decent... but... what is it exactly o.O i read what you wrote and i dont understand at all

edit : in terms of relevance to my interests

[Argh]

Basically, it's a way to deploy a lot of shader stuff in a hassle-free way. And some shader stuff I've been tweaking for awhile.

And it is also a way to make maps that can do new things.

Still working on things, it's not perfect, but here are some screenies:







There are some fairly serious problems with UnitRendering that I need to talk about later, though- long story short, when you have > 4 textures, stuff starts going sideways and I have to force gl.Texture in the predl, amongst other things...

[AF]

hmmm Id think multitexturing would be a little dubious at best, cant you just rerender the unit but with the second/third/ etc textures? It'd be more robust/flexible in terms of graphics card support

[Master-Athmos]

Looking forward to your final results!

[Neddie]

Well, good to know we're all trying new things.