I googled that the problem is that the graphics driver does not support texture compression used by old models.
3DO ("old model") textures are NOT S3TC-compressed, they can only be .bmp's or .tga's and Spring reads those into client memory as-is. This is just yet another one of ATI's GL driver bugs.
EDIT: The spring rendering code has some sections which handle DXT/S3TC compression (which is used in .dds). My ATI driver does not support DXT/S3TC decompression, so the problem must have something to do with S3TC.
But if all the textures are BMP and TGA (which don't have any compression, except RLE), how there can be problems with textures and S3TC?
Last edited by megaNaab on 21 Jun 2010, 20:48, edited 2 times in total.
A little knowledge is a dangerous thing. It is obviously a combination of user incompetence and bad driver testing by ATi, so please stop say what devs "have to do".
I would request a lock for this thread, because it doesn't lead to anywhere.
Devs are no longer even responsible for tatextures_vXX.sdz and haven't been for years. And as kloot said they are all bmp and tga. (at least in the most recent version I have)
Anyone using .dds with 3do is smoking some serious products...
Well, im as much as a layman about this as anyone, but heres what I think happens (anyone knowing better please correct me or feel free to edit/delete this post) :
3do's use 1 texture per face, so each face has a UV range of (0,0)-(1,1) Thus each face uses 1 single texture. Now having the gfx card switch textures bindings to a new image on _every_ face is slow, thus undesirable.
What the engine does instead, is it takes all these per face images, and tiles them on a large texture, then transforms the UV coordinates of the faces to correspond to the correct part of the large tiled image. Somewhere along the ATI driver update, functionality on a pathway related to coordinate generation/transformation was changed, thus resulting in the UV's not being transformed from the (0,0)-(1,1) range to their corresponding small areas. So the gfx drivers map the whole tile map to each single face.
Of course it is possible, but your time is better spent spamming ATI with bug reports IMO. There will also be mod checksum mismatch if you change the textures, so you will need a hacked EXE.
So lets coordinate our efforts in sending bug reports. Can someone report how to submit those bug reports? I haven't done one till now.
However seems that the 10.5 and the 10.6 driver versions put some problem with few old, but more known games. Maybe if Ati fix them, it will resolve our problem too.
Joined: 08 Jan 2009, 23:39 Location: North Carolina
I have the exact same problem with my 4830 running 10.5 drivers. I like the drivers though cause they fix all the longstanding issues in IL-2 1946. Why can't spring be updated to get away from such ancient compression? Just saying I have no other issues with anything else.
There should be a big warning message when installing spring. As Ati is very popular at the moment and having the latest driver installed is not unusual either, a big chunk of newbies that install spring today will get gfx errors making them cry and uninstall spring.
Joined: 29 Aug 2009, 19:12 Location: Also Richmond
That's a good point. I would hate to jump through all the hoops just to find that the textures are screwy. Then again they might pick a game that has s3o's...but still a polite heads up would probably be...well polite.
Users browsing this forum: Bing [Bot] and 2 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum