When will it be possible to be able to use high res textures?

Also note that you don't have to do something like alter every single str2 file to get your textures to work. The way our texture system works you could put a larger texture into the startup/al peg and it will use that instead of what is with the asset.
 
[V] Knobby said:
Also note that you don't have to do something like alter every single str2 file to get your textures to work. The way our texture system works you could put a larger texture into the startup/al peg and it will use that instead of what is with the asset.
Click to expand...

Now that is very handy to know. I was planning on writing a recursive texture replacer that scanned through all the game files replacing all instances of a texture. Now I don't need to. :)
 
Yeah i hope there's no problems with the game engine. Not like limitation of the Skyrim engine. If you reach 3.1GB of used RAM the game will crash. That was revealed weeks ago
 
MarbleD410 said:
I blame console limitations for something like this.
Click to expand...
I am not too sure myself but it could be the game engine itself or something have to do with DX9 32bit

BTW, i wonder what DX is SRIV running at for PC? For some reason SRTT DX11 looks better to me. Not to mention RF Guerrilla look better too.
 
Minimum system requirements are DirectX 10.
 
I remember reading something also about DX9 liking to mirror all textures into ram as part of its operation. That alone apparently is half the reason Skyrim crashes (particularly for anyone who's used a texture mod to get past the smeary vaseline textures of vanilla.. oh, and that hi-res DLC mod Beth released? Yeah, that REALLY hits it hard).. now SR3 is a lot less buggy (which is no feat, Bethesda coders probably work flat out to do their best but the engine needed a rewrite years ago, and I imagine their alloted debug time is measured in *days*, total) but it probably has some inbuilt assumptions too.. if you have hard memory limits lurking you might smash that too quick. On the other hand, SR4 (and most SR3 players) are happy with DX10 and 11.

It does raise questions how far the engine could be pushed.. higher draw distances, processing distances, massive texture leaps, bigger files and more of em.. how much hassle would it be to remove some of the caps and let the engine run wild (so to speak), ignoring the whole platform synchronicity that's come up before? Would it hit the same "Aaa 64 bit I'm afraid!" crash point, or would it laugh right up until it ran out of available memory, which could well be a good double to triple what it normally expects?
 
As far as that line in the .ini, I swear I've seen it a handful of times before, not limited to this franchise.

I think even some Beth games like FO:NV and Skyrim have it, and I think it's essentially useless, changing nothing.

Then again, those games let you just drop a .DDS file in the game's install dir (in the right folder path, of course), and it'll load that, regardless of how hi-rez it is, even letting you use an uncompressed 32-bit DDS with the 8.8.8.8 ARGB profile (though when a texture that was 512x512 is upped to 4096x4096, the 8.8.8.8 is kinda overkill in my mind; DXT5 isn't noticeable when the texture is that damn big...)

---------------------------------------------------------------------

As far as beyond that...:

Usually the answer for higher rez textures is Texmod, but it doesn't work with every game, and (only in my efforts) I've found it doesn't with 4 (couldn't even get it to work with 3).

I think it's dependent on a game running on DirectX9, but I'm not sure. May be the engine?

If someone who owns SR2 on PC (mistakenly bought it for XB360 myself; no Gentlemen of the Row for me :() and is familiar with Texmod could run it to see if they can dump/replace textures successfully, that'd be nice.

Specifically, using the Steam workaround of renaming the game's .exe to (assuming SR2's executable is called saintsrow2.exe) saintsrow2_texmod.exe, and renaming "Texmod.exe" to "saintsrow2.exe", then after starting the game through steam, which will load Texmod, pointing Texmod to the actual, renamed .exe as the target game.

So, I'd like someone to try this with the *actual* game's .exe, with Steam—not some cracked .exe; I can't stress that part enough.
Y'all know the rules.

Thanks to anyone who'll do that.
 
Broccoli said:
Yeah i hope there's no problems with the game engine. Not like limitation of the Skyrim engine. If you reach 3.1GB of used RAM the game will crash. That was revealed weeks ago
Click to expand...

That's a 32 bit application limit. Under 64 bit windows and with the application having the LAA flag active an application can use up to 4Gbs of memory. That 4Gb includes any shared library files (dll files - like direct x) and drivers. Maybe one day, when all the 3rd party libraries support it, Volition will switch to a 64 bit version of the engine.

Gondar said:
I remember reading something also about DX9 liking to mirror all textures into ram as part of its operation. That alone apparently is half the reason Skyrim crashes (particularly for anyone who's used a texture mod to get past the smeary vaseline textures of vanilla.. oh, and that hi-res DLC mod Beth released? Yeah, that REALLY hits it hard).. now SR3 is a lot less buggy (which is no feat, Bethesda coders probably work flat out to do their best but the engine needed a rewrite years ago, and I imagine their alloted debug time is measured in *days*, total) but it probably has some inbuilt assumptions too.. if you have hard memory limits lurking you might smash that too quick. On the other hand, SR4 (and most SR3 players) are happy with DX10 and 11.

It does raise questions how far the engine could be pushed.. higher draw distances, processing distances, massive texture leaps, bigger files and more of em.. how much hassle would it be to remove some of the caps and let the engine run wild (so to speak), ignoring the whole platform synchronicity that's come up before? Would it hit the same "Aaa 64 bit I'm afraid!" crash point, or would it laugh right up until it ran out of available memory, which could well be a good double to triple what it normally expects?
Click to expand...

Yes any managed texture contains a copy of the texture in the systems RAM. This is because if the graphics card hits an error state it clears all the memory in the card, including all the textures and reloads them. A managed texture will do this automatically for you and, believe me, you want it to do it automatically for you.

Also you don't have to worry how much memory a graphics card has as Direct X will automatically load and unload a managed texture into your graphics cards memory.
 
Except that the Skyrim bug is NOT a simple LAA flag thing. The engine inherently assumes it is 32 bit only, and the allocation assumes such. There was a patch to make the game go LAA anyways.. but even so, the inherent underlying assumptions still believe it's limited to under the 3.2gb cap. As soon as you hit that, the game pukes all over itself and crashes. The engine has some real fundamental problems, and when they swapped out the Gamebryo rendering engine the underlying game engine was still just tweaked.

I'm no professional coder but I know that there's probably some hidden assumptions in the code about memory space that might start throwing fits if broken. If it was so easy to just flip a bit to make it a 64-bit program all those memory limits we have in the game would be a non-issue, and we wouldn't have all these constraints on even something as simple as xtbl entries. The fact that we have all of them and repeated statements from Volition members about the neat little tricks they had to make sure the game doesn't get too big imply there's some buried stuff that might start to panic given too much space if it isn't fixed. I mean, sure your game might start allocating bigger, but if some part assumes 32 bit for indexing and uses 32 bits to access.. well.. yeah.
 
You must log in or register to reply here.
Back
Top