Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Threaded sound, graphics, randomization

Author
Message
SunDawg
19
Years of Service
User Offline
Joined: 21st Dec 2004
Location: Massachusetts
Posted: 22nd Jul 2008 08:40 Edited at: 22nd Jul 2008 08:40
While the three are pretty limited, I thought the simultaneous threading of it was kind of cool.


Try it, and see what you think.


My site, for various stuff that I make.
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 22nd Jul 2008 12:00
YES very cool.
I have also been getting very excited with multithreading, it has so much potential.
The beauty is that it adds almost no significant overhead when running on a single core CPU, and provides huge benefits when running on a multi core CPU.

I will take the opportunity to add the following to this thread as it is relevant to the topic title.

Phoenix73 code sample:


It would be great if others contribute what they may have to this thread as an easily findable information repository for people interested in multithreading with Dark GDK.

Thanks for sharing your experiments.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 22nd Jul 2008 14:28
i think that multithreading is ESSENTIAL today with multicore pcs, and its very good to see that it is quite simple to implement
FERSIS
18
Years of Service
User Offline
Joined: 17th May 2006
Location:
Posted: 22nd Jul 2008 16:02
The multitredz are de devil !
Just kidding !, but they can be hard to mantain on big projects.
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 22nd Jul 2008 16:59
Quote: "but they can be hard to mantain on big projects."


I can well believe that.
What I find interesting is that there can be big benefits to just dividing the game down into 4 unique threads. This way things can be kept easily under control.

Something like:
Thread1, Graphics
Thread2, Collisions
Thread3, A.I.
Thread4, networking and other support tasks.

OK..., this way one will not get the maximum out of a system, but it will be easy to manage the code and the data types, as well as still benefiting greatly from CPUs all the way up to 4 cores.
With a small amount of ingenious data updating, it can still be very easy to keep data current and valid.
FERSIS
18
Years of Service
User Offline
Joined: 17th May 2006
Location:
Posted: 22nd Jul 2008 18:15
If you guys are interested on the subject, you can take a look at : http://www.insomniacgames.com/tech/techpage.php
Those are the guys who made Resistance and Ratchet and Clack for the PS3. As you imagine ,they 'HAVE' to use threading ,and they share some of they knowledge on that website.
(They even talk about their mistakes)
Cheers man
SunDawg
19
Years of Service
User Offline
Joined: 21st Dec 2004
Location: Massachusetts
Posted: 22nd Jul 2008 19:12
Even course threading, that is to say splitting the major bits like rendering, basic math, physics, AI, etc. will make a noticeable performance boost, without a major drawback on single-core machines. It won't be long before single-core is something that doesn't even need to be considered; I don't know of a new computer with one processor. The point of my little demo was that you can use Beep(), a windows api call that normally freezes the program, while being able to do other things.


My site, for various stuff that I make.
Phoenix73
16
Years of Service
User Offline
Joined: 27th May 2008
Location: Australia
Posted: 23rd Jul 2008 07:20
I am working on making my game as scalable as possible. My code posted here by Sydbod was something I put together to see how DarkGDK would handle things on two CPU's.

I've been refining things since then to work with any number of cores. With upcoming 3, 4 & 8 core CPU's in the mass-production mainstream pipeline I don't want to limit myself to 2 threads.

Also, Intel seem to be indicating that their upcoming multi-core CPUs will also have hyper threading meaning that their 8-CPU chip might be able to run 4 threads per core leading to 32 simultaneous threads!

To get my game 'engine' to scale, I am implementing a simple 'work queue' and I am dynamically allocating a pool of 'worker threads' to process this queue - just picking work up as it's placed there. The worker threads will be allocated based on the machine's core count and hyper-threading capabilities.

I am breaking up all AI tasks as small as possible to see if this works in practice. I.e. each enemy robot sends it's path-finding routine off to the work queue to be calculated each round.

(And yes, I have considered the penalty of working with 'out-of-date' information when I do too many things simultaneously - this is a penalty I am happy to suffer.)

