How much can the game be Optimized?

Hah! It's you, you!

Someone go get @brianpurkiss

/the sig says it's Stuart, but I didn't know Stuart played SMNC/

Pressure ...

Get out of here, go back to the depths of the SMNC forums from whence you came!

I've been lurking the PA board longer than you have hombre

Yes they do. Muscle is dense and heavy. A man with muscles is going to be larger than a man without.

On this point I must disagree. A "bigger" man typically is a measure of volume, not mass. Surpassable by the average fat ***.

For that matter, the extraordinary fat *** can surpass any well muscled fellow in every metric of both size and weight.

True. But it still can make the bigger man.

Muscles make the bigger man.

Fat makes the bigger man bigger.

Why settle for a 6 pack when you can have a keg?!

This got derailed fast.

Bigger man maybe, but if we are talking about the "alpha male", well in humans that is a mix of talent and skill and build and execution of action. And confidence to achieve all those I guess. Smaller guys can surpass larger ones, larger ones can surpass smaller ones, it's anyones game and all situational, who really focuses about this shtuff?

Anyway, my comment to the topic, is SupCom was based on old non-modular technology. This game will probably optimize well following the current tech, so anything based on advancement of the current tech will work well with it. A complete changeup of OS except for a unbelievable future linux becoming main OS of the world, or a changeup of the hardware like CPUS using some sort of mass webwork design entirely instead of threads or some brand new design, is the only thing that would dampen this game (and unbelievably mess up any program from today and before). So it is as futureproof as possible.

Also, anything can be optimized by the public at a way later date if a better sequel isn't released for better technology anyway. Such like people done TA and FAF.

I think you are all forgetting the implications of height.

Even if TA or Supcom are not optimized for today's tech, well at least they still run, and that's better than a lot of games over lenght of time. If PA can follow this trend, I'm a happy camper. I like when developpers take time to do a solid, everlasting engine that just work, like the classic doom for example. 20 years later, and all people had to do is quickly patch together a port and bam, we're good for another decade or two. And TA, you didn't had to patch crap, and it still work!!

And while making the PA engine compatible with 3 different platform is tricky and time consuming, like you said it just help to make it futureproof, hopefully!

As for crazy future tech, forget linux or anything like that. It's gonna be ALL Google and their quantum computers. They're gonna crush the puny resistence that the other OS will desesperatly put up. ALLLL HAILLLL.GOOGLLLLE.
Now seriously if you didn't know, check it out. they're prototyping quantum tech.

So is IBM I don't think anything is certain at this point (and btw IBM have been doing all sorts of crazy research in the background whilst focusing on the business market, I wouldn't be surprised if they come back to consumer in a BIG way soon- I mean Apple did it!)

It's a bit of a misconception that quantum computers are going to replace classical computers. While quantum computers may be able to do a lot of stuff a hell of a lot faster/better than classical computers, they also do a bunch of things worse. Quantum computers are not better, they are just different.

Have you guys gone crazy and started replacing bits of heavily utilized code with hyper-tweaked assembly yet? Until that happens, you haven't finished optimizing XD

People probably said something similar to that when they saw the first cars. Big, clunky, noisy, not that much faster or better than good old horses. And yet...

One general rule of evolution, technological or otherwise: It doesn't have to be perfect, it just have to be better. And they are better, or rather, will be. The first car was not really better than a horse, but look at us now. And don't try the "but pollution" argument. Cows and pig farms alone pollute more than cars.

So yeah scientist might have to bust their head to make classic computing efficient in a quantum computer, but they'll do it, and happily, simply because a quantum computer will still be able to do other things better than the classic computer that reached its peek. One step back, two steps forward.

I don't think you can get as low as assembly access in PC software as you're building on top of layers and layers of existing code and drivers that abstract everything from the hardware....

Of course you can. You can't hack around standard libraries, but the most expensive code is usually part of the application and thereby under your control. So you are always free to use inline assembler which translates directly into machine code.

However, it's usually not worth it. Well written* C/C++ already does translate into the most efficient assembly possible. There are only rare exceptions where the compiler isn't aware of the sheer existence of certain instructions or its runtime behavior.

*And there's the catch.
Even experienced programmers often have problems expressing what they actually want. Mostly due to lack of understanding what their code actually means and which side effects it would have in special cases. Because these side effects - even if they don't actually occur during runtime at all - prevent the compiler from doing what the user actually intended, instead the compiler is forced to generate assembly which does exactly what the user told it to do.

If your inline assembler happens to be faster than your C / C++, then it usually means that your code was flawed in such way that the compiler couldn't get your actual intention.
In C++, consequent use of the stdlib can help avoiding that issue, because even though using stdlib in every place possible *might* sound like additional overhead, it's actually the other way around. Strict use of stdlib clarifies your intentions towards the compiler and allows for optimizations which wouldn't have been possible with plain boilerplate code.
As for an example from the C world, just have a look at the restrict keyword. Little known, yet it has an extreme impact on performance.

Quantum computing is not a generalized computing model. It's more of a specialized tool that is limited to doing a few types of calculations that are not practical to compute using a conventional computer. See, for example, the explanation by Prof. Morello at this video at the 5:10 mark. (It's a really good video, by the way.)

No, it's still quite possible, most x86 compilers allow inline assembly code. However, it's very seldom worthwhile anymore because of advances in compiler technology and advances in specialized hardware on CPUs that shuffles instructions around on the fly so that they get executed in the most efficient possible order.

Now, what PA needs to do is to take it to the extreme. Thanks to Intel, it's now possible to create to turn part of an x86 processor into (effectively) a customized chip just to accelerate a specific program. It's really fascinating stuff.

Quantum computer is to computing as plasmids is to genetic advancement.

That is to say: not quite what the public expects. And we can already tweak plasmids!