LINE gets flipped over? 1

[qbasicking]

Why is it in screen 9 if you use a verticle line on the far bottom of the screen it gets flipped over?
I am using line for my font, whenever I print something at the bottom the letters are upside-down.
I have ways around it, but it involved GETting and PUTting, does anybody know how to stop this from happening?

This is what I mean:
LINE (100,339)-(100,349),,,992
This is what I get This is what I should get
0 1
0 1
0 1
0 1
0 1
1 0
1 0
1 0
1 0
1 0

 

[shanley06]

if the numbers get switched as the y value gets higher, can't you switch the y-valuse when you draw the lines? like instead of LINE (100,339)-(100,349),,,992 couldn't you use LINE (100,349)-(100,339)? i don't know if this is what you meant though, so if its not tell me

 

[qbasicking]

That doesn't work, it still gives you the same backwards pattern
Beleive me, i've tried that

 

[shanley06]

ok, i tried out your code and i figured out what was wrong. I converted 992 into hex and it worked fine. so instead of LINE (100,339)-(100,349),,,992 you need to use
LINE (100,339)-(100,349),,,&H3E0 and the code works fine

 

[Oak]

This code works for me too. I've tried this code for testing your posts and didn't get anything going wrong.

SCREEN 9
COLOR , 1 'for defining the screen's bounds
LINE (0, 0)-(600, 0), , , &HFFFF
LINE (0, 15)-(600, 15), , , &HFFFF
LINE (0, 339)-(600, 339), , , &HFFFF

LINE (100, 0)-(100, 15), , , 992
a$ = INPUT$(1)
LINE (110, 0)-(110, 349), , , 992
a$ = INPUT$(1)
LINE (120, 339)-(120, 349), , , 992
a$ = INPUT$(1)

LINE (130, 0)-(130, 15), , , &H3E0
a$ = INPUT$(1)
LINE (140, 0)-(140, 349), , , &H3E0
a$ = INPUT$(1)
LINE (150, 339)-(150, 349), , , &H3E0
a$ = INPUT$(1)

I've got the same result with decimal and hex.

BUT, my prog leads me something interesting: 992 or 3E0 is in fact-> 0000 0011 1110 0000

When you switch 992 to bin it makes 1111100000b. But Qb LINE paterns are always 2 bytes which means that 992(1111100000b) are read 0000 0011 1110 0000b by the LINE statement.

Qbasic assume 2 bytes of data to make its patern.->0000H
When you give it 3E0H, qb will assume the missing 4 bites are zero -> 03E0H

Tell me if it helps.
Oak

 

[qbasicking]

The reason that you get 0000001111100000, is because my line was only 10 pixils long, but qbasic loops lines in groups of 15, so the last few zeros are the 5 that I just don't show

 

[shanley06]

Ok, i've got it now. instead of hex numbers i used oct numbers. i tested it like this

screen 9
'test the top of the screen where the command works fine
'i made the line longer than in your code just to check for
'consistency
LINE (1,1)-(1,30),,,992
'now i do the same length line on the bottom of the screen
LINE (100,339)-(100,309),,,&O1740
'wait for keypress so you can see the bottom line
do:loop until(inkey$=" &quot
end

and the lines looked exactly the same

if i still have a mistake please tell me but from what idid above it looks like it worked

 

[qbasicking]

huh, it does work now. I am using hex numbers, why do you think it doesn't work in decimal?

 

[shanley06]

because when you make your own line pattern it was created with binary numbers 0 and 1. all hex is a way to write binary numbers faster with less space and the computer can use hex numbers right off the bat, but it has to convert decimal numbers.

 

[logiclrd]

Actually, decimal, hexadecimal and octal numbers in the source code all translate to binary representations in memory before the program begins to execute. The reason it "didn't work" was because qbasicking was inadvertantly asking it to do the wrong thing Oak's explanation is correct -- if you look at the pattern you're giving, it has hidden 0's at the start.