Optimisation and the inner workings of Blitz
Blitz3D Forums/Blitz3D Programming/Optimisation and the inner workings of Blitz
| ||
| Just a few questions : 1) I'm fully aware that surface count is the no. 1 speed barrier in Blitz. However I'm a little unclear on how Blitz allocates new surfaces. Lets say I have 10 particles (sprites). They are all identical - same texture, same color, same alpha. How many surfaces? 2) Now I alter the alpha of 5 of the 10 particles to 0.5. How many surfaces? 3) Now I use EntityColor() to make all the particles DIFFERENT colors. How many surfaces? 4) When I started my project I didn't know about the sizing 'rules' for meshes (1 unit=1 foot or whatever) and consequently all my geometry is very large-scale. Changing it all would be a MAJOR job. It works fine, but I have to have the CameraRange set to 75,55000. My question is : could this have negative effects down the line ie. are there graphics cards / PCs that wont like such a large number and kick up z-buffer / framerate / other problems? NB. my VooDoo3 seems to handle it just fine, and that's some pretty old hardware ;) 5) Does .png have any speed advantages over .bmp in terms of loading times (what with the files being much smaller). Thanks in advance :) |
| ||
| 5) pngs are compressed. So of course they load slower than bmps, which do not need to decompress during loading (CPU dependant versus harddrive speed dependant - I'm assuming CPUs can decompress a png faster than a harddrive can load a bmp:). Of course, who the hell cares, the file sizes rock. =] |
| ||
| Hi, 1) Sprites work by dynamically creating a mesh each render world. But the mesh is drawn in 'chunks', with renderstate changes in between. Blitz checks for redundant changes, though, so the overhead isn't too bad. Still, this could be dramamtically improved using vertex alpha/color. 4) I would recommend reducing the size of your units! You may have future problems with zbuffering and collisions. |
| ||
| 5) Personally I have dropped all .jpgs/.pngs from my game from the start... I want 100% quality where every pixel is like I want and does not detoriate during editing (saving, editing, saving etc .jpgs does that) and only .tga and .bmp formats can deliver that. Filesizes are bigger, yes, but in the end the difference isn't that great IMO (what's few megs anyway...). And of course .tgas and .bmps compress pretty nicely for installer/download package. |
| ||
| @Mustang Aren't PNGs lossless in their compression? If not, they make a pretty job of hiding it. JPGs - Just a bit too lossy for me! |
| ||
| PNGs are lossless, yes. Nobody should EVER, EVER, be loading jpegs, editing them and saving them again. Load your uncompressed version, edit it, and resave the jpeg over the top of the old jpeg. |
| ||
| Yeh Mustang, leave pngs out of it, they rock ;] jpegs are of course fine if you compress them at 0%, but they're still a little large. Like, not compressed at all. =] |
| ||
| I hate .pngs just because they do not get along with my Photoshop6 (which is not .pngs fault of course!). Just try to do .png with alpha using Photoshop... not fun! I gave up and use .tga with alpha channel - works 100%. |
| ||
| I would recommend reducing the size of your units! You may have future problems with zbuffering and collisions. Duh? I can't say for the collisions as it clearly depends on the blitz implementation, but for zbuffer, why would there be any problem with big scales? Unless you use very, very big scales (going to the limit of floats precision), all that matters for zfighting issues on todays gfx cards is the ratio "far clipping distance / near clipping distance", meaning that havingCameraRange(cam,1,1000)or CameraRange(cam,100,100000); (with entities 100 times bigger)should give the exact same result. Any enlightment, Mark? Maybe I've missed some Blitz specific issue, but just can't figure out what. |
| ||
| Really? What problem do you have with png + alpha + photoshop 6? It all seems okay to me. |
| ||
| I can't speak for his problems of course but for me alpha in png has the obvious problem of losing the alpha-ed out portions of the image when I load the png. I use png for my alpha transparency needs but I always have to work on and save from a non-png version (as you pointed out to do with jpg images) because loading the png image loses a lot of information. Mustang, note that doing alpha transparency for png is fundamentally different than for tga images. With the latter you simply create a new channel called "alpha." While this technically works with png you end up with ugly white halos due to anti-aliasing and the fact that alpha-ed out portions of the image are turned white when the png is saved. Instead you need to set the image as a layer, eliminate all other layers (including the background layer,) add a mask to the image layer, and paste your alpha image onto the mask's channel. ***** Skitchy, things are a little different with sprites (as mark indicated) but for most entities surfaces are allocated by entity first, and then further split up based on texture/material within and entity. So even if they all have the exact same texture/material, 10 separate entities are 10 separate surfaces. |
| ||
| Mustang, note that doing alpha transparency for png is fundamentally different than for tga images. With the latter you simply create a new channel called "alpha." While this technically works with png you end up with ugly white halos due to anti-aliasing and the fact that alpha-ed out portions of the image are turned white when the png is saved. Instead you need to set the image as a layer, eliminate all other layers (including the background layer,) add a mask to the image layer, and paste your alpha image onto the mask's channel. Yup. I use .TGAs at work (or separate alpha images that the code compiles together) so working with .TGA and alpha channels is like "second nature" to me... PNGs gave me so much unneeded hassle and problems + different workflow that I just ditched PNG - why fight when I have working alternative? (bit like DarkBasic vs. Blitz3D... :)). |
| ||
| Ah okay. Since I always work from psd files and save out to whatever format I need from there, I guess it never cropped up for me. |
   |