In addition, network calls are processed on another queue entry and the 'dead-reckoning' routines for each networked player will also be individual work queue entries. I won't be injecting network checking work queue commands into every screen refresh though to be kinder to traffic - I will simply use the dead-reckoning results instead.

It will be a few more weeks until I can get the code to run to see if fragmenting things to this level of granularity kills my performance.

Interestingly, I found that an old Microprose game Wiki:Falcon 4 had multi-threading back in 1998!

One thought about single-core CPU's I've been having is that Windows is always running lots of threads and processes anyway - system, drivers, network, trayicons etc etc etc. This WinXP machine with just FireFox open and a few trayicons has 40 processes running totaling over 500 threads (admittedly not all active at once).

Maybe by breaking up my code into smaller threads, there is less work for Windows when it has to pre-emptively swap out my game process to execute some Windows code.

My basic theory is that if I put my game in one monolithic thread, Windows has more work to swap it out and preserve it when it inevitably runs other system tasks.

Does anyone have any thoughts on this idea?
Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 23rd Jul 2008 07:30
It's a wonderful idea. I can't wait to see some code. Working with special performance techniques like this is what interest me most.

Also, I haven't learned a ton about multi-tasking on CPU's, but I'm almost positive you're right about the smaller threads and Windows idea. It should make better use of the pipeline.

Windows Vista Home Premium Intel Pentium Dual-Core 1.6 Ghz 1GB GeForce 8600GT Twin Turbo
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 23rd Jul 2008 08:27 Edited at: 23rd Jul 2008 08:29
I am still a little worried with creating a large number of threads and not providing some sort of data locking.
I could imagine on rare occasions data changes happening that may cause divide by zero occurrences or object motion that can not be handled by the game code.
At some point, the small overheads of a simple thread must become significant when compared to a small thread code fragment.

It is good that some people are going to try this and hopefully we all can learn from the results.

When I get the chance, i would like to look at thread distribution in the time domain for the data. I have not seen this used yet.

What I want to do is update screen information on data one game frame in the past, while doing collision calculations on the current game frame data, while priming the next frame data with current IO information.
Basically having game data duplicated over a time domain and at the start of each game frame do a block data update to get the new relevant data in its correct place.

Could be an interesting twist
This way I am hoping to avoid any data problems.
Phoenix73
16
Years of Service
User Offline
Joined: 27th May 2008
Location: Australia
Posted: 23rd Jul 2008 08:31
Depending on the situation, some queue items will be using 'copies' of the data and using a 'critical section' at the end of calculation to update the global memory.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 6th Aug 2008 23:07
could someone please enlighten a bit, on the most important commands used in the 2 samples provided, and maybe some additional info.

no need for complete tutorials but just some simple info will do.
Phoenix73
16
Years of Service
User Offline
Joined: 27th May 2008
Location: Australia
Posted: 7th Aug 2008 02:13
Quote: "no need for complete tutorials but just some simple info will do."


Here is a simple article that spells out the basics of multi-threaded synchronization under windows:

Thread Synchronization Article

Without an understanding of synchronization it is difficult to understand the structure of a multi-threaded program.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 7th Aug 2008 09:51
Thanks a lot Phoenix73 the article was much needed for beginners like me
Phoenix73
16
Years of Service
User Offline
Joined: 27th May 2008
Location: Australia
Posted: 7th Aug 2008 10:02
You're welcome! Now you know as much as I do - possibly more if you understood the article better than me!
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 7th Aug 2008 15:42
is it possible to have dGDK draw commands like dbText, dbSprite etc in threads?

cos my screen display got completely garbled out!

what about if i use threads to dbLoadImage to cut down on loading times?

or am i only limited to non dgdk commands like math calculations?
Phoenix73
16
Years of Service
User Offline
Joined: 27th May 2008
Location: Australia
Posted: 8th Aug 2008 02:47
I don't think it's possible to put DarkGDK commands into any other thread than the main thread. My approach is to do any calculations (collision, procedural map generation, physics), sound, network etc into the other threads. This leaves pure screen drawing commands into the main thread. So far this approach is giving me a good use of both CPU's.
SunDawg
19
Years of Service
User Offline
Joined: 21st Dec 2004
Location: Massachusetts
Posted: 8th Aug 2008 19:44
You can't do any drawing operations in other threads. However, you can use most other GDK commands, such as dbInk, that do not expressly effect the display.


