[Eldorado.Railroad]

?

[captain_bazza]

Hi'ya Eldorado,

There is a statement regard current graphics resolution MSTS > OR in the OR FAQ.

Quote

Will Open Rails make my MSTS routes and trains look better?

MSTS displays textures as 16-bit color even though most are stored as 24 or 32-bit ACE files. Therefore, the graphic foundation is there for improved visual with existing MSTS textures. Open Rails could provide better lighting effects and texture effects to give a better view of the current MSTS models. Nevertheless, Open Rails will not magically make everything look much better.

In my experience with OR, better quality artwork shows well in OR even after processing with old MSTS tools.

2048x2048 24b textures work, too.

I can't answer about alpha textures, I don't use them, so someone else might be able to answer about that aspect.

Generally, OR shows artwork better than MSTS.

Cheers Bazza

[thegrindre]

I, too, can attest to the fact that OR does indeed display the old MSTS graphics noticeably better.
It's very hard to post comparison shots of each because of all the varied PC types out there but, with a good graphics board and a good monitor, it is very apparent.
I'm still using 512x and haven't tried the 1024x or 2048x textures yet but, I can honestly say, WOW, there is a difference in OR's graphics.
(I do have a nice PC with a good graphics board and a good monitor, btw)

:wheelchair:

[longiron]

Eldorado.Railroad, on 30 August 2010 - 09:31 AM, said:

As OR uses a different display engine I wonder if 24-32 bit textures with transparencies and/or alpha channels are handled any differently than MSTS?

Are there provisions for alpha channels with more bit depth?

Can textures without reduced palettes be used without the palette aliasing seen in MSTS?

Eldorado

In general, OR will not reduce the color palette like MSTS does. However, OR does not provide more bit depth than what's in the original artwork. So, if you've used 8 bit alpha OR is stuck with the bit depth of the ace file.

The team is investigating texture file formats that provide much greater bit depth for the future. But nothing has been decided, nor a roadmap for implementation of alternative textures is committed.
chrisvw
Project Lead
openrails.org

[Genma Saotome]

The OR team has occasionally kicked around the idea that alternative image formats might be useful but to date nothing has been done with the idea. Paul Gausden suggested using the a different makeace program (the name escapes me), perhaps one that comes with Railworks (or is intended for use w/ Railworks) that can do better types of DTX compression. AFAIK no one has tested that idea but Paul does know his stuff so I expect he's correct.

For myself, I kinda like the idea of moving away from the .ace format as I think of it as a pretty corner case image format. Something more widely used, like .dds, is one idea. But as Chris said, nothing yet has been done.

[James Ross]

I'm not convinced compressing individual files is an advantage any more (though it may have been at MSTS's time), but multiple files in a single "package" (compressed or not) is. E.g. having downloadable content in a single zip that doesn't even need to be extracted to work (just save to the right folder) would be cool, but we can think more about this when we get to that stage.

In any case, I'd also support using DDS for textures, for the already mentioned reasons.

[captain_bazza]

Hmmmm, great idea for the future development of texture formats for OR.

[longiron]

Some good discussion about the advantages of texture file formats on the XNA forum. It appears DDS has a lot going for it including a lot of existing tools to manipulate and convert.

http://forums.xna.co...ms/t/43208.aspx

[captain_bazza]

Will OR support bump mapping, or does it already do so?

Thanks.

Cheers Bazza