memory allocation
Author
Is there a function for allocating video memory (like malloc or GlobalAlloc)? If there is, is there also a function like GlobalMemoryStatus to go with it?
I know I could use the DDSCAPS_VIDEOMEMORY for DirectDraw surfaces, but it would be a bit difficult (for me, at least) to adapt my memory manger to use non-contiguos blocks of memory; also that would defeat the purpose of most of the work I''ve already done.
Does anyone else find it odd that MicroSoft''s introduction to DirectDraw goes on about how slow gdi is, but their tutorials also recommend using ddutil.cpp which has at least one gdi call per function?
----------
meh
Balbasaur,
You cannot allocate Video Memory, at least, you cannot allocated "Video Memory" in VRAM. You can only use it !!
I known that the best way, and by the way you ask, its will be a linear buffer. But i don''t think DX support linear buffer. i must check that one. DOS in PM support it beautifully.
Happy Coding,
LowRad
You cannot allocate Video Memory, at least, you cannot allocated "Video Memory" in VRAM. You can only use it !!
I known that the best way, and by the way you ask, its will be a linear buffer. But i don''t think DX support linear buffer. i must check that one. DOS in PM support it beautifully.
Happy Coding,
LowRad
When you use the DDSCAPS_VIDEOMEMORY flag to create a surface, all it is doing is allocating linear memory on the video card (if there is video memory left), direct draw just manages it for you. The only way to access that memory is to lock the surface. when you use the IDirectDrawSurface::Lock(RECT,LPDDSURFACEDESC,DWORD,HANDLE ) function to lock the memory, a pointer is returned to the lpSurface variable in the Surface Descriptor that can be used as linear memory:
BYTE *8bitpixel=(BYTE *)DDSurfaceDesc.lpSurface;
8bitpixel[10]=0xFE;
However, with this process there are a few things you should know. For one, this is SLOW! I am not sure exactly if you are directly manipulating video memory, my guess is that when you lock the surface, a copy is made in system memory which you manipulate, then when you unlock the surface it is moved back into video memory. The next thing you should know is that when you lock the surface, EVERYTHING comes to a screeching halt, you can''t do much except do what you want to do with the surface then unlock it. If you try to do much else without unlocking the surface, you will get protection errors and be booted out!
The last thing you should know is, when you lock a surface, the memory allocated is larger than the actual linear surface size. There is a buffer zone on the right edge of the surface which must be accounted for. If the width of your surface RECT is 40, you cannot "SEE" the data at position [41] since it is part of the buffer zone on the outter edge of the surface. I say "SEE" because when you use the surface as graphical data, anything written to the buffer zone while it is locked will not be displayed after it is unlocked. So the question is, how do you get the data position of the next available pixel? Well, there is a variable in your Surface Descriptor called lPitch which gives the true width of each line. So to get the position of line two''s first pixel you must multiply the X position you want by the lPitch variable:
8bitpixel[1*DDSurfaceDesc.lPitch]=0xFE;
Does anybody know what happens to the buffer zone after you unlock the surface? Does the data you have written there stay there, or is it over written by the time you relock the surface, I have never tested that.
BYTE *8bitpixel=(BYTE *)DDSurfaceDesc.lpSurface;
8bitpixel[10]=0xFE;
However, with this process there are a few things you should know. For one, this is SLOW! I am not sure exactly if you are directly manipulating video memory, my guess is that when you lock the surface, a copy is made in system memory which you manipulate, then when you unlock the surface it is moved back into video memory. The next thing you should know is that when you lock the surface, EVERYTHING comes to a screeching halt, you can''t do much except do what you want to do with the surface then unlock it. If you try to do much else without unlocking the surface, you will get protection errors and be booted out!
The last thing you should know is, when you lock a surface, the memory allocated is larger than the actual linear surface size. There is a buffer zone on the right edge of the surface which must be accounted for. If the width of your surface RECT is 40, you cannot "SEE" the data at position [41] since it is part of the buffer zone on the outter edge of the surface. I say "SEE" because when you use the surface as graphical data, anything written to the buffer zone while it is locked will not be displayed after it is unlocked. So the question is, how do you get the data position of the next available pixel? Well, there is a variable in your Surface Descriptor called lPitch which gives the true width of each line. So to get the position of line two''s first pixel you must multiply the X position you want by the lPitch variable:
8bitpixel[1*DDSurfaceDesc.lPitch]=0xFE;
Does anybody know what happens to the buffer zone after you unlock the surface? Does the data you have written there stay there, or is it over written by the time you relock the surface, I have never tested that.
OOPS that is:
Y = line numer, 0 being line one;
X = Pixel number, 0 being first pixel on the line + 1;
8bitpixel[Y*lPitch+(X+1)]
Sorry about that!
Y = line numer, 0 being line one;
X = Pixel number, 0 being first pixel on the line + 1;
8bitpixel[Y*lPitch+(X+1)]
Sorry about that!
Bulbasaur: The ddutil functions use the GDI functions for convenience for loading/reloading bitmaps, which is not done during the drawing. The GDI is slow with drawing.
Why do you need to use a memory manager?
- null_pointer
Sabre Multimedia
Why do you need to use a memory manager?
- null_pointer
Sabre Multimedia
Author
I know all that stuff about DDraw surfaces, that''s why I''m not using them for anything besides the primary surface (possibly a secondary surface, haven''t tried that yet, though).I was just hoping of some way to get contiguous blocks of video memory; if the user has all this video memory, why not use it? I did not know there were no services for vram, though, very interesting.
I wrote simple memory management functions because malloc is slow and under several compilers there is a minimum amount of memory you can allocate; if you allocate to little, extra memory sits unusable until you free.There are also a few other benefits to doing it this way.The major downside to this is if your heap is too small you can''t use realloc to make it larger.I also wanted to see if I could do it
Anyhow, since DDraw surfaces don''t return contiguous blocks (the caching gets in the way), I cannot adapt my current memory functions to use it.I suppose its possible, but I don''t want to try.
The gdi thing was a joke Thanks for all the help
----------
meh
I wrote simple memory management functions because malloc is slow and under several compilers there is a minimum amount of memory you can allocate; if you allocate to little, extra memory sits unusable until you free.There are also a few other benefits to doing it this way.The major downside to this is if your heap is too small you can''t use realloc to make it larger.I also wanted to see if I could do it
Anyhow, since DDraw surfaces don''t return contiguous blocks (the caching gets in the way), I cannot adapt my current memory functions to use it.I suppose its possible, but I don''t want to try.
The gdi thing was a joke
Thanks for all the help ----------
meh
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
