I'm saying I only tend to get slowdown on large offline Tf2 botmatches but never on supcom2.

I'm not questioning anybody's intelligence. I'm just trying to formulate my inquiries so as not to exclude anyone because of their training (this has nothing to do with intelligence. You can be a very, very smart person, but if you don't understand the language of mathematics because you find some other profession more interesting...).

Even though we don't have an explicit algorithm, we can still get a rough idea of what's happening.

Let's say we have n units in play (they are all units of the same faction). We want to move all these n units simultaneously. The first thing we need to do is a scan to identify and locate all these n units. That has an execution cost E(n,s), where s=scan. Now, we have to (1) compute the paths, and then (2) move.

Let's divide our n units up and scatter them across the map. Lets say that the units on the left side of the map have very simple unobstructed trajectories. Because all these n units are being issued the same command, what will be the execution cost using A* vs FF?

If we use A*, the left units can start moving at the outset. However, with FF, their movement is delayed pending the calculation of the paths for the right side. Why??? Their trajectories are independent, yet the FF algorithm will at least attempt to analyze if the movements can be combined - this is an added calculation. And in the case where the paths are disjunct, this extra calculation will be useless.

If we consider A* from the outset (p stands for paths):

E(n,p) = Sum(i=1..n) i(p_i),

i.e., the sum of all n units where i(p_i) denotes a path function of the ith unit that is itself a function of the ith unit.

Now, in the case where there are no overlapping paths among the units, we still have,

E(n,p) = Sum(i=1..n, j=i..n) i(p_i) + i(p_i,j)

i.e., all the individual paths still have to be calculated i(p_i), but now there is a superfluous cross term to calculate the paths between the ith and jth units to see if there is any overlap. If there is not, then you've SIGNIFICANTLY increased computational time because for every ith unit being considered, you have to calculate n-1 subpaths (note the interview with CT where he said that the actual calculation is more intensive than in FA).

