Back to the original topic...

Can you send me some source code to look at? If you want, just create the smallest piece of code you can to create this "bug".

------------------

-Kentamanos

Awww geez. Couldn't you save that "bug" connotation until you see if you can disprove me or not?

Source is sent, and follow the instructions above to cause bug (it may take a few trys, but its pretty reliable)

Rock

Didn't mean to upset you with that "bug" thing. Trust me, it's nothing personal...hehehe. I'm just trying to play QA guy. I guess it's a knee-jerk reaction to how those guys treat me at work.

Something screwed up the attachment. I'll email you directly to give you a better address to send it to (just in case hotmail has a bug...hehehe).

Thanks,

------------------

-Kentamanos

If you are accessing surfaces that were created in video memory, the WIN16 lock MUST be used. Doing otherwise is asking for trouble (in DX5, I don't know about the newer versions), so DX5 will do it automatically. I don't have the references here, but if you call Lock on a vidmem surface using DDLOCK_NOSYSLOCK, the call should either fail, or that flag will be ignored and WIN16 lock will be used anyway. The WIN16 lock prevents task switching, so you shouldn't have been able to ALT-TAB during the Lock.
The fact that thing did get messed up can mean (at least) two things:
1) DX did not use the WIN16 lock during vidmem surface access, while it should have done so. -> DX bug.
2) You used a surface pointer for drawing after calling Unlock on that surface, i.e. when the surface wasn't locked anymore, and WIN16 lock wasn't active anymore. -> your bug.

Anyway, if you're accessing vidmem, forget about DDLOCK_NOSYSLOCK. It won't work.
If accessing something that was explicitly created in sysmem, you can use DDOCK_NOSYSLOCK.
If the surface wasn't explicitly created in sysmem, but DX decided to put it there, behavior is unsure (DDLOCK_NOSYSLOCK may be used, but perhaps it won't).
If it's created in nonlocal vidmem (AGP), I don't know. Anyone else who can tell us?

This is kind of more of a warning than a question, but I'd like to see if anyone has seen this or if they can test for it with success.

I'm using DX5, and I was locking my surfaces using the DDLOCK_NOSYSLOCK flag. But it doesn't return the correct surface ptr in certain situations.

To test (I saw it pretty reliably), open a fullscreen DOS box, and run your game's .exe. When the game is running, ALT-TAB out, back into the starting DOS box. Then type exit to close it, mouse click the desktop and empty portions of the task bar a few times, then click on your game to maximize it again. More often than not, if using NOSYSLOCK (and page flipping), one of the flipping surfaces will return an illegal surface pointer. This may be an odd point to the video card somewhere (so your drawing shows up in strange places), or it may be an illegal ptr and KABOOM!

Can anyone test this under a later version of DX (development wise, not runtime)? I thought they were trying to integrate the locking so it didn't use the WIN16 locks, but I'm not sure if they found this bug. It doesn't show up using DX's blitting or fill routines, just if your accessing the surface directly. I spent 4 days pulling my hair out trying to track this down, and it happened on all my computers. WATCH OUT!

Rock

Well, I didn't ALT-TAB while the lock was in place. The general algorithm was a normal lock/draw/unlock/back to main main loop where msgs are checked. So the surface was never locked while the app was minimized or anything.

The problem is as you laid it out in #1, where, upon restoring the surface, and then trying to lock/draw in the normal loop, the lock would return an incorrect ptr. So yes, my assumption is that DX is NOT using the Win16 lock, even though it IS a video mem surface I'm locking (the active surface in particlular). And the lock did return an OK status also. So I concluded, I believe rightly so, that it is a DX bug. I never read anything saying that DDLOCK_NOSYSLOCK couldn't be used on video surfs, but I think clearly that you are correct.

Also, for anyone following this, I finally downloaded the DX7 runtime, and they appear to have fixed it in the runtime. But DX5 and 6 have this problem.

Rock