I broke your RAM cap.

[Raijan]

I also wonder if 64bit would require going up to DX10, I haven't met many games with 64bit executables but I seem to remember that even back to Crysis 1 it was always the combo of 64 + DX10.

That one I do know, the WOW64 exe can use both Directx 9 and 10.

The next question is why do I still have wow installed...

[bumpinthenight]

I also wonder if 64bit would require going up to DX10, I haven't met many games with 64bit executables but I seem to remember that even back to Crysis 1 it was always the combo of 64 + DX10.

That one I do know, the WOW64 exe can use both Directx 9 and 10.

The next question is why do I still have wow installed...

Neat, well at least that sounds promising, if I do get my refund I hope that eventually Rebirth gets a 64bit executable and gets the optimizations it requires to play smoothly. I'd re buy it down the road if that happens and at what ever price its slipped to by then.

[savagetwinky]

You clearly don't understand how vram is manipulated. It is not addressed in the same fashion as ram that is accessed by the cpu. You cannot hold a pointer to an address in vram and use that pointer in the same fashion for cpu-based operations. Thus it does not consume the address space.

Now there is some address space consumed by the gfx card and other hardware, because that is how they are accessed and controlled by the program. However this is never the full amount of vram available. Otherwise you would literally not be able to use a 4gb gfx card on a 32 bit os as the entire address space would be consumed. Actually, you wont be able to use a 2gb gfx card in most setups.

Edit: So that does mean that he's technically wrong, the game does not have full access to 4gb for storage of game data. It's closer to 3.5-3.75gb. But it's not 3gb for a 1gb card or 2gb for a 2gb card.

Here's my understanding: Something has to keep track of where everything in the video card's memory lives, this is the driver's responsibility but your program still indirectly does the tasking and managing via directX which is doing the virtual memory manipulations. Your code isn't directly talking to the pointers, its calls to DirectX are doing that. But DirectX isn't some service your application polls, its a library your application has incorporated. Your 32bit application, both count towards the 2^32 limitation.

That's my understanding, and no its not like the second a game loads it needs to map the entire card's memory, it only needs to alloc what it needs and believe me it was pretty apparent via watching Nvidia Inspector's vram graph + Process monitor that whenever a 32bit game's combined quantity reaches 2^32 it'd crash. Skyrim was the only one where this became a fairly common annoyance but hearing that Rebirth is capable of using 3GB of system memory makes me wary since I know its already commonly eating 2.3-2.6GB of vram whenever I'm watching it.

Thank god that applications don't need to directly map the raw video memory and my 64bit driver gets that honour, us SLI users would be shafted way way worse.

Holding information on where things are in VRAM doesn't require you to map the entire space in main memory so you could theoretically use 4GB (or the max of your vcard) of vram with 4GB of system ram..

Now the one thing they haven't mentioned is there is a huge limitation on DX9. It requires video memory to be shadows in main memory. So rebirth being a 32 process and dx9 is kind of crippled.

edit: also sli users I believe are shafted no matter what, the memory is completely identical between cards

[Sam L.R. Griffiths]

Out of curiosity CBJ do you know why Egosoft decided not to make a 64 bit application?

More then likely the cost of developing a 64bit application was not cost effective for the benefits it provides.

Typically, a 64-bit application does not cost any more to develop than a 32-bit application - it is normally just a compiler switch.

What may make a difference is if there are any third party library problems. This is due to issues such as the different sizes of some base types such as integers and pointers.

Either way it is rather moot, X-Rebirth is a 32-bit LAA application and probably will always be now.

[Spikeles]

Now the one thing they haven't mentioned is there is a huge limitation on DX9. It requires video memory to be shadows in main memory. So rebirth being a 32 process and dx9 is kind of crippled.

No it doesnt, where did you hear that "fact"?

Here, go read about how D3D9 actually manages resources: http://msdn.microsoft.com/en-us/library ... 85%29.aspx

If resources are created using D3DPOOL_DEFAULT, then D3D is free to place that resource wherever it wants, including video memory. This memory IS NOT shadowed to main memory which is one reason by resources that are placed into that pool need to be recreated when the device is lost (eg, an alt-tab)

So, if you don't know how D3D works, here is quick (albeit simplified) primer:

