On the way home from work yesterday, I had that funny idea of dynamic groups. More precisely, when you select one unit, you not only select this one unit, but all of the units that had the same last command issued. Box-select units wouldn't do this, so you can use boy-select to create new groups and issue those groups other commands. I'm not sure if this would be practical, but it would be interesting to try out. It would be a command-oriented grouping system, which would go perfectly with a meta group behaviour, but for sure, this is just pure coincidence.
and who'd've thought. I had problems creating an account for their forum because guess what? my email was already registered. I was a very very old customer of theirs. I used to use their windows themeing app. can't believe they made such a big step up from theming to games!
Same, my name is taken by myself on an account with an email I have no access to anymore since years. xD They have been making games for a while though
I think @cwarner7264 isn't entirely wrong in his assumption. ofc you're right it's much more about the fact it was developed for MUCH older software not to mention for single threaded cores. but while 32-bit games run fine, in the case of larger calculations (such as huge quantities of simulated projectiles like we see in supcom) 64-bit allows for a faster resolution of the calculations. Multi-thread (if they focus at all on threading over at Stardock) will of course yeild way more interesting results. as per this video, they're taking a leap ahead and making sure to be the first on the block with directx 12 which is simultaneously good and bad because it implies that hoping for a linux port is hopeless:
Sorry but that afaik that is completely false. 64 bit means that the cpu addresses memory with 64 bit long values. So you can have more memory. A LOT more memory. That is all. Just having more available addresses for memory do not do anything for calculation speed. In fact it means if you have structures in your code that are largely build up by pointers you will potentially need more memory, as pointers are bigger with a 64 bit application. Ofc only supporting ~3GB of ram is a massive limitation to a game like SupCom, but the sim speed won't be affected. Compiling a 64 bit version of a program also usually is just a switch in the compiler I think (though I don't have much experience with that, it may or may not create issues in code), so it isn't really much more than a setting.
so potentially you could send in bigger values to be calculated? apparently this was why sup com's floats were limited to three digits or something
I have no idea what you are talking about, but I don't think it makes any sense. 64 bit addresses have no influence of on how accurate big floats are. A float is a 32 bit value and will stay a 32 bit value on a 64 bit architecture. If you want a bigger floating value you can use a double, which is 64 bit big. That is true on 32 bit systems as well. Both systems will be slower in working with doubles, as there is twice as much work to do. I don't the the added accuracy of doubles is very useful in games so I doubt doubles are used a lot. What changes is the addresses in the memory. A 32 bit can only use 32 bit for the addresses of stuff in memory, a 64 bit system 64 bit. So it can address a lot more floats, but their size doesn't change. In laymans terms basically 64 bit architecture means that the address on top of boxes are a lot longer, so you can handle more boxes. The size of the boxes does not change. Since the addresses are longer it however means you need more memory to store them. Also about linux support, their FAQ says this:
my bad. still learning this stuff. doesn't the fact that there are more "boxes" speed up the process? and neat find for linux although that's just like saying "yeah mayyyyyybe"
No having more boxes does not generally speed up anything. It just means you need more memory to manage where your boxes are.
Omgggggg... Do want.. <3 Time to spend 99$ (Oh boy I get a dollar) on this! Wish me luck! ;P Edit: How are you not just drooling over this? @tatsujb (even without direct linux support) xD
I am considering it, but I am kinda surprised how they seriously plan THREE expansions and a dozen DLCs. I mean it is basically paying in hopes they actually are successful and do that many extras later on xD
DLC adds thing after the fact that weren't originally going to be in the game. We've been over thiisssss..
well you know the endless DLC tropes. did you ever know these days? when you come from this, makes you feel like we had something special going and now we're just constantly taking it up the butt.
that DLCs are more often then not what would've already been in the game back then had time/budget/the gods of benediction allowed it. not to mention different editions when crossed with DLC:
Well how great that DLC is a term that is extremely generic you could call PA a DLC. I at least downloaded my copy.
It's been sullied to the point it's comical when people attempt to restore some value and title to it. the way it is now, i'd be much better off inventing a new term if you don't mean to scare people off.
Thanks for sharing that, it looks much better when in motion (as compared to screen shots). He said it is a year away so that's good to know.