Rebellion.. The Fourth, and Final Expansion for SotSE....
For all that do not know what TSOP is, or have not been keeping up with current events at all for the last four years. Check this topic. The Original TSOP for Trinity topic.
TSOP was originally created to fix the very annoying 2 gig hard coded crash bug that plagued Trinity. IT WORKED. Without changing any game play aspects of Sins. Without changing the quality of the game itself. During the time we worked on TSOP we found many bugs, and errors that the Dev's missed over time, or that were created with the relentless Sins patches of the past, and new expansions. With the Diplomacy 1.32-1.34 series of patches some elements of TSOP: Trinity were incorporated into Diplomacy. Mainly the Errors, Typo's, and Particle fix's. We are all human, and we all make mistakes. A company as small as Ironclad was bound to make some mistakes. Especially on their first game. I want to make it clear once again that this project in no way is a disrespect of Ironclad, or Stardock. Quite the opposite. You guys made a great game! There is no denying that. We wouldn't be here right now if you did make a bad game.
The goal of TSOP:R Is to add what was NOT incorporated from the Diplomacy TSOP incorporation. We will Bug Hunt, Look for errors, and typos that were not seen before, and Fix it. Just like we did for Trinity. We will convert the TGA formatted textures to the highest quality DDS format possible (This includes the UI textures). Just like we did for Trinity. We will try to put back into Rebellion what was taken out from Trinity (the varying planet types). We will also look into optimizing the new rebellion shadow system some more (if it is at all possible).
Rebellion reduced the size of the ship textures (mainly all of the frigates) to the next size down (by a power of 2). So frigates that had a 2048 resolution texture now have a 1024 resolution texture in Rebellion. Which is brilliant, It is hardly noticeable, and it made lots of room for more Rebellion features. TSOP:R will expand upon that, and bring back the "Strategic Particle Texture Reduction" of TSOP Trinity. There is much more we can do to optimize if we look for it. However, the goal is to optimize without changing the quality of the game, or if there is to be a loss of quality. make it as minimal as humanly possible. Just like we did for Trinity.
We also plan on bringing the Trinity versions of TSOP up to date.
All of this, and more that TSOP:R will do will free up more Ram, and improve your Graphic Performance. So you should be able to run Rebellion on a slightly lower end system, or a not so hot video card. CPU lag is still, and will always be a problem. We tried to deal with it by reducing poly counts on meshes in Trinity. That failed. Poly counts surprisingly have very little impact in Sins. It is the sheer number of units on the map that a Single Core of your CPU has to deal with that causes the lag. The only way i can think of to deal with the Late Game CPU Lag issue is to remove, and/or lower the number of units on the map. We WILL NOT do that. We WILL NOT change any game play, or balancing aspect of Rebellion. Just like we did not change it for Trinity. Let the developers deal with the Game Play, and Balance. We only wish to improve upon the game itself. We Bring..
The Sins Optimization Project: Rebellion
So.. Here we are once again..
TSOP for Rebellion is more of a Graphic Optimization mod than it was for Trinity. Many of the issues that plagued Trinity were fixed by Ironclad/Stardock for Rebellion. So there is no need for any GameInfo folders any more. Also the 2 gig crash issue that TSOP was originally created for has also been fixed. TSOP:R is more intended as a performance improvement mod than anything else.
TSOP, and TSOP:R is an open community project. Anyone who wishes to contribute is welcome to do so. Also anyone who wishes to use TSOP/TSOP:R in their mods, or other projects are also more than welcome to do so. No Questions Asked. This project is for you. Use it!
Do not run TSOP with other mods. TSOP is intended to be a Stand Alone mod. Running other mods with TSOP. Especially Graphic Enhancement mods. Will defeat the entire purpose of TSOP. TSOP is intended to improve your Vanilla Sins experience. Other mods like Distant Stars have incorporated elements of TSOP into their mods.
I will ask that we please DO NOT discuss Multi Core support, 64 bit, or LAA on this topic. It is a dead horse issue that has been beaten down so many times that people are beating the dust on the ground where the dead horse was laying. Its not gonna happen! EVER! The Dev's said its not gonna happen. DO NOT DISCUSS THE ISSUE!!... please.
TSOP:R Release 1.1
All mesh, and particle bad file path names fixed.
Mesh fix's (Unnecessary team color entry's removed)
GameInfo files fixed by Stardock/Ironclad so it is no longer needed in TSOP
All particle, and UI textures converted to DDS format. Some very large texture resolutions reduced.
Optimized Sounds, Music ported from TSOP Trinity.
Optimized Trade ship, Strike Craft, and Constructor meshes ported from TSOP Trinity.
Game holds steady at 1.6-1.7 gigs ram usage using Random Vast Competitive map. Max settings for everything. 9 vicious AI's Results may differ for you depending on your system. No Dev.exe errors were present. No crashes. Late game lag still an issue, but game is playable much longer than vanilla.
See various "Fixed" text's for complete list of changes, and fixes.
Thank you Myfist0 for ModDB link
Well I won't be uploading anything under this "company", but it's nice to have a group of all of us anyways.
Ohhh, getting lots of members
I am basically giving everyone full access except for deleting members or their content. I will keep up the profile.
Just to make sure, this only applies to stuff where the group is set as the company right? Anything I upload under my own projects shouldn't be accessible regardless of those setting.
Correct, 2 separate companies all together. If people click on your name they will see your company, with your access settings, and SoaSE M0dders, with your access settings there.
If you are asking about a mod you upload under SoaSE M0dders, just log into TSOP rebellion and see what rights you have.
EDIT: just tried with those settings in TSOP, I can edit the desc or the image but no delete. Will keep that settings list for members that have been in the community for a while. I dont foresee any problems with regs mucking up others work. If they do, I will swing myfists and give 'em myboot
Well, I signed up for that.
Yup, you should have the rights in the pic above. It will kinda be like the public skydrive that can hold very large files, or upload pics and scoop the direct link for this forum from the embed tag
uploaded here http://www.moddb.com/company/soase-m0dders/images
embed big tag<a href="http://www.moddb.com/company/soase-m0dders/images/dalek" title="Dalek - Mod DB" target="_blank"><img src="http://media.moddb.com/cache/images/groups/1/10/9917/thumb_620x2000/Dalek_StrikeCraft_XLR.png" alt="Dalek" width="309" /></a>
http://media.moddb.com/cache/images/groups/1/10/9917/thumb_620x2000/Dalek_StrikeCraft_XLR.png
very fast, and a good way to share pics across sites
Thought I ask here as I don't know where else. Is this mod compatible with ICO MP games or will I have incompatibility issues if I install this mod? ( I mainly play 5s and 4s game styles).
I am having problems with minidumps, seems to happen most of the time in 5v5 games (maybe the # of players in this game style puts a strain on the 2gb limit). I reduced graphics to medium and turned off all special effects/exhaust trails/shadows etc. but still even today i dumped after about 1.5 hours (which I guess is an improvement to when i played on max graphics which usually resulted in a MD within the one hour mark but still frustrating as it leaves the team one man short each time someone drops).
Thanks in advance.
You "shouldn't" have any issues playing on ICO with TSOP. TSOP does not change, or alter any game stats. Nor does it alter the vanilla game balance at all. As far as i am aware of there are no online issues.
On medium, or default settings you shouldn't be using much more than a gig of ram even on large map/multiple players, and AI vanilla games. Especially if you turned off shadows, and effects. What kind of rig do you have?
It sounds like you are having sync issues. The only thing i can suggest is to try TSOP out, and see if there is any kind of improvement.
Also despite it sounding redundant you should double check all of your drivers to make sure they are up to date.
I suppose drivers as the cause could be eliminated by doing some single player matches against a similar number of AIs as your MP games.
You can check if your game is nearing the 2Gb limit by Alt-Tab'ing to the desktop and looking at the memory usage of Sins of a Solar Empire Rebellion.exe in the Processes tab of taskmgr.exe, although you might have enable the Working Set (Memory) column via the View->Select Columns menu.
If single player games are reliable then it sounds like Major Stress's suspicions may be correct.
My Rig is 7 years old:
Windows Vista
Dual core AMD Athlon 2.7 Ghz (OC)
Nvidia 9800 GTX+
4GB Ram.
My drivers are up to date. Single player games against same # AI's are fine. In fact I've ever ever crashed/minidumped playing single player since getting this game for xmas.
Come to think of it, 5s seem to be the only game styles resulting in minidumps. I played a 1v1 the other day that went on for well over 3 hours on max graphics setting with no problems. I also played a few 3v3/2v2 games and cannot recall the last time i minidumped. But 5v5 games seem to be a whole different story in he last 2 weeks I minidumped in pretty much 90% of 5s games.
As suggested I will keep eye on how much memory SINs is using to see if it gets close to the 2gb limit. And i will try this mod and see if things improve.
Lastly, what causes sync issues? is there anyway to prevent them?
Though it is an old rig it still meets the recommended specs to run sins. I am assuming the video card is at least 256 megs. You really want at least a 1 gig card to get the best from the video. The only bottle neck i can see is the CPU. You want at least a 3 gig, or better. Doesnt matter how many cores, because sins only uses one core. Vista can use quite a chunk of ram just running the OS itself. Check out http://www.blackviper.com/ He shows you how can disable unnecessary services, and processes to see if you can squeeze some more free ram, and speed out of your rig.
TSOP should help you speed up sins. Especially since you got an older rig.
The sync issues have plagued the MP game for a long time, I am not sure exactly what causes them, and i am not sure if the dev's fixed it yet. That issue is a little above my pay grade.
On my computer, the late game still lag periodically. Very strange!
I play 72 planet - 3 star map, 4vs4, all hard AI. My computer is core i7, 2.0G->2.8G, Geforce 550M, 2G video ram, 8G memory. Decent hardware still lags. Not computer 's problem.
I do have some programming experience in optimizing games. See http://tieba.baidu.com/p/2120490946, I have optimized their graphical system so that the FPS (frame-per-second) increases from 9 to 55 (saturated).
Now it seems to me that as long as the game runs single-threaded, no matter how you optimize via modding, it will always lag unless you have a future-standard computer. So is it possible for us to get the game source code to perform a CPU time analysis, i.e. most of the time is spent on what piece of code? Is it really on graphics? Can modding tool do this?
Once we found that piece of critical code, I can convert it into multithread or use SSE assembly code optimization if possible. Thanks!
You are correct in that aspect. As long as Sins uses a single core there is only so much we can do. We try to do the best we can with what we have to work with. Nobody working on this can program. However i took what i learned during my old Homeworld modding days, and applied it here.
You would have to speak with Ironclad, and Stardock to see if they can let you see the source code. They said that they will not re-write the engine themselves, because it will not be cost effective. But if a limited multithread mod under NDA can be done. Then we would be that much closer to this games potential.
"However i took what i learned during my old Homeworld modding days, and applied it here."
What do you mean by this sentence?
I have actually tried to apply the Optimization mod and at the same time turn all settings to minimum. But it still lags a lot. Not much different from that without TSOP and turn all settings to high. I guess it must have something to do with unit update, rather than graphics. Modern graphics card have improved the arithmetic logic for certain computations, so it can do much faster in certain graphic calculations. Whenever there are more units, you've got to process more, no free lunch. The only effective way is to use multi-threading.
Do you have any idea on how to contact Ironclad Stardock?
When Homeworld 1 was in its modding heyday we found out that the game was hard code limited to 32 megs of texture memory. So we found ways to stay within those limits, but improve the texture resolutions themselves. Simply by removing the "waste" of the unused texture spaces. In Homeworlds case we remapped meshes with lots of little textures. Instead of one large texture.
TSOP does something similar Especially with the planet, and skybox textures (upcoming release). By removing the wasted areas, and re-uv mapping a ton of memory is saved. Other areas were just reducing resolutions of some excessively high resolution particles. You don't need a 1024 resolution texture for particles that show as nothing more than a small dot in game.
Converting all particle textures to DDS helped as well. Though some may argue TGA is better, and it is a better format for quality. However DDS textures on the particles uses the mip mapping feature to scale down just as it does on the ship meshes (both in game and in the options). Where TGA doesn't scale down at all.
TSOP was made to help eliminate the 2 gig hard code crash of earlier versions, and the focus was on eliminating graphic memory waste. We tried reducing polys on some meshes. Mainly the strike craft, but it turns out the Iron Engine can handle much more polys than most other games like this can.
I have stated before that TSOP does not help the late game CPU lag issue. Nothing can help that problem. Unless we can find a way to make the game use more than one CPU core. Even then i think if we can make the game use more cores it will only prolong the issue. The real problem is 32 bit gaming. Once 64 bit gaming becomes mainstream we wont have to worry about issues like this. We will have to worry about a whole new set of issues.
Contact SD/IC from the main page.
Unfortunately, I am getting "version differs from host" incompatibility when attempting to use this mod for ICO MP games. Hopefully Stardock will incorporate your mod in the next few patches...well at least here's to hoping.
Good news is all my minidumps seemed to be related to recorded MP videos. Wherefore I simply moved them to another directory and haven't experienced any MDs since; and its already been a few days without a single MD. I've also reduced everything to low and turned all effects/shadows off and, set CPU affinity to single core- dramatically reducing late game lag. \(^o^)/
New discovery...it seems that the "Pressed" and "Normal" versions of some texture sheets (like the ones for ability/research icons) seem identical...however, the brush references include both....I'm not sure if this is true for everything but it seems to be true for a lot of things....
The texture sheets are around 4 megs or so....up to you all whether it is worth the trouble to change every "pressed" reference to refer to the "normal" sheet...
you could get rid of the 'pressed' button sheets but actually they are different though they look the same. The normal button is 47x33 and the image is only 46x32 with the clear space on the bottom and right sides, the pressed is 47x33, the image is 46x32 with the clear area on the top and left. This gives the impression of the button moving when it is clicked. You can re-reference the pressed brushes to call the normal sheet but each brush would have to be changed.
top is normal, bottom pressed
Was
brush name "HUDICON_ABILITY_PSIORBITALCANNON" content "States" Disabled fileName "Buttons_Research_Disabled" pixelBox [ 5 , 253 , 47 , 33 ] Pressed fileName "Buttons_Research_Pressed" pixelBox [ 5 , 253 , 47 , 33 ] CursorOver fileName "Buttons_Research_CursorOver" pixelBox [ 5 , 253 , 47 , 33 ] Focused fileName "Buttons_Research_Normal" pixelBox [ 5 , 253 , 47 , 33 ] Normal fileName "Buttons_Research_Normal" pixelBox [ 5 , 253 , 47 , 33 ]
Change to
brush name "HUDICON_ABILITY_PSIORBITALCANNON" content "States" Disabled fileName "Buttons_Research_Disabled" pixelBox [ 5 , 253 , 47 , 33 ] PressedfileName "Buttons_Research_Normal" pixelBox [ 4 , 252 , 47 , 33 ] CursorOver fileName "Buttons_Research_CursorOver" pixelBox [ 5 , 253 , 47 , 33 ] Focused fileName "Buttons_Research_Normal" pixelBox [ 5 , 253 , 47 , 33 ] Normal fileName "Buttons_Research_Normal" pixelBox [ 5 , 253 , 47 , 33 ]
EDIT: Also, ther is a slight difference in the button highlights
OK, Highlighted is CursorOver
Does anyone know if this optimization mod is compatable with other mods such as Enhanced 4X or Maelstrom?
No, not compatible, possibly combatible
From the OP
First, I'm not a modder or programmer, but I know you guys are. I was reading through Josh Parnell dev blog, that's the guy who is working on Limit Theory. And he came across something that made me wonder, could the same thing be used in Sins. I don't know if this is hard coded in game therefore, be implemented to be of any use. But anyway this is what he said...
This really won't make sense unless you're a programmer, but I'll share it nonetheless. It's probably the most useful thing I ever learned in that operating systems class I took " /> So you know linked lists? Yeah, cool stuff, but usually I avoid them like the plague, because, traditionally, they operate on non-contiguous, dynamic memory. That's asking for trouble in a real-time application. Usually I prefer contiguous storage (a "vector") when I need to keep a list of things. However, sometimes, there is an option that blows both a vector and a traditional linked list out of the water. It's called an internal linked list, and it makes a super clever observation: if you can guarantee that a given element is only going to be a part of one list at a time, then you can directly place a linked list "element" (which could be a forward pointer, or forward & backward pointers, depending on the type of list) inside the type that you're keeping a list of, and use that to do all of the bookkeeping! This way, traversing the list is the same as traversing the elements of the list! It also means that keeping track of the list is the same as keeping track of the elements of the list! Zero extra memory required, zero extra indirection's zero extra cache misses. Whoa!!! It's almost magical. Not sure why I didn't remember this neat trick earlier, but, for some reason, I remembered it today when looking through some code that was using vectors to keep track of things, and I realized I could make the whole thing a lot cleaner, simpler, and less memory-hungry with this approach. After a bit of low-level pain, I had it working, and had replaced several parts of the engine " /> I love these kinds of clever programming tricks. Thanks CS140!
Well..? Thoughts...
Linked-lists and arrays/vectors are groups of data structures that are coded into the executable.
Each element of a linked list has its own dynamic memory allocation, with a pointer to the next element. Double linked lists also have a pointer to the previous element.
A vector/array on the other hand has a single, contiguous, memory allocation for all N members of the group.
Linked list: obj1->obj2->obj3-> ... ->objN
Vector/Array: obj[1, 2, 3, 4, 5, 6 ... N]
No modding will be able to affect the way Sins's data structures are managed by the engine. All that TSOP can do is minimize the number and size of these dynamic memory objects.
That's what I figured, it's hard coded in the game therefore it must be done at the programmer level...I wonder how the current engine reworked, will there be boost in performance and over all drop in ram usage...?
Damn Code Monkeys,... I am a 3D Graphic Artist. Not a Programmer.
It's all Greek to me how the Iron Engine itself works. Most of it is pretty much hard coded from what i gather. You are correct in that we reduced the size of some textures (within reason) to create a buffer zone as to not hit the 2 gig limit.
There are many great features available to you once you register, including:
Sign in or Create Account
