Open gl optimization (texture question)
BlitzMax Forums/BlitzMax Beginners Area/Open gl optimization (texture question)
| ||
| Hi, I wonder which one is the best method for optimizng textures to be displayed under opengl; so far, to my understanding DirectX displays (blitz3D) prefered the use of big maps containing the textures for more objects rather than small textures for objects. Is Open gl the same? (one 1024 x 1024 map better than 4 256 x 256 maps). Would it be better to use jpgs instead of bmps? (size of file seems smaller, but i do not know if at runtime it is the size of the map the one that matters) And finally, what sizes are recommended for texturing (speaking of textures for buildings, that will be displayed ). Any help is very welcome, including probably some links to sample geometry and textures. Thanks. |
| ||
| The fileformat should not make a difference as far as texturing is concerned -- as far as I know, the image data is stored in video ram in uncompressed form. That means that after starting the program and loading the textures, they are in neither JPG or BMP format, but raw image data. You still have a choice though: using .JPG for your textures will make the image you have to distribute with your program smaller, but will typically also be of lower quality (compression artificacts) than BMP would. |
| ||
| Don't know but Col released a bmax DDS compressed texture loader. In my experience, in most cases about 4x compression still looks good, and should use less video ram. |
| ||
| These issues are usually hardware related. On one card it may be faster, on another maybe not. It depends. In general the rule is that you don't want to switch textures for every triangle. You want to use the same texture as long as possible. |
| ||
| Thanks for the repplies, i'll be checking the dds compressed textures. About texture sizes, any thoughts? (i would like to have 25 maps sized 1024x1024, but i guess that would be serious overkill, am i quite off?) |
| ||
| Yeah could be critical without S3TC compression ( which is the same as DDS which only has a more specific name ) as 1024x1024 are normally 4 MB in VRAM -> *25 gives 100MB VRAM Think by far to much especially for only 25 maps |
| ||
| you need to make your textures depending on how much scree space they are taking up. Not make 1024x1024 textures becasue you can. Most people play games at 1280x1024 or less, so if an object in your game rearely takes up more than 1/4 of the screen, your probably won't need more than 512x512. If you have multiple maps on one 1024x1024 texture thats another matter. Blitz3D would certainly benefit from fewer larger texures if you combined surfaces and shared textures. But with BLitzmax you will probably have to experiment for yourself and see what works best. |
| ||
| Thank you guys, i'll be screening my project on a cinema, so that was why i wanted to have really large maps for each object, however wasn't sure how it would work. I'll try to see if my machine doesn't crawls that much using the dds compression, as i want to have really "sharp" images on screen; either i am really bad at mapping at 512x512 or i do need the 1024 ones. |
| ||
| I just read about not using .JPG because of the compression it loses alot of the pixels in the compression and if you try to save it to another format it still will not correct it. They stated to use bmp targa or png image files. Enjoy |
| ||
| you can often get away with Jpg if you work on the bitmaps in another format and save the Jpg's out at the end. There are also some pretty good jpg tools that allow you to use different compression in other regions. If your making a online downloadable game, you want the filesize as small as possible (obviously). Pax, I'd recommend working on your textures at 1024x1024 and try smaller sizes see which give the best mix of quality and size. You might be surprised. When I worked on the PS2 and Xbox, all the xbox textures were 256x256 with a handfull of larger ones 512x512, 512x1024 etc in 32bit with alpha. When we converted to PS2 we had to scale those 256x256 textures to 64x64 and 128x128 sometimes smaller and reduced the bitrates as low as we could, It's surprising how small you can get your textures and still have them look good. |
| ||
| Unless you're using 24-bit photo-realistic images it's a good idea to avoid JPG entirely. PNG provides pretty good lossless compression for images and is far better for the kind of images you're likely to use for games. Plus PNG supports alpha, and JPG doesn't. Muttley |
| ||
| yeah, I was talking about downloadable shareware. If you can get your download size below 5mb you will get about 60% more downloads than if it were 10mb. And if it's under 1mb you will get many times more. You have to decide, Unless your using flat textures JPG can be fine. I prefer PNG though too, if your using fairly flat textures you might be able to use a custom pallet and save as PNG with 16,32 or 64 colours. Sometimes even a lightmap can look good in 8 bit. A single 2048x2048 lightmap would be at least 10mb as 24bit PNG, but may be only 300 - 500k if its 128 or 256 colours. Just depends what your doing. I'm always looking to get the least expensive result as far as download size but still maintain the best quality possible. At the end of the day you have to find a good balance. |
| ||
| Hey, thanks a lot for this, really good information. One last question, though. Reducing bith depth is the same as compressing the image right (say jpg for instance)? In the sense that it'll only be lower for archive sizes, but at runtime it'll need the same video memory because it is the same size (else, i can use a lot of palete reduction, as my maps are turning out quite monochromatic). Thanks again :D |
| ||
| yeah, most engines run in 32bit internaly and everything gets converted to 32bit on load, so your bets bet is probably going to be the DDS compressed texture module that someone released a few days ago. there's some texture tools at the nvidia site that work with photoshop and Pantshop pro etc which are really good for compressing your textures. |
   |