0

I drew boxes in the 320x200*256 mode, it appears they are flickering, is there a way to fix this pixel flickering? what should I do to fix this, is there any good tutorials about this I only found a little documentation around in google like this http://webpages.charter.net/danrollins/techhelp/0113.HTM and this http://stanislavs.org/helppc/int_10.html is there any step by step tutorial.

    [bits 16]
    [org 0x7c00]
start:
    xor ax, ax
    mov ds, ax
    mov es, ax
    mov sp, 0x09000
    mov bp,sp
    mov ebx,13h
    mov eax,4f02h
    int 10h
    mov ax,2h
    mov  ebx,0xa000
    mov ecx,0
    mov es,ebx
    mov ebx,0
    xor edi,edi

j:
    mov ax,4h
    mov cx, 200
    mov dx,200
    mov bx,220
    call drawBox
    mov ax,1h
    mov cx, 100
    mov dx,140
    mov bx,140
    call drawBox
    mov ax,0x16
    mov cx, 150
    mov dx,90
    mov bx,200
    call drawBox
    mov ax,0x25
    mov cx, 20
    mov dx,20
    mov bx,80
    call drawBox
    mov ax,2h
    call fill
    jmp j
fill:
    mov [bp+202],word cx
    mov [bp+204],word bx
    mov [bp+200] ,word dx
    xor cx,cx
    xor dx,dx
    mov bx,200
    call drawBox
    mov cx,[bp+202] 
    mov bx,[bp+204]
    mov dx,[bp+200]

drawBox:
    mov [bp],word cx
    mov [bp+4],word dx
    .keepdrawing:
        call setXY
        inc cx
        cmp cx,bx
        je .reset
    jmp .keepdrawing
    .reset:
        mov cx,[bp]
        inc dx
        cmp dx,bx
        jge .done
    jmp .keepdrawing
    .done:
    mov cx,[bp]
    mov dx,[bp+4]
    ret
setXY: ;requires cx Xposition, dx Yposition
    mov [bp+16], word ax
    mov [bp+20], word dx
    xor ax,ax
    add ax,320
    mul dx;; dx = y posiion
    mov di,cx ; cx = x position
    add di,ax 
    mov ax,[bp+16]
    mov dx,[bp+20] 
    cmp ax,[es:di]
        je .done
        jne .put
    .put:
    mov [es:di],ax
    .done:
    ret
times (510 - ($-$$)) db 0x00
dw 0xAA55
Dodo
  • 228
  • 1
  • 9
  • 1
    Here one of my general chit-chats about the topic: https://stackoverflow.com/questions/37255631/how-to-move-shapes-for-eg-square-in-assembly-x86-language/37273073#37273073 ... actually I believe I have somewhere some demo (in answer on SO) between animation based on DOS timer vs VSYNC-ed ... but can't find it right now... whoa, I did a bit too many answers... Anyway, if you don't understand why the image does flicker, you will have to understand how CRT tubes did display signal from graphic card, and how the timing of reading video ram data is crucial. – Ped7g Mar 26 '18 at 21:23
  • 1
    this one: https://stackoverflow.com/a/42946600/4271923 ... and this one: https://stackoverflow.com/a/44247290/4271923 ... should be enough info for you to understand what is happening and why, and what are your options... still long way to fix your code, because you will have to pick one of the options and design around that. – Ped7g Mar 26 '18 at 21:25
  • still flickers slowing it down with int 15h 86 only slows down the flickering, only when i slow it down to a really slow frame rate where its really annoyingly slow it doesnt flicker – Dodo Mar 27 '18 at 01:38
  • Well, did you understand most of those answers and if not, which part is not clear? Now I did read through your code, and it looks like you draw few boxes on screen overlapping, again and again, in non-synced [toward the CRT display beam] way, so sometimes the beam will draw at display one box over another and then later at the same spot the other one will be on top, so they will naturally flicker. You have to design your code logic to have in video ram data in sync with the beam, if you want flicker-free display. – Ped7g Mar 27 '18 at 07:52
  • If this is like prototyping OS GUI, you may want to use some kind of backbuffer in cooperation with dirty-rectangles optimization to update the screen only partially (unless you plan your OS to modify whole screen often, like modern desktop animations doing genie from bottle minimize, etc - then you may want to check design of various "kompozitor" window managers - mind you, this is quickly getting way over your skills in terms of complexity, judging by the extremely poor quality of your current code, so don't rush, take small steps to stay in control and keep experimenting + learning). – Ped7g Mar 27 '18 at 07:56
  • 1
    is it a good idea to copy to ram with bp the move all at once to the vram – Dodo Mar 27 '18 at 16:48
  • not sure what you mean by *"with bp"*, but to copy memory reasonably fast on any 80386+ CPU, with fixed size aligned buffer like video ram backbuffer tend to be, you may use simple `rep movsd`. The idea of drawing first the final image into backbuffer (ordinary RAM, not being displayed by video card), then copying the finished state into video ram, is very robust and simple to implement. It's also reasonably performant, and you can optimize it heavily **later** by introducing intelligent redraw being aware of parts of windows being overlapped, etc. So it's probably perfect fit for a start. – Ped7g Mar 28 '18 at 09:41

0 Answers0