Tiron_Raptor Posted January 11, 2012 Author Share Posted January 11, 2012 I understand that, but on my reading, there's a heck of a lot of hyberbole & speculation still in the white sections - maybe that's just my reading of it. I just would prefer to see it kept to known facts, and leave the speculation for the thread itself. For an equivalent example, you don't go labelling a process a rootkit until you are very very sure of what it does. Even the thread title assumes and implies a copy protection system in place. A newcomer is very much led down a given path of thinking. You still have statements like: Which is why all the other stuff is colored, locked off, etc: to make sure it gets noticed. As more information comes out it'll continue to be updated, and all the 'rampant speculation' will be gone. Seriously, what exactly is the news about TOR having two processes? Out of process communication & proxy processes are pretty commonplace. I've written two in the last year for our product; it enables you to do all sorts of things. Please stop with the utterly unhelpful rampant speculation as to what they do. You don't know unless you've looked at the code. A bunch of numbers is frankly meaningless statistics about activity, not what activity they are doing. Of course those two processes are going to communicate - they wouldn't be there if they weren't. It's not news, but an unrelated thread that I linked in the OP, talking about UAC of all things, mentioned in passing that the fact that it's apparently tied into the remoterenderingserver.ibc could be why one of the processes was requesting elevation. He had it listed in that thread as being 'swtor.exe @remoterenderingserver.ibc' Where he got that from I haven't figured out yet, but it suggests a connection, as you posit, to the remote rendering system. Depending on what this 'remote rendering' actually IS...it could be substantial or nothing at all. We're just now starting to get some decent data to determine which. Has it occurred to anyone at all yet that the words Remote Renderer mean 'remote as in another process' because I'd surely consider calling a remote rendering server that I run next to the main app so as to work around 32-bit address space limitations exactly that. Yes. The question is why you'd need to run a 'renderer' alongside the main process, and if that could explain, somehow or another, some of the problems we've been seeing. Everything from simple latency added in to certain things because of the extra processing time to poor performance when having to wait on it to do...something. Link to comment Share on other sites More sharing options...
Bluebpy Posted January 11, 2012 Share Posted January 11, 2012 Not sure what game your playing, last i checked graphics are defaulted to medium...And if your getting 20 frames your pc is a pos. yep I-7 920 overclocked to 4.3ghz 16 gigs of ram 2 460's overclocked in SLi runs battlefield 3 maxed out at over 70fps total ****..... I'm no the only one with these problems. there are tons of people Link to comment Share on other sites More sharing options...
DarthSublimitas Posted January 11, 2012 Share Posted January 11, 2012 Think for a moment. Outsourcing rendering for 100.000's of clients. You got to be kidding me I do not think this is even possible and if it is, it is a stupid thing to implement it. There are ways to do this more intelligent and uses less resources. There are certainly issues with rendering and high texture availability. Even though I have a high end machine, in some outdoor areas, the game runs choppy while my fps is still 80 (with AA x8 enabled). Also at off peak hours, while I do have a good internet connection, I usually see 1000+ ms for a second and then it drops to the normal 30ms. On peak hours there is no problem at all, go figure. Above problems never occur in any other game I play! For sure Bioware is doing something which gives a lot a bad performance, but outsourcing rendering can not be the reason. If only Bioware is communicating with their player base as some (Trion for example) does. I support this thread though. Yes your point is valid. If not for the reason that they were being cheap and cutting corners, outsourcing and using a piece of garbage system of Hero Engine and not using an in house solution like most professionals do, then I guess we wouldn't be suffering from all these issues. Link to comment Share on other sites More sharing options...
boomxi Posted January 11, 2012 Share Posted January 11, 2012 Then go pirate it. That's the delicious irony of DRM. No matter how much we want to actually pay for a game, the pirated DRM free version is almost always higher quality. THANKS FOR THAT UBISOFT! Actually no, best answer you can give is ignore publisher/developer and never buy/pirate any of their products. It's what I've done with codemasters. No matter how good game may be they're on my **** list, I will never pay for another game I will never play another game made/published by them. Link to comment Share on other sites More sharing options...
nonforma Posted January 11, 2012 Share Posted January 11, 2012 Sorry, I don't see it mentioned; could you quote the bit you mean? If I'm just being blind, then no worries Bottom of the first paragraph: [Edit: it has been stated further on, but not confirmed, that the 'RemoteRenderer' is just part of the normal rendering system, and may be a renaming of or replacement for an original Hero Engine Component: The name may just be a coincidence. Hard data needed.] Not trying to be a dick, but not everyone here is just flipping out with speculation. Link to comment Share on other sites More sharing options...
McButter Posted January 11, 2012 Share Posted January 11, 2012 Bioware.. we are not console gamers, we aren't sheep. We are pc gamers. We are smart and will find problems and call you out on them.... NERD ANGRY! NERD RAGE! ARGHHHHHHH! Take a deep breath, step away from the keyboard and relax for a few. Link to comment Share on other sites More sharing options...
Mannic Posted January 11, 2012 Share Posted January 11, 2012 (edited) So per SR the textures that we're seeing in cut-scenes now are the high-res textures? They're "high-res?" Really Bioware? Really? Edited January 11, 2012 by Mannic Link to comment Share on other sites More sharing options...
Tiron_Raptor Posted January 11, 2012 Author Share Posted January 11, 2012 (edited) Sorry, I don't see it mentioned; could you quote the bit you mean? If I'm just being blind, then no worries It isn't in the OP so far as I know, not directly anyway. It's hinted at, but mostly only discussed in the posts themselves and easily missed... Maybe I should fix that... So per SR the textures that we're seeing in cut-scenes now are the high-res textures? Really Bioware? Really? Sort of. The high res textures your computer can't feed to the memory fast enough in a normal environment, causing lag. They're crystal clear, absolutely glorious. The textures you see the rest of the time are toned down to stop the hard drive thrashing when it needs to load a lot of textures at once. Edited January 11, 2012 by Tiron_Raptor Link to comment Share on other sites More sharing options...
Exilious Posted January 11, 2012 Share Posted January 11, 2012 Oh - and I might as well add: SWTOR.exe PID 6772 (they main pid I think that is doing all the disk reads, etc) is: 935.220 MB memory / 900,488 private SWTOR.exe PID 2156 (the secondary process the above guy is doing something with) is: 292,824 MB memory / 197,776 private That is a heafty primary process, huh? There seems to be a memory leak as those processes can hit the 3.2gb extended address aware cap. They just keep going up and up. Link to comment Share on other sites More sharing options...
Grammarye Posted January 11, 2012 Share Posted January 11, 2012 (edited) Which is why all the other stuff is colored, locked off, etc: to make sure it gets noticed. As more information comes out it'll continue to be updated, and all the 'rampant speculation' will be gone. It's not news, but an unrelated thread that I linked in the OP, talking about UAC of all things, mentioned in passing that the fact that it's apparently tied into the remoterenderingserver.ibc could be why one of the processes was requesting elevation. He had it listed in that thread as being 'swtor.exe @remoterenderingserver.ibc' Where he got that from I haven't figured out yet, but it suggests a connection, as you posit, to the remote rendering system. Depending on what this 'remote rendering' actually IS...it could be substantial or nothing at all. We're just now starting to get some decent data to determine which. Yes. The question is why you'd need to run a 'renderer' alongside the main process, and if that could explain, somehow or another, some of the problems we've been seeing. Everything from simple latency added in to certain things because of the extra processing time to poor performance when having to wait on it to do...something. I posted in that UAC thread; it is not that surprising that the launcher requires UAC, and the launcher launches the game. Here's what I would expect TOR to be doing, short version. TOR is a DX9 game. As you map VRAM into process address space and want to load textures and so on, that all takes up address space. 32-bit processes on a 32-bit machine only ever get 2GB of space. If you have more than 2GB of textures and shaders and other data you want to handle, plus all the actual game data of things like where you are, you will run out of room. 64-bit addresses all of this, but TOR needs to be widely applicable. So you take what rendering you can off into another process and do it there. Backdrops would be a great example of something you can remotely render and pass back for straight inclusion in the main rendering thread. I would expect significant traffic between those two processes. Probably a memory mapped file backed by the pagefile which would yield shared RAM between the two, one updates the virtual memory, the other sees the update immediately. That's how I'd do it anyway. Edited January 11, 2012 by Grammarye Link to comment Share on other sites More sharing options...
Jonlinar Posted January 11, 2012 Share Posted January 11, 2012 (edited) Yes. The question is why you'd need to run a 'renderer' alongside the main process, and if that could explain, somehow or another, some of the problems we've been seeing. Everything from simple latency added in to certain things because of the extra processing time to poor performance when having to wait on it to do...something. Easy. In a 32 bit world, you can only do so much. The same is true in any bit world but 64 bit has a much higher limit. Thus, having two processes let's you do things you can't do with just one. If you have one process handling all the UI/"game" stuff and the other simply being responsible for JUST rendering and the graphics pipeline then you can take advantage of all 32 of your bits for addressing instead of just 24.... or even 16.... *shudder* or 8. ninja'd Edited January 11, 2012 by Jonlinar Link to comment Share on other sites More sharing options...
sataren Posted January 11, 2012 Share Posted January 11, 2012 Wow. I'm speechless. Link to comment Share on other sites More sharing options...
Tiron_Raptor Posted January 11, 2012 Author Share Posted January 11, 2012 (edited) There seems to be a memory leak as those processes can hit the 3.2gb extended address aware cap. They just keep going up and up. Odd, I've only seen that happen on taris or when blowing up the communications array on a station, and both have been fixed. In my case the highest I've seen the client process go and still be functional was 2.1 GB, and I think that was on leaky taris. Normally it's more like 1 to 1.5 Could your very observation of it be affecting it somehow? I posted in that UAC thread; it is not that surprising that the launcher requires UAC, and the launcher launches the game. Here's what I would expect TOR to be doing, short version. TOR is a DX9 game. As you map VRAM into process address space and want to load textures and so on, that all takes up address space. 32-bit processes on a 32-bit machine only ever get 2GB of space. If you have more than 2GB of textures and shaders and other data you want to handle, plus all the actual game data of things like where you are, you will run out of room. 64-bit addresses all of this, but TOR needs to be widely applicable. So you take what rendering you can off into another process and do it there. Backdrops would be a great example of something you can remotely render and pass back for straight inclusion in the main rendering thread. Might make sense on 32 Bit OS. On my 64 bit OS, however, it's got that large memory address aware (or whatever it is) flag set that causes WOW64 to give it the full 4GB. Which I should know, because I've seen it shoot up as high as 3.8GB under the influence of one of those explosive memory leaks I mentioned a bit earlier. Edited January 11, 2012 by Tiron_Raptor Link to comment Share on other sites More sharing options...
shananigan Posted January 11, 2012 Share Posted January 11, 2012 (edited) Side note to the person who mentioned developer debugger. I uninstalled the beta client and removed the directory. This is a digital download from early head start. Not sure if you implied that I did something or it is something else or that is what it is. Just saying I notice two processes. lol, it is a debugger from beta, that they never removed, I was not saying it should not be on your computer,rather it should not be there period, that is what the second .exe is. I wonder what could be manipulated through that though... hmmm Edited January 11, 2012 by shananigan Link to comment Share on other sites More sharing options...
Kourage Posted January 11, 2012 Share Posted January 11, 2012 Maybe they'll open it up later. Would suck if someone started opening private servers a week after release. Link to comment Share on other sites More sharing options...
Jonlinar Posted January 11, 2012 Share Posted January 11, 2012 Might make sense on 32 Bit OS. On my 64 bit OS, however, it's got that large memory address aware (or whatever it is) flag set that causes WOW64 to give it the full 4GB. Which I should know, because I've seen it shoot up as high as 3.8GB under the influence of one of those explosive memory leaks I mentioned a bit earlier. They need to support systems other than Windows. The 32 bit world has been around a lot longer than 64 bit has and is more pervasive and "stable." Link to comment Share on other sites More sharing options...
Mannic Posted January 11, 2012 Share Posted January 11, 2012 (edited) Sort of. The high res textures your computer can't feed to the memory fast enough in a normal environment, causing lag. They're crystal clear, absolutely glorious. The textures you see the rest of the time are toned down to stop the hard drive thrashing when it needs to load a lot of textures at once. Sorry but if the textures we're currently seeing in cut-scenes are the "hi-res" textures, that's pretty sad. I have literally seen games with superior texture quality on their normal-camera views than BW's cut-scene, "hi-res" textures. I seriously wonder how people can continue to support the idea that this engine isn't poorly optimized. They have to kil texture quality, remove native AA and include only 8x AF while advising people not to run high-quality shadows just to get the game to run well, and it still has trouble with varying hardware configurations, often on the highest end systems. If what BW has in current cut-scenes is what they consider "hi-res" textures that's fairly disappointing. Edited January 11, 2012 by Mannic Link to comment Share on other sites More sharing options...
Grammarye Posted January 11, 2012 Share Posted January 11, 2012 (edited) lol, it is a debugger from beta, that they never removed, I was not saying it should not be on your computer,rather it should not be there period, that is what the second .exe is. I wonder what could be manipulated through that though... hmmm How do you know? Where's your proof? Might make sense on 32 Bit OS. On my 64 bit OS, however, it's got that large memory address aware (or whatever it is) flag set that causes WOW64 to give it the full 4GB. Which I should know, because I've seen it shoot up as high as 3.8GB under the influence of one of those explosive memory leaks I mentioned a bit earlier. Yes that is my point. 32-bit OSes are still in use. You don't needlessly limit your market. You also don't run entirely different code paths on different bitness of OSes, because trust me that way madless lies. Edited January 11, 2012 by Grammarye Link to comment Share on other sites More sharing options...
Tiron_Raptor Posted January 11, 2012 Author Share Posted January 11, 2012 (edited) Easy. In a 32 bit world, you can only do so much. The same is true in any bit world but 64 bit has a much higher limit. Thus, having two processes let's you do things you can't do with just one. If you have one process handling all the UI/"game" stuff and the other simply being responsible for JUST rendering and the graphics pipeline then you can take advantage of all 32 of your bits for addressing instead of just 24.... or even 16.... *shudder* or 8. ninja'd The 64 bit limit is so stupidly high that it's not a serious concern for the foreseeable future(16 EXAbytes if I recall an old calculation I did once correctly. Exa is the prefix above the prefix above Tera, btw). Even when running as a 32 bit process, it still gains access to up to 4GB of total addressing space, which I've yet to see it come close to except under the influence of memory leaks. Given than a 32 bit system is only going to support a max of 3-odd GB of RAM anyway, trying to push it to more than 2GB is kinda pointless: you're gonna need around half to all of the remainder just to run the OS. It also uses starkly less memory than the main process. Edited January 11, 2012 by Tiron_Raptor Link to comment Share on other sites More sharing options...
Bluebpy Posted January 11, 2012 Share Posted January 11, 2012 Sorry but if the textures we're currently seeing in cut-scenes are the "hi-res" textures, that's pretty sad. I have literally seen games with superior texture quality on their normal-camera views than BW's cut-scene, "hi-res" textures. I seriously wonder how people can continue to support the idea that this engine isn't poorly optimized. They have to kil texture quality, remove AA and include only 8x AF to get the game to run well, and it still has trouble with varying hardware configurations, often on the highest end systems. If what BW has in current cut-scenes is what they consider "hi-res" textures that's fairly disappointing. How i feel man......... how i feel http://30.media.tumblr.com/tumblr_liylt3rAnh1qzsokro1_500.png Link to comment Share on other sites More sharing options...
Tiron_Raptor Posted January 11, 2012 Author Share Posted January 11, 2012 Sorry but if the textures we're currently seeing in cut-scenes are the "hi-res" textures, that's pretty sad. I have literally seen games with superior texture quality on their normal-camera views than BW's cut-scene, "hi-res" textures. I seriously wonder how people can continue to support the idea that this engine isn't poorly optimized. They have to kil texture quality, remove native AA and include only 8x AF while advising people not to run high-quality shadows just to get the game to run well, and it still has trouble with varying hardware configurations, often on the highest end systems. If what BW has in current cut-scenes is what they consider "hi-res" textures that's fairly disappointing. ...you might have that bug where if you installed before Jan 4th, the setting doesn't work right. You can clear that by changing the setting, then changing it back. 'Cause the max res textures I've seen were almost perfect, nearly flawless. Link to comment Share on other sites More sharing options...
Grammarye Posted January 11, 2012 Share Posted January 11, 2012 (edited) The 64 bit limit is so stupidly high that it's not a serious concern for the foreseeable future(16 EXAbytes if I recall an old calculation I did once correctly. Exa is the prefix above the prefix above Tera, btw). Even when running as a 32 bit process, it still gains access to up to 4GB of total addressing space, which I've yet to see it come close to except under the influence of memory leaks. Given than a 32 bit system is only going to support a max of 3-odd GB of RAM anyway, trying to push it to more than 2GB is kinda pointless: you're gonna need around half to all of the remainder just to run the OS. It also uses starkly less memory than the main process. You are confusing RAM with address space. System RAM is not the only user of address space. That 2GB VRAM on your graphics card counts too. Edited January 11, 2012 by Grammarye Link to comment Share on other sites More sharing options...
Jonlinar Posted January 11, 2012 Share Posted January 11, 2012 It also uses starkly less memory than the main process. For now. They may have plans down the line for it. Or, if it is a debugger artifact, they could remove it entirely. If they do have plans for it, then it's one of those architecture decisions you make early and "just use it" to make your life easier down the road. Link to comment Share on other sites More sharing options...
SLOcardshark Posted January 11, 2012 Share Posted January 11, 2012 I think the game should just give us the option to choose how many Player-Controlled Characters are being displayed on our screens...for instance... 0 PC characters displayed (except for your own, of course)) Party Members Only Displayed All PC Characters displayed. Also. let us alter the Field-of-view parameters from "Close" to "Far". Link to comment Share on other sites More sharing options...
KennethHoover Posted January 11, 2012 Share Posted January 11, 2012 But how can people be happy if they're not running around screaming and overreacting? Link to comment Share on other sites More sharing options...
Recommended Posts