My site, for various stuff that I make.
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 24th Aug 2008 09:23
UPDATE******

Has any one actually looked at the individual CPU core loads when running a standard (nonthreaded) code based on DGDK.

Have been putting together some tools to enable more efficient code optimisation.

The latest (V1.5.8.1260 Beta) ATI Tray Tools (for those using ATI video cards) has some very nice features in it.
It allows the display of individual CPU core loads , memory usage/ video card memory usage / FPS / various temperatures etc....etc....etc as an overlay on the display screen.

On my dual core machine, whenever I run any program written in DGDK, I see both cores share the load.

It is looking like DGDK is actually running in a multithreaded mode by default.

It would be interesting if some one with a 4 core CPU may test out if all the 4 cores share the load also.

If so, then there looks to be no point with any of us actively configuring our code for multithreading.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 24th Aug 2008 11:20
it could be that Windows is sharing different process loads on different cores.

to test out if dgdk is using multithreading one has to try it on a vanilla windows installation with absolutley nothing running.

i doubt that dgdk is multithreading on its own though.

I am using the Fmod music system, and use multithreading to load different music tracks while my game is running.

i have quadcore but no ATI card. i am looking for a good core monitor. right now i am using Speedfan but it is not ideal for this test.
Phoenix73
16
Years of Service
User Offline
Joined: 27th May 2008
Location: Australia
Posted: 24th Aug 2008 11:57
might the ati card be using the cpu for some of its calculations? What model is the card?
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 24th Aug 2008 13:44
I am using a HD2400XT in the dual core machine.

It does not matter what DGDK program is being run, we see the load on each core oscillate around the same % readings ..... it makes no difference what particular DGDK program is running.
The 2 cores do not show the exact same reading, they jiggle up and down, some times one is a little higher and other times the other one sits a little higher, but they are moving a little all the time.

I doubt it is a simple split where the video card driver is using one core, and the program is using the other core...... the core utilisation always tend to converge into a similar usage % range.

Any one with an ATI video card, please give the new beta version of ATI Tray Tools a try.

http://www.softpedia.com/get/Tweak/Video-Tweak/ATI-Tray-Tools.shtml

It can replace the CCC and has so many exta usefull features that are usefull for game developers.
It lets people overlay information on the screen like

FPS
GPU Speed
GPU Memory Speed
GPU Temperature
FAN Duty
Free Video Memory
Free Texture Memory
Show 3D API Type
System memory used by process
GPU %
CPU Load.

All the above are available with the latest HD48XX series video cards, with progressively less available the older the ATI video card generation happens to be.
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 24th Aug 2008 14:33


The information on the top right side of the image is from ATI Tray Tools beta.

You can see both cores are around almost evenly loaded while in a DGDK game .
The readings for each core is normally around 0% to 2% when not in the game.

It is a clean install of Windows XP SP2 that is only a few days old.

It can only be the game that has added so much load to both cores.
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 24th Aug 2008 17:23
A GDK game will run at 100% on 1 core, 50% each on dual core, 25% each on quad core - that's not multithreading at work, it's simply the OS running the process on whichever processor has the lightest load at the time.

You'll see something different when you use threads - the total percentage will increase above 100% as long as circumstances are right.

bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 24th Aug 2008 17:41
also VC++ has options for multithreading (/MT)

doe sthis make any difference?
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 24th Aug 2008 17:47
What that does is include the C & C++ libraries that are safe for use in a multithreaded environment. It doesn't make your app multithreaded, nor make any other libraries that you use safe or multithreaded (such as the GDK for example).

sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 24th Aug 2008 18:57
Quote: "50% each on dual core.....it's simply the OS running the process on whichever processor has the lightest load at the time."


AHHHHHH...... Ok that makes sense.

Sorry all for the red herring ..... at least now we know there are benefits to be gained by actually multithreading the code.

Login to post a reply

Server time is: 2024-09-30 05:19:35
Your offset time is: 2024-09-30 05:19:35