The usual practice of using resources, such as index buffers, vertex buffers, textures, etc, etc, is to load them into D3D. Then D3D gives you an ID(in the form of a COM object), you then use this ID for all future access.

If you want to change a resource (eg, update a texture), then you do what they call a "LOCK" which copies the resource to system ram and gives you a nice pointer you can use to do a memcpy or whatever you want. Then you "UNLOCK" it and D3D can copy it back wherever it was before.

Now, i've run an API monitor on X:Rebirth, and wouldn't you know it, a fair amount of textures (just one example I looked it) were D3DPOOL_DEFAULT.

[pirke123]

Legacy C and C++ code... it can often assume things are 32 bit. Casting a pointer to an int. Bit shift 16 left and right to set the first 16 bits to 0 (very fast but ugly as hell). To name a few. Third-party stuff that's only available in 32 bit is another issue. When they started 7 years ago, the whole world was 32 bit Win XP. And you can always use multiple processes to divide the memory usage. We have 20+ 32bit processes on a 64bit OS, our 32bit application uses 5 to 10gb in total.

If you start from scratch *now* then 64bits is preferred. If you drag along many years of bad written code, then conversion to 64bits is a costly operation.

[dmk]

If you start from scratch *now* then 64bits is preferred. If you drag along many years of bad written code, then conversion to 64bits is a costly operation.

actually 7 years ago was already know that new code should be able to compile for x64, and mostly work, they did argue that rewritten engine from scratch, why did not they think about x64, knowing that memory of average gaming system will have definitely more than 4gb, and writing memory consuming application?

that seems like manager or programmer's team leader failure, a costly one,
because many game reviewers probably tested game on machines with much memory, so they lost in reviews 10-30% only because of this decision.

[Sam L.R. Griffiths]

many game reviewers probably tested game on machines with much memory, so they lost in reviews 10-30% only because of this decision.

The issues are a bit more complicated than 32-bit/64-bit wrt reviews, more importantly is the apparent lower than par quality/comprehensiveness of the testing resulting in lots of release time bugs.

The release time bugs are probably the biggest cause of any memory management issues. Whether some are due to design decisions is a bit moot since it is probably going to be too costly in both time and money to revisit such things.

The best we can hope for is that they address the outstanding issues as best and quickly as they can.

[Alan Phipps]

Since this is now a design decision debate and not a request for technical support with an issue, it can move.

[bumpinthenight]

Since this is now a design decision debate and not a request for technical support with an issue, it can move.

Your game is crashing on high end systems because of this problem and Egosoft so far hasn't even acknowledged its an issue, your opting to move this out of sight isn't helping and only further reinforces that Egosoft has no intention of facing it. The debate only exists because of the vacuum provided by Egosoft.

If you could, could you drop a line at Steam and help them move my refund along while you're here?

[Mauzi!]

If you could, could you drop a line at Steam and help them move my refund along while you're here?

No need to ask Egosoft for help, here's all you need for refunding:

http://forum.egosoft.com/viewtopic.php? ... 65#4237165

[hisazul]

Converting to 64bit isn't as simple as converting just the 32bit executable to 64bit and calling it a day. You need to rewrite the entire API with the engine and graphical engine (maybe).
Also Dx is a bottleneck in its own right. There is only so much that old thing can handle if microsoft got their head out of their asses and quit with their mindless "its awesomesause" campaign and just went finally past Dx in its current iteration then MAYBE just maybe devs would have a higher inclination to go 64bit from get go. Otherwise they will still hit the Dx wall.

Oh wait... we have consoles so microsoft will never abandon Dx or they will face a shitstorm.

Anyway... What ego does need to do is make some proper memory cleaning routines. Some junk doesn't seem to ever go anywhere and it just sits there unused. Also some stuff is utterly redundant.

To make example... why the heck is entire configuration+coordinates+speed+turrets+a ton of other nonsense I never even figured out is being stored in player used stacks. (memory)
It may not sound much but that stuff, after just god forbid managing to target something, JUST SITS THERE. Pages upon pages of things that will never be used again. Hell pretty sure your target data doesn't even get dumped after target is dead. -_-
Pseudo memory leaks imo.

