Probs with Windowed mode

Started by
7 comments, last by Rah 23 years, 12 months ago
Hi, After much frustration, I finally implemented a switchable direct draw windowed mode. However, it appears to be seriously ''laggy''.... by laggy I mean the mouse cursor jumps a few inches per update on the screen etc. Generally unresponsive. After much playing around with stuff, I still couldn''t get it to work resposively. However, I just tried it on a different PC and it works fine... Now... my dev machine is a dual monitor system, running Win2k. Could this possibly be the culprit for this? Are there any known problems with ddraw and dual monitor/win2k systems? (note: I''m not using d-input). The machine it worked perfectly on was a basic single monitor/win98 setup. Any pointers appreciated... -- Russ
Advertisement
I don''t know if this is your problem, but it could be due to a intentionally broken d3d driver.

What happens is that driver writers will batch together frames in order to artificially inflate benchmark numbers (they should only batch 1.5 frames at max, according to specs) I have heard of several other poeple having similiar probelms.

You could try something like...

while( DDERR_WASSTILLDRAWING==FrontBuffer->GetBltStatus(DDGBS_ISBLTDONE);

..each frame to see if this fixes the problem (which would at least tell you if this is the problem)
When you say your app becomes "laggy", is that only in Windowed mode? Do you have a fps counter? Does the fps drop when you go to windowed mode.

I had a problem that caused my app to drop from 60+ fps in fullscreen to 12 fps windowed. I found that the reason for this was that the primary surface was in video memory while the back surface was in system memory.

I placed both of them in system memory and now I get (with dirty rect drawing) 140+ fps fullscreen and 140+ fps windowed (60+ both without dirty rect drawing). On machines that can handle it, placing both surfaces in video memory also provides an enormous performance boost.


Josh
http://www.jh-software.com
Joshhttp://www.jh-software.com
same as josh.

also, it could be your video card, ATI cards are notorious for doing this jumpy/laggy mouse when running direct draw apps.

Also, are you sure you only create the clipper in the initiallization and delete it after it''s been done once?
___________________________Freeware development:ruinedsoft.com
Hi,


By laggy, I mean in general responsiveness from the mouse etc. I''ve just whacked an fps counter in and I''m getting a little over 1/fps... Odd. In fullscreen it''s fine however.
I currently have my primary surface in vidmem, with my secondary in sysmem; I know this is slow, but I''m performing a lot of manual surface manipulation (well, will be) so I need the speed of reading from sysmem.

Josh, how can you make the primary surface in system memory? Surely, if this were even possible, the primary surface would still need to be upped to the vid card for displaying on the monitor? Or do you mean you placed them both in vid memory?

Thanks for the replies guys,

--
Russ
quote:
Josh, how can you make the primary surface in system memory? Surely, if this were even possible, the primary surface would still need to be upped to the vid card for displaying on the monitor? Or do you mean you placed them both in vid memory?


When you go to create your primary surface, OR the DDSCAPS_SYSTEMMEMORY flag with the ddsd.ddsCaps.dwCaps.

You could place them both in video memory, but that''s a lot of video memory and some slightly older video cards may not be able to handle it. Perhaps you could check for available video memory.

This method works well with every card I''ve tried it on and it gives you a good frame rate. Hope this helps!



Josh
http://www.jh-software.com
Joshhttp://www.jh-software.com
Hmm... Can you explain how you can have a primary surface in system ram? I mean, the whole point of the primary surface is that it''s the one constantly shown on the monitor... Am I wrong on this?

And if it was created in system memory, surely it (the data) would still have to travel up into video memory for it to be displayed, since this is where the physical monitor is attatched..?

Can you explain how this works exactly? I did try ORing the system memory flag, and it appeared to work but I''m guessing it just ignored it and created in vidmem anyway?

Sorry to keep bothering you

--
Russ
It''s no bother

You tried the system memory thing and it worked? Well, don''t look a gift horse in the mouth by asking why!

Just kidding. In windowed mode, because it''s unable to do a flip, the primary surface doesn''t have to be in video memory. Don''t ask me why it works in fullscreen mode though. It''s one of those mysteries of the universe that will never be solved...


Josh
http://www.jh-software.com
Joshhttp://www.jh-software.com
In windowed mode, the primary surface is the whole desktop.

Well, in either mode, the primary is the entire desktop. It''s what is displayed, so Rah is right. Adding the SYSMEM flag just wouldn''t have worked.

Try creating your back buffer in vidmem for the hell of it and post the frames.

How many frames a second do you get in full screen mode?
and at which resolution?

It seems to me that there still is something that''s being unnecissarily called during windowed (and maybe full screen) mode that''s causing it to be that slow.

How big is your window?

If you get 10fps in full but 1~2 in windowed that sounds about right. But if it''s like 60 to 1fps.. then there must be something weird going on.
___________________________Freeware development:ruinedsoft.com

This topic is closed to new replies.

Advertisement