The infamous low res gfx problem.

[Gumboots]

Ok, this is fixable. I know it is fixable. Someone ought to fix it, right?

If the problem is newer gfx cards that have too much RAM, then fixing the problem should be simply a matter of finding where the game checks for GPU RAM and changing the limit of what it checks for. It has to be a basic if then else statement. These things are easy to change, once you know where to find them. People have done far more difficult things with the coding of this game.

If we're interested in extending the playable life of the game, enabling decent gfx on modern gfx cards and OS would be one very good thing to do. The easy tricks that some people have tried (ie: limiting available RAM system wide) do not always work. It doesn't work on my box, for instance, and I'm quite sure there will be a lot of other boxes it wont work on either. It's also bad for system performance in general, if you want to be running several other apps at the same time as RRT3.

So, where is this pesky code hiding, and what does it look like? If it was written in PHP I'd be able to find it and edit it without any trouble. Unfortunately, it's written in gobbledegook.

My current guess is that the code in question will be hiding in Data/Configuration/engine.cfg. Has anyone really looked through this file? Is anyone familiar with the contents?

[thietavu]

The problem is not in having too much VRAM. I have confirmed this with nicely working 3 AMD Radeon cards, with 1, 1 and 2 GB. However, the problem did occur in my Nvidia card with 768 MB... Strange. RRT3 utilizes only up to 256 MB VRAM (I measured recently). Therefore it just might have trouble with anything over 256 MB and under 1 GB. Can someone test this with an integrated GPU with adjustable video memory?

[Gumboots]

Ok then, we can eliminate the "too much RAM" myth from consideration. There's no need for anyone to ever mention that one again. Myth busted. The problem has to be something else.

I'm currently running one of these - GeForce GT 630 Specifications - in the DDR3 version on Window 7 64 bit.

That has 1 gig of RAM, and I'm still getting the low res problem in a big way. So, if you get good gfx with a 1 gig card then it seems that a card between 256 meg and 1 gig is not the cause of the problem either.

[thietavu]

Ok then, we can eliminate the "too much RAM" myth from consideration. There's no need for anyone to ever mention that one again. Myth busted. The problem has to be something else.

I'm currently running one of these - GeForce GT 630 Specifications - in the DDR3 version on Window 7 64 bit.

That has 1 gig of RAM, and I'm still getting the low res problem in a big way. So, if you get good gfx with a 1 gig card then it seems that a card between 256 meg and 1 gig is not the cause of the problem either.

Just wondering... My Nvidia card had the problem. My last 3 AMD cards don't have the problem... Your Nvidia card has the problem... Hmmm.

[Gumboots]

That had occurred to me too, but the sample size is still a bit low for that conclusion. More importantly, even if that conclusion does end up being justified it still doesn't (in itself) explain why it is happening. A why is going to be necessary before any workaround can be implemented.

If nVidia cards are targeted then there has to be a reason why they trigger the game settings in this way. It may well apply to other brands too. It may even start to affect AMD cards if they change something in their specs. vNidia are good quality units in general, so you can't expect people to not buy them, or to replace them when they work for everything else.

Just for reference, from my recent testing I know what is actually happening, at least in the cases of locomotives and tenders. The game disregards the A, B and C skins and only uses the D and E skins, even at close range. I haven't made test skins for other game elements like buildings and trees, but I would say that the same applies to them. This may be a handy clue if it becomes necessary to dig into the game coding.

A game code fix would be the optimal solution, because frankly this automatic check is no longer applicable to modern systems anyway. Any modern system has more than enough RAM (general or gfx) to run RRT3, so constantly running a check is inefficient use of processor time. If the check can be removed, that would provide a future-proof fix that works for everyone, which is better than trying to play whack a mole.

=================================================================

I'll throw in a sweetener here, just to get others involved, since I really want a result for this.

Know something about RRT3 core coding? Got a favourite user-created locomotive, and you don't want it to glow in the dark? I'll re-alpha it for you, even if it's diesel or electric.

This is not a small undertaking. It requires checking and setting the correct alpha value for every one of 349,184 pixels* for every locomotive and every tender. This is why most people never bother to do it.

The catch is that at the moment, I can't check the results for the A, B and C skins. Why not? Because, as mentioned above, on boxes affected by this low-res problem the game only utilises the D and E skins. Help me fix that, and your favourite user-created loco will stop glowing in the dark, even at very close range.

*Total pixel count for standard A, B, C, D and E skins.

[nedfumpkin]

Hey, I got an idea...why not fix the Consolidation II from the cowboy engines. There is a part of the smokestack I can't get rid of, and a part of the cowcatcher that shouldn't be there. Been driving me nuts....your turn. :)

