[DirectDraw] Problems while IDirectDrawSurface-Lock on xscale pxa255

Started by
2 comments, last by frob 15 years, 5 months ago
I tried to use DirectDraw under WinCE4.2 like below: step1. DirectDrawCreate succeed. step2. CreateSurface(primary surface) succeed. step3. IDirectDrawSurface->Lock succeed, return the vram address. step4. I tried to memset the vram, just want to make a black screen. step5. IDirectDrawSurface->Unlock step6. call MessageBox() to notice me that the function had execute Those code above execute succeed on ARAM(Sumung2440A), but when it executed on XScale PXA255, it failed on step4. After call memset, nothing happeded, and also MessageBox didn't being called. The vram address return by IDirectDrawSurface->Lock() is 0x01A0XXXX, it seems like that this address is not a valid address. If I call CreateSurface with parameter "OFFSCREENPLAIN" in step2, then the vram address return in step3 will be 0x4XXXXXXX, and it seems like a valid address. Anyone can tell me why?
Advertisement
I didn't think it was supported on WinCE4.2. I thought it was a 5.01 and above system. I'll assume that you have the right version for the rest of the post.


What was the result of the Lock() call? If the result was anything other than DD_OK then you can't trust the returned pointer.

Are you properly considering the pitch length between pixels and between rows? You must not touch the memory between pixels.

Are you using exactly the pixel format Lock() returns to you? Even a slight difference will cause problems to many devices.

Is your data properly aligned? This is a very common problem on these devices.



All of those bugs could result in the behavior your describe. It might appear to work on one system and fail on another.
Quote:Original post by brinker
I tried to use DirectDraw under WinCE4.2 like below:

step4. I tried to memset the vram, just want to make a black screen.


just a note: a directdraw surface is composed of lines with the data of the content of the surface, which can be followed by some data, needed by the surface.

so if you did a memset on the whole data that the Lock returns, then you might have screwed something. You must do a memset line by line
Quote:Original post by Vincent Torri
You must do a memset line by line

Not necessarily by line.

If the lPitch is specified, you must have the space between the lines. If the lXPitch is specified, there is additional space between the pixels.

Using memset will fail on most devices because they include non-zero pitch distances. You must not touch the memory between pixels.

This topic is closed to new replies.

Advertisement