Loading png vs bmp
BlitzPlus Forums/BlitzPlus Programming/Loading png vs bmp
| ||
| Is there a differnce in the speed of loading these different types of graphics. I know png's are smaller, but they may have to be reformatted (decompressed) into bmps for Direct X.. I'm not sure. Anyone know off hand? Thanks |
| ||
| In the second page of this forum there's a post like this one ,i think it's called"Witch format .bmp .jpg. .png?". Do you see many interesting arguments. |
| ||
| I haven't seen the other thread but I use png's for everything and have no problems with speed |
| ||
| Yeah, I saw that other post, but it doesn't really answer the question. I guess I could do the experiment myself, but I figured I'd ask before I went to the trouble. fyi: I'm loading ten 800x600x8 bmps and it takes 12-15 seconds. Not long, I know, but I'd like to speed it up if I could. .. yeah I could load them as I need them but then I end up with 1 second load times at 12-15 places.. and that's much more distracting I think. |
| ||
| Well I would EXPECT that providing your PC wasn't too old and clunky, the extra time taken to load a png would be more than made up for by the less time it took to read it off the HDD, and the faster the PC was, the bigger the difference you'd see. |
| ||
| Ten 800x600x8... try to use tiles. It seems that if you load an image (PNG, BMP, etc), Blitz will convert it in the game resolution ; if you run 16bits, the image will be 16bits into the memory card. So, if your 800x600 (Gloups !!!) is 15kb and run your game in 32bits, the image will be a true 800x600x32 into the memory card. |
| ||
| I always use PNG format, saves on disk space and I don't think the speed affected to much, so I don't anyone will notice. :) |
| ||
| These are hand drawn 800x600 fullscreen backgrounds, and 800x600 graphics that are collections of buttons, graphical fonts, and other misc. in-game graphics. There are no tiles or tileing in my game. And most of them need to be loaded at all times. I know how to do tiles, see the link in my signature for evidence of that. I suspect that Anthony Flack is right, but I'm curious to see actual results. If I do this test, I'll post the results here. |
| ||
| Yikes.. I'm a good programmer. You'll notice me pimping my game in my signature, but I'm new to blitz. I say this because my results were pretty startling and I'm not going to be surprised if one of you more experiecenced blitzers tells me that I did something wrong. My test code is this ;--- Graphics 800, 600 DebugLog MilliSecs() For i = 0 To 100 imgtemp = LoadImage("C:\slug.bmp") ; or slug.png Next DebugLog MilliSecs() ;------- I used the same 800x600 image saved as png, and as 24-bit bitmap. the bmp was 1.34MB, and the png was 500K. When I did the loop 100 times. The bmp took approx 80 seconds (just less than one second per image, this is what I see in my game too). The png took only 500ms, or 1/2 second. The png was 160 times faster!?! Is that possible? When I did the test for only 10 iterations. The bmp took approx 8 seconds and the png took 5 milliseconds. These results seem pretty unbelivable to me. But I did it several times. Am I somehow using Millisecs() incorrectly? (I subtracted start time from end time). Or are there other blitz factors I'm unaware of. There's got to be something fishy going on because the png is 1/3 the size of the bmp, you'd think it would take at least 1/3 of the time (just to read the disk!). Perhaps blitz checks the contents of a imgVariable before loading in a new image or something? Anyone want to use this code and verify my resluts? Is there a flaw in my reasoning? |
| ||
| Hi, I am not so sure about your result.. I use loads of images in my latest project.. (728 to be exact), and I had to convert them all back to bmp, since it was taking forever to load in all the imagesequences in png format. Are you using 256 color images, or 24/16 bit? Maybe there is a difference? Cheers /.D |
| ||
| Loading .bmp is always faster than .png in all cases, as it must be decoded. But the difference is less noticable, the faster your PC is. It's not significant anyway unless you're planning to load images in real time during your main game loop. Loading things like big .ogg files is where loading times increase substantially. |
| ||
| Can some one explain the flaw in my test code or my analysis of its results? |
| ||
| Hi APE I'de say that the png is small enough to loaded into the windows disk cash so it only loads once from the hard drive and 99 times from memory. The BMP is probabaly being loaded from the hard drive every time. Or The file loading routines for Png and BMP are different. To isolate the hard drive time try creating a ram disk to store the image. Ps in real world PNG will be faster as the hard drive is far more of a bottle neck than the CPU having to process the PNG. Thats my bit |
| ||
| Don't forget you can use PNGcrush to get the PNG files even smaller. |
| ||
| Well I just wrote a simple benchmarking program to find out the answer here. I'm using a 2.4GHz P4 with 512MB RAM with a 7200 RPM hard disk so bear in mind that PNGs and JPEGs are relatively less disk intensive and more CPU intensive. I started with four high resolution digital photographs 1800x1350 or so (they started as JPEGs) and exported them to PNG and BMP. The JPEGs ended up being roughly 1.5MB, the PNGs 4-5MB, and the BMPs 11MB each. Total load times were: BMPs 1.1s JPEGs 1.79s PNGs 3.215s Note that since these were photographs, this is a considerable disadvantage for the PNG file format (which does not do a great job compressing photographs). However, it's interesting to note that a 2.4GHz processor doing the crunching does not help the JPEGs to load faster than the far larger BMPs. Edit: I got 7 PNG files from an old multimedia project. These vary in size (they're pretty "realistic" kinds of images since they combine photographs with computer graphics and are reasonably small). BMPs 0.038s JPEGs 0.061s PNGs 0.103s Note that these PNGs have alpha channels, so loading the JPEGs and BMPs is less work to begin with -- but here we see PNGs falling further behind. So -- my immediate inclination would be to always use PNGs and JPEGs, but if performance is an issue it looks like BMPs win hands down. |
| ||
| I wouldn't have thought that PNG would take that much longer, as I'd have figured that the processing time for decompressing a PNG would be much faster than the time taken to access the hard disk space for a much larger file (BMP) than a PNG. |
| ||
| "So, if your 800x600 is 15kb" "These are hand drawn 800x600 fullscreen backgrounds... There are no tiles or tileing in my game... most of them need to be loaded at all times." Where did you get 15kb? Even at 1bit (ie. 2 colors) an 800x600 image is 60kb. At 32bit color depth it is 1.8MB. Multiplied by 10 is 18MB. Add the front and back buffers (assuming the game itself is 800x600) and you're looking at around 20MB. APE, barely anyone has enough memory for that. You are going to have to redesign your game so that it uses less video memory. Yes that mean compromising your vision but design is compromise. Frankly I think you will need to just accept the 1 second load times here and there because having all those background images loaded in all the time is a killer. 1 second is really not all that long; even without the load time you'ld want to give your players a little time to rest between levels. ****** OT, was "Once Twice Thrice" developed in Blitz? If so I didn't realize that. Up until they stopped taking outside submissions I was at Dexterity.com a lot so I am familiar with your game. |
| ||
| I don't think I said that my 800x600's were 15K, that was Reno. My dev machine has a half-gig of ram and 64MB video so I know I'm pretty top-of-the-line, but time to negotiate for low end machines hasn't come quite yet. I'm actually curious to see how Blitz handles swithcing between video memory and system memory. DX does this pretty transparently and I want to see how blitz compares. I'll have all those surfaces in memory but I'll only be drawing from two or three of them at a time, so I'm hoping blitz will keep the ones I need at hand and let the rest live in system memory so that I don't have to stop and load between screens so much. OTT was done in VB6 with DX7. I've only been in Blitz for a couple months now. The debugging is more trouble than it is in VB, but the other advantages are very good. So far, I'm very happy to have made the switch. I'm curious to know how different the products will be to support. I'm starting to believe that BB will be easier than VB, but the true test of that will come after finishing the current project. |
| ||
| Seth: I totally agree. Before I did the test I was ready to say use PNGs or JPEGs and leave BMPs well and truly alone. Now I am rethinking my position... I might add that whoever was doing hundreds of loads in a loop was really benchmarking disk caching and not useful performance. Heck, if the decompression is being done in a well-written library, the decompressed images may well be being cached too (consider that a typical decompression task involves reassembling small GIFs and JPEGs for a web page, which are frequently re-used in a design). |
| ||
| Oi, benchmarking the cache. I used to work with moron website developers who would benchmark pages they were designing without clearing the cache first. |
| ||
| Heh. APE, I think you may be right. Blitz should transfer those images between VidRAM and sysRAM without problems. I think. |
| ||
| @APE&Anthony : are you sure Blitz transfer images from VidRAM to SysRAM by itself ? I don't think so. I guess you must create a bank, store your data from image (ReadPixelFast) into the bank and then free the image. Maybe using B+ with LoadImage "SysRAM flag", you store images in normal memory, but you lack a lot of speed when blitting. |
| ||
| Believe it or not... In my latest production I used .PCX files... The most popular picture format in the MS-DOS era... I was surprised Blitz supports it, but since the programs I prefer to use are DOS-apps and thus writing in .PCX, it saved me a lot of trouble... By the way, I don't even have a way to write .PNG files... Which util can do that? Oh wth... I think I'm about to use my own format one of these days... |
| ||
| To load a PNG you need more time. I've tested it. It's not so much. I think bmp was about 30% faster. In the graphics-memory every graphic, eqal to bmp, jpg, png or CreateImage :D) needs the same memory (=size of bmp). It is only a difference on the disk. |
| ||
| That can be true.... Bmp contains no form of compression... This can speed up the process since decompression can eat up more time when your processor is slow... Alas when you create a BIG production, working with BMP is hell since they eat us so many diskspace.... All true is that when Blitz loads such pictures it's all converted into the same formal that Blitz uses for its memory maintanance, so once the file has been loaded, there's no diffrence at all in these pictures... Not even if you create your own picture format... |
   |