🔒 Locked

GetAsyncKeyState problem

Started by Saberman Jan 5, 2004 at 7:25 PM 5 replies 1.2k views

Original Post

Jan 5, 2004 at 7:25 PM

Hallo everybod I''m experiencing a new (for me of course)problem ... I''ve an application that does the following things : 1)creates a window. 2)after window creation starts a new thread and from inside this creates a new window that is used to render. so I ve two message loops acting together one for the rendering window (that''s in foreground and it''s contained in the thread created by app), and the other in the app that created the thread. The question arises when I try to Call GetAsyncKeyState for getting keyboard input for updating camera position. It fails.(while if I call updating routines from inside a WM_CHAR message in the render wnd_proc all works fine). On MSDN I found : Windows NT/2000/XP: The return value is zero for the following cases: The current desktop is not the active desktop The foreground thread belongs to another process and the desktop does not allow the hook or the journal record. So I''m asking if this is the real problem(It''s the first time I write a program that renders from a thread, before I simply used the main window for rendering intead of creating a second one), and if so if anybody could suggest me a way to solve this, or if it''s not the problem what is going wrong? (As i told before updating routines work well, I''m pretty sure it''s GetAsync... that fails) Many Thanks Saberman I checked

flangazor

106

flangazor

Jan 6, 2004 at 4:16 AM

First, I would suggest deleting your account and using a name that doesn''t look like you are impersonating one of the most respected members of these forums (no disrespect to you).

Secondly, do you feel confident that you understand multithreaded programming? If not, then I suggest reading about it. Petzold gives it some treatment, but I found the OReilly book on pthreads was more in depth (though its not for win32).

What you can do is set up a monitor with a bitvec mapped to keys and check the key state on the main window process (i.e. called from the WindProc) and then set bitvec elements appropriately. This setting will be in a critical section, and then the getting of the bitvec elements (in your rendering thread) will wait on the critical section and then read the values you are sending through the monitor.

I hope this helps.

Saberman

Author

Saberman

Jan 6, 2004 at 6:27 AM

Ok, I didn''t know my nick was already in use, so I''m gonna change it.

Surely I''m quite new to multithread so I''m beginning to learn.
Your solution appears good but I''d also like to know if there was any method to use GetAsyncKeyState in such a situation.

Many Thanks

Ex Saberman

flangazor

106

flangazor

Jan 6, 2004 at 2:10 PM

Yes you can use GetAsyncKeyState in this solution. You would call GetAsyncKeyState from the main thread and then use the information you gained from the call in setting the bitvec in the monitor. Then you read the monitor bitvec from the rendering thread.

daerid

Jan 6, 2004 at 4:08 PM

One question though: Why do you feel you need to perform the rendering in a separate thread?

Saberman

Author

Saberman

Jan 7, 2004 at 2:27 PM

I got the function working...It was a trivial error(the background thread doesn''t do anything but remaining alive...)

I wanted to emulate quake3 start-up behaviour( have you noted that small window that is opened as program starts printing out all the initialization operation the program is performing...?)
(Also in mCGee''s alice...)

I''ve ever used system console to display such output but I''d like to have my own customized window so I made a post in this forum asking if someone could give an hint about the way I colud realize such a thing.

I was told it was a simpe window used to display output...

So I succeded in having an identical one.
Now I needed to create the rendering window and I thought that it would be nice and a good occasion to start having a look at threads,
so I decided to implement it this way :

a thread for debug-window and one for the render...

So when I quit the rendering program I still have my window alive and working...

Maybe it''s strange but this is the motive.
Just one question ...The facto og having thwo threads will have a significant negative impact on rendering performance?

Gaxx(ex saberman...ah how can I change my nick?)

flangazor

106

flangazor

Jan 8, 2004 at 3:41 AM

quote:
Just one question ...The facto og having thwo threads will have a significant negative impact on rendering performance?

It depends on a lot of things and to answer it, you''re probably best off reading more about multithreaded applications.

There are many variables that affect the speed of multithreaded applications and in general they can be slower than single threaded apps on single processor machines, however, processors with hyperthreading can be thought of as multiprocessor systems, so they can process two (or more) threads at once. This can make the program quicker, but will ultimately not make the render quicker since it will only be as fast as the quickest thread (unless you are farming off portions of the scene to different threads) -but as I mentioned there are so many variables my answer is probably imprecise.

gl hf

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.