int grun()
{
if(KEYDOWN(VK_ESCAPE))
{
PostMessage(handle,WM_QUIT,0,0);
}
memset((void *)sec_buffer,0,640*480);
for(int i = 1 ; i < 50 ; i++ )
{
x = rand()%640;
y = rand()%480;
color = rand()%256;
sec_buffer[x + y*640] = color;
}
memset(&ddsd,0,sizeof(ddsd));
ddsd.dwSize = sizeof(ddsd);
if(FAILED(lpdds->Lock(NULL,&ddsd,DDLOCK_WAIT|DDLOCK_SURFACEMEMORYPTR,NULL)))
return(0);
prim_buffer = (UCHAR *)ddsd.lpSurface;
mempitch = (int)ddsd.lPitch;
if(mempitch == 640)
{
memcpy((void *)prim_buffer,(void *)sec_buffer,640*480);
}
else
{
for(i = 0 ; i < 480 ; i++ )
{
memcpy((void *)prim_buffer,(void *)sec_buffer,640);
sec_buffer+= 640;
prim_buffer+=mempitch;
}
}
if(FAILED(lpdds->Unlock(NULL)))
return(0);
Sleep(500);
return(1);
}
Some error with a double buffering program
Author
OK heres the deal...
Im reading this book called "Tricks of windows game programming..." by andre lamothe (The same book which is oftenly criticised here,well i bought this book way before i joined gamedev :| )
Anyways theres this program which implements double buffering (without Flip() and using memcpy)
The thing is its not giving any compiler or linker errors,but when i run it a black screen appears and the following message:
"This program has encountered an error and needs to close bla bla"
Heres the code from the function:
im using dx7 and vc++ 6
Are you trying to learn C or C++ programming?
The reason I ask is that those are functions of the C standard library. If you're using C++ it will work but it's far from safe and far from the current industry standards.
If you truly want to learn Windows programming, using memory tricks like that will more than likely cause you more headaches than it's worth. Get a book on DirectX programming or GDI programming (if it's specifically for graphics).
I can only assume that the code you're running is attempting to draw graphics to the screen. There are much better and far safer methods than by using direct memory calls. More over, direct memory calls like that are very much taboo on Windows platforms and are grounds for calling a program 'misbehaved'.
I would recommend, if you're looking into 3D programming, that you get a book on DirectX or, if you're interested in cross-platform development, a book on OpenGL. Perhaps even a book on both. Also make sure that the book or books are current (e.g., newer than at the very earliest 2000). Technology and operating systems have changed considerably since the days of Windows '95 which is when that code may have been acceptable.
The reason I ask is that those are functions of the C standard library. If you're using C++ it will work but it's far from safe and far from the current industry standards.
If you truly want to learn Windows programming, using memory tricks like that will more than likely cause you more headaches than it's worth. Get a book on DirectX programming or GDI programming (if it's specifically for graphics).
I can only assume that the code you're running is attempting to draw graphics to the screen. There are much better and far safer methods than by using direct memory calls. More over, direct memory calls like that are very much taboo on Windows platforms and are grounds for calling a program 'misbehaved'.
I would recommend, if you're looking into 3D programming, that you get a book on DirectX or, if you're interested in cross-platform development, a book on OpenGL. Perhaps even a book on both. Also make sure that the book or books are current (e.g., newer than at the very earliest 2000). Technology and operating systems have changed considerably since the days of Windows '95 which is when that code may have been acceptable.
Author
Quote:Original post by leeor_net
Are you trying to learn C or C++ programming?
UM....yes and no
C++(or turbo c++ to be more specific) was part of my school curriculum and i studied it for 2 years,but it was all text based with no emphasis on graphics
I am learning windows programming and directx from the book "tricks of the windows game programming gurus" by andre lamothe and the preceding code was taken from there,this is more like a test program rather than an implementation...
thanks for the reply though...i didnt know programs could misbehave :)
Yep. They very much can. Windows, by nature, doesn't allow direct access to the hardware. By not using a function like Flip() (I'm not terribly familiar with DirectX, I tend to use cross-platform solutions instead like SDL, OpenGL and OpenAL) and instead using a direct memory access, who knows what could happen. You probably don't know the exact pixel format and working with memory like that is very dangerous (in terms of program stability). In the past, doing such a thing on Windows '95 may have worked but virtually garanteed a system lockup should there be bugs. Not to mention, trying to do direct memory accesses is very error-prone.
I would say the book is trying to illustrate a point but it's been my experience that using 'clever tricks' is vulnerable to bugginess and is a maintenance nightmare.
As for misbehaving programs, this is basically a program running under an OS that doesn't do what the OS expects. For instance, requesting a Device Context but never freeing it virtually garantees a crash. Like I said earlier, on Win'95 this would bring the OS to its knees but XP/Vista/Win7 handle this much more gracefully.
Another way of misbehaving is not responding to Window Messages (e.g., filling the windproc() function with code that responds to WM_ events). This is when you get a 'Program not responding' problem. Modern version of windows handle this very well but those of us who've been around awhile may remember the smearing that happened when a program stopped responding on Windows '95 often followed with a BSOD of some sort.
Yet anothe way is not sharing resources. If your program goes out of focus, you need to release device contexts. Not doing so can cause all sorts of problems and Windows will often shut down a program that refuses to share its resources.
The list goes on and on but my suggestion is to be very careful with any 'tricks of the trade' because they can be much more trouble than they're worth if you're not 100% sure exactly what the code does.
I would say the book is trying to illustrate a point but it's been my experience that using 'clever tricks' is vulnerable to bugginess and is a maintenance nightmare.
As for misbehaving programs, this is basically a program running under an OS that doesn't do what the OS expects. For instance, requesting a Device Context but never freeing it virtually garantees a crash. Like I said earlier, on Win'95 this would bring the OS to its knees but XP/Vista/Win7 handle this much more gracefully.
Another way of misbehaving is not responding to Window Messages (e.g., filling the windproc() function with code that responds to WM_ events). This is when you get a 'Program not responding' problem. Modern version of windows handle this very well but those of us who've been around awhile may remember the smearing that happened when a program stopped responding on Windows '95 often followed with a BSOD of some sort.
Yet anothe way is not sharing resources. If your program goes out of focus, you need to release device contexts. Not doing so can cause all sorts of problems and Windows will often shut down a program that refuses to share its resources.
The list goes on and on but my suggestion is to be very careful with any 'tricks of the trade' because they can be much more trouble than they're worth if you're not 100% sure exactly what the code does.
Author
Hurrah!
Found the answer...
"C++ does not protect you from your own stupidity"
is what someone wrote here at gamedev and that was it....
it Turns out i wasnt allocating memory for a pointer i was using (the sec_buffer)
How massively stupid!!
Anyways thanks to you,leeor net for sparing time for a newbie like me...Really helpful post about menacing programs :)
Found the answer...
"C++ does not protect you from your own stupidity"
is what someone wrote here at gamedev and that was it....
it Turns out i wasnt allocating memory for a pointer i was using (the sec_buffer)
How massively stupid!!
Anyways thanks to you,leeor net for sparing time for a newbie like me...Really helpful post about menacing programs :)
Quote:Original post by leeor_net
Windows, by nature, doesn't allow direct access to the hardware. By not using a function like Flip() (I'm not terribly familiar with DirectX, I tend to use cross-platform solutions instead like SDL, OpenGL and OpenAL) and instead using a direct memory access, who knows what could happen.
True, but just to clarify, when you Lock() a DirectDraw surface, its memory is copied (or behaves as if copied) into system memory so it can be accessed like normal. When you Unlock() it, it is (probably) copied back into video memory. You are quite right about the pitfalls, but LaMothe is not actually accessing video memory directly in the code above.
Manpreet - I can't comment directly on the book as I haven't read it, but I would point out that DirectDraw is horribly out of date and had a nasty interface anyway. It was deprecated by Microsoft when DX8 came out and you'd be far better to skip DirectDraw, find some resources about doing 2D games with Direct3D and starting from there.
[opinion]
I have heard of the book and wonder why the author considers implementing your own page flipping with memcpy() a trick of a guru but that is far less of an issue than its age.
Learning about page flipping by writing a program to simulate it is a bit like crossing a swimming pool in a barrel to learn about Columbus' discovery of America. If you want to know more about page flipping, just read about it then let your graphics API and the hardware do it for you. [smile]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
