Page 9 of 14
Posted: Mon 12 Dec, 2005 11:51 pm
by Timendus
kv83 wrote:We discussed featuring this project and came to the conclusion that we want to wait a little longer to see how this project develops... It has a good chance though
I expected you'd be discussing that
I don't care horribly much if this gets featured or not, but it would be cool. Thanks for the info.
I added some drawing and math routines that I found on Ticalc.org, because I really (no
REALLY) suck at math, so calculating square roots or the clipping of lines in binary is not my cup of tea. I'm not sure if they're the fastest routines available, or if they'll work at all, but it's a start
I'm working on a much cooler addition to the API myself, but I'm not really sure how I'm going to make this work, so I'll keep that to myself for now
Posted: Tue 13 Dec, 2005 1:15 am
by currahee
You're not the only one that sucks at math ... well at least routines.
Posted: Tue 13 Dec, 2005 2:42 am
by Jim e
I wrote a square routine a while back, it runs in under 900 clocks I believe. So if speed is really the concern this works well, plus it only uses the registers, no extra memory.
Code: Select all
;--------------------------------------
;square root by James Montelongo
; √(DE) = A
;All registers destoryed
;180 bytes
; >900 clocks
sqrt:
xor a
ld h,a
ld l,a
ld b,a
rl d
rl l
rl d
rl l
ld c,1
sbc hl,bc
jp c,$+3+2+1
sbc hl,bc
inc a
add hl,bc
add a,a
rl d
rl l
rl d
rl l
ld c,a
scf
rl c
sbc hl,bc
jp c,$+3+2+1
sbc hl,bc
inc a
add hl,bc
add a,a
rl d
rl l
rl d
rl l
ld c,a
scf
rl c
sbc hl,bc
jp c,$+3+2+1
sbc hl,bc
inc a
add hl,bc
add a,a
rl d
rl l
rl d
rl l
ld c,a
scf
rl c
sbc hl,bc
jp c,$+3+2+1
sbc hl,bc
inc a
add hl,bc
add a,a
rl e
adc hl,hl
rl e
adc hl,hl
ld c,a
scf
rl c
sbc hl,bc
jp c,$+3+2+1
sbc hl,bc
inc a
add hl,bc
add a,a
rl e
adc hl,hl
rl e
adc hl,hl
ld c,a
scf
rl c
sbc hl,bc
jp c,$+3+2+1
sbc hl,bc
inc a
add hl,bc
add a,a
rl e
adc hl,hl
rl e
adc hl,hl
ld c,a
scf
rl c
sbc hl,bc
jp c,$+3+2+1
sbc hl,bc
inc a
add hl,bc
add a,a
rl e
adc hl,hl
rl e
adc hl,hl
ld c,a
scf
rl c
rl b
sbc hl,bc
jp c,$+3+2+1
sbc hl,bc
inc a
add hl,bc
ret
Posted: Tue 13 Dec, 2005 3:59 am
by necro
*Necro's head explodes* Jim...would you mind making a guide on stacks and registered geared specificaly towards people like me who are very bad at them?
Posted: Tue 13 Dec, 2005 3:12 pm
by Timendus
Thanks, Jim! That other routine really sucked, so this is very useful
currahee wrote:You're not the only one that sucks at math ... well at least routines.
It sucks to be bad with numbers in this line of work
Posted: Tue 13 Dec, 2005 10:24 pm
by Timendus
Jim permitted me to include his version of the greyscale package in the API. Sorry Duck, but his is faster and it doesn't require a frequency setting
on the other hand it lacks documentation, so I'll be nicking that from you
Anyway, I put most of the package in the API, and tested gs.enable(), gs.disable(), gs.getcsc() and gs.drawXor(...), and they run like a charm:
(I really like how that took me 5 minutes to code, 10 minutes to draw the sprite
The API rules
;))
Anyway, this too still needs to be documented properly (mostly descriptions and examples). I'm putting that off a lot, I know, but I think it needs functionality first, documentation second and optimization third, so I'll be working on this with that order of priorities
Edit: Hmm, this is pretty funny... It runs like a charm with NODOUBLEBUFFER defined, but without that it only shows a white screen... What did I do wrong..?
Posted: Tue 13 Dec, 2005 10:29 pm
by kalan_vod
Wow, that is so cool. Maybee there is hope for me after all! Go JIM and TIMENDUS!
Posted: Tue 13 Dec, 2005 11:05 pm
by Jim e
Timendus wrote:Hmm, this is pretty funny... It runs like a charm with NODOUBLEBUFFER defined, but without that it only shows a white screen... What did I do wrong..?
You must update the prebuffer to the current buffer when you want it to be drawn to the lcd. If you were to make say a Raycaster the time it takes draw the entire screen would become visable to the player so thats why a pre-buffer is used.
I think the routine is called update screen.
Posted: Tue 13 Dec, 2005 11:32 pm
by Timendus
Ah, yes of course... I missed the very point of having double buffers
Stupid me... And the routine is called gs.copyBuffer() now
Edit: Damn, using double buffers slows it down a LOT
Anyway, still goodlooking
Posted: Wed 14 Dec, 2005 1:59 am
by necro
damn, that is still very fast...wait...10 minute for the sprite?
Posted: Wed 14 Dec, 2005 2:32 am
by gangsta
can u give the source for that?
Posted: Wed 14 Dec, 2005 3:01 am
by Jim e
I'm noticing something, some code is getting reused in several routines, plus there are dependants that honestly could cause problems. Perhaps you should make a dependant section. Like section that normally the coder wouldn't use directly. Maybe just a MISC area.
Such as this, it's used a few times in my routine and could be useful routine
Code: Select all
;MUST BE DIVISIBLE BY 16 BYTES, save 4000 clocks
api_gs_gsCopy:
ldi \ ldi \ ldi \ ldi
ldi \ ldi \ ldi \ ldi
ldi \ ldi \ ldi \ ldi
ldi \ ldi \ ldi \ ldi
jp pe,gsCopy
ret
Also ionrandom could be replaced be another routine just a random 256 a nd a H times E routine.
I'm gonna try add things personally but could you give me quick rundown on precisely the format.
Posted: Wed 14 Dec, 2005 3:39 am
by necro
yay Jim! Realy quick question, can a hook be triggered inside of a asm program...as in can you use xlib real statemnets in a asm prog?
Posted: Wed 14 Dec, 2005 4:15 pm
by Timendus
necro wrote:damn, that is still very fast...wait...10 minute for the sprite?
Yup, I started over a few times though
gangsta wrote:can u give the source for that?
Sure, but it's not optimized at all, just a bit of code to be able to test everything:
Code: Select all
; #define NODOUBLEBUFFER
graph.clear()
ld hl,background
ld de,gbuf2
ld bc,768
ldir
ld hl,background2
ld de,gbuf1
ld bc,768
ldir
graph.output("Greyscale test")
gs.enable()
ld de,$4030
redraw:
push de
gs.drawXor(sprite,8,d,e)
gs.copyBuffer()
loop:
gs.getcsc()
cp 2
jr z,left
cp 4
jr z,up
cp 1
jr z,down
cp 3
jr z,right
cp 9 ; Enter quits
jr nz,loop
pop de
gs.disable()
ret
left:
pop de
push de
gs.drawXor(sprite,8,d,e)
pop de
dec d
jr redraw
right:
pop de
push de
gs.drawXor(sprite,8,d,e)
pop de
inc d
jr redraw
up:
pop de
push de
gs.drawXor(sprite,8,d,e)
pop de
dec e
jr redraw
down:
pop de
push de
gs.drawXor(sprite,8,d,e)
pop de
inc e
jr redraw
Jim e wrote:I'm noticing something, some code is getting reused in several routines, plus there are dependants that honestly could cause problems. Perhaps you should make a dependant section. Like section that normally the coder wouldn't use directly. Maybe just a MISC area.
Such as this, it's used a few times in my routine and could be useful routine
[...]
If it's a useful routine, you should just add it as a routine, and let all routines that need it depend on it. Anything that you don't need to be able to call seperately should be put in the gs.enable() routine, so it gets included when you enable greyscale.
Also ionrandom could be replaced be another routine just a random 256 a nd a H times E routine.
I'm gonna try add things personally but could you give me quick rundown on precisely the format.
Just take a look at the template that the website generates when you try to add a routine. If you don't understand it, feel free to ask.
Posted: Wed 14 Dec, 2005 4:17 pm
by kalan_vod
Wow, I actually understand the code posted above! So once this get a little further I will give it a try
, and when I get it down I will look at the code of the routine used so I get even more of an understanding.