spotlessmind1975 / ugbasic

An isomorphic BASIC language compiler for retrocomputers
Apache License 2.0
94 stars 17 forks source link

SET LINE problem (CPC) #984

Open poppichicken opened 3 weeks ago

poppichicken commented 3 weeks ago

Hi Marco.

I can't seem to make the lines look different. I've experimented with different values in the SET LINE commands, but the lines always look the same.

BITMAP ENABLE (160,200,16)
CLS BLACK

INK YELLOW
SET LINE $F0F0
BOX 50,50 TO 100,100
SET LINE %1100110011001100
BOX 110,110 TO 140,170

image

spotlessmind1975 commented 3 weeks ago

Hi @poppichicken , and thank you for your bug report!

I can't reproduce the anomaly directly with your source, which gives me this output:

image

However, it is possible that a change in the line hatching is not generated because this mode is excluded if you never use SET LINE before any attempt to draw lines and flat geometric figures (squares, rectangles, ...). In this case, the best thing is to place SET LINE as the first instruction, perhaps with the pattern you want as the preferred one, and then possibly modify it during execution. I will add this indication in the manual, and in the example.

Thank you!

spotlessmind1975 commented 3 weeks ago

Hi @poppichicken , the book has been revised, in order to be clearer: image

poppichicken commented 3 weeks ago

Hi Marco.

I've reproduced the error and found a clue for why it is happening. Notice in the code below I have a DRAW command, but it is skipped over.

BITMAP ENABLE (160,200,16)
CLS BLACK

GOTO 10
DRAW 50 ,50 TO 150 ,150

10
INK YELLOW
SET LINE $F0F0
BOX 50,50 TO 100,100
SET LINE %1100110011001100
BOX 110,110 TO 140,170

image

If I comment the DRAW line, the boxes are drawn correctly!

BITMAP ENABLE (160,200,16)
CLS BLACK

GOTO 10
'DRAW 50 ,50 TO 150 ,150

10
INK YELLOW
SET LINE $F0F0
BOX 50,50 TO 100,100
SET LINE %1100110011001100
BOX 110,110 TO 140,170

image

spotlessmind1975 commented 3 weeks ago

Hi @poppichicken , thank you for the feedback! In my opinion this is the expected behavior, in the sense that, as it is written in the explanations, it is necessary to call SET LINE before any drawing command. However, I transform the ticket as an improvement.

poppichicken commented 3 weeks ago

Hi Marco.

My apologies for being difficult. :)

This code:

BITMAP ENABLE (160,200,16)
CLS BLACK

GOTO 10
'DRAW 50 ,50 TO 150 ,150

10
INK YELLOW
SET LINE $F0F0
BOX 50,50 TO 100,100
SET LINE %1100110011001100
BOX 110,110 TO 140,170

Works fine, and draws the lines with the correct hatch pattern. The DRAW line is commented out and ignored.

I'm just concerned that there may be some sort of problem during compilation or execution, when the DRAW line is uncommented. Even though the line is skipped because of the GOTO 10 before it, the DRAW line still somehow affects the way the boxes are drawn. When the draw line is not commented, the boxes are not hatched.

DRAW 50 ,50 TO 150 ,150
spotlessmind1975 commented 3 weeks ago

Hi @poppichicken , and thank you for your feedback!

I'm just concerned that there may be some sort of problem during compilation or execution, when the DRAW line is uncommented.

Your intuition is correct, in the sense that the problem occurs during compilation but not during execution. During that phase, ugBASIC scans the source one line at a time and, as soon as it gets to the request to draw something (DRAW, but also BOX, for example), it implements a routine that does not handle the hatching. This is because it has never been changed before. The fact that you will use SET LINE after is irrilevant, at least at that point.

If you put a GOTO before the DRAW, the compiler will still compile in the same order in which the commands are present, that is not the execution order. In this case, as soon as it generates the code, it will omit the hatching management.

So, when you comment it out, the compiler will generate the code for the DRAW only a few lines later, especially after you have used the SET LINE command. This will generate a routine that handles the hatching.

The improvement I am planning to implement is a sort of "look ahead" (or "look back") to check if the hatching is really necessary. I classified this as an improvement and not a bug because the behavior described is what was expected.

poppichicken commented 3 weeks ago

I understand now. That makes sense.

So I tried putting in a SET LINE before the draw.

BITMAP ENABLE (160,200,16)
CLS BLACK

GOTO 10
SET LINE $FFFF
DRAW 50 ,50 TO 150 ,150

10
INK YELLOW
SET LINE $F0F0
BOX 50,50 TO 100,100
SET LINE %1100110011001100
BOX 110,110 TO 140,170

And it works correctly now.

image

poppichicken commented 6 days ago

hi Marco. this ticket can probably be closed.

spotlessmind1975 commented 6 days ago

Hi @poppichicken , actually not, because it is no longer a bug but an improvement. Which I will implement as soon as possible on the beta, and then publish it on the final version. Thank you!

poppichicken commented 6 days ago

Ah I see, thanks!