[bumpinthenight]

If you could, could you drop a line at Steam and help them move my refund along while you're here?

No need to ask Egosoft for help, here's all you need for refunding:

http://forum.egosoft.com/viewtopic.php? ... 65#4237165

Fraid that link just goes to one of your posts linking to an escapist article with the PR guy spinning up the state of the game, but all good I'd already initiated the refund yesterday after reading the instructions from that thread I'm just chiding Alan with that line, once I've got a refund I won't be lurking this forum for at least a few months, likely until I see the game go on sale for $20 and get curious to see if they ever managed to make it run well.

[ajax34i]

Why?

Because under 64-bit Windows, the game has access to up to 4GB, which is more than it actually needs.

[bumpinthenight]

Why?

Because under 64-bit Windows, the game has access to up to 4GB, which is more than it actually needs.

Read the first post, just like Skyrim it appears this game crashes at the 3.1 mark, why it does that is not entirely certain but the fact this thread exists because someone did kind of reinforces that no the game does not have all the memory access that it needs and as time and modding goes on that wall will get hit more often.

How to address that has created a lot of posts here, but 'sweeping it under the rug' is not an acceptable solution.

[Mauzi!]

Because under 64-bit Windows, the game has access to up to 4GB, which is more than it actually needs.

I have seen my XR using 3.5GB at one point, so this "more than it needs" isn't quite correct. Of course, I dunno why it used that much, e.g. due to memory leaks, but nevertheless it DID use somewhat near 4GB peak at least once.

[pref]

FYI mem leaks can eat up any amount of memory in time. If you had 8G it could use up that as well. Does not mean that the app would need more then 4G of memory.
And still then 3.5 < 4..

[savagetwinky]

Now the one thing they haven't mentioned is there is a huge limitation on DX9. It requires video memory to be shadows in main memory. So rebirth being a 32 process and dx9 is kind of crippled.

No it doesnt, where did you hear that "fact"?

Here, go read about how D3D9 actually manages resources: http://msdn.microsoft.com/en-us/library ... 85%29.aspx

If resources are created using D3DPOOL_DEFAULT, then D3D is free to place that resource wherever it wants, including video memory. This memory IS NOT shadowed to main memory which is one reason by resources that are placed into that pool need to be recreated when the device is lost (eg, an alt-tab)

So, if you don't know how D3D works, here is quick (albeit simplified) primer:

The usual practice of using resources, such as index buffers, vertex buffers, textures, etc, etc, is to load them into D3D. Then D3D gives you an ID(in the form of a COM object), you then use this ID for all future access.

If you want to change a resource (eg, update a texture), then you do what they call a "LOCK" which copies the resource to system ram and gives you a nice pointer you can use to do a memcpy or whatever you want. Then you "UNLOCK" it and D3D can copy it back wherever it was before.

Now, i've run an API monitor on X:Rebirth, and wouldn't you know it, a fair amount of textures (just one example I looked it) were D3DPOOL_DEFAULT.

hmm i think the chat below didn't fully understand the article

http://www.techpowerup.com/forums/threa ... rds.91260/

States dx9 requires resources to be shadowed based on

http://www.tomshardware.com/news/window ... ,7644.html

Now that i've reread it they appear to do it so they can render the windows manager in software

The same application window data is duplicated again in system RAM for the CPU to render independent of graphics hardware.

[pref]

hmm i think the chat below didn't fully understand the article

http://www.techpowerup.com/forums/threa ... rds.91260/

States dx9 requires resources to be shadowed based on

http://www.tomshardware.com/news/window ... ,7644.html

Now that i've reread it they appear to do it so they can render the windows manager in software

This is about windows desktop visuals... not sure how this is related to X:R

[savagetwinky]

hmm i think the chat below didn't fully understand the article

http://www.techpowerup.com/forums/threa ... rds.91260/

States dx9 requires resources to be shadowed based on

http://www.tomshardware.com/news/window ... ,7644.html

Now that i've reread it they appear to do it so they can render the windows manager in software

This is about windows desktop visuals... not sure how this is related to X:R

There is a small snippet in the article about being able to move the resources to vram because of the driver model change, win7 used dx10 for the desktop vs dx9 in previous windows