anything against the removal of the SM3 map format?

[Forboding Angel]

Technically true, but the attributes map is render using maths and it stands to reason that if you output coordinates to a list, you get the same thing. Ideally without the massive memory usage of having 4 or 5 maps expanded out like sm3 used.

Sm3 could reliably handle 3 layers, which isn't even remotely close to enough.

[knorke]

None of that makes much sense.

[Forboding Angel]

I am speaking of the difference between a text list of coordinates, and taking an image and draping it over an entire 8192x8192 pixel map.

[AF]

I'm aware Arghs map renderer used a unit as its basis, I'm sure if he was around now and had just made it he would have rendered it directly

But rather than speculate, let's ask the man himself:

Kloot, you're just plain wrong. What you think you're seeing is not the whole picture. The important point that you apparently missed (or glossed over) is that the entire demo runs without rendering the map at all, because that ran more than twice as slowly.

To summarize:

1. The test proves that SSMF is sucking up very considerable amounts of CPU load just preparing data for rendering (let alone the other problems).

When my rendering Gadget is turned off and the map is back to rendering via SSMF, loads are significantly higher.

2. This proves the point that I was making before you and the rest of your coterie of stupid asshats decided to ban me instead of banning the person sending me death-threats, to whit:

A. A static mesh implementation would have huge performance advantages over the dynamic system of SSMF.

B. The issues with SSMF are directly related to the internal implementation (i.e., data read / write and overhead) not to how many triangles are being pushed or the complexity of the shader.

3. Moreover... if a static mesh system was used and a static mesh was used for pathfinding, considerable load-sharing and other benefits would result when running the whole system in MT:

A. The rendering side of the mapping system would not require data from the sim side at all. This would make MT much more plausible, in terms of keeping sync, because it's one of the major sources of large CPU events in the sim.

B. Pathfinding could be almost completely divorced from sim because the data would, again, be entirely static. Sim would pass pathfinding destinations and Unit positions from input, pathfinder would output current path vectors back, sim would update path-following the next frame and update the Unit positions, etc.

Really clean, and path-finding could probably be updated every frame then, with searches for population densities and suchlike to finally solve all those issues with pathfinding that, erm, appear to not have been solved over the last 3 years...



To summarize: given that the cost would be terrain deformation but the benefits would be vastly increased speed, sync stability, artist control over mesh densities, improved use of MT concepts and all that, it's a no-brainer.




But hey, this kind of thing requires people who give a shit and want to talk about ideas, instead of shooting the messenger. It's not my fault you people quit listening, haven't found new idea-people and have largely quit innovating.

Instead, a cursory reading of the "latest developments" indicates a tiny player-base, continuing problems with the BA / TA license (guess that whole, "we're going to make new content and get past the license issues" stuff never happened, huh, and I see ZK was never the replacement you hoped for, either) lack of any modern features worth mentioning (still don't have IK model formats and modern animation systems even though MT should make it a non-issue in terms of load), what little new activity has been done with shaders is largely old forks of the slow-slow Kloot code instead of using the fast stuff I released in that demo, etc., etc. Hell, you people couldn't even port P.O.P.S. successfully!

I've been pretty quiet about all of this. I didn't even bother setting up a new account after the ban. I want nothing to do with a place where Smoth is allowed to roam about unsupervised, I think he's mentally ill and would have been banned anywhere decent and I'm glad to be elsewhere.

But after sharing the last of my work with AF and seeing it get un-released for over a year, then sharing it with FLOZi and getting mocked without a chance to defend my work and the conclusions that arise from it, without an ounce of real testing of your mistaken assumptions, you people deserve absolutely nothing more from me. Good riddance, Spring. It was a cool idealistic thing, once.

I'll get around to putting his stuff up sometime soon. I had to make a handful of adjustments to get it rendering everything fully but nothing major, any of you could have done it given five minutes, and yes, a unit shader, but it does the job

[FLOZi]

To summarize: given that the cost would be terrain deformation but the benefits would be vastly increased speed, sync stability, artist control over mesh densities, improved use of MT concepts and all that, it's a no-brainer.

Yes it is a no brainer.

Terrain deformation is a vital part of Springs appeal, a vital part of several games' gameplay, and removing it would be unthinkable.

I might also point out that those who haven't read the reports and the discussion at the time should perhaps not pass judgement about the banning of Argh.

Nota bene; I was opposed to it at the time, now that I am more informed I probably would have suggested a temp-ban for both Argh and smoth so they might cool off, but I can see why others thought we were past that point.

[smoth]

dunno, argh seems pretty happy where he ended up. I don't really like to revisit all of that. I don't like that people want to bring it up as it is none of their business and honestly it was between us. We started out well and I wish it had stayed that way. I think it was a combination of us both pulling long hours working on our respective projects. We both have very different views on several issues and are very strong personalities. I don't know what this has to do with SM3 but despite my refusal to generally mention the guy and try and joke about it. I feel it was one of spring's darker moments.

do I think it would have been possible to use a short term ban? NOPE. The escalation of things at the time was such that it would have resumed right afterwards.

I don't want to say what I feel wronged about as I don't feel it is fair without allowing him to speak his peace. As I am ENTIRELY uninterested in that discourse I request you lot let sleeping dragons lie instead of stirring up drama for personal amusement.

[Forboding Angel]

Is this the part where I say salmon pink, therefore your argument is invalid?

[smoth]

Is this the part where I say salmon pink, therefore your argument is invalid?

no

[KingRaptor]

So I downloaded SmartBuild and extracted Spring 91.0 over it (I would've used 94.1.1 but the maps are SM3, which 95.0 dropped support for), and ran Spring on the included "You vs. Aliens" game on the map SmokeCity.

Argh's Lua rendering: 40 FPS
Engine rendering (LuaGaia gadgets disabled): 40-41 FPS

Not an apples-to-apples comparison, since the engine-rendered map and the Lua-rendered map are visibly different, and Argh's rendering would presumably be much faster if it was done in C++, but I'm not seeing the dramatic speed improvement regardless.

[Cheesecan]

You could be limited by fill rate. It is not faster for you, but might be on another hardware setup.

Even if you had evidence of speedup on that map, it is completely flat and ugly.

The way I see it, Argh's argument(no pun intended) is rife with fallacies.

[FLOZi]

Argh's argument(no pun intended) is rife with fallacies.

[zwzsg]

Terrain deformation is a vital part of Springs appeal, a vital part of several games' gameplay, and removing it would be unthinkable.

I aren't convinced: Sure, ZK has terraforming, because ZK got to have every conceivable feature, but every other Spring game I know either disabled or lowered to barely visible the terrain deformation.