Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: Geekboy1011 on March 09, 2014, 10:46:22 pm
-
So over the last couple weeks I have been working on a small side project that will be being used in an upcoming project of Iambian's and mine. This project is a Text Subsystem that would be used in an RPG.
Features
* Arbitrary Bounding Box
* 5xW Font (Borrowed with permission from DCS)
* Customizable Corners
* Word Wrapping
* Character Wrapping
* Post processing Effect (see next list)
* Supporting Routines
Post Processors
* Italics
* Mirror
* Flip
* Inverse
* Underline
It comes with a host of supporting routines to make interfacing with it easier for the end coder
Routines
* NewLine
* HomeUp
* SetFulScreen
* SetBoundsStack
The program is interfaced with 2 Main routines these are DrawBox And PutStr. PutStr Puts the null terminated string pointed to by hd inside the bounded box that has been defined. DrawBox Draws the visual Box around the Text and takes the corner style in A.
The PutStr Routine supports inline modifiers for the text output that is supplemented via a macro.
Mod(Italics,Underline,Flip,Mirror,Inverse,WordWrap) OR any combination of the settings. Which makes adding effects to strings rather easy.
Ok enough Jargon Lets put some examples and screenies :D
.db "Welcome to Cemetech",CrlF,Mod(Italics,Underline),"LTTFW",0
(https://dl.dropboxusercontent.com/u/98196116/TextSys/cemetechltwttf.gif)
.db "This Is right up",CrLf,Mod(Mirror,Flip),"This is not!",0
(https://dl.dropboxusercontent.com/u/98196116/TextSys/mirror.gif)
.db Mod(Inverse),"White",Mod(Clear),"Black",Mod(Inverse),"White",Mod(Clear),"Black",0.db Mod(Inverse),"White",Mod(Clear)," Black",Mod(Inverse),"White",Mod(Clear)," Black",0
(https://dl.dropboxusercontent.com/u/98196116/TextSys/WhiteBlack.gif)
Its' Word Wrapping is rather robust.
(https://dl.dropboxusercontent.com/u/98196116/screenies/animooted.gif)
And it supports style changes by changing a byte in ram :D
(https://dl.dropboxusercontent.com/u/98196116/screenies/animooted4.gif)
Why is there no release? Because this is just a showing of it so far I have to polish some of the code and make some changes to make it so when compiled with a DCS program you don't have to include the entire DCS font map and other things. (saves a few hundred bytes worth of data!)
So thoughts and suggestions/Things you would like to see?
-
This is looking pretty awesome so far! Can't wait to see more of it :)
-
Looks like a very robust system ! :D I can't stop thinking of an OpenOffice-like program ;D
Suggestions : would it be feasible to have different text sizes ? Embedded images ? Scrolling text for larger-than-screen document viewing ?
-
Looks like a very robust system ! :D I can't stop thinking of an OpenOffice-like program ;D
[...]
Erm, there is already DCS's text editor.
-
Looks like a very robust system ! :D I can't stop thinking of an OpenOffice-like program ;D
Suggestions : would it be feasible to have different text sizes ? Embedded images ? Scrolling text for larger-than-screen document viewing ?
Text sizes no as its all based off a static font map. In line images I see no reason why not but is past the scope of what im making(though I plan on editing the font to have basic ascii images for simple art/text maps) . And anything is possible it's based around a putchar routine so you could technically make it do anything you wanted! I'll have a text stroller demo soon for an rpg. Just didn't get there the other night
-
Looks like a very robust system ! :D I can't stop thinking of an OpenOffice-like program ;D
[...]
Erm, there is already DCS's text editor.
Well heh, it requires DCS. I usually don't even have 16384 bytes of free flash.
-
Just to make debate. I personally don't see the point of a text editor on calc it's rather pointless when compared to pen and paper. And is honestly more cumbersome ton work with then anything else.
-
Just to make debate. I personally don't see the point of a text editor on calc it's rather pointless when compared to pen and paper. And is honestly more cumbersome ton work with then anything else.
I have two arguments
- You don't always have a pen or paper, and personnally, I almost always have a calculator with me
- You can easily lose the paper you wrote on but less easily lose your calc
Now, those arguments can be defeated with the word "phone" for most people but they applied for me last year when my phone was complete crap.
(also, it's "more than", not "more then", "then" is for what comes next, "than" is for comparisons ;))
-
The biggest reason to have a decent on-calc text editor, I think, is so we can move away from the idea of using the built-in BASIC editor for programming. It's a bad editor for non-tokenized languages. If we had a real text editor then we might even be able to get named functions in an on-calc language.
-
The biggest reason to have a decent on-calc text editor, I think, is so we can move away from the idea of using the built-in BASIC editor for programming. It's a bad editor for non-tokenized languages. If we had a real text editor then we might even be able to get named functions in an on-calc language.
I would Rather see a specific app for this then a hacked up text editor that can export tokens. That's just my opinion though. making some code base changes to add a few internal features tonight hopefully it pans out.
-
I see this is coming along quite nicely. Good work guys! :D
-
(https://dl.dropboxusercontent.com/u/98196116/screenies/animooted7.gif)
Did a little grunt work then made some fancy animations :3
-
looking awesome :P
-
Looks nice geek! :D
THis reminds me, I should maybe revive the text box engine I had in The Reign of Legends 4ever back in 2004, but use xLIB instead of CODEX and merge it with the text/menu engine in the 2007 incarnation of The Reign of Legends 4. This could be handy for people who makes RPGs.
-
Yeah the only problem I am having as of the moment is I need a masked sprite routine for the Corners. I will probably have to rewrite the code for the corners sadly to accommodate. When I designed it at first I did not account for the fact that I need them masked >.<
-
I've got a simple masked sprite routine you can use, though i think it uses SMC.
-
I will gladly take a look at it/if it works use it :D
-
OK, here's the first one, it requires the mask to immediately follow the sprite. This one was for an 8x7 cursor i had, so you might want to change the 7s to 8s if you want to draw an 8x8 sprite. Also, my graph buffer had an extra 16x16 column (14 bytes wide), so you might need to adjust some of the width values. For example, the multiplication at the beginning, the ld de,14 for the aligned loop, and the ld de,13 at the ebd if the notAligned loop.
;l = y
;a = x
;ix = sprite
putSpriteMasked:
ld b,7
ld h,0
ld e,l
ld d,h ;ld de,hl
add hl, hl ;x2
add hl, de ;x3
add hl, hl ;x6
add hl, de ;x7
add hl, hl ;x14
ld e,a ;guardar e en a para sacar el offset x
srl e
srl e
srl e ;/8
add hl,de
ld de,gbuf
add hl,de
ld (cursorGbufLoc),hl
push hl
push bc
ex af,af'
;copy the bytes beneath the cursor
ld a,b ;sprite height
ld de,cursorGbufSave
ldi ;load gbuf into gbuf buffer ()
ldi ;guardar dos bytes debajo del cursor
ld bc,12
add hl,bc ;próxima fila del gbuf
dec a
jr nz,$-9
ex af,af'
pop bc
pop hl
and $07 ;x offset
ld c,a
or a ;si x offset=0, significa que el sprite está alineado
jr nz,maskedNotAlignedLoop
ld de,14
maskedAlignedLoop:
ld a,(hl)
and (ix+7)
xor (ix)
ld (hl),a ;guardar
inc ix ;próximo byte
add hl,de ;próxima fila del gbuf
djnz maskedAlignedLoop
ret
maskedNotAlignedLoop:
push bc ;b = número de iteraciones restantes, c = xoffset
ld b,c
ld a,(ix+7) ;máscara
ld c,$FF ;dummy byte
ld d,(ix)
ld e,0
mNARotate:
scf
rra ;a = mask
rr c ;c = overflow
srl d ;d = sprite byte
rr e ;e = sprite overflow
djnz mNARotate
;mask = ac
;sprite = de
and (hl)
xor d
ld (hl),a ;primer byte
inc hl
ld a,c
and (hl)
xor e
ld (hl),a ;segundo byte del sprite
ld de,13
add hl,de ;próxima fila
inc ix
pop bc
djnz maskedNotAlignedLoop
ret
This is a modified 8xY version of that that supports variable height masks and with simple y clipping (only for the bottom, but adding it for the top is really easy) and x boundary detection, ie it won't draw the sprite if a pixel is offscreen.
;e = x
;l = y
;a = sprite height
draw_sprite_mask12:
ld a,12
draw_sprite_mask:
ld (aligned_mask),a ;update masks
ld (unaligned_mask),a ;masks should be at the end of the sprite (sprite+sprite_height)
ld d,a
ld a,e ;check x
cp 89
ret nc
ld a,l ;check y offscreen and simple clipping
or a
jp p,+_
neg
ld c,a
ld b,0
add ix,bc
neg
add a,d ;a negative Y + height will tell us the new height (pixels on screen)
ld d,a ;save new height (y+height)
ld l,0 ;set y coord to 0
_ add a,d
cp 65
ret nc
ld a,d
ld h,0
ld d,h
ld c,l
ld b,h ;ld bc,hl
add hl,hl ; *2
add hl,bc ; *3
add hl,hl ; *6
add hl,hl ;Y*12
ld b,a ;sprite height to b
ld a,e
srl e
srl e
srl e ;/8
add hl,de
ld de,gbuf
add hl,de ;gbuf + y offset + x offset
and $07 ;x offset
ld c,a
or a ;if x offset=0, sprite's aligned
jr nz,maskedNotAlignedLoop
ld de,12
maskedAlignedLoop:
ld a,(hl) ;gbuf byte
aligned_mask = $+2
and (ix+12) ;mix the mask
xor (ix) ;fill in with the sprite
ld (hl),a ;update
inc ix ;next byte
add hl,de ;next row
djnz maskedAlignedLoop
ret
maskedNotAlignedLoop:
push bc ;b = iterations left, c = x offset
ld b,c
unaligned_mask = $+2
ld a,(ix+12) ;mask
ld c,$FF ;dummy byte
ld d,(ix)
ld e,0
mNARotate:
scf
rra ;a = mask
rr c ;c = overflow
srl d ;d = sprite byte
rr e ;e = sprite overflow
djnz mNARotate
;mask = ac
;sprite = de
and (hl) ;mask1 + gbuf1
xor d ;sprite1
ld (hl),a
inc hl
ld a,c
and (hl) ;mask2 + gbuf2
xor e ;sprite2
ld (hl),a
ld de,11
add hl,de ;next row gbuf
inc ix ;next row sprite
pop bc
djnz maskedNotAlignedLoop
retEDIT: The second one is for a normal 12-byte width gbuf.
-
I shall more then likely use then second one thanks :D clipping is not my problem sooo lol
-
Well then you can remove the clipping code at the top and save a few bytes :)