Results 1 to 7 of 7

Thread: SWRender timing problem with new example

  1. #1
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default SWRender timing problem with new example

    A new very simple example has been commited to 2.2 and 2.3 svn.

    It is to demonstate timing for simple 2D games. See - http://clanlib.org/wiki/MainDocs:Timing

    It works perfectly when using OpenGL (clanGL and clanGL1).
    But it does not run smoothly when using clanSWRender.

    I am not sure why

    Examples/Display/Timing :

  2. #2
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Fixed in 2.2 and 2.3 svn:

    1) Add CL_System::get_microseconds()

    This was added, although it was not required. The function returns a cl_uint64.

    2) Fix CL_System::get_time() accuracy.

    (In psuedo code)
    Before it calculated the time as: "int frequency /= 1000; value = time / frequency"
    This has been changed to: "value = (1000.0 * time) / frequency" (working in doubles)

    3) Fix CL_System::sleep()

    Added spinlock to CL_System::sleep() for small values to avoid the win32 scheduler misunderstanding the sleep hint.

    4) Changed SWRender default refresh rate (when enabled) from 60hz to 100hz.

    Looks a bit smoother, because the accuracy of get_time() and sleep() is usually a multiply of 10ms
    (Note - This is only used when flip(1) is used in clanSWRender)

  3. #3
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Quote Originally Posted by rombust View Post
    3) Fix CL_System::sleep()

    Added spinlock to CL_System::sleep() for small values to avoid the win32 scheduler misunderstanding the sleep hint.
    Now that was a silly idea

    A wise person , pointed out that this would cause 100% cpu usage :wheelchair:

    For 3D games or applications where exact timing is not an issue, the old sleep() would be preferable

    For 2D side scrolling games where smooth animation is required, we require a CL_System:: pause() that performs that spinlock code (Still calling ::sleep(0) on each loop).

    I am unsure if CL_System:: pause() should have a millisecond or microsecond accuracy. Personally, I think millisecond, to avoid confusion with get_time(), sleep().

  4. #4

    Default

    1) Add CL_System::get_microseconds()

    This was added, although it was not required. The function returns a cl_uint64.
    Any particular reason for a 64 bit int here? And is there a 32 bit sibling for this function?



    I am unsure if CL_System:: pause() should have a millisecond or microsecond accuracy. Personally, I think millisecond, to avoid confusion with get_time(), sleep().
    Personally I find it more confusing to have a different accuracy between the two. While I like the idea of the higher accuracy, I think it should all have the same accuracy, and I'm not sure that things like sleep benefit from the higher level of accuracy... Hopefully that makes sense?

  5. #5
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Quote Originally Posted by WickedShell View Post
    Any particular reason for a 64 bit int here? And is there a 32 bit sibling for this function?
    Microseconds is 1000000th of a second.
    1 second in hexadecimal is 0xF4240
    60 seconds is 0x3938700
    1 hour is 0xD693A400
    2 hours is 0x1AD274800 <--- exceeding a 32 bit integer

    Although, you can adjust the code to check for 32bit integer overflow, it's tricky to get right.

    The compiler can automatically convert the cl_int64 to an int. (Usually with a warning, if not casted).

    In my opinion, very few people will use this function. Milliseconds (1000'th of a second) should be okay for most people.


    Quote Originally Posted by WickedShell View Post
    Personally I find it more confusing to have a different accuracy between the two. While I like the idea of the higher accuracy, I think it should all have the same accuracy, and I'm not sure that things like sleep benefit from the higher level of accuracy... Hopefully that makes sense?
    Yes, that is what I mean. I will have pause() the same accuracy as the existing get_time() and sleep() ... which all is milliseconds (1000th of a second)

  6. #6

    Default

    /headdesk/

    Nope you're completely right. I didn't sit down and do the math on when the overflow would occur, I knew it would, but thought it was farther out then 2 hours. Carry on sir! Sorry for being an idiot.

  7. #7
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Commited patch to 2.2 and 2.3 SVN

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •