|
|
 Up |
|
|
  |
Author: Bryan ParkoffBryan Parkoff Date: Sep 3, 2006 10:04
I use DirectX 9.0 to write emulator project. I only want to write 2D
pixel data into memory using 2D array 60 times per second. It is designed to
modify pixel data on the first frame. It repeats the same procedure for
second frame and so forth to be total 60 frames per second. It is how
emulator uses vertical frequency 60 Hz.
Run() function has cycle counting. 14.318180 MHz is perfect for
emulated NTSC into SVGA monitor. 238944 cycles out of 14.318180 MHz cycles
is spent for 1/60 frames. The problem is with DirectX functions which it
runs slower than real time vertical frequency 60 Hz.
I did research and I determine that UpdateSurface function may degrade
performance when crtical speed is very important. I have used two versions
of D3DPRESENT_PARAMETERS which they deal with MultiSample Type / Quality,
SwapEffect, Flags, and PresentationInterval. I tried both versions, but the
speed is still the same.
I am supposed to write 2D pixel data to video memory directly for
critical speed. The DirectX 9.0 documenation states that texture may be
better choice than UpdateScreen. I am not sure which functions are right for
me.
Run() function creates to scroll 16 color rows to the screen. I have
enclosed my sample source code. It is very simpler and short code. Please ...
|
| Show full article (7.75Kb) |
|
| | 14 Comments |
|
|
Author: Jan BrunsJan Bruns Date: Sep 3, 2006 18:04
"Bryan Parkoff":
> I use DirectX 9.0 to write emulator project. I only want to write 2D
> pixel data into memory using 2D array 60 times per second. It is designed to
> modify pixel data on the first frame. It repeats the same procedure for
> second frame and so forth to be total 60 frames per second. It is how
> emulator uses vertical frequency 60 Hz.
> Run() function has cycle counting. 14.318180 MHz is perfect for
> emulated NTSC into SVGA monitor. 238944 cycles out of 14.318180 MHz cycles
> is spent for 1/60 frames. The problem is with DirectX functions which it
> runs slower than real time vertical frequency 60 Hz.
What do you expect this loop
|
| Show full article (2.87Kb) |
|
| | 13 Comments |
|
|
Author: Jan BrunsJan Bruns Date: Sep 3, 2006 18:16
"Jan Bruns":
> There's probably not too much to say against using UpdateSurface
> to copy sysmem-surfaces directly to the backbuffer, but keep in mind
> the gpu won't be a limiting factor for such a simple video-stream.
> Merely expect CPU-side, or CPU->Vidmem transfer problems. You're
> actually dealing with about 100MByte memory access on the CPU-side.
About 100MByte/s. Sorry.
Gruss
Jan Bruns
|
| |
| 2 Comments |
|
|
Author: Bryan ParkoffBryan Parkoff Date: Sep 3, 2006 20:22
>"Bryan Parkoff":
>> I use DirectX 9.0 to write emulator project. I only want to write 2D
>> pixel data into memory using 2D array 60 times per second. It is designed to
>> modify pixel data on the first frame. It repeats the same procedure for
>> second frame and so forth to be total 60 frames per second. It is how
>> emulator uses vertical frequency 60 Hz.
>> Run() function has cycle counting. 14.318180 MHz is perfect for
>> emulated NTSC into SVGA monitor. 238944 cycles out of 14.318180 MHz cycles
>> is spent for 1/60 frames. The problem is with DirectX functions which it
>> runs slower than real time vertical frequency 60 Hz.
>
>What do you expect this loop
Yes, loop has to be endless forever until WM_QUIT can break the loop and
exit WinMain() function.
|
| Show full article (4.70Kb) |
| 1 Comment |
|
|
Author: Stephan RoseStephan Rose Date: Sep 4, 2006 03:10
>
>If you basically want to stream video data to the screen,
>maybe better try this:
>
>g_d3dpp.FullScreen_RefreshRateInHz = 60;
>g_d3dpp.PresentationInterval = D3DPRESENT_INTERVAL_ONE;
>
>This automatically limits the framerate to 60Hz, no matter
>how fast you attempt to render. This also automatically limits
>the frequency you can call g_pd3dDevice->Present(NULL, NULL, NULL, NULL)
>to 60Hz, so you can almost completly forget about these timer-clocks
>(or should be reading some system clock once per frame to ensure
>a constant framerate (by deciding what to draw based on this clock)).
Bad idea Jan.
For one, if I have a CRT set at 80Hz I would scream if anyone screwed
with my refresh rate and lowered it to 60Hz at which point in time I
would have a massive headache in under 60 seconds....
On an LCD you wouldn't even be able to modify the refresh rate so if
it isn't 60 Hz you can't do anything about it.
|
| Show full article (3.21Kb) |
| 9 Comments |
|
|
Author: Bryan ParkoffBryan Parkoff Date: Sep 4, 2006 17:23
>>If you basically want to stream video data to the screen,
>>maybe better try this:
>>
>>g_d3dpp.FullScreen_RefreshRateInHz = 60;
>>g_d3dpp.PresentationInterval = D3DPRESENT_INTERVAL_ONE;
>>
>>This automatically limits the framerate to 60Hz, no matter
>>how fast you attempt to render. This also automatically limits
>>the frequency you can call g_pd3dDevice->Present(NULL, NULL, NULL, NULL)
>>to 60Hz, so you can almost completly forget about these timer-clocks
>>(or should be reading some system clock once per frame to ensure
>>a constant framerate (by deciding what to draw based on this clock)).
>
> Bad idea Jan.
>
> For one, if I have a CRT set at 80Hz I would scream if anyone screwed
> with my refresh rate and lowered it to 60Hz at which point in time I
> would have a massive headache in under 60 seconds....
>
> On an LCD you wouldn't even be able to modify the refresh rate so if ...
|
| Show full article (6.84Kb) |
| 2 Comments |
|
|
Author: Jan BrunsJan Bruns Date: Sep 4, 2006 20:29
"Stephan Rose":
> Jan Bruns:
>>If you basically want to stream video data to the screen,
>>maybe better try this:
>>g_d3dpp.FullScreen_RefreshRateInHz = 60;
>>g_d3dpp.PresentationInterval = D3DPRESENT_INTERVAL_ONE;
>>
>>This automatically limits the framerate to 60Hz, no matter
>>how fast you attempt to render. This also automatically limits
>>the frequency you can call g_pd3dDevice->Present(NULL, NULL, NULL, NULL)
>>to 60Hz, so you can almost completly forget about these timer-clocks
>>(or should be reading some system clock once per frame to ensure
>>a constant framerate (by deciding what to draw based on this clock)).
> Bad idea Jan.
It's a bad idea to tell Bryan what setting the RefreshRateInHz actually
does to the execution of a program?
> Secondly, Interval One only means you will get 60 frames per second IF
> and only IF your rendering speed is greater than 60 frames per second!
|
| Show full article (1.82Kb) |
| 5 Comments |
|
|
Author: Jan BrunsJan Bruns Date: Sep 4, 2006 23:18
"Bryan Parkoff":
> Yes, 14,318,180 cycles have to be spent per second as long Run() function is
> always repeating over and over. It is perfect for emulator.
Emulator?
>>Do you really expect the rest of your function to finish within
>>1/14318180s ~ 70ns? Your're working on about 1/2 MByte memory
>>serveral times there, so better expect this work to consume some ms.
> Well, 1/14318180 always increment the number of cycle until it reaches
> 238944 cycles for 1/60 frames...
Once again: 60 out of the 60*238944=14336640 cycles per second are
diffrent from the others in that your code will take longer. Not only
longer compared to the code for all the other cycles, but also longer
than 1/(14 MHz).
Ok, maybe I don't see what you're trying to emulate.
>>g_d3dpp.FullScreen_RefreshRateInHz = 60;
>>g_d3dpp.PresentationInterval = D3DPRESENT_INTERVAL_ONE;
|
| Show full article (3.54Kb) |
| no comments |
|
|
|
|
|
|
|
|
Author: Stephan RoseStephan Rose Date: Sep 5, 2006 01:43
On Mon, 4 Sep 2006 17:23:02 -0700, Bryan Parkoff
discussions.microsoft.com> wrote:
>>>If you basically want to stream video data to the screen,
>>>maybe better try this:
>>>
>>>g_d3dpp.FullScreen_RefreshRateInHz = 60;
>>>g_d3dpp.PresentationInterval = D3DPRESENT_INTERVAL_ONE;
>...
|
| Show full article (9.18Kb) |
| no comments |
|
|
|
|