So, for FF, for every ith unit where there are no overlapping paths, you are practically increasing the cost by a factor of n each time! (Technically, n-1, but overall it's still on the order of O(n*n), which, when you have a lot of units in play, is HUGE compared to just O(n)).

Also, we have to consider the case when using FF, of having units overlapping more than one possible path trajectory. Therefore, we still need a further computation to determine which trajectory the unit will actually take.

The use of FF might be good for closely packed units following a strict trajectory, but it is by no means outright efficient all the time over A*. In fact, using the two methods together and deciding which is most appropriate to use pending the initial scan (for example, only units within a certain radius of each other are considered for FF) would be a much needed improvement.

Initially, it had little impact because we were using placeholder terrain that looked horrible. Shortly after the renderer went live, the first "real" map was added, the Borehole. That was the biggest, "Holy crap!" moment of the entire project, and I think the entire team got totally jazzed because it was the first time we realized that we weren't just making tweaks to FA. At the time we were still using the old UI (hacked together to do the research tree) and units for testing, and it still didn't feel like a new game.

The process relieved stress from the cpu onto the gpu what should have been processed by the gpu in the first place!

But that aside, what are the prospects for the current engine to actually off-load to the gpu (or gpu's in some cases) some of the cpu-specific instructions? And if this is possible, how would this off-loading scale with changes in graphics settings? This way, at least some of the cpu stress can be relieved without sacrificing the mono-core cpu market.

Would GPG consider releasing the engine (with the old A* pathfinding and no research tech tree for SupCom 2) as a patch update for FA? You already have it, so there is no additional work to be done. I think that would go a long way to maintain a fanbase for the franchise and show you reasonably care about supporting your products. It has been a long time that any update has been provided for FA, despite that FA is very active on these forums and in the modding community.

Physics has nothing to do with pathfinding.


There are on a per-unit basis because the research system lets each unit have more weapons systems and effects. The base tank is the equal to a tank to SC/FA, but then you add AA and a shield and extra barrels, and those are all new projectiles and effects and weapons and targeting systems. If you threw 4000 SC/FA tanks into battle versus 4000 base tanks, it may be a wash. But if it was 4000 fully researched SupCom 2 tanks, I'm guessing the SupCom 2 ones are more CPU intensive when it comes to effects, projectiles, and weapons. The pathing improvements and rendering improvements would give you savings. To what degree, I have no idea.


It's possible, but on the biggest maps in FA with 8 players all at the unit cap, it will go over 2GB of RAM use. Not to mention it'll run painfully slow. Hell, do the same on Seton's in both games. Despite what everyone seems to think, the maps are identically sized in both games. (The SupCom 2 version was built from the heightmap used in FA.) If you look at RAM use, FA used to sit around 1.5GB, whereas SupCom 2 would be 500-800MB.


By focusing almost exclusively on multiple core development, you risk cutting out every single core CPU in the world. This is a bigger problem in some regions than others, and an even bigger problem today with the rise of single-core netbooks.

It's the reality of PC development; you either target the high-end and risk lower sales because you cut off wide swaths of potential players or you try to balance your development. Most of the work is done to make it playable across a variety of GPUs, so single-core CPUs are often the baseline. With infinite time and development resources, you could make multi- and single-core versions, 64-bit executables, etc.

Ironically, console development forces multi-core development. It also forces you to lower your RAM requirements and speed up load times, both of which are good things for overall performance. They force efficiency, whereas pure PC development allows a lot of slop.


That's not how it works. All of those bug fixes and tweaking are based on over a year's worth of engineering work, so you couldn't revert the entire game to November of 2009 (or whatever cutoff) and hand it off as FA with a new renderer. At that point, it's just a broken version of FA with a first pass at a new renderer. That next year is when everything started working and became more efficient.


I'm going to go out on a limb and say there's no system in any game that's "fully optimized." I've spoken with the guy that did our pathing, and most of its subtleties are lost on me and makes my brain go "glop."


The rendering of effects is done on the GPU. The calculations that go into whether the effect is on or off is a CPU task.


It's possible. I have no idea as I've never looked at those systems, and they'd likely be beyond my skill level, regardless. I know there were plenty of bugs regarding lua processes that were never ending that were addressed during development, and there are probably still bugs that could cause slowdowns over time.

The way the engine was originally architected, it used lua for a lot of its systems. Take what I'm saying with a grain of salt as I'm not an engineer, but it's my understanding that while useful for development (more people can handle lua than C++) and modding, it proved problematic because of the lack of proper debugging when things didn't work, a lack of garbage collection, and the general inefficiency of a script language versus a compiled one. The lua code didn't scale very well when it was suddenly tasked with managing thousands of units and processes. This is one of the primary reasons that a lot of that code was moved to C++; more would've been switched if we'd had the time.

That couldn't be further from the truth. It's not that simple. Content from SC2 is almost completely incompatible with content from SC/FA. If you want a few quick bullet points:

* Every map would have to be remade
* Every texture would have to be re-exported
* AI would have to be rewritten (why would SC2 have a working AI for SC1 units?)
* UI would need to be redone (old Lua UI codepaths are gone)
* GPGNet network code would have to be readded and Steamworks removed

And those are just a few major issues from the engine side. There's still tons of content and tuning values that have been updated or changed that are referenced differently between the games.

I would have figured that someone in your field would easily understand these technical limitations. It's like asking why can I plug my SATA-II hard drive into an old system that only has IDE.

If you're talking about how some of the math software works, yes, that would be an ideal scenario, but it's also pretty custom to GPUs. Physx does this for you, for example, but only with Nvidia cards.

I'm guessing you'd have to code ATI, Nvidia, and Intel versions, and another version for when the GPU can't handle those calculations. Then you'd have to load balance between rendering, and you'd have to be concerned about how videocard drivers may break your entire game to an even greater extent.

In the end, it would probably take less work to do single- and multi-core development.

This thread is now about bazookawhale

From steveb's post, it sounded like the porting of FA was to the new moho engine and not the SupCom 2 framework - no FF, no new units, just the graphics rendering update. And only once that was accomplished then major development changes were undertaken so as to differentiate FA and SupCom 2. That's the way I understood it. steveb said that it didn't feel like a new game. So, I figured you guys had something playable very close to FA.

I understand technical limitations. But I never attended a GPG board meeting to know what was on the agenda.

Lua's approach to memory management constantly irks me. It collects it's own memory, which is great, but really sucks if you need it to tell you so you can collect your memory that's referenced from Lua. Compared to the ease with which automated memory management can be implemented with a modern compiler in C++, it's fairly ridiculous. I would love to implement scripting for more of my own applications, but constantly having to manage the memory for them drives me mad.

Just out of curiosity, which compiler do you guys use?

Sure, our playable version of FA was FA.

We're talking about the earliest days of development here. Like, the first few weeks, maybe a month or two. We hacked in proof-of-concept versions of the research system, unit upgrading, and other gameplay systems in FA while engineering worked on the new renderer and other underlying systems, and art was working on unit and map concepts and building some 3D terrain in Max. Once we realized the gameplay changes were fun, we moved ahead and started to implement those systems properly.

Visual C++. I'm not sure what version, since I don't have a copy on my box since I wouldn't know what to do with the thing.

I read an interview with CT where he said that you guys already have the mod manager programmed into SupCom 2, but just haven't enabled it yet (http://ve3d.ign.com/articles/features/53364/Supreme-Commander-2-PC-Interview/p3/c1/).

The community has reached a straining point where we would like conclusive answers as to whether or not the mod manager will be activated. I know you guys have a business model and that DLC can always be a potential source of revenue, but if that is the approach that GPG wants to take, can we at least get a conclusive answer?

Has GPG contemplated the possibility of taking an approach similar to the StarCraft 2 EULA in mandating that all custom content belong to Blizzard?

Is it a money issue? Because you guys know that modding support is greatly desired by the community.

Also, to what extent will 3rd-party modding be able to revert some of the gameplay changes back to FA, namely, deficit banking and a tier construction system? I think those two changes alone would be enough to placate die-hard FA players. We'll keep the research tech tree, but get it to do something else...

If they wanted to release a mod manager, I imagine they wouldve done that months ago. I would HUGELY appreciate one though.

Visual C++ makes sense for two reasons: 1) it provides a direct link with the underlying Windows framework and allows Win7 to be more aggressive with cpu optimizations, and 2) you can still compile to unmanaged code.

