Double Buffering

[rain_storm]

syncing to the vertical retrace is not always enough to ensure that your frame will be drawn without slicing. If it takes you longer to draw a scan line than the strict timing allowed for you might want to try double buffering. It is a simple matter to add double buffering to a program without having to define the 64k buffer yourself.

Here is an example that double buffers and is suitable for com files up to 52992 bytes in size. This leaves you plenty of space for what not when making a 256b or even 1k/4k vga demos. The value 07D00h is the maximum starting address that works and is unused and will give you 52992 bytes for you executable. 07000h is the segment where your com file gets loaded into memory and you will be using some of this segment for the buffer.

Of course you should only use this if you have room to spare and your demo is experiencing slicing even with syncing enabled. The better thing to do is improve the speed of the drawing routine if possible. not always possible though (example drawing vertical lines / polygons)

Code: [Select]

ORG 100h

 PALLET = 003C8h ; PALLET INDEX REGISTER
 VTRACE = 003DAh ; VERTICAL RETRACE STATUS PORT ADDRESS
 KEYBRD = 00060h ; KEYBOARD INPUT PORT ADDRESS
 VIDMEM = 0A000h ; VIDEO SEGMENT ADDRESS
 BUFFER = 07D00h ; DOUBLE BUFFER ADDRESS (MUST BE ABOVE 07010h FOR 256b / 07100h for 1k)
 VIDSIZ = 0FA00h ; SIZE OF SCREEN IN BYTES

 INIT:MOV   AX,13h
      INT   10h
      PUSH  VIDMEM
      POP   ES
      PUSH  BUFFER
      POP   DS

 COLR:MOV   DX,PALLET
      XOR   AX,AX
      OUT   DX,AL
      INC   DX

 GREY:OUT   DX,AL
      OUT   DX,AL
      OUT   DX,AL
      INC   AX
      JNZ   GREY

 MAIN:XOR   DI,DI
      XOR   SI,SI
      MOV   CX,VIDSIZ/4
      MOV   DX,VTRACE

 SYNC:IN    AL,DX
      TEST  AL,08h
      JZ    SYNC
      REP   MOVSD

      XOR   SI,SI
      MOV   CX,VIDSIZ/2
 DRAW:MOV   AX,[DS:SI]
      INC   AL
      INC   AH
      MOV   [DS:SI],AX
      ADD   SI,2
      LOOP  DRAW

 EXIT:IN    AL,KEYBRD
      DEC   AL
      JNZ   MAIN
      RET

EDIT:
I just wanted to add that double buffering in this manner has more than doubled the fps on any example ive thrown it into

[hellfire]

double buffering has more than doubled the fps

sure, video-memory is slow and you are now writing aligned dwords instead of single bytes...
still it consumes some extra-bytes which usually aren't extant on a 256-byte budget.

[Jim]

Whacking the whole screen over like that (or in a few variations of that) is a pretty good way to avoid tearing.  It's not quite what I would call double buffering - that (to me) involves 2 screens in video RAM.  You draw to one and display the other, and can flip between the two outputs with a special command.  But many, many games in the early 90s did it your way

Jim

[rain_storm]

double buffering has more than doubled the fps

sure, video-memory is slow and you are now writing aligned dwords instead of single bytes...
still it consumes some extra-bytes which usually aren't extant on a 256-byte budget.

Yeah I heard that all along but it was only recently that I saw the speed bonus. high level languages take care of all these details so I just took it for granted not anymore

@Jim so is this just buffering or single buffering