Loadimage - maximum image size
Blitz3D Forums/Blitz3D Programming/Loadimage - maximum image size
| ||
| Hello, I was wondering what is the maximum image size that I could load with the Loadimage function? I tried 4200x600 pixels and I get a lot of trash on screen. However with 4000x600 image it works just fine. Of course I have to crop the image to the screen size to produce it on screen. Thanks, Marko |
| ||
| Generally it is recommended that you don't load any images larger than the screen resolution. 4000 * 600 may work on your computer but it is not guarenteed to work on others. I would suggest breaking the image up into 5 or 6 seperate files and then just drawing them side by side. |
| ||
| Thanks for the response, however I don't understand why it would not work on any other computer. What I did is: I loaded the whole image (4000x600) and then copied only the screen size of the picture to front buffer. this should work on any computer no matter how big the picture realy is. I am trying to make a scrolling picture on the screen and have images larger than 4000 pixels in width. thanks, marko |
| ||
| Some graphics cards may handle this badly. I used to have an nvidia vanta which displayed junk when I tried to load a very wide image, about 5000 pixels. But I could load and properly display an even bigger image with the same card. This bigger image was so large it would not fit into the 16mb of graphics memory. Apparently Blitz then loaded it into system RAM and copied only the required portion to the screen display each frame. |
| ||
| On a related topic, i've had no problems loading large images (4096x4096), but when i use createimage to create an image the same size, frame rate suffers drastically? |
| ||
| Floyd's absolutely right. One of my laptops absolutely refuses to load images larger than screen size -- the remaining image gets filled with random memory garbage when you try to display it; you have no guarantee that loading any images in larger than that will work. IIRC it's to do with the way drivers interact with DirectX's surfaces but the specifics elude me. To do what you want to do reliably, you'll need to chop the image up into smaller bits and tile them traditionally. |
| ||
| If your trying to display and scroll the super large image, maybe you should look into tile maps :o) |
| ||
| I was under the impression that Mark has implemented code to automatically break up the images behind-the-scenes, so you might want to post this in the bug reports forum. I tried 4200x600 pixels and I get a lot of trash on screen. I'll wager 4096 is the magic number for your particular card, before it starts screwing up... Powers of 2. |
| ||
| Hello all, Thank you for all the comments. However, this still doesn't solve the problem. What I need to do is to display a scrolling image on screen that is larger than 4000 pixels. Howerver I do not have any influence on the images (i can't change them because this is supposed to work dinamicly for any picture put into the folder). What I have learned here is that there is no way I could load a bigger picture (bigger 4000 pixels in width) and work with it? Does this mean that LoadImage loads the complete image into video ram? Can I load the image directly into ram somehow and then move parts of it into video ram? thanks, Marko |
| ||
| That isn't the whole truth. I have some problems that are related to this topic. Try the following: pic=createimage(5120,256) then fill the pic with some random graphics, then draw it to the screen. On my Computer this works without any problems. But big surprise, when i use SaveBuffer or SaveImage to save this image as a BMP, I got some vertical garbage strips in the File. The fact that this happens whle saving (or in your case while loading) suggests, that it isn't a videoram issue, but rather a file operation problem. probably a buffering bug. Please try the CreateImage test. ( BTW has anyone an idea how I could save an array of images in one big image to be used with LoadAnimTexture WITHOUT to use SaveBuffer? Should I manualy save the BMP? Maybe use a Bank to save it quickly? any BMP Header description around?) |
| ||
| ok, i have some new infos: I have written a custom BMP export function that will save an Image Pixel by Pixel. Although I can drawImage a 5120*256 Image that was created using CreateImage to the screen without any troubles, the same carbage stripes reappear in the saved faile that I used to save using my custom BMP Save Function. Now this is weird. It seems like: PIxels can be written at any image size. Pixels may return garbage when you read (ReadPixel or ReadPixelFast) them from very big images! can anybody confirm this? |
| ||
| I don't know about these 2 statements but I can add that: Pixels won't return garbage when you read them from very big images IF the portion that you read is on screen (fitting in screen resolution). That's a statement from previous experience with (loaded)images of 4000*600 or bigger (don't know if there is a limit) and this on all my computers (got 4, all different videocards and cpu). I was scrolling the image and saving bmp's of 800*600. |
| ||
| Ok, I got a workaround that works for my custom code: my frame-handles (images) for the animTexture are stored in the array "strip(n)", so I only need to readpixel them to store the big picture/animstrip. It was a bit confusing to read from the right frame while writing the big picture. It is no longer a generic BMP Saver now, but works for me. Surprisingly the Animstrip loads correctly when loaded with the LoadAnimTexture command. For your Problem with the Loading Garbage artifacts, you could write a custom Loader, something like this (I assume it's a 24bit BMP): n$="bipicture.bmp" fs=filesize(n$) img=loadimage(n$) w=imagewidth() h=imageheight() ; (alternatively you could also read w and h from the bmp header: at offset 18 and offset 22 are width and height in 32 Bit values (low bytes first)) freeimage img img=createimage(w,h) bank=createbank(fs-54) re=readfile(n$) readbytes bank,re,54,fs-54 closefile re setbuffer imagebuffer(img) lockbuffer for y=0 to h-1 for x=0 to w-1 adr=(x*3)+(y*w*3) r=peekbyte(bank,adr+2) g=peekbyte(bank,adr+1) b=peekbyte(bank,adr+0) rgb=(r shl 16)or(g shl 8)or b writepixelfast x,y,rgb next next unlockbuffer setbuffer backbuffer() Freebank bank something like that (not tested). If you want to use other Image Formats, it may be harder. |
| ||
| LAB - Didn't work for me: The garbage bar was visible all across the whole width of the image. |
| ||
| In my opinion there must be a problem with the loadimage command rather then the way to show loaded picture on screen. Best regards Marko |
| ||
| there must be a problem with the loadimage command No, it's just a limitation of different graphics cards/drivers. |
| ||
| A reference from gamedev.net implies that DirectX 5 and up can create image surfaces of =any= size; if the drivers or hardware don't support the operation then the image is created in system ram. This is expected behavior, and in a perfect world you'd be able to trundle along with your original plan -- though with images that size you'd be constantly swapping out between system ram and video ram, which isn't good practice because it makes a significant speed hit. As this isn't a perfect world, what I suspect is happening in these 'garbage' cases is that a driver reports that the card has this capability when it actually doesn't, and the result is the garbage you're seeing on a lot of older cards. Unfortunately there's nothing you can do if you want to stay compatible with these cards aside from keeping image size no larger than screen size. |
   |