Do image go to ordinary RAM?
BlitzMax Forums/BlitzMax Programming/Do image go to ordinary RAM?
| ||
| ..or to some VRAM'ish section? E.g. Can I just load 300MB (or 1GB for all I care) worth o' images and have 'em all in mem, or am I limited to -say- 64MB of the VRAM or shared VRAM? (it's not for a game) |
| ||
| As I understand it : Images go to system RAM until they are drawn. They are then loaded to Video Memory which causes a slight delay the first time. I know that the DX driver uses the default algo for texture memory management which means the Least Used textures are replaced by new textures if you run out of VRAM. You really want to avoid this though as it causes slowdown. |
| ||
| what I'm doing is: - have images in ram - have max 4 images on screen, they're selected by keys - fade the newly selected image in, fade out the previous image, actually, the reason why I have 4 images is because of a cycle system to prevent seeing an older image switch to the new image during its fade-out. So the images that one sees at the same time is really 4 max. So, performance is not really shocking, as long as e.g. a notebook with 512MB mem can cope with it.. Otherwise I'll have to use a meatier notebook with more mem. |
| ||
| Images are in first step represented as TPixmap -> stored in RAM If you draw them for the first time, they are uploaded to the VRAM -> TImage if other Images (actually textures) need the VRAM, they are replaced and can be rewritten later if needed. But don't come up with the idea of using 300MB of RAM for it. This means that the system at least needs to have 768MB of RAM on XP and newer (not 512) and I do not think that there is any scenario where 300MB of data must be loaded at the same time for a single level in 2D |
| ||
| YEah they guys have it right. Also make sure they are not above 1024x1024 if you want slightly older cards to be able to use the textures. |
| ||
| dreamora: it's not a level, it's not a game.. :P It's a slide show. The sole reason I have all pix in mem is because I show small thumbnails. (setscale'd images). I could create thumbnails first and use them while I load the correct image from HD whenever I need it. But that's extra time I need to put into then, hoped I could avoid it. As for the amount of RAM, I dunno. 1024x768 would mean 3MB, and 100 images is perhaps a bit over the top. I could also try 512x384 images. After all the whole shebang will be displayed using a beamer, for a crowd averaging 60+ who're listening to accordion-ensemble 'music' .. (don't ask :P) |
| ||
| For a slideshow I don't think you'll have much problem unless you're going to time the images to the music. You could try just using loadpixmap and drawpixmap rather than images which will keep everything in system RAM. |
| ||
| Yupp, would suggest pure pixmap here as well. A slideshow does not need realtime normally. The only problem is that the alpha, scale etc commands only apply to images. But another thing that puzzles me a little: Do you have 3000x3000 screen? otherwise the 100 thumbs won't be onscreen which means that the images do not need to exist as well. PS: not even asyncron file handling will solve the problem as the largest part of the loading of an image is the upload and especially the mipmap generation. So by disabling mipmap and filtering it should already speed up considerably. PS: 1024x768 actually means 1024x1024 and if you didn't make sure you don't load with mipmap, this is actually around 6MB not 4MB (it will never be 3MB no mather what you do) |
| ||
| 1024x1024x4 bytes (for 32-bit colour) = 4MB. It's that simple (unless you Mipmap it) |
| ||
| You could create some form of image compression? |
| ||
| And then? In RAM and VRAM its still pure byte data unless you use S3TC compression (DXT on DX) which is not implemented. Image Compression is only nice for saving harddisk space at the cost of higher loading times |
| ||
Behold: The output widow right/below is normally to be placed right outside the screen so it'll appear onto the beamer. On top the main window with left a list o' groups, and right the images in such a group. Note that an image can appear in any group. One presses a key on the keyboard, and the image that belongs to that key will fade in while the previous image will fade out, e.g. a crossfade. The app itself works like a charm sofar. Since I'll also be doing the stage-lights/spots and a bit o' mixing, the slideshow can run by itself by simply moving on to the next image by a set interval. The thumbnails are simply the images with some setscale 1/16.0, 1/16.0 or something.., that's why I wanted 'em all in RAM, it'd save me the hastle to make a workaround for that. Anyway, I'll experiment a bit with 512x384 images, while also experimenting a bit with a vista notebook with 2GB mem I may be temporarily using from wednesday. |
| ||
| It's actually a shame that Image Compression hasn't been implemented. It's one of the few "fancy features" which are most useful for a 3D-accelerated 2D game. I know that pretty much any basic onboard card is going to have 64MB of VRam available, but if that's shared ram, you could seriously cut the bandwidth requirements if you were using 1/4 as much. Not to mention the extra animations and frames of animations you could fit in with that. |
| ||
| Well, thats just confused it, if Tpixmaps are indeed stored in memory, then why on earth can my system not manually modify a pixmap? Its obviously not a driver issue anymore? :S (sorry to half-hijack but the only functions that I can do in pure max right now is setcolour and plot...) Strange considering FLow and other 3D graphics work fine..... |
| ||
| They are indeed pure RAM, they are actually even pure Bytearrays meant to be uploaded later ... That you don't see the output btw does not mean that the content is not modified ... might be that the copy command actually fails due to beeing too high end and using DX7 |
| ||
| Image Compression hasn't been implemented. Wouldn't it be possible to create your own compression method, even a crude one? When you need to use it, decompress the data into a normal pixmap to then be shipped off to the graphics card. |
| ||
| and then? the compression would still be only on the harddisk. it has nothing to do with the pixmap and especially image size so its pointless as you can just use PNG, they are about the size you get with ultra zip compression of any kind of 32bit image data |
| ||
| Why would it? Store the pictures in memory as just a compressed stream of bytes. When a picture needs to be drawn, decompress it to a pixmap and send it to be drawn. Only one big image needs to be drawn at once, right? |
| ||
| that way you would even have it twice in RAM! Once as compressed and once as pixmap as the pixmap will exist until the image is null-ified so that would definitely be the worst idea. What people were talking above is actually real hardware compression. S3TC / DXT. that is small on disc and remains as small in VRAM. Benefit of it is faster loading time and pregenerated mipmaps if you want to use them. They drastically reduce loading and upload actually and raise the FPS due to that (as texture binds are faster as well) |
| ||
| that way you would even have it twice in RAM! Once as compressed and once as pixmap as the pixmap will exist until the image is null-ified I think the idea is to have 1 pixmap and 100 compressed pixmaps rather than 100 pixmaps. Might work if the decompression is quick enough. TBH I would probably look for a 'loadpoint' where I load some more images from disk and get rid of those already seen. |
| ||
| OK, the loading from RAM instead of disc could make a difference if you want to force it to "only have pixmap for what drawn at the moment". Problem is that even a compressed one will take some space (+- png file size) and you would still be forced to remain on pixmaps |
   |