How does MMF use video memory?
I looked around for a discussion of this, but I didn't see anything.
How does MMF use the video memory?
I know that many 3D video cards basically require textures to be sized to a power of two, have a 1:1 horizontal/vertical ratio, and be no more than 1024x1024 in order to run optimally. Does this matter to MMF? I would imagine that using many sprites of arbitrary sizes (and frame/animation/direction counts) will leave a lot of gaps in VRAM, resulting in an inefficient use of the available memory (though with many cards having 128MB as a minimum, even terribly packed I would guess one would still have to load around 64MB of graphic data in one frame to overload it).
Another question is: Does MMF load all of the graphical data on frame load, or does it move it in and out of system memory during runtime?
Mainly I'm trying to get an idea of how to optimize an HWA project for low-end video cards. I can get awesome framerates on my dev machine, but my test machine, which has the same CPU but a vastly inferior video card, doesn't get anywhere near the same performance.
Re: How does MMF use video memory?
This is basically immaterial.
remember the gfx card only renders a single entity(a platform) everything else exists as skins layed over.
soo put basically unless all your object are being displayed at once your object count will have a menial effect on performance.
where you do need to watch out is the event editor; limit your always events and generally don'
t have things happen that don't need to also some post renders such as 'blur real' can have pretty serious down sides when used on several objects at once.
Re: How does MMF use video memory?
Quote:
Another question is: Does MMF load all of the graphical data on frame load, or does it move it in and out of system memory during runtime?
I think it can do both, I think there are object options for loading on call or on frame (I think) (In object properties).
Jason
Re: How does MMF use video memory?
Quote:
Originally Posted by SEELE
This is basically immaterial.
remember the gfx card only renders a single entity(a platform) everything else exists as skins layed over.
soo put basically unless all your object are being displayed at once your object count will have a menial effect on performance.
I was asking about the usage of VRAM to load all of the frames for each sprite, along with the other data. The video card needs to load the data into VRAM in order to display it. 3D cards are optimized for loading textures, not sprites, so they expect things like 512x512 squares with MIP maps, not for instance 32x52 sprites with 52 frames of animation total, which might become a 1664x2704 "texture" in memory, unless MMF does some optimized packing or adds on some zero padding to make it fit the nearest power of two. Such a large texture could slow a low end video card's rendering down, and it's likely to leave gaps in VRAM.
Quote:
Originally Posted by SEELE
where you do need to watch out is the event editor; limit your always events and generally don'
t have things happen that don't need to also some post renders such as 'blur real' can have pretty serious down sides when used on several objects at once.
I doubt this is the case, as both machines have the exact same CPU and the same amount of RAM. The most significant difference is one has an ATI X1950 card, and the other has an integrated Intel video chip which is WAY less powerful. One gets 96FPS, the other gets 62 (and is skipping a full 6 frames on machine independent to do it). Clearly the video card matters. The performance is still vastly better than software rendering, but I'd just like to know if there's anything I can do to help it along a bit more.
Quote:
Originally Posted by JasonDarby
Quote:
Another question is: Does MMF load all of the graphical data on frame load, or does it move it in and out of system memory during runtime?
I think it can do both, I think there are object options for loading on call or on frame (I think) (In object properties).
Jason
Yeah, I know about the Load on Call feature, but I meant does the engine unload and later reload graphics on its own during a frame in HWA mode, or does it do one big load into VRAM and that's it (barring Load on Call) until the next frame. This is less important, but it could be relevant if an app needs to sequentially load a lot of graphical data on a card with limited VRAM, since the data in VRAM is probably uncompressed, so everything's likely the size of a BMP in there. An average PNG image may be 72-120KB on disk, but it's still close to a meg or more in memory. You have to pay for every pixel in there unless you're dealing with advanced formats like DDS.
Re: How does MMF use video memory?
I've heard that MMF does not unload textures from memory even when using load on call. Once the object is loaded in a frame it is not unloaded untill the frame ends.
I'm not 100% on that though. Just what I have heard.
Re: How does MMF use video memory?
It may render slower but that is because it has a slower card, if there both using direct3d9(or whatever) then 60% of the speed comes directly from that... what you do with that is 5% and how your app controls that is 35%; basically if your running slower then speedup your app because you can't speed up your hardware.
Re: How does MMF use video memory?
Quote:
Originally Posted by SEELE
It may render slower but that is because it has a slower card, if there both using direct3d9(or whatever) then 60% of the speed comes directly from that... what you do with that is 5% and how your app controls that is 35%; basically if your running slower then speedup your app because you can't speed up your hardware.
Right. That's why I'm asking how it handles VRAM and texture size issues, and if there are any quirks that can be worked around to improve performance. Rendering sprites should be incredibly easy for any 3D card since they are generally used in large quantities for UIs and for particles in addition to full 3D geometry, but I find that MMF slows down more than I think it should given what the hardware can do. That's why I believe that it has certain specific issues with the way it handles the graphics. I probably shouldn't bother asking until beta 2d or 3 though, as it's implied that the next version contains core optimizations.
Re: How does MMF use video memory?
iirc MMF still has some room for optimization; at one point Yves was trying to get MMF to auto-split non-power of 2 or non-square images during runtime, but he was having problems getting it to work. plus there were a few other improvable areas mentioned in the beta updates
most graphical extensions don't take advantage of HWA yet. if they work at all, they'll only run as fast as they do in software (i believe the graphical extensions that come with MMF are optimized)
of course, the CPU usage of hundreds of objects alone can still slow the game down
Re: How does MMF use video memory?
You seem to be missing what I'm saying it only samples from a single layer.
That means only 1 very large image can literally fit, there really is no issue here.
If your worried about actually using up VRAM then don't it WONT happen and if by chance it does then your doing something wrong... even if some one is using a 64mb video card that still leaves more then enough room for a very large finished game.
Re: How does MMF use video memory?
SEELE: It's for example really important to know what happens if an object image is 513x513 (a width one pixel larger from 512x512). If it rounds up to the nearest power of two, that means that memory for a 1024x1024 image has to be allocated for that 513x513 object, and if you just reduce the width and height of the original image by a single pixel you'll save 3/4 of the memory and gpu usage. That's why it's important to know this stuff, and the questions that DevonV asks is stuff I sooner or later will need the answer to as well.
It's fine for us if you don't care about optimizing your applications if you believe that every graphics card can handle it, but I like to optimize whatever I can.