For computations on the GPU, DirectX 11 has this new feature called DirectCompute which to the best of my knowledge allows DX11-enabled GPUs to do general computations without being limited to a specific brand. But the problem here is that coding KnC or SupCom to use DirectCompute would lock out all users who didn't have a DX11 card or used XP, as well as making ports to other platforms more or less impossible.

Just a question to the GPG devs who can respond: to the best of my knowledge, the Moho engine uses 2 major threads (sim and render) and about 20 other minor threads. So the engine cannot really use more than 3 cores (1 for sim, 1 for render, and 1 for the other 20). Would it be possible to divide the workload among more threads? Like separate the AI or pathfinding into a separate thread? Would that take a titanic amount of time and resources?

Just make sure that the bottleneck is not from the pathfinding algorithm itself or the engine. Because if that's where the bottleneck is coming from, you wont max out cpu usage even on a single-core if the cpu is powerful enough, and therefore multi-core processing wouldn't make a difference.

As for multithreading, that's not difficult in and of itself. The problem is to take into account mono-cores. Does GPG ship two exe's, one for multi-core and one for single-core? Also, if you're talking about multi-core, you have X2, X3, X4, X6, etc. to consider. So, which one do you target? If you spend a lot of time and resources to target say, X2, and if that's a dying market, then you only get a marginal increase in performance as oppossed to going X4.

Also, I'm kind of perplexed that mention was made of netbooks. Please don't tell me that GPG is targeting netbooks???

It's a part of the market share madface

Not only that, but some magazine or something somewhere announced this year marks the upcoming death of the PC after this year's CES...

...or something like that.

Yeah, netbooks, tablets, and smartphones are the future. One of my friends is a complete believer in the mobile sector. He thinks that the mobile segment is the future, it is the growth industry, it is where the innovation takes place. He thinks that the age of the desktop PC is over. I disagree to an extent, I think the PC will still hold an important position for the foreseeable future in gaming, professional work, and performance computing, but really the main growth market right now is mobile, on tablets and netbooks and smartphones. Desktop PCs aren't cool anymore to mainstream consumers.; they want a smaller, more mobile device. GPG would be foolish to not target those segments of the market.

But even on those mobile devices, dual-cores are starting to crop up. I believe several manufacturers of tablets announced dual-cored versions of their products. The only problem here is that those dual-cores are ARM chips and don't support the usual x86 instructions that most PC CPUs do.

Hmm, with the mention of netbooks, I wonder if GPG's secret project has anything to do with them. Moho engine on netbook in the future? Unreal has been ported to IPhone, so it's not outside the realm of possibility.

Just to throw that out there I'm studying to become a diesel mechanic. Everything I do is totally hands on and I learn from real examples.

From what I experienced SC2 is just as graphically intensive as FA. I was able to play seton's games on my machine in FA with lag only after an hours play. SC2 is the same way after an hour I have the same problem. Keep in mind that I was able to play crysis wars ice level on high settings with no lag. IMO once SC2 gets to the point where it has to cope with space temples, shields and KK's it starts to lose performance.

Also steveb said that seton's was the same size. What's the scale difference between FA and SC2?

Units in SupCom2 are generally 2 to 4 times larger than their FA counterparts. The Cybran ACU was height 2.2 in FA but in SupCom2 it is 5.

Want to convert that to something that makes sense? Like feet and meters.

FA had a mod manager, so some of that code is swimming around in there, but to do a full-featured one for SupCom 2 would be a non trivial amount work, nevermind the added complexity and costs if we chose to host them.


DLC has zero impact on mods. It's simply a question of time and manpower and priorities.


That wouldn't be our call.


Everything is a money issue on some level, in that features take time, and time costs money. If an engineer spends a month working on a mod manager, that means it cost X dollars, and took away from doing Y and/or Z.


I wouldn't put anything past modders, but the amount of content work required to match the tier system of FA would be sizable, and changes to the UI would be difficult. I'm not sure if the economy is exposed in lua or is all in C++, so it may or may not be easy.

Multiply all distance measures by 19.5 meters. At least that's how it was in FA according to SupComDB, although real world metrics are useless in this situation, only the engine values count.

Also, steveb, thank you for the time you spend answering our questions on this forum. We are well aware that you are taking time away from doing other more important things to talk to us.