OpenEuphoria

2. Re: Graphics mode 19 update rate

• Posted by Pete Eberlein <xseal at HARBORSIDE.COM> Sep 01, 1997
• 570 views
• Last edited Sep 02, 1997

Einar Mogen wrote:
> I am writing platform game routines, and I use Bolin's extended mem_copy.
> I've done a couple of tests, and it says that it can update the screen with
> bakground and tiles at 60 fps. When I copy into screen-memory, I do the
> whole screen at once, and not tile by tile. Well, the problem is that when
> I scroll the screen sideways, it is not good to look at, it is as lower
> parts of the screen gets updated a little after the upper parts. But since
> I get 60 fps per second, this should not occur. Then I thought that maybe
> the screen itself could not get updated at 60 fps even if the screen memory
> could. Is this the case, is the lower parts of the screen getting updated
> after another mem_copy to screen memory have occured? If so, what can I do?
> If it is needed, I can post the code I use. And I guess my explenation of
> the problem is a bit bad, but I hope you understand nevertheless. BTW, I
> use graphics mode 19.

The problem you describe is called screen shear.  It happens when your
monitor is refreshed in the middle of a mem_copy operation.  The lower
part is updated but the above part isn't updated until the next refresh,
resulting in an flasing cut image.  The solution is to wait until right
after a vertical retrace ends before starting a mem_copy.  That way you
will have the whole length of time between refreshes to write to video
memory without having to worry about screen shear.  But you also have to
check for a retrace to start before you check if it is is off.  If you
just check to see if it is off, you don't know for sure when the retrace
will come on again.  But if your code is in pretty good sync with the
monitor, and does all its pre-graphics processing during the retrace, it
will be ready to blast the buffer to memory just in time for the next
one.  I have used both retrace and refresh to explain this, they both
refer to the same thing.
Here's the code to check for when you can write to video memory.
---- code begins ----

constant wait_retrace = allocate(20)
poke(wait_retrace, {
           #50,        -- PUSH EAX
           #52,        -- PUSH EDX
           #BA,#DA,3,0,0,-- MOV EDX, 0x03DA
           #EC,        -- IN AL, DX
           #24,#08,    -- AND AL, 0x08
           #75,#FB,    -- JNZ $-5
           #EC,        -- IN AL, DX
           #24,#08,    -- AND AL, 0x08
           #74,#FB,    -- JZ $-5
           #5A,        -- POP EDX
           #58,        -- POP EAX
           #C3 })      -- RET

-- start of your main loop

  -- do game processing or whatever
  -- build your screen buffer here

  call(wait_retrace)
  -- copy your buffer to screen memory

-- end of your main loop

---- code ends ----

This has been the topic of conversation before and this are the same
codes, but I hope I explained it a little better this time around 

--
                   _____         _____         _____
    ________      /\    \       /\    \       /\    \
   /   \    \    /  \____\     /  \____\     /  \____\
  /  _  \____\  /   / ___/_   /   /____/    /   / ___/_
 /  / \  |____|/   / /\____\ /    \    \   /   / /\____\
 \  \_/ /    / \   \/ / ___/_\     \    \  \   \/ / ___/_
  \    /____/   \    / /\    \\/\   \    \  \    / /\    \
   \   \    \    \   \/  \____\  \   \    \  \   \/  \____\
    \   \    \    \      /    /   \   \____\  \      /    /
     \   \____\    \    /    /     \  /    /   \    /    /
      \  /    /     \  /    /       \/____/     \  /    /
       \/____/       \/____/                     \/____/