Fast Multimedia Timer for Games and Demos

[avcaballero]

I believe that the stutter in the floor demo is due to the stretching mixing one colors with others. If you increases the size of the window it runs smoothly. Please, if you have time, check it out and tell me.

Most of flickers dissapear using a double buffer, but bearing in mind that what you do between to frames has to be finished before the next starts. Another flickers appear because in two consecutive frames don't join.

If you try this version of floor demo with rigid frames, doesn't appear the flickering

[Siekmanski]

The colors are stable now, but there are still stutters.

[LordAdef]

I am doing my game in GDI with plans to port it to something else in the future.
But with all the Dx talk I'm getting munchies to do it sooner.

I'm basically just blitting to back buffer and them to the window. I guess it wouldn't be too hard to implement it, would it?

First I thought of Opengl, but what the hack, I would not be able to port the masm anyway, so that wouldn't make sense.

[LordAdef]

Hi Marinus,

What's the unit for your timers and how can I output it to console?

Further, would it be possible to return the milliseconds taken by the loop and the FPS? Usually I'd like to know the milliseconds, and put it to sleep the remaining milliseconds in order to keep the FPS/milliseconds constant.

By the way, do you deal with Sleep granularity with TimeBeginTime?

[Siekmanski]

The unit is in seconds.

A way to print floats in a console application:
( Possibly there are routines for this in the masm lib? )

Code Select Expand

includelib  \masm32\lib\msvcrt.lib

sprintf proto C :vararg ; from msvcrt.lib

TEXT_ MACRO your_text:VARARG
    LOCAL text_string
    .data
     text_string db your_text,0
    .code
    EXITM <addr text_string>
ENDM

.data?
szString_buffer db 512 dup (?)

fp8value real8 ?

.code

align 4
StdOut proc lpszText:DWORD

    LOCAL hOutPut  :DWORD
    LOCAL bWritten :DWORD
    LOCAL sl       :DWORD

    invoke GetStdHandle,STD_OUTPUT_HANDLE
    mov hOutPut, eax

    invoke  lstrlen,lpszText
    mov sl, eax

    invoke WriteFile,hOutPut,lpszText,sl,ADDR bWritten,NULL

    mov eax, bWritten
    ret

StdOut endp

PrintTimer proc
fld Timers.Timer1 ; Real4 format -> convert to real8 format
fstp fp8value ; save as Real8 format for use with sprintf function

invoke sprintf,addr szString_buffer,TEXT_("Timer: %0.06f",13,10),fp8value
invoke StdOut,addr szString_buffer
PrintTimer endp


TimeBeginTime is just wrapper code, better deal directly with,
QueryPerformanceFrequency and QueryPerformanceCounter
NtQueryTimerResolution
NtSetTimerResolution
NtDelayExecution ( 500 microseconds delay )

No, I use Sleep with the standard granularity for normal occasions
But for threaded interrupt timers ( 100 nanosecond units ) I use the 500 microseconds Sleep version to do fast synchronizations.
Which I will use in the vertical blank routine I'm writing  ( hope to show it next week or a week later )

[LordAdef]

Hi Marinus!
So, I modified your first timing routine into a multi-timer for code profiling. It's still your original code,I simply made a structure from all globals so I could save individual timings in various part of the code. I intend to plot them later.
Would you review and polish it for me?

[Siekmanski]

 :t

[LordAdef]

:t

I sent you my modded code for you through MP, so we can save forum space.

[felipe]

:t

I sent you my modded code for you through MP, so we can save forum space.

Sounds like a "don't want to share" thing... :(  Shouldn't be PM? (is MP some kind of code obfuscation tactic?).


Please don't take it too personal...I was just kidding...  :icon_mrgreen:

[Siekmanski]

We are on a secret mission. 

[daydreamer]

We are on a secret mission. 

...to rule the world

[LordAdef]

We are on a secret mission. 

Yep, Brazil and Holland joining to take over!

[LordAdef]

:t

I sent you my modded code for you through MP, so we can save forum space.

Sounds like a "don't want to share" thing... :(  Shouldn't be PM? (is MP some kind of code obfuscation tactic?).


Please don't take it too personal...I was just kidding...  :icon_mrgreen:

Hi Felipe, MP is Portuguese for PM, I mixed up.The code will be shared of course! And hopefully very useful

[felipe]

Thanks LordAdef.  :t

[daydreamer]

Yes, you can make smooth graphics with GDI. Almost the 90% of what my production is with GDI.

DirectX seems to use a buffer rectangle determinated, let's say 600x400 and if you want to see it in full screen what it does is stretch this buffer to the whole screen. That is what I have done here with the GDI templates. Some time ago made this full screen fire demo, no tricky involved here, the program calculates your screen dimension and makes a buffer with this size (full screen), in my computer runs smootly. This is a very big buffer where to write to.

I wonder how faster is DirectX than GDI in fact. When I have time I will make this proof.

There's no doubt that DirectX has some advantages over GDI. It is a big library of functions prepared to be used in graphics programming such 2d and 3d that you have already installed in your pc, so the programs you made with DirectX are smaller that those made with GDI for these themes. In GDI you have to make your own graphics functions, what I find more attractive.

Regards

PS: Don't know if it is possible to make a no suttering at all graphic demo with GDI, maybe it depends on the workload of the processor at all times. I can not tell if DirectX is able to monopolize all that capacity.

question is,should it be possible to move GDI drawing to a workerthread for a software renderer,so on a modern multicore it ends up running on second core,not competing with GUI programming,so that ends up with the more cpu intensive graphics,the GUI gets extremely laggy???
also timer controlled code that controls so you get a steady fps only,is good,instead of unecesary ridicoulus fps is good