Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
0 user currently in Programming. | 3 guests
Acmlm's Board - I2 Archive - Programming - Thinking of getting serious with C. | |
Pages: 1 2 3Add to favorites | "RSS" Feed | Next newer thread | Next older thread
User Post
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 2982/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 01-20-05 12:06 AM Link | Quote
Ah, didn't know the brackets made a difference. It's working now, thanks!
Parasyte

Bullet Bill
Level: 35

Posts: 211/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 01-20-05 12:14 AM Link | Quote
Parantheses are so incredibly useful. I would suggest using them as often as you can. (Though it's kind of silly to go overboard with it.)

Good:
if ((foo == bar) && ((tmp = iCoolDude(man))))

Bad:
if (foo == bar && tmp = iCoolDude(man))
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 2983/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 01-20-05 04:53 AM Link | Quote
Yes, I always use them in cases like that. I just didn't know that (*var) meant something different than *var on its own. (Though seeing how it's essentially the same as in assembly, I'm not that surprised. )

Haha, here's some nice statistics for ya:
Actual Game Boy CPU: 4,194,304 instructions per second.
Emulator core written in VB: 75,000 instructions per second.
In C, updating window on each instruction: 900,000 instructions per second.
In C, updating window once per second: 11,000,000 instructions per second.

Of course once per second is far too slow to update the window, but hey, this is C. I can make another thread do it. (Now we see one of the major reasons VB's so slow.)
neotransotaku

Baby Mario
戻れたら、
誰も気が付く
Level: 87

Posts: 1947/4016
EXP: 6220548
For next: 172226

Since: 03-15-04
From: Outside of Time/Space

Since last post: 11 hours
Last activity: 1 hour
Posted on 01-20-05 05:27 AM Link | Quote
Originally posted by HyperHacker
Yes, I always use them in cases like that. I just didn't know that (*var) meant something different than *var on its own. (Though seeing how it's essentially the same as in assembly, I'm not that surprised. )


Well *var++ and (*var)++ are two different things because of the order of precedence in C. So, when you are unsure what is going to happen first, just use parenthesis to ensure what you want to happen is going to happen.
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 2984/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 01-20-05 06:47 AM Link | Quote
[edit] Pooh, I can't have one thread create the window and a different one handle the messages? That's a rather stupid restriction. I'll just have to have the update thread create it then.


(edited by HyperHacker on 01-19-05 09:51 PM)
(edited by HyperHacker on 01-19-05 10:26 PM)
Dish

Spiny
Level: 38

Posts: 237/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 01-20-05 07:31 AM Link | Quote
I'm not sure if creating a window in one thread and running the message pump in another thread is a good idea. I don't even see why you'd need a seperate thread at all (you could just check for messages periodically in your main thread... like say every frame or something).

But that aside... if hVideoWindow is a valid window handle... PeekMessage WILL return true (unless that thread thing is a problem). Are you sure it's not returning true? I'm not exactly sure how printf() fits in here... since this isn't a console program (where are you expecting it to print to?)

As for other potential problems... sometimes when vars are only used within a small area of code (like your StopWindowUpdateThread var in this example), the processor will keep the value in a register and not write it back to RAM. Basically... this will cause problems when you rely on your second thread to react to a change made to the var from your first thread. To avoid this... declare vars that MUST be "thread safe" as volatile:

volatile int StopWindowUpdateThread;

When you write to it in 1 thread... the second thread will be sure to pick up the changes on the next read. However this removes the occasional optimization which will make slower code... so only use volatile where needed (and try to keep the number of inter-thread variables to a minimum)

But like I said... multithreading is not recommended unless necessary.


- edit -

bah... way to make my post useless XD


(edited by Disch on 01-19-05 10:31 PM)
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 2985/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 01-20-05 08:11 AM Link | Quote
Originally posted by Disch
I don't even see why you'd need a seperate thread at all (you could just check for messages periodically in your main thread... like say every frame or something).

Too slow. If I checked every frame it slowed down the emulation drastically, and if I checked every second or so the window became very unresponsive.


if hVideoWindow is a valid window handle... PeekMessage WILL return true (unless that thread thing is a problem).

This would appear to be the case, but according to MSDN, it has to be called by the thread that created the window. Hence why I had to move the window creation to the other thread as well.


Are you sure it's not returning true? I'm not exactly sure how printf() fits in here... since this isn't a console program (where are you expecting it to print to?)

It does have a console window for debug output. If it returned true, a message would be printed to the console window.


declare vars that MUST be "thread safe" as volatile

I was using this, but removed it when trying to fix something. I probably should put it back though.


bah... way to make my post useless XD

Dish

Spiny
Level: 38

Posts: 238/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 01-20-05 08:38 AM Link | Quote
Originally posted by HyperHacker
Too slow. If I checked every frame it slowed down the emulation drastically, and if I checked every second or so the window became very unresponsive.


Not really. The time you spend processing windows messages is next to nothing. Besides... the CPU divies up processing time as needed for every running thread. You're still telling it to do the same amount of work.... making it divie up its attention to 2 seperate threads doesn't somehow make the processor run faster... if anything it makes it slower (more threads = more CPU split time).

The basic idea is:

Process all pending messages... Do a frame... and sleep if time allows (if you don't spend time sleeping, your program will gobble 100% of the CPU's time). For a demonstration:


----

while( runprogram )
{

while( PeekMessage( wnd, &msg, 0,0, PM_REMOVE ) )
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}

if( emulationpaused )
{
Sleep(10); // if emulation isn't running for some reason, don't hog CPU time... sleep
continue; // and go back to pump
}

DoAnEmulationFrame();

// check time here, if it's too early to do another emulation frame, Sleep for a while

}

----

that runs suprisingly fast... hardly any CPU time will be spent on the PeekMessage loop. And if your time checking code is good... it can be smooth. The Demo NES Emu I made a while back does something like this. You can check the winmain cpp file in the source of said emu (or whatever the file is named) for a demonstration. That emu is very quick on my machine (typically no more than 0-1% CPU time)

Running multiple threads won't speed anything up... they may actually slow things down a bit. Not to mention they severly complicate things and cause lots of weird quirks (like your prior window problem).
Pages: 1 2 3Add to favorites | "RSS" Feed | Next newer thread | Next older thread
Acmlm's Board - I2 Archive - Programming - Thinking of getting serious with C. | |


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.007 seconds.