voidhawk Posted October 30, 2001 Share Posted October 30, 2001 OK, so before being flamed to death, let me state right up front that I love all those mods as much as any other mod slut - and I have 542M worth of files in my bmp folder to prove it! But...I have to wonder, do we really need all mods to be of 512x256 resolution? For instance, the recent set of (very nice looking) bunker textures, and the older sets of Jeep and Kubelwagen textures all use this size for their "main" textures. But think about that - at a typical screen resolution of 1024x768, the object in question would have to fill more than half the screen before pixellation would become noticable. How often do you get that close to (say) a jeep? What I am proposing (flak jacket on) is that the textures sizes of mods are kept a little more in proportion to the size - and importance - of the object in question. After all, a jeep is only half the size of a tank, so why use the same texture size? (Sorry to keep going on about the jeep; I do like the mod - but I've scaled it down, see below) Even though I'm running what I think is a pretty much up-to-date system as far as CPU and graphics card is concerned, I find myself scaling down such large textures just to keep the frame rate up a bit (I run with FSAA on.) And guess what - for all intents and purposes, the end result is indistinguishable from the original, but uses only one quarter of the memory! On a side note, I wrote a small C program that halves a texture file while correctly maintaining transparancy as part of an effort to provide a "lo-res" copy of my high-res bmp directory for somebody else who is limited to smaller textures sizes on a V3-based system. I found there were a number of files that used values other than ff/00/ff (or fe/00/fe) for transparancy, and thus originally "broke" my halving program. It seems that CM can actually cope with values that are at least a little more off from the nominal values above; check out the holes in the "damaged" Pnz IV skirts (3106.bmp) or around the MG mount of the hi-res jeep (3640.bmp) for some typical values. Question: does anybody know what the actual allowable range is? I could experiment, but I'm so busy as it is... If there is interest I can make my "halving" C program available either here (it is small) or via some other mechanism; it operates on ppm files so some extra work is required to convert from bmp into ppm and then back again; I do all this on Linux. As a second side note, in order to possibly quantify the effect of texture sizes on performance, does anybody know of a utility that shows how much of the texture memory of a graphics card is actually being used, and/or how much is being swapped in and out over the bus? CMMOS could even be used to select between lo and hi-res texture sets...we'd need a naming convention for that though..."_lr", "_hr"? Such a selection mechanism might work well for objects that have a limited number of textures, such that the size of a CMMOS package would not become too big if it included both lo and hi res textures...just a though. I'll hide under my desk now. :eek: voidhawk Link to comment Share on other sites More sharing options...
Maastrictian Posted October 30, 2001 Share Posted October 30, 2001 Your C code could even be incorporated into the CMMOS to change from hi_res origionals to lo_res copies on the fly. --Chris Link to comment Share on other sites More sharing options...
voidhawk Posted October 30, 2001 Author Share Posted October 30, 2001 That sounds like a good idea - perhaps even as some kind of "global" option, e.g. just for files that are larger than a certain size. When I made the reduced-resolution copy of the bmp directory myself, I wrote a script that for each of my current bmp files, found what the corresponding "CM original" bmp size was (not a trivial problem), and then only scaled-down the ones that had a larger resolution than the original ones (and met some other criteria, to avoid scaling down improved buttons etc.) CMMOS would not know what the "expected" texture resolutions would be, and thus some other heuristic would have to be used for scaling textures on the fly, as there is not that much to be gained by scaling down the smaller textures. voidhawk Link to comment Share on other sites More sharing options...
voidhawk Posted October 31, 2001 Author Share Posted October 31, 2001 Optimistic bump for the daytime crowd... Link to comment Share on other sites More sharing options...
Cubbies Phan Posted October 31, 2001 Share Posted October 31, 2001 Well the large texture sizes really have nothing to do with screen displays as you put it where you have to fill the screen to notice pixelization. Texture enlargements are done to allow bigger textures upon which to draw the detail in better. It's easier to draw on a 512x256 texture than it is a 128x64 texture per say. Now as you say when reducing the size of a texture that has transparent pink in it, distorts the pink around the edges. However, as I have experimented with is when you drop the size of a texture, it does lose clarity. it other words, it becomes a little blurry. And I believe this bluriness causes the shift in pink pixels. If you have Felgrau's Churchill mod, you will notice that his textures are extremely oversized, sometimes 3 or 4x the size of the original texture. He did that so he could get the level of detail he wanted. Link to comment Share on other sites More sharing options...
voidhawk Posted October 31, 2001 Author Share Posted October 31, 2001 I reali[sz]e that texture size has nothing to do with the size of the screen display - what I said was that the extra detail that is possible in the larger textures is only visible if the object in question occupies the same, or larger, number of bits on the screen. For instance, a texture that is 512 bits wide will not show any more detail than a 256 bit texture when the texture is mapped to an object on the screen that is only 256 screen pixels wide. Textures can be scaled down without getting pink edges by handling samples containing the transparant color in a special fashion (majority rule), as I did with my own "halving" program. No more pink edges, and transparancy is preserved. Sure, object will look a little more blurry when viewed close up (see constraint above), but there is a memory cost associated with the larger textures. A texture 3 times the linear dimensions of the original will use 9 times as much (video card) memory; 4 times as large results in 16 times the memory use! As an experiment I swapped my bmp directory to such a "halved" (i.e. only textures that were bigger than the ones that came with the game were halved in linear dimensions) directory. And guess what - it still looked pretty good. Sure, there was some blurring visible on levels 1 and 2, but not on 3 and beyond. This suggests that hi-res textures are not needed for typical views - and that is why other 3D applications use MIP mapping for performance reasons - but at the expense of memory (as now both large and small textures have to be stored.) Anyway, that is not the issue here, and CM does not use MIP mapping as far as I can tell. As I said at the start, I love those hi-res mods too, but not everybody can run with them, and it is worth keeping that in mind with all these very nice hi-res only CMMOS mods coming out. Link to comment Share on other sites More sharing options...
MikeyD Posted October 31, 2001 Share Posted October 31, 2001 I suspect many of these super-mods are done more as an exercise in 'virtual modelling' and playability be damned. What seems to work best visually for me is medium-resolution art, but with special attention paid to a lot of faux 3-D cast shadows. I'd rather have a sparcely detailed tank that looks 'real' from a distance than super-modified art that's the same shade of green on all 4 sides at a distance. Link to comment Share on other sites More sharing options...
Captain Wacky Posted October 31, 2001 Share Posted October 31, 2001 I was getting annoyed by all the high-res CM mod bitmaps slowing down my comp, so I went back and coverted them all to the original resolution using Paint Shop Pro. The difference is negligable, especially if you play at level 3 and 4 like I usually do. Link to comment Share on other sites More sharing options...
Pascal DI FOLCO Posted October 31, 2001 Share Posted October 31, 2001 Good discussion ... From experience with a very modest system (Athlon500, 32Mb ATI rage card) and every HiRes mod that exist -or nearly so :eek: - there seems to be mainly 2 - and only 2- types of mods that hit performances : grass, and buildings (the extremely big ones from Tanks A Lot) ... IMO this is because the game loads all grass and buildings BMP every game (replace "grass" with "snow"' for winter games )! Apart from that, a vehicle or infantry mod seems to have negligible effects, because there's not many TYPES of vehicles and infantry on a given game. So I'm not sure than reverting to LoRes vehicles will give so much increase in perfs... but perhaps I'm wrong ! Anyway I'll have a try at your tool if you make it available and working on W9x ! Link to comment Share on other sites More sharing options...
voidhawk Posted October 31, 2001 Author Share Posted October 31, 2001 Yes, performance is one aspect, and as you say, as long as there are not too many units involved, the performance impact of a couple of hi-res mods may be overshadowed by the effects of the terrain and building textures. However, some graphics cards (such as the Voodoo 3) can't even handle textures greater than 256x256 from what I gather. Now...I used to have a V3, and although some of the textures (such as the sky) are larger than this limit, they were still displayed...which leaves me a little puzzled. Perhaps the V3 driver simply scaled down the texture itself (by discarding pixels rather than interpolating?) Anyway, it would still still seem like a good idea to be able to scale down textures on the fly using a tool such as CMMOS. As for the W9* implementation of my program...that could be a while as I do not have a W9* development environment - but I'd be happy to supply my algorithm to anybody who wants to turn it into a W9* program that operates on bmp files. Link to comment Share on other sites More sharing options...
MikeyD Posted November 1, 2001 Share Posted November 1, 2001 I have noticed a large map scenario with a lot of units will cause the resolution of my graphics to drop - sometimes considerably! A tank or a building that's sharp as a tack on a small map will get muddy and fuzzy on a large map. Link to comment Share on other sites More sharing options...
voidhawk Posted November 1, 2001 Author Share Posted November 1, 2001 <blockquote>quote:</font><hr> I have noticed a large map scenario with a lot of units will cause the resolution of my graphics to drop - sometimes considerably! A tank or a building that's sharp as a tack on a small map will get muddy and fuzzy on a large map. <hr></blockquote> What kind of graphics card are you using? Link to comment Share on other sites More sharing options...
Recommended Posts