James Dunne wrote:
> lol, sorry for the repeated conversations with myself... (I keep getting brainwaves after I send my last post)
> 
> Here is some C SDL code from one of my projects which gives me a ~60 frames per second.  This is from the update screen procedure.
> 
>     // About 60 fps:    (60fps = 16.667 ms/frame)
>     while (SDL_GetTicks() - curticks <= 16);
>     curticks = SDL_GetTicks();
> 
>     SDL_GL_SwapBuffers();
> 
> Try it out in your project to see if it works.  I recall I had similar problems with the accuracy of SDL's ticks.  Sometimes the program would run so fast that the number of milliseconds between frames would actually be 0 - so that nothing would ever move!  You almost have to put in a pause like this nowadays.

I wouldn't recommend SDL_GetTicks for anything bug a wall-clock... I use RDTSC and it's got damn good accuracy ;)



-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Thanks a bunch for your posts, guess it looks like I'll have to plug in a frame rate limiter and fix my time data types.

James Dunne wrote:
> lol, sorry for the repeated conversations with myself... (I keep getting brainwaves after I send my last post)
> 
> Here is some C SDL code from one of my projects which gives me a ~60 frames per second.  This is from the update screen procedure.
> 
>     // About 60 fps:    (60fps = 16.667 ms/frame)
>     while (SDL_GetTicks() - curticks <= 16);
>     curticks = SDL_GetTicks();
> 
>     SDL_GL_SwapBuffers();
> 
> Try it out in your project to see if it works.  I recall I had similar problems with the accuracy of SDL's ticks.  Sometimes the program would run so fast that the number of milliseconds between frames would actually be 0 - so that nothing would ever move!  You almost have to put in a pause like this nowadays.
> 
> James Dunne wrote:
> 
>> Okay, I've found the problem.
>>
>> You should know that I'm running your executable on Windows XP SP2, not Linux.  I can give it a shot in Linux if you like and let you know my results - I'm betting they'll be drastically different.
>>
>> In your arc.phy.time.d module, you're assuming that SDL_GetTicks() returns a double, when it in fact returns a Uint32 (see derelict/sdl/timer.d).  You must've compiled without -w otherwise you might've had a chance to catch this (perhaps).  Then, for some odd reason, you're adding 0.1 to the current tick counter...
>>
>> The most recent SDL documentation says that "SDL_GetTicks() returns the number of milliseconds since the library's initialization."  I could've sworn that older versions returned a platform-dependent tick count, meaning that the time length of a tick was not consistent and that you had to divide by the TICKS_PER_SECOND constant in order to get a value in actual seconds.
>>
>>
>> James Dunne wrote:
>>
>>> I believe my machine is too FAST to play it, apparently =P.  (AMD Athlon XP 1900+, 512 MB RAM, nVidia GeForce FX 5700)
>>>
>>> 1) The ball flies across the screen at incomprehensible speeds
>>> 2) The paddle movement is unbobly slow
>>> 3) There is no 'pause' time to let the human gather his/her composure before beginning play.
>>>
>>> I'm thinking either
>>>
>>> a) You meant it to be played this insanely fast and it does so on all machines
>>>      or
>>> b) You didn't mean it to be played this insanely fast since it plays just fine (like normal pong) on your and other's machines except mine.
>>>
>>> You might need a frame-rate limiter or at least wait for vsync.  I'll check out your code and see if I can spot what is to blame for my insanely high FPS rate.
>>>
>>> clayasaurus wrote:
>>>
>>>> It might help if you explain why : ) I assume your machine doesn't have 3D support. In the next version 1.0 I plan to have an SDL software renderer which may fix the problem.
>>>>
>>>> James Dunne wrote:
>>>>
>>>>> clayasaurus wrote:
>>>>>
>>>>>> -------------------------------
>>>>>> Requirements:
>>>>>>  - somewhat OK OpenGL support
>>>>>>  - windows/linux (breezy 5.10)
>>>>>> -------------------------------
>>>>>>
>>>>>> -------------------------------
>>>>>> Download:
>>>>>> http://svn.dsource.org/projects/warbots/downloads/mpong_05_bin.zip
>>>>>> -------------------------------
>>>>>>
>>>>>> --------------------------------------------------------------------------- 
>>>>>>
>>>>>> Background Info:
>>>>>>   I like bit size pieces. Originally I've been working on warbots, but since I'm just a hobby dev. and have yet to make a complete game, I thought it would be fun to make a small pong clone and develop an OpenGL 2D game library besides it to make warbots dev easier down the road.
>>>>>>   I started this little project on December 14th. The original goal was a pong clone with a twist that had multiplayer support, however I underestimated the multiplayer portion could not be implemented in a day (tight schedule) and I'm going to be gone for a short while so I might as well show the single player portion I have so far and call it v.5. Expect a version 1.0 + win/lin server in the not too distant future.
>>>>>>   The point of this exercise is to develop an understanding of what features can ease 2D game dev and by the time I get to 1.0 I should have figured out all the tricks necessary for pong at least and update the Arc code + documentation as needed. My goal is an x-platform 2D game library that is useful for multiple styles of 2D games. I plan on making a few more 'minigames' in the future as well.
>>>>>> ---------------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------------- 
>>>>>>
>>>>>> Arc: 2D game library docs
>>>>>> kept here: http://svn.dsource.org/projects/warbots/web/arc/index.html
>>>>>> DDoc has been great at quickly developing docs.
>>>>>> Docs have not yet been updated with GUI or raknet code.
>>>>>> ---------------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------------- 
>>>>>>
>>>>>> Technology involved:
>>>>>> D - Game Code + Arc
>>>>>> SDL, SDL_image, and mixer (for the future).
>>>>>> RakNet for future multiplayer code in the future
>>>>>> Lua scripting language for configuration files
>>>>>>
>>>>>> Liscense: Mostly zlib/png, however rotoZoom + a software circle 'drawing' code are under lgpl, RakNet is GPL, lua is MIT.
>>>>>> ---------------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------------- 
>>>>>>
>>>>>> People who have made this possible...
>>>>>> - Walter, for D
>>>>>> - Aldacron for Derelict, a killer suite of multimedia apps
>>>>>> - John Reimer, very helpful
>>>>>> ---------------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> Drawbacks: I expect the code to be a littly buggy, the 'physics' are horrid and the game code is a mess, along with my attempt so far at
>>>>>> multiplayer programming, and lack of sound. These should be fixed by 1.0. I'm hoping the time based code keeps ball velocity about the same among different speed machines, but I havn't been able to test this feature much, except to say it doesn't work well with a low frame rate. Oh, and if you resize the window on windows, you lose all OpenGL texture information, but not on linux.
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> Fun Tip: Player around with .lua files to change window size and mess around with particle physics and colors
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> Have fun!
>>>>>> ~ Clay
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> OMG!  Impossible to play!  But nice start.