Also, you do realize that if ever you figure out the gfx issue, RT3 fans will build shrines in your honour, and celebrate your birthday with naked stonehenge like festivals.

[Gumboots]

Not so fast, mate. I aint re-alpha-ing nothing until there is measurable progress towards a solution here.

[thietavu]

What is certain: in special debug or info-mode RRT3 reported having a *negative (!)* amount of VRAM with my Nvidia card... This would explain why the game chooses the lowest settings. With all the AMDs, it reports the correct amount. Also, since they run hi-res graphics with T&L enabled (i.e. no "Vista Fix needed), the acceleration features are almost all in use.

Almost? Yes, the game reports that some shader or something isn't enabled correctly.

Conclusions? I think this might be about some very old DirectX or other call the game uses to query OS about the available video memory. Chances are that Nvidia no longer supports that call in their drivers, but AMD does. That would seem like a logical explanation to me.

About the similarity of AMD cards... I have now used models 4890, 5770, 5850 and 7870. Hmm... So, it's four, not three cards, sorry! As far as I know, all these cards have completely different architectures, as different as putting an Nvidia card to replace any of them. Especially the 7870 has nothing in common with the rest.

This would also point to a driver-level issue. However, I still haven't ruled out the possibility that some optional Microsoft compatibility fix (they have released several for old programs) affects these things.

Btw, I have only used TrainMaster version for a long time now, so I can't verify all this applies to normal RRT3 versions. Will install normal RR3 again soon, then we'll know for sure...

[Gumboots]

RRT3 installation asks you to install DirectX 3.1 IIRC, so it's definitely a bit out of date there.

I'm not sure the acceleration features would be such a big deal, given that any modern gfx card should eat this game for a snack. If anyone really wants to cut back on the gfx settings on a particular game, they can still do that manually. Having it forced automatically is a waste of code.

Anyway, I still think the important bit is that the whole checking for VRAM is a waste of time now, and is just asking for more problems long term if it is kept. So, it needs to be tracked down and shot.

I can open the config files in a hex editor, but I have very little idea what I'm looking at. The relevant code may not even be in the config files (although it would be nice if it was). Does anyone know what language this beast is written in, and does anyone have any clues about what code resides in what file?

Presumably, if we know the coding language it should not be impossible to run a search for basic if then else stuff.

[Gumboots]

Been Googling a bit. Found some stuff.

My GTX 580 3GB has TOO much VRAM

It's just a bug, someone using a signed int instead of an unsigned int when reading the VRAM size.

Because 2GB's is the largest positive number a signed int can hold it ends up returning a negative value.

Also Out of memory with good graphics card.

The problem actually comes from the fact that it is signed int measured, not unsigned, thus +-2B are the max and thats +-2GB.

I've that with my GTX280 on Vista64/Win7 as well that I in many techs have -1GB VRAM (thats 1GB onboard + 2GB system ram texture memory)

The latter post is a bit garbled, but he seems to be making the same point as the first quote. The point being that there is additional RAM assigned from the general system RAM, and when that is added to the VRAM the result is a figure which the signed int cannot deal with correctly, so it returns a negative value.

One possible solution is presented here: [Solved] GeForce GTX 660 Ti not compatible with T3D 1.2?

I believe I have a solution for the negative VRAM value you were seeing. I don't know if this will completely correct your issues, but it certainly isn't a good thing.

Open platformWin32/videoInfo/wmiVideoInfo.cpp. Go to line 544 and change it to read like so:

Code: Select all

    case VT_I4:  
       {  
          LONG longVal = v.lVal;  
      
          if( queryType == PVI_VRAM )  
          {  
             longVal = longVal >> 20; // Convert to megabytes  
      
             // While this value is reported as a signed integer, it is possible  
             // for video cards to have 2GB or more.  In those cases the signed  
             // bit is set and will give us a negative number.  Treating this  
             // as unsigned will allows us to handle video cards with up to  
             // 4GB of memory.  After that we'll need a new solution from Microsoft.  
             *outValue = String::ToString( (U32)longVal );  
          }  
          else  
          {  
             *outValue = String::ToString( (S32)longVal );  
          }  
          break;  
       }  

This is not a good option for a lot of people (IMHO) because it involves editing a Windows system file, which is generally best avoided if possible. The principle is simple enough though, and ties in with what the other guys were saying.

ETA: Just did some more checking, and the above code is not referring to a Windows file, but to a this file, which wont be applicable.

Then there's this: Get it to run on Windows Vista / 7 x64

Act of War ask for video memory by calling DirectX function GetAvailableTextureMem.

We just need limit value returned by this function to avoid crash caused by video memory amount.
I found this article on web http://www.codeguru.com/cpp/g-m/directx ... xy-DLL.htm

There is also sources of simple dllproxy for directx (do nothing, simple call original directx functions).

Changing this code in file myIDirect3DDevice9.cpp

UINT myIDirect3DDevice9::GetAvailableTextureMem(void)
{
return(m_pIDirect3DDevice9->GetAvailableTextureMem());
}

to this (never say to application values greater then 1Gb of video memory)

UINT myIDirect3DDevice9::GetAvailableTextureMem(void)
{
const UINT TextureMemoryLimit = 1024 * 1024 * 1024;
UINT AvailableTextureMem = m_pIDirect3DDevice9->GetAvailableTextureMem();
if(AvailableTextureMem > TextureMemoryLimit)
return TextureMemoryLimit;
else
return AvailableTextureMem;
}

and compile we get proxy which can fix negative memory error in Act of War.

Proxy dll must be placed in Act of War folder (same folder where game exe file located), not in windows system folder (this break directx functionality)

There is a proxy with a memory reporting fix http://cns-spb.ru/d3d9.zip or anyone can compile it using Microsoft Visual Studio Express and Microsoft DirectX SDK (these can be downloaded from Microsoft site for free).

Again, a bit garbled, but the article he links to sounds promising.

Intercept Calls to DirectX with a Proxy DLL

Sounds like all we have to do is figure out how to spoof the RAM value, so that RRT3 always thinks there is a decent amount of it. The spoofed value could be 500 meg or 1 gig or whatever. I'd be inclined to choose 1 gig myself.

Problem is that using the above method would require knowing the names for the .dll files, which means it wouldn't be future-proof against future versions of DirectX. A fix within the game code itself is still going to be the best option.

Oh and at a guess, I'd say the dfference between AMD and nVidia in this case is that AMD is correcting for the negative value, while nVidia is just swallowing the DirectX output value without questioning it. Or something like that.

[Hawk]

RRT3 installation asks you to install DirectX 3.1 IIRC, so it's definitely a bit out of date there.

That would be DirectX 8.1, which was released in 2001.

There was no DirectX 3.1. Only 3.0, 3.0a and 3.0b, all 3 released in 1996.

DX 9 wasn't released until Dec. of 2002.

All the above info is according to this Wikipedia article: https://en.wikipedia.org/wiki/DirectX

Yea! I know. Completely irrelevant to this topic.

[Gumboots]

Hawk: click this. You'll love it!

[Gumboots]

Anyway, back on topic (curse the admin).

Does anyone have any clues about this bit?

I can open the config files in a hex editor, but I have very little idea what I'm looking at. The relevant code may not even be in the config files (although it would be nice if it was). Does anyone know what language this beast is written in, and does anyone have any clues about what code resides in what file?

Presumably, if we know the coding language it should not be impossible to run a search for basic if then else stuff.

I don't mind getting hold of a decompiler or whatever if necessary, and learning the basics of how to run a search in it. Operating it at that level can't be too difficult, and is probably all that's required to find this pesky code.

I know we can look at stuff in a hex editor, but that in itself is not a lot of use. My guess is that RRT3 was either written with MASM or, if we're lucky, C or C++ (we're probably not lucky). These languages are not written in a pile of hexadecimals, so with the right tools it should be possible to view what was actually written by the devs at the time. It may even be commented (but I wont hold my breath on that one).

Anyone got ideas?

[Hawk]

Hawk: click this. You'll love it!

A Google search for random news? What's it all about?

[Gumboots]

I was winding you up about your lecture on old versions of DirectX. <=> Random news item.

Anyway, I've been sifting through a couple of files. Tried the tiny .cfg files first, but of course no luck there. So, I went right through RT3.exe (1.05 version) and have learned a few things.

First thing I learned is that hex files are horrible.

Second thing I learned is that I need a more powerful and flexible hex editor. That means one that will spit out the dump columns as a separate text file or, alternatively, is capable of running a search on the dump columns independently of the hex columns. Even better if it does both. I don't care if the sucker is a 25 meg download and chews 3 gig of RAM, as long as it does what I want it to do.

Third thing I learned is that, not suprisingly, the vast majority of RT3.exe consists of the various equations that are required to run the gfx engine and other aspects of the game. Most of it is stuff I'd never want to edit, because it already does the job well. This is good in one respect (most of the file can be ignored) and bad in another (have to find the bits that can't be ignored).

Fourth thing is that I'd kill for a decent roadmap to the syntax used for the variables, etc. The file is not written in standard mathematical notation, even in the dump columns. If anyone has managed to map some sections of the .exe, even if their notes are as rough as guts, I'd very much like to see such notes (got any, Ned?).

