Frame syncing problem

Game development specific discussions.
xlucas
Posts: 260
Joined: May 09, 2014 21:19
Location: Argentina

Frame syncing problem

Postby xlucas » Jun 25, 2017 1:24

I'm having difficulties to get my test code to display smooth movement. Here's what I wrote:

Code: Select all

#define pi 3.14159

Dim As Double x, y, vx, vy, d, t
Dim As Integer mx, my, mb, emx, emy

ScreenRes 1024, 720, 32, 2

x = 512 : y = 380 : d = 0

ScreenSet 1, 0
SetMouse x, y, 0
emx = x : emy = y

t = Timer
Do
   If Timer >= t + .03 Then
      Dim As Byte framex, framey
      
      GetMouse mx, my, , mb
      
      Line (0, 16)-(1023, 719), 0, BF
      
      If mx <> 512 Or my <> 380 Then
         mx = mx - 512
         my = 380 - my
         
         vx += mx / 10
         vy += my / 10
         
         d = ATn(-vy / vx)
         If mx < 0 Then   '2nd or 3rd quadrant
            d += pi
         ElseIf mx > 0 And my < 0 Then   '4th quadrant
            d += 2 * pi
         End If
         
         d -= pi / 2
         If d < 0 Then d += 2 * pi
         
         Locate 1, 1
         Print mx; "  "; my; "  "
         Print Int(d * 180 / pi); "  "; 12 * d / pi; "   ";
      End If
      
      x += vx
      y -= vy
      If x < 0 Then x = 0
      If y < 0 Then y = 0
      If x > 1023 Then x = 1023
      If y > 719 Then y = 719
      
      framex = 12 * d / pi
      framey = framex \ 8
      framex = framex Mod 8
      Circle (x, y), 20, RGB(50, 250, 200), , , , F
                  
      ScreenCopy 1, 0
      SetMouse 512, 380
      
      t = Timer
   End If
Loop Until Len(InKey)

End


Please ignore the direction calculation with the arctangent. My original code uses it to pick the right frame (and it's still not doing it correctly), but here I've replaced that with a filled circle so that I don't have to include the graphics.
Move the circle with the mouse and use ESC to exit. The movement is not perfect, but that's not the problem. See how, when you gather some speed, the movement is no longer smooth. On my computer, I can see two circles at the same time and I can clearly see the jump between a frame and the next even though the frequency is relatively high. If I change to a higher frequency, the problem persists, although it becomes harder to control the circle.

In DOS, I used to sync my drawing with the vertical retrace, but in Linux and Windows, as far as I know, that can't be done. The OS takes care of that part. When I capture the screen, the resulting picture always shows one circle only, which means I'm seeing the screen sweeping, not the actual contents of the window. This makes sense, since I'm working on a parallel screen and also, FB does its own double-buffering, if I'm not mistaken. Because I'm only drawing one rectangle (albeit big) and one circle, I would be surprised if this were taking more time to draw than the duration of a cycle. If I remove the ScreenCopy and ScreenSet statements, the movement becomes "heavier", but the display problem is still noticeable.

What is going on here? What can I do?
dodicat
Posts: 4881
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Frame syncing problem

Postby dodicat » Jun 25, 2017 1:53

With the 64 bit compiler you get jumpy graphics.
Sometimes a sleep 1,1 fixes this.
ScreenCopy 1, 0
SetMouse 512, 380
sleep 1,1
t = Timer

With the 32 bit -gen gcc also jumpy graphics -- sometimes.
A sleep there is also helpful.
32 bit -gen gas is the best graphics option (IMO).
But you should use a sleep 1,1 in the loop anyway.
With sleep 1,1 the framerate is about 32 (similar to no sleep)
xlucas
Posts: 260
Joined: May 09, 2014 21:19
Location: Argentina

Re: Frame syncing problem

Postby xlucas » Jun 25, 2017 3:52

Uhm.... I tried that and still get the same thing. First, I added the Sleep and compiled as usual. Got the same result, so I opened the console (the GNU/Linux I use most of the time is the 32bit one) and compiled specifically with -gen gas. The result was the same. Then I thought I'd compare the executable file sizes and found they were the same, so I tried compiling with -gen gcc. Compilation took a little longer and the file was larger, meaning my fbc was already defaulting to GAS. The GCC executable still gave the same result.

I've tried changing the colour depth to 16 and to 8. Same problem. It's strange, because an old game I made does not seem to do this. (http://www.dimioca.com/syderal). That old game does something that's not optimal at all: it redraws everything 200 times per second. I thought I'd use a more reasonable frequency now so I didn't eat up the microprocessor, but looks like that works better than this :S
leopardpm
Posts: 1597
Joined: Feb 28, 2009 20:58

Re: Frame syncing problem

Postby leopardpm » Jun 25, 2017 4:05

hmmm... not understanding the issue - I see no 'jumpiness'

I also added this right before the loop statement so that the 'free time' was given to the OS, not eaten up by needless loops...:

Code: Select all

sleep (timer - t + .03)

".03" for 33 frames per second...

BTW: framex & framey are not used at all in this loop... but you probably knew that...
Last edited by leopardpm on Jun 25, 2017 17:56, edited 1 time in total.
sancho2
Posts: 547
Joined: May 17, 2015 6:41

Re: Frame syncing problem

Postby sancho2 » Jun 25, 2017 7:01

I can confirm leopardpm and say this runs smooth as silk on windows 10.
leopardpm
Posts: 1597
Joined: Feb 28, 2009 20:58

Re: Frame syncing problem

Postby leopardpm » Jun 25, 2017 17:57

sancho2 wrote:I can confirm leopardpm and say this runs smooth as silk on windows 10.

good to know... my system is slow,clunky and has some issues so I was thinking that perhaps I couldn't see the 'jumpiness' due to some problem on my end... also win10
xlucas
Posts: 260
Joined: May 09, 2014 21:19
Location: Argentina

Re: Frame syncing problem

Postby xlucas » Jun 25, 2017 19:04

Well, then, either my 5 year old computer is not fast enough to do it smoothly, or the double buffering via X is not perfect (I'm compiling in GNU/Linux). Anyway, what I see is not "exactly" jumping. I can see the different frames not because of the time it takes between them, but because I am somehow seeing two frames superimposed somehow. It looks like the system hadn't been able to erase the old frame before drawing the new one, but... if I take a snapshot, only one is seen. Makes me think it could also be my monitor :S

Anyway, thanks for testing, guys. I feel better knowing that it works well over there. If anybody could test it in GNU/Linux and confirm it works well too, I'd appreciate it.

And yes, the framex and framey are variables I use because in my version of the code, I Put a sprite instead of the circle (which makes the effect more noticeable) and the frame depends on the angle.
dafhi
Posts: 1006
Joined: Jun 04, 2005 9:51

Re: Frame syncing problem

Postby dafhi » Jun 25, 2017 22:13

might be your distro. i've never seen that with either screenset or screenlock
Tourist Trap
Posts: 2326
Joined: Jun 02, 2015 16:24

Re: Frame syncing problem

Postby Tourist Trap » Aug 13, 2017 20:06

xlucas wrote:I'm having difficulties to get my test code to display smooth movement. Here's what I wrote:

Smooth here (xp win32).
xlucas
Posts: 260
Joined: May 09, 2014 21:19
Location: Argentina

Re: Frame syncing problem

Postby xlucas » Sep 01, 2017 0:38

Alright, then. I guess it's my system, ha, ha. Thanks for testing, guys

Return to “Game Dev”

Who is online

Users browsing this forum: No registered users and 2 guests