Hi everyone, I have been having some trouble with DirectX and I wanted to share these with others, see if you had the same trouble, whether you had solved these problems and to find out about more DirectX Mysteries..... (PS. If you download anything you have here and solve the problems, then please, reply to the board, with an explanation of the problem, or a location at which a fixed copy can be found. Thank you) Mystery 1. When working on a source code base, my friend realised that sometimes the source code would stop compiling, for no known reason. It''s a simple starfield using DirectDraw, running at 800x600x8bpp. Now. When the code ran, it would run fine. But when it would cease to compile, it would cease for a period of time. Then, later, would start compiling again. This has been shown, by my friend having no problem compiling the code, going to sleep, waking up, opening the project again and compiling, it would compile, but the code would refuse to run. The source code can be downloaded from http://mx9.xoom.com/KoshHome/inv.zip Mystery 2. When using a simple starfield code(the same code that is being used for the starfield ), running in DirectDraw at 800x60016bpp, this code would return a lPitch from the backbuffer (800x600x16bpp) of 800 (when divided by 2 to get the number of pixels). When this simple starfield code was inserted into a larger project (it was developed to be a part of the final codebase) the code would then return a lPitch from the backbuffer (still the same, 800x600x16bpp) of 4096 (when divided by 2 to get the number of pixels). Why could this be ? They surely shouldnt differ ? http://mx9.xoom.com/KoshHome/Invaders.zip Okay, everyone, take a peek, perhaps something about the init of DirectX being wrong, or creation of surfaces is incorrect, I dont know, perhaps you do. Thats all for now, there are more mysteries, but we need to pin them down before I go making a foo! of myself. So bye for now, and remember, keep watching the SKIES!!! kosh has left the building

lpitch MAY differ. That''s the reason, why it is there. If it would be always the SizeOfSurface*NumberOfBytesPerPixel, then why would a driver return it ?
I do personaly believe, that lpitch may change only after surface allocation ... after surface init you will very likely get the same lpitch in each lock surface call... but I didn''t found anything proving this in help files, so be carefull...

to the first mystery .. windows sucks ... when your apps crash or so, and something starts to act weird, simply restart windows... or at least rerun MSVC ...
In your case maybe you are doing something bad in deinit part, you leave something locked, or you have some memory leaks, or maybe everythinh is ok, just windows is playing tricks with you, or some other application ...


---------------------------------------------------
Ped - Peter Helcmanovsky - 7 Gods demo group
http://7gods.rulez.sk
First Sight Entertainment - http://members.xoom.com/fseteam
---------------------------------------------------

The compiling mystery has happened to me as well. Do you use MSVC++ v6.0? I believe it has something to do with the amount of memory in your machine. My computers both have 32MB of RAM so that may be the problem. Maybe I can dug within my couch and save enough pocket change to get more.

I just do not understand why all surfaces are not linear but oh well.
Just get your lPitch by accessing it from your DDSURFACEDESC structure.

Good luck

quote: Original post by GoofProg

I just do not understand why all surfaces are not linear but oh well.

Because it is often faster/easier for the video card to deal with ''reasonably-sized'' blocks, generally a power of 2 across. Things such as alignment issues, and being able to use shifts rather than multiply/divides, come to mind.