A little help for optimize drawing

[Arnaud]

Hi,
i'm coding a function in assembly to draw a large image (80x160) and it's not fast enough.

The function draw only the center part of image (not the red border)

img_view.png
(0.37 kB, 160x160 - viewed 142 times)

All ideas are welcome.

Thanks,
Arnaud

Here the full cpctelera project and the asm file only.

[roudoudou]

To be faster you will need dedicated code for each image

[Targhan]

Your "BC26" is very slow.

You can duplicate your code 8 times, and at the end of each, either ADD #800 or #c050. You need to point to the right one from the start, depending on the first line of the block you display on.
Slower but versatile (can manage 32k screen), use "difference" table with #800, #800, #800, #800, #800, #800, #800, #c050, #800, #800... with an offset on it depending on the number of the line of the block. How you read it depends on your implementation, I tend to point in the stack on it and do :
pop de
add hl,de

[Arnaud]

You can duplicate your code 8 times, and at the end of each, either ADD #800 or #c050. You need to point to the right one from the start, depending on the first line of the block you display on.

You are right i have improved this part of code (24us)

Code: [Select]

    ld   bc, #-80         ;; [3] Go to start line
    add  hl, bc           ;; [3]

    ld   a, h            ;; [1] Start of next pixel line normally is 0x0800 bytes away.
    add  e               ;; [1]    so we add it to DE (just by adding 0x08 to D)
    ld   h, a            ;; [1]
    and  #0x38           ;; [2] We check if we have crossed memory boundary (every 8 pixel lines)
    jr   nz, startScanLine ;; [2/3]  by checking the 4 bits that identify present memory line.
                                   ;; ....  If 0, we have crossed boundaries

    ld   a, l            ;; [1] DE = DE + 0xC050h
    add  #0x50           ;; [2] -- Relocate DE pointer to the start of the next pixel line:
    ld   l, a            ;; [1] -- DE is moved forward 3 memory banks plus 50 bytes (4000h * 3)
    ld   a, h            ;; [1] -- which effectively is the same as moving it 1 bank backwards and then
    adc  #0xC0           ;; [2] -- 50 bytes forwards (which is what we want to move it to the next pixel line)
    ld   h, a            ;; [1] -- Calculations are made with 8 bit maths as it is faster than other alternatives here
    jr   nz, startScanLine ;; [2/3]  Draw next line
by (17us)

Code: [Select]

startScanLine:
        add  hl, bc               ;; [3]
...

dec  e                    ;; [1]
ld   bc, #0x07B0          ;; [3] Go to start line
jr   nz, startScanLine    ;; [2/3]
ld   e, #08               ;; [2]
ld   bc, #-0x3800         ;; [3] Go to start line
jr   startScanLine        ;; [3]
...

[Targhan]

One other technique is the "gray encoding" by displaying the line in a "gray" binary order, only one bit has to be changed to go from a line to another. This requires your gfx to be encoded in a non-linear manner.

Oh, if you have unrolled your code, you can use set 3,h instead of add hl,bc on every even line.

[Targhan]

Unroll your code, it's not big (use a macro). Remove all your tests. Add either #800 (or set 3,h) or #c050 directly. Don't bother with anything else (unless you are using hardware scrolling and require more complex line calculation.