need some folks to test this out

[ninogenio]

hey all im messing around with a gdi blitter framework sort of thing and i need some of you guys to test it out firstly to see if it works ok on your systems and secondly to see i it runs at ok speeds there is no delta timing yet so there is a wee bit of shredding.

ive included my source up to this point also and would like to know if my cpp gdi coding is ok up to this point or if im totally missing the point in some areas.

[taj]

It runs ok but not brilliantly here. The zoom at the start pauses part way through amd when its full screen, the boxes drifting from side to side appear to be not smooth. Nowthis said, I dont know how GDI should run so maybe this is really good for GDI.

Chris

[ninogenio]

hmm odd it should run pretty fast i get decent speed myself with tearing coming from the fact it draws between vblanks.

i think im blitting all the gfx as quickly as possible maybe not though..

[Shockwave]

It seems to run fast enough here (Dual core 1.8 ghz), it suffers from jerkieness because of no sync though.

[benny!]

@ninogenio:
Runs ok here. Like Shockwave says it lacks of some smooth movement - maybe because of no
sync.

General question - do you use plain GDI for that ? If so - why not use the new GDIPlus library -
it supports stuff like :

- Alpha blending
- Gradient brushes
-Transformations and rotations
- Scalable regions
- Support for several image formats

Have a look at the following url for more information :

http://www.codeproject.com/vcpp/gdiplus/startinggdiplus.asp

[Positron]

You are using the WM_TIMER event to start redrawing, right? But this event only appears if windows has nothing else to do. It's not guaranteed that you get your wished interval. So the time between the animation steps are different and I think this is the reason why the animation isn't smooth.

[Jim]

That's part of the problem, though calling timeBeginPeriod(1) at the start of the program improves matters a bit.
With WM_TIMER you can't do much in the way of delta timing either - it's basically like an interrupt that goes off at a fixed period, but nowhere near as accurate as a vblank interrupt on a console - could be off by 10s of milliseconds.
It's relatively easy to switch it over to a draw-as-fast-as-possible approach where you can add delta timing - it just means changing the GetMessage loop into a PeekMessage one and killing off the WM_TIMER/WM_PAINT messages, but you will get more tearing that way, I suspect.
Having said all that, it looks pretty good for a GDI app - expectations are low...

Jim

[ninogenio]

i decided to let it run at full speed and it improves the animation quite a bit heres what ive done to get rid of the wm_timer.

Code: [Select]

do
        {
                InvalidateRect(scene_window, NULL, FALSE);                 
                while (PeekMessage(&msg, scene_window, 0, 0, PM_NOREMOVE))
                {
                        if (GetMessage(&msg, scene_window, 0,0) < 0)
                                break;
                        TranslateMessage(&msg);
                        DispatchMessage(&msg);
                }
                GenioMain( OffScreenDC , scene_window ) ;

        } while (!quit);

it runs fine for a few seconds on my comp then the text goes funny and stops spinning and all my hdc boxes go small.

[Jim]

Totally delete the cases for WM_PAINT and WM_TIMER.  Just get them out of there   And the InvalidateRect call.
Then just call

Code: [Select]

GenioMain(...)
HDC destdc = GetDC(hwnd)
BitBlt(destdc, ...)
ReleaseDC(hwnd,destdc);
in your main loop.
Then, just for now, add

Code: [Select]

Sleep(15);
after ReleaseDC.

Jim

[ninogenio]

cool the sleep fixed the hdc messup problem!

i take it without the sleep the program goes too fast for windows to keep updating.

will it be ok to take the sleep out when i add delta timing?

[Jim]

It was removing the InvalidateRect and WM_PAINT that fixed it.  That would mess it up totally

You'll want to keep it running slower than 100Hz at least, so you'll need Sleep(10) 10=1000/100, unless your drawing is taking forever.  The trick here is to keep a track of how long you took to draw the last frame and use that to work out how much to move the next frame.  But don't even bother trying to go over 100fps.  You'll get even more tearing than normal and suck up 100% CPU.

Jim

[ninogenio]

cheers jim ive stuck a delta timer in and i think its working ok does it run smooth on you guys systems now also.

here is the timer code dont know much about c++ timers so i dont know if this is right.

Code: [Select]

LARGE_INTEGER Frequency;
        QueryPerformanceFrequency(&Frequency);
       
        do
        {
                LARGE_INTEGER liStart;
                LARGE_INTEGER liStop;

                QueryPerformanceCounter(&liStart);
                     
                while (PeekMessage(&msg, scene_window, 0, 0, PM_NOREMOVE))
                {
                        if (GetMessage(&msg, scene_window, 0,0) < 0)
                                break;
                        TranslateMessage(&msg);
                        DispatchMessage(&msg);
                }
               
                HDC destdc = GetDC( scene_window );
                GenioMain( OffScreenDC , scene_window );
                BitBlt( destdc , 0 , 0 , SCREEN_X , SCREEN_Y , OffScreenDC , 0 , 0 , SRCCOPY );
                ReleaseDC( scene_window , destdc );
                Sleep(0);     
                QueryPerformanceCounter(&liStop);

                LONGLONG llTimeDiff = liStop.QuadPart - liStart.QuadPart;

                dftDuration = (double) llTimeDiff * 1000.0 / (double) Frequency.QuadPart;

        } while (!quit);


[Positron]

The delta timer is right. Is running smooth for GDI.

[Jim]

That's a lot better.  I still think you ought to put in a longer Sleep() but 0 is the absolute minimum requirement to be multitasking friendly.  Basically, while you're sleeping other apps get a chance to do some real work.  If you don't sleep, everything else runs very, very slowly.

Some of the blobs seems to get stuck on the side of the screen.

Jim

[ninogenio]

i would have liked to put a longer sleep in there jim but anything other than 0 on my system runs slow even just a sleep 1 runs at about half the speed.

i read that sleep can be diffrent from system to system so its maybe some of my hardware thats makes sleep weird on my comp.

oh and btw the blobs will get stuck i just threw this together to see if i could animate smooth but now ill actually do something with it.

- edit on your system does the top text go big after a few seconds cause on mine im having a weird bug in my text class that two seperate constructed variables based on my text class take on each others characteristics in width and height and lfescapment after a few seconds but not of color and as much as ive tried i cant figure out why?

[Jim]

edit on your system does the top text go big after a few seconds

Yes, I think it did.  Have you read the documentation for SelectObject()?
http://msdn2.microsoft.com/en-us/library/ms533272.aspx
Might be relevant.   Might also be a proper bug 

Jim

[ninogenio]

yeah ive read that, the only thing im not doing is saving and replacing to old font so that might be where its coming from.

the only thing i dont quite get is why its only lfescapment/orentation and width/height that goes weird not x/y and color.

[ninogenio]

been messing around again trust me   

i can get even smother almost console refresh with a sleep(13) and my refresh set to 75 using dmScreenSettings.dmDisplayFrequency but how reliable will 75 be at 800x600 as opposed to 60 on other peoples comps id like to be able to use it with confidence as it runs really nicely.

[Jim]

People with LCDs often don't have refresh rates over 60Hz in any mode.
Perhaps your font isn't changing but the dest rectangle/location is being corrupted somehow?

Jim

[ninogenio]

it could be the dest location that is getting corrupted but my other classes for blitting sprites to the same hdc works fine.

would using the QueryPerformanceFrequency/Counter to create a wait/loop to set the fps to 6ohz be any good at emulating a vblank for folks with an lcd monitor.

im finding delta timing not very good for large objects.