Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

SikCiv

Video mem or sys mem?

This topic is 6915 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Since im blitting alot of alpha blending stuff, I have put all my surfaces into System Memory. But ive lost half my framerate in Fullscreen mode!!!!!! How do I overcome this problem? Should I put the surfaces that are not involved with alpha blitting into video memory or something? HELP!!

Share this post


Link to post
Share on other sites
Advertisement
Vid mem is obviously fastes, but if you are forced to use system memory (for alpha) then you need to try to cut down on the amount of data that must be transfered from sys->vid memory. This is where the real bottleneck is. System mem is slow compared to video memory, but the transfer between the two is just killer performance-wise!

Check out the GPI project today!

Share this post


Link to post
Share on other sites
So i guess having lotsa small surfaces for each frame of animation is better than putting all the frames on one big surface, in terms of pumping as much surface mem into the vidcard?

I guess I should also put surfaces that are blitted alot into vidmem.?.

Share this post


Link to post
Share on other sites
If you are using any per-pixel hand-coded operations such as alpha-blending then to maximize your framerate you want all surfaces that take part in the alpha-blending to be in sysmem. The system I use is this:

1. Create your front and back buffers in vidmem.
2. create a surface (we''ll call i, worksurface) in sysmem the size of your back buffer.
3. All bitmaps involved in alpha-blending get created in sysmem.
4. Any bitmaps that do not involve alpha-blending (such as a health meter or decretive border) go in vidmem.

Compose your next frame of animation on the worksurface with alpha-blending etc., copy thisd to the back buffer, then blt your health meters and borders etc.

With this method do not expect to achieve 85fps. I figure 30fps is possible. That''s the cost of per-pixel operations.

If you have a static background performance can be improved by using dirty rectangles.

2-cents,
John

Share this post


Link to post
Share on other sites
But when I put most of my surfaces in SysMem I lost over half my framerate.

The Alpha blending function used two surfaces, on of them needs to be the backbuffer in my case, as im blending some sprites with the backbuffer.

This is how i do it:
1) Copy the destination rect from the back buffer to a surface in sysmem.
2) Blend the two surfaces.
3) copy the result back to the back buffer.

Its kinda slow, is there an alternative?







Share this post


Link to post
Share on other sites
quote:
Original post by SikCiv

This is how i do it:
1) Copy the destination rect from the back buffer to a surface in sysmem.
2) Blend the two surfaces.
3) copy the result back to the back buffer.



Stage 1 is probably the killer. If you are reading from video memory to system memory (that is, is your backbuffer in video memory?) then this will slow you right down.

Yes, there is an alternatuive. Put the backbuffer in system memory too. Or, given the onscreen coordinates of the rectangle where the blending will take place, redraw that section of the screen into a ''scratchpad'' surface in system memory, do your blending, and blit that to the back buffer.

Share this post


Link to post
Share on other sites
Kylotan is right on. The copy from vidmem to sysmem is killing you. After many failed attempts I came to the conclusion that if you want per-pixel hand-coded effects then you have to do everything in sysmem in a ''scratch buffer'' or ''work surface'' then copy all of this or a parts of it (dirty rects) to your vidmem back buffer. Do not get hung up on framerate, you will NOT be able to sustain 60fps and have hand-coded alpha-blending.

John

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!