I love the jaggies!

[mnrvovrfc]

I created a sub that has too many parameters but could fake the block graphic characters drawn by ancient computers such as the TRS-80 Model III. I have found a bug while composing this on Linux.

Code: (Select All)

option _explicit
dim as integer i, x, y, re, be, ge, scw, sch, saiz

scw = 1152
sch = 672
screen _newimage(scw, sch, 32)
saiz = 48
re = 96
ge = re
be = re
'for i = 128 to 191
'    block i - 128, saiz, 2, 3, x, y, _rgb(255, 255, 255)
'    x = x + saiz
'    if x >= 800 then
'        x = 0
'        y = y + saiz
'    end if
'next
'goto pend
saiz = 12
for i = 0 to 4095
    block i, saiz, 3, 4, x, y, _rgb(re, ge, be)
    x = x + saiz
    if x >= scw then
        x = 0
        y = y + saiz
        if y >= sch then exit for
        ge = ge + 32
        if ge > 255 then ge = 96: be = be + 12
    end if
next
pend:
sleep
system

''num = fake character code (bits will be checked)
''siz = point size of the whole "rectangle"
''wd = number of pixels across
''ht = number of pixels vertically
''xx, yy = coordinates of top-left corner (desired to avoid this and "co")
''co = 32-bit color value
''eg. TRS-80 monochrome graphics, wd = 2 and ht = 3, graphics 128 x 48
''for Tandy Coco as well "num" must start at zero but graphics chars started at CHR$(128)
sub block (num as _unsigned integer, siz as integer, wd as integer, ht as integer, xx as single, yy as single, co as long)
    static as integer x, y, k
    static as _byte p
    static as long m
    static as single w, h
    w = siz / wd
    h = siz / ht
    p = 0
    for y = 0 to ht - 1
        for x = 0 to wd - 1
            m = 2 ^ p
            if num and m then
                line(xx + x * w, yy + y * h)-step(w, h), co, bf
            end if
            p = p + 1
        next
    next
end sub

The colors are a vain attempt to see the influence of the pixel rows more clearly. This should have range checking. This wasn't tested under "VIEW" and "WINDOW" setting.

Composed this on Fedora 36 MATE. (Yeah got stuck yesterday waiting for 37 to discover they postponed it for another week!)
This is the bug:

On a laptop or other screen with 768 pixels vertically, try changing "sch" to a value higher than 672, compile and run. The top part of the picture is scrolled off as if "PRINT" were used without semicolon near the bottom of the screen. This is seen more obviously if the commented parts were the demonstration, which draws much-larger pixel blocks. This drove me crazy for about half an hour and while I was getting the 3x4-pixel thing straightened out.

My laptop has only 768 pixels vertically. With "task bar" enabled the area is reduced to 720 or less, however that "task bar" has no influence on the user program's window. Maybe somebody with a larger viewport hardware could handle a larger size, but this bug should happen when the vertical dimension is quite near the maximum.