Sins 2 will be another thing all together. I would expect Sins 2 if it actually manifests itself to be a 64 bit multicore capable game. Packed with all of the bells and whistles that come with it.

Right now we are talking about Rebellion, and the Iron engine that is starting to become dated. Dated only because of the fact that it is 32 bit. TSOP pretty much proved that more can be crammed into the iron engine in its current state. With strategic optimizations of both the code, and the textures. IC took care of the code with the diplomacy 1.2 patch.

The thing you have to ask is just because you can use a 4096 resolution texture, does it mean that you "should" use it? Especially if a 2048 resolution texture yields the same, or similar results. Do you really need a 512 res texture for a particle that is the size of a pinpoint in game?

Another thing to look at is why there is late game cpu lag. Yes, CPU lag. The very same problem Supreme Commander had until recently. TSOP fixed some of the video lag problems, but the CPU lag is due to a game engine optimized for single core 32 bit cpu's. and way too many units on the map for our quad core cpu's that only use 1 core to play sins to handle. 1 core cannot handle thousands of units on a map along with calculating those thousands of units movement, weapons, buff's, debuff's, and ability's. Along with the particles, and effects involved.

The Iron engine handles meshes beautifully as in high poly counts with little hit on performance. That is what really impressed me with this engine.

If the existing engine can be worked over to use multiple cores i think we will have 2/3rds of the problems solved.

I recall, at some point, perhaps it was merely a suggestion/rumor, to make the engine work by rendering certain things on different cores. Ex. Ships on one core, with planets on another. Not sure if it's even possible with the engine, though it would make for an interesting workaround which may help.

Some necro post...

Very true... a recent test with my space station model... look at the video at http://www.love-from-russia.be/g4_swarm-6.25_million_poly.avi ... 125 mobile starbase, with each starbase being around 50k poly, with 3 rotating part ( small neutron star and the two ring ), over 200 weapons hardpoint, 4 set of texture map, etc... and no slowdow...

As for the opening post :

Samaz, the 2gb thing is not a iron engine limit but a OS limit...

Today, i have start a huge multistar map, with 10 races and pirates using 7DS 2.1 ... all setting on very high : this alone crash directly when using windows...

Now, look at the screenshot below :

Game is using a little over 3.5 gb ( 175% more that the so called "2gb sins limit" )... along with a little over 20 mb for wine ( windows compatibility layer )... it is a non modified sins.exe ( not LAA and limited to a max of 4gb )... the only difference is a other OS... Linux ( Kubuntu )... Stardock/Ironclad don't support Linux but sins of a solar empire work better on Linux that on Windows...

The point is that a lot of the sins limit is not related to the iron engine but to the layer below that people call OS...

NOTE : multiplayer work on linux ( need mono for a .NET compatible layer )... Impulse don't work ( unless you have enough linux knowledge for install/compile wine with "winetricks dotnet20 gdiplus" who solve the login problem )... so, for a Joe user, windows is needed for patch... once patched, copy the full folder from windows to Linux...

INFO : http://appdb.winehq.org/objectManager.php?sClass=version&iId=19966 ( trinity on Linux )

everfades, ARE you one of the engine developers for the iron engine?

if NOT, then the LAA FLAG ON works ONLY on 64 bit windows AND STILL only ALLOWS ram use by the 32bit program to reach 4gb before crash  ON 64 bit windows, and with the laa flag off OR 32 bit windows, the program is STILL limited to 2gb.

if you ARE then WHY THE FUCK have you not supplied a 64 bit version of the iron engine???

the cheatengine would be using the LAA flag to do this.

and for your read edification, the MAIN limitation in sins is the LAG at mid-late game from all the thousands of strikecraft, trade ships, frigates,cap ships starbases, structures,weapon shots, particles, effects AND titans that NEED to be updated every fraction of a second, and only one of the causes of the minidumps IS too many ships/structures/strikecraft/starbases/particles/effects, the more common during mod development/use IS minor errors in the mod's files compared with that the engine expects and wants.

harpo

While by default it is a 2GB/2GB split, it is possible to configure 32-bit versions of windows to restrict the kernel to only 1GB of the available 4GB address space and make the remaining 3GB available to applications (though they must be LAA to take advantage of this).

Minimising the amount of resources required is often the best approach to these kinds of problems.

In addition to reducing memory requirements, such optimizations usually also improve performance - TSOP proved this to such an extent that many of its changes were incorporated in to Diplomacy itself.

It is these kinds of refinements that make Sins playable on older hardware, a consideration that you don't often see in today's gaming market.

However, from reading the MSDN article Thoumsin pointed to it would be interesting to see what would happen if the dev's enabled the /LARGEADDRESSAWARE linker flag when compiling Sins - I'm assuming Visual Studio is used.

This would give users of x86-64 systems, and those x86-32 systems with boot.ini changes, the capability of using more memory, without (hopefully) affecting the compatibility of unmodified 32-bit systems and multiplayer.

It was tested and deemed to add too much instability.

Ahh well, it was worth a shot - seemed a solution that might have satisfied a few on the forum without too many adverse side effects.

As harpo99999 points out, you would need one hell of a fast (single) core to cope with the larger numbers of objects that can be stored in the increased address space.

Well, it is your loss.

On a more serious note, the ammount of games that make use of multi core is quite limited, even nowadays. Run one of your games for a bit after starting task manager. Then watch the CPU usage off all cores. You are going to be dissapointed because many of them arent doing much.

Same for 64 Bit.... If your game does not use more than 2 GB of RAM at anytime... there is no point or advantage in running 64 bit.

If your using 32bit XP you likely don't have a full 2GB available for your game even if you have 4GB of RAM installed.

Better still.  StarClad should start working on Trinity/Rebellion for Linux so we don't have to screw about to get better performance out of the game.

I have a question, If 32bit will only allow 2GB per process, then why not add a second process? Would that be possible? or am I way off?

You start Sins and it has Sins A and Sins B processes, keeping the high demand items in Sins A, and storing lesser used things in Sins B.

-Æ

The overhead & complexity trying to do IPC (Inter Process Communication) for Sins would be horrific.

By comparison porting to x86-64 is fairly straight-forward, even multi-threading would probably be easier.