Fifth thing is the good bit. I think I found the culprits.

Haven't had time to dig any further, and I know I can't just shove extra bytes into the .exe any old how, but this is looking very much like the stuff I was hunting. So, I assume the next step is to track down where those variables are coming from, and head them off at the pass.

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

Also found a variety of other interesting stuff.

In the range 00168300 to 0017b6b0, there are several mentions of DXT1 through to DXT5. These are outdated lossy image compression algorithms: http://en.wikipedia.org/wiki/S3_Texture_Compression
My suspicion is that these are the algorithms responsible for map degradation on saving. That opens up the possibility that maybe, at some point, another non-lossy algorithm could be called for the editor. That's probably not nearly as easy as it sounds, but I assume it would be possible.

Selection of A, B, C and D skins appears to be controlled by the code from 001de130 to 001de1c0.

001df530 to 001df560 call an outdated version: Direct3D/D3DX8 Shader Assembler Version 0.91. This could well be the faulty shader that Thietavu mentioned earlier. If the call was updated, that might be useful.

A pile of .dll files are called from 001ebeb0 to 001ec070.

Day/night cycling appears to be controlled around 00233930 and on. Not sure if anything can be done with that.

Also, the single track wooden bridge is called at 001cafa0. It looks like it shouldn't be too hard to add code for double tracked wooden bridges, if anyone ever wanted to do it.

Now I need a break from $^#&! hex files.

[thietavu]

Nice work!

The text you found looks like the hidden special version of "show fps" option I used to check for the VRAM in use and soe other statistics of the graphics engine.

[Wolverine@MSU]

Gumboots: Have you looked at PJay's stuff? He's a guy who used to dabble with RT3 stuff while he was in college (several years ago) but has dropped out of the following. He did a lot of the stuff you're doing, and was the author of the BMP2GMP/GMP2BMP programs for swapping colormaps in and out of GMP files. I've attached a ZIP file with some of his notes. There's one in there that maps the GMP files, at least what he was able to decipher. You might find it useful. It also has some notes from Milo, another "lost soul".

[Gumboots]

Yup. Got those already, but thanks anyway. What I would really like is a guide to the sort of syntax found here:

Y'see the problem with hex is that the same bytes can mean different things in different contexts. Just as an example, 4c can mean a capital L or it can mean 76. Then there are all the odd symbols used in the dump column:

Code: Select all

Q‹L$$R‹T$0Pèðýÿÿ

I'd bet my boots that $ does not mean dollars there. That symbol is commonly used for PHP variables and operations. I'm assuming something similar here, but I have no guide to the syntax. < probably still means less than, but less than what, and why?

In many places I can recognise the general forms of the sorts of equations I'd expect to see, but I can't (at the moment) decipher much in the way of specifics. If I knew what language the thing had been written in or what tools had been used to put it together, gaining an insight into the syntax would be a lot easier. I don't want to reverse engineer the entire graphics engine or anything daft like that. I'd just like to be able to read the bits I will need to edit to debug the behaviour I'm trying to fix.

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

Update: this hex editor seems like a very good one. http://mh-nexus.de/en/hxd/ Gets good reviews, has intuitive GUI, seems to do the business. I like it.

Syntax. Hmm. Turns out that the COFF line numbers and table entries have been removed from RT3.exe. In English, that means no dictionary for syntax and variables. Also, from the .exe it's not possible to determine which language it was written in or what it was compiled with. This is understandable, since they were trying to protect commercial code, but is still a nuisance for us.

Have managed to get a nice list of all the .dll files that it imports though.

ADVAPI32.dll
binkw32.dll
comdlg32.dll
d3d8.dll
DINPUT8.dll
DSOUND.dll
GDI32.dll
KERNEL32.dll
mss32.dll
ole32.dll
USER32.dll
VERSION.dll
WS2_32.dll
WSOCK32.dll

Also, AFAICT the address of the entry point is 1A313B, which is suspect is not entirely accurate since the same tool gives a total byte count for the .exe which is slightly off. Might be worth noting anyway. Could be useful at some stage.

[nedfumpkin]

Fifth thing is the good bit. I think I found the culprits.

eureka.png

You seem to be right on track here. Sorry, no notes that could help you....but here's something...what if the % kb was changed to % mb? Is it possible that it might work? Seriously...I dunno.

[Gumboots]

Yeah thought of that. Will try it, but I think it wont work. Look at the variables called there. %1, %2, %3 etc are called for several things, which must have different values. Trees and VRAM can't be the same.

Will give it a go anyway. Will try this and see what happens:

Code: Select all

Total SRAM: 99 Mb.Total VRAM: 99 Mb