britlion Wrote:I'm playing with some code for this - I think the font is going to come in handy.
What /would/ be nice, since it's a bit slow, is to be able to have my screen address tables in the compiler as a #include option. I need to be able to #include it, and have it align and #include once basically.
Boriel, if I send you code for this are you okay with adding it to the distribution? I think a standard 4k screen address and similar rotate tables would be fairly common; and I can re-use them for quite a few screen routines. If they are in as standard library routines, such that they are guaranteed to only be inserted once, I don't have to worry about code duplication happening - using any of the sprite/graphics routines would include the tables once and once only.
I'm much more recovered now. I will debug the compiler (to fix the above crash error), and start working on it.
I've missed many threads and feel a bit "out" of some discussions. Sorry for that; it's not I'm not interested, but I was resting instead.
After debugging this error, I would also check those routines you say they worked on previous compiler versions and now they don't. This is essential before adding new features, etc...
It was probably a case of cut n paste from here to the compiler puts spaces in front of # include.
This is two bugs:
1> Code in the forum copies/pastes with spaces in front of it for some reason.
2> (space)# include in the compiler generates an unhelpful error not at all related to the actual problem!
nitrofurano Wrote:btw, i checked my code by testing it in part, and the compiler bug seems to be related with a variable name i used - i replaced 'character$' with 'name$', and that error message dissapeared.
Code:
...
sub print64x32at(x2 as ubyte,y2 as ubyte,characters$ as string)
for i3=0 to len(characters$)-1
e3=code(character$(i3)) ' <<== BUG wrong (undeclared) variable
putchar64x32( (x2+i3) mod 64 ,y2 + int((x2+i3)/64), e3)
next i3
end sub
...
First of all, the above code has a bug: the parameter variable is characters$ whilst the inner variable is character$ (there is a missing -s at the end). They're different variables. The compiler crashed because it was not correctly managing this bug: when you use an undeclared alfanumeric VARIABLE$(Expression) it can mean be one of these 3 things:
VARIABLE$ is an array of Strings, and you want to get the i-th one (<expression>). This is discarded as undeclared arrays are not allowed (precisely to avoid this ambiguity)
VARIABLE$ is a function returning a string, and you want to get the result (<expression> is the parameter). This is also discarded, since ZX Basic requires you to use DECLARE to prototype functions in advance.
VARIABLE$ is a String, and you want the i-th character (string slicing). THIS is the meaning the compiler will get now since the other two are discarded.
03-04-2012, 12:24 PM (This post was last modified: 02-01-2021, 08:37 PM by boriel.
Edit Reason: Fix URL
)
Never enough time. Still. See attachment.
Doesn't do colour at the moment. (Not sure how it easily, can - the colour grid doesn't fit!)
Note that it's a print routine, so is coded to print(Y,X) format. 0<=Y<=31, 0<=X<=63
Also Uploaded as attachment, because I re-used the Screen Tables asm again. Which is enormous. This should only be ever loaded once - so If you use HRPRintFast, as well, for example, make sure screen and rotate tables only get included once.
This version also includes Block Graphics and UDG - there's a reference to @HiResPrintUdg embedded in the code so you can change these as you wish.
Edit: Slight bugfix in that it wasn't advancing print position correctly at end of string. Fixed
Edit2: Separated ScreenTables and RotateTables - Since I wasn't using rotate for this.
LD DE,HiResPrintCharSet-96 ;Offset is because space=32, and it's a 3 byte table - so we go 96 bytes too far forward when mult by 3.
ADD HL,DE
; HL now points to Correct Character. p
LD BC,(HiResPrint_X_Coord) ; Loads Y,X into BC
LD A,B ; B=B*6
ADD A,A ; |
LD B,A ; |
ADD A,A ; |
ADD A,B ; |
LD B,A ; v
; B now has 0-191 value for Y. C has X value in 0-63 format.
CALL HiResPrintScreenAddress
; DE now points at the screen address we need.
LD A,C
AND 1
LD A,%00001111
JP NZ,HiResPrintRightSide
HiResPrintLeftSide:
EXX
LD D,3
HiResPrintLeftSideLoop:
EXX
LD A,(HL)
AND %11110000
EXX
LD E,A
EXX
LD A,(DE)
AND %00001111
EXX
OR E
EXX
LD (DE),A
INC B
CALL HiResPrintScreenAddress
; HL Now has 2nd Line
LD A,(HL)
AND %00001111 ; Grab second four bits.
RLCA ; Push to left side of byte.
RLCA
RLCA
RLCA
EXX
LD C,A
EXX
LD A,(DE)
AND %00001111
EXX
OR C
EXX
LD (DE),A
INC HL
INC B
CALL HiResPrintScreenAddress
EXX
DEC D
JR NZ, HiResPrintLeftSideLoop
EXX
RET
HiResPrintRightSide:
EXX
LD D,3
HiResPrintRightSideLoop:
EXX
LD A,(HL)
AND %11110000
RRCA ;Push to right side.
RRCA
RRCA
RRCA
EXX
LD E,A
EXX
LD A,(DE)
AND %1111000
EXX
OR E
EXX
LD (DE),A
INC B
CALL HiResPrintScreenAddress
; HL Now has 2nd Line
LD A,(HL)
AND %00001111 ; Grab second four bits.
EXX
LD C,A
EXX
LD A,(DE)
AND %11110000
EXX
OR C
EXX
LD (DE),A
INC HL
INC B
CALL HiResPrintScreenAddress
EXX
DEC D
JR NZ, HiResPrintRightSideLoop
EXX
RET
; Screen address.
HiResPrintScreenAddress:
EX DE,HL
LD H,ScreenTables/256
LD L,B
LD A,(HL)
INC H
LD L,(HL)
LD H,A
LD A,C
SRL A ; Divide A(xcoord) by 2.
ADD A,L
LD L,A
EX DE,HL
RET
; Update Coordinates
HiResPrintUpdateCoordinates:
LD A,(HiResPrint_X_Coord)
INC A
CP 65
JR Z,HiResPrintOffLine
LD (HiResPrint_X_Coord),A
RET
HiResPrintOffLine:
XOR A
LD (HiResPrint_X_Coord),A
LD A,(HiResPrint_Y_Coord)
INC A
CP 33
JR Z, HiResPrintOffScreen
LD (HiResPrint_Y_Coord),A
RET
; Could scroll instead? Right now go back to top.
HiResPrintOffScreen:
XOR A
LD (HiResPrint_Y_Coord),A
RET
HiResPrintStringAt(15,5,"Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.")
Britlion, don't worry about the colour (at least for now) - i think my version is "fast" enough for that, and i think wouldn't be a problem when 'applied' over that somehow (the method i used is the attribute value were applied over its area on each 'y=0' and 'y=5' pixel line of each character, i understand perfectly how hard is calculating it on assembly ) - only missed the trickest part you did very successfully, the bitmap part! - thanks again!
