Jump to content

  • Log In with Google      Sign In   
  • Create Account

Noctumus

Member Since 29 Apr 2012
Offline Last Active Apr 24 2014 12:26 AM

Topics I've Started

This may sound stupid ... [multitasking]

19 February 2014 - 02:57 PM

In this article on MSDN about mutitasking the author mentions that each thread on a Windows system runs for the duration of a "time slice" and that one of these time slices is around 20 milliseconds. In another article I read the author referes to time slices as "quantums" and wrote that they are usually around 15 milliseconds on a Windows system.
 
Now, what I don't understand is that when I run a program and use a timer (like QPC/QPF or timeGetTime) to continuously spit out time-stamps it seems my program is indeed not suspended every 15-20 milliseconds. In fact, it looks like it isn't suspended at all.
 
Also, when I ran the program there was a total of 618 threads running on my system which means that if each of them was granted a 20 milliseconds time slice each thread would have to wait no less than 12.36 seconds every time it had worked for 20 milliseconds, which obviously isn't the case. I know a lot of these threads are sleeping most of the time, but even when I had Left 4 Dead 2 running which has 45 threads (during gameplay) and uses quite a lot of CPU resources it still didn't seem to affect my program ... ?

Is this a good idea? (D3D9, beginner)

12 December 2013 - 09:19 AM

Hello Forum
 
Suppose you wanted to make a loading module for your game displaying some object rotating on the screen while your game's resources were being loaded. My intuitive approach for this task would be to split it into two threads; one for rendering the animation (the main thread), and one for loading the resources in the background.
 
Unfortunately I learned that D3D9 doesn't allow you to share devices and resources (vertex buffers, textures, ...) between threads, which obviously killed that idea. However it did give me another idea of splitting the data into many small blocks and uploading1* them between each frame, like
 
upload block, render frame, upload block, render frame ...
 
in order to avoid the risk of stalling the rendering process due to the time it would take to upload a large portion of data at once.
 
The problem is that even if this would work it somehow feels like a "hack solution" to me. On the other hand I don't really see any other way of doing it since you have no choice but to keep everything in a single thread when using DirectX.
 
How would you do it?
 
1* By uploading I mean transferring data from local memory into a D3D object, eg. obtaining a pointer to the contents of a vertex buffer using IDirect3DVertexBuffer9::Lock and then copying the local data to that address.

"Rendering System" or "Render System" ... ?

07 December 2013 - 04:51 AM

Intuitively I think "Rendering System" sounds more correct, but both give plenty of hits on Google (OGRE, for example, has a class called RenderSystem) so I was wondering what you guys think is the more grammatically correct term? Or do they actually have different meanings?


Visual artifact, advice would be appreciated (beginner, D3D9)

12 November 2013 - 11:16 AM

Greetings, Forum!
 
I've recently begun studying Direct3D 9 but have unfortunately encountered a little bug in my latest experiment; a simple program that rotates a textured 6 pointed star figure about the 3 axes with a single directional light (source code available here). To describe the bug imagine I was rendering a ball instead of a star moving from the left side of the screen to the right. Then, this is what it looks like when the program runs normally (the top number being the frame in which the ball is rendered):
 
motion_normal.png
 
And this is what appears to be happening when the glitch occurs:
 
motion_glitch.png
 
I tried running the program without clearing the screen in each frame and managed to capture what it looks like when the glitch occurs with vsync enabled at 60 Hz (all three arrows point to visual artifacts caused by the same glitch):
 
glitch_screenshot.png
 
It appears what I thought was happening could actually be the case (especially if you look closely (click image to magnify) at what's going on near the left arrow). The problem is I don't have a clue what the heck is causing it. Taken into consideration I have less than a week's experience with Direct3D there's a good chance it's something very basic I'm missing that one of you can teach me about. At least I hope so, because right now it's driving me nuts blink.png
 
Here are some of the things I have gathered so far from testing and experimenting:
 
The glitch is apparently not caused by
  • A floating point rounding error
  • The performance counter returning a wrong value
The glitch is apparently not affected by whether
  • I use hardware or software vertex processing (D3DCREATE flags)
  • I use performance counters (QPF/QPC) or multimedia timers (timeGetTime) for calculating the delta time
  • I restrict the program to only run on a single CPU core or not
Some other observations:
  • The glitch appears, on average, about once every 10th second on my computer when vsync is enabled and about once every 3rd second when it's not (using D3DPRESENT_INTERVAL_IMMEDIATE in the present parameters to disable it)
  • The impact/magnitude of the glitch doesn't seem to be affected by whether vsync is enabled or not
  • The glitch appears very randomly; not at any specific angle or time and sometimes (much) less frequent than others (every now and then the program can run smoothly without any problems for several minutes)
 
I tried creating the device using D3DDEVTYPE_REF but this causes the framerate to drop so dramatically it's impossible for me to determine if the glitch still occurs. I also examined a couple of my Direct3D accelerated games to see if something similar could occur in one of them, but that didn't seem to be the case.
 
PS: If you want to compile and run the program you can download the texture here

PARTNERS