This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Runer112
Pages: 1 ... 97 98 [99] 100 101 ... 153
1471
« on: February 18, 2011, 05:22:09 pm »
Here's the most optimized code I could come up with. Only while finding the top left corner does it fully calculate the position. The other corners reuse previously found values and conditionally add to them as necessary. Note that this will only work with the corner locations being calculated in the order below (although code can exist between calculations), and only for the player being at (45,29) due to optimizations tuned specifically to this coordinate.
.Top Left
29-Osub(D8)+J*[map_width]+(45-Nsub(D8)+I)+E→r₆
.Top Right
Nsub(O00)→r₅+r₆
.Bottom Left
Osub(O00)*[map_width]+r₆→r₆
.Bottom Right
r₅+r₆
Lbl D8
/2/2/2
Return
Lbl O00
//2≠⁻2
Return
1472
« on: February 18, 2011, 01:43:36 am »
For the smallest you can use ClrDrawr:DrawInvr methinks
If the DrawInv routine already exists in your program, then yes, that is the smallest solution. Here would be my priorities for the smallest way to fill the back buffer based on what routines already exist in your program: - If the DrawInv routine exists — ClrDrawr:DrawInv r [12 bytes]
- If the Rect() routine exists — Rect(0,,-1,)r [18 bytes]
- Otherwise — EFFFF→{L3}r:Fill(L3+1,766) [20 bytes]
Also, in case anyone was wondering, the smallest ways to fill the front buffer: - If the DrawInv routine exists — ClrDraw:DrawInv [6 bytes]
- If the Rect() routine exists — Rect(0,,-1,) [10 bytes]
- If the RectI() routine exists — ClrDraw:RectI(0,,-1,) [13 bytes]
- Otherwise — EFFFF→{L6}r:Fill(L6+1,766) [20 bytes]
And the smallest ways to fill both buffers: - If the DrawInv routine exists — ClrDraw:DrawInv :StorePic [17 bytes]
- If the Rect() routine exists — Rect(0,,-1,):StorePic [21 bytes]
- If the RectI() routine exists — ClrDraw:RectI(0,,-1,):StorePic [24 bytes]
- Otherwise — ClrDraw:DrawInv :StorePic [33 bytes]
1473
« on: February 17, 2011, 10:46:03 pm »
The easiest thing to do is just to store the 16x16 sprites as 4 individual 8x8 sprites, as Axe has no built-in 16x16 sprite drawing capabilities. You would then store the 4 individual sprites in memory with the top left corner first, then the top right corner, then the bottom left corner, and finally the bottom right corner. You could then draw the whole sprite with something like the following:
Lbl SPR
Pt-On(r₁,r₂,r₃)
Pt-On(r₁+8,r₂,r₃+8)
Pt-On(r₁,r₂+8→r₂,r₃+16)
Pt-On(r₁+8,r₂,r₃+24)
Return
1474
« on: February 17, 2011, 10:02:59 pm »
Correction  ᴇFFFF→{L₃}ʳ
Fill(L₃+1,766)
1475
« on: February 17, 2011, 09:47:36 pm »
Now that you have absolute jumps implemented:
p_Exchange:
.db 13
pop de
ex (sp),hl
pop bc
ld a,(de)
ldi
dec hl
ld (hl),a
inc hl
ld a,b
or c
jr nz,$-8
| |
p_Exchange:
.db 12
pop de
ex (sp),hl
pop bc
__ExchangeLoop:
ld a,(de)
ldi
dec hl
ld (hl),a
inc hl
jp pe,__ExchangeLoop ;or is it po?
|
1476
« on: February 17, 2011, 04:23:16 pm »
You are correct. I have fixed that now, but I probably won't bother to make a new release just for a silly text mistake. I will probably upload a new version/revision if I change any of the speed/size data, in which case this fix will be included.
1477
« on: February 17, 2011, 04:35:33 am »
You're multiplying just the 2 most significant bytes of the score, right? May I suggest the following then:
Mul16by8:
ex de,hl ;INPUTS: hl = multiplicand a = multiplier
ld hl,0 ;OUTPUTS: ahl = product b = 0
ld b,8
__Mul16by8loop:
add hl,hl
rla
jr nc,__Mul16by8skip
add hl,de
adc a,0
__Mul16by8skip:
djnz __Mul16by8loop
ret
And if you only need a 24/16 division routine, this should hopefully work:
Div24by16:
push hl ;INPUTS: ahl = dividend de = divisor
pop ix ;OUTPUTS: ahl = quotient de = divisor
ld hl,0
ld b,24
__Div24by16loop:
add ix,ix
rla
adc hl,hl
jr c,__Div24by16setbit
or a
sbc hl,de
add hl,de
jr c,__Div24by16skip
__Div24by16setbit:
or a
sbc hl,de
inc ix
__Div24by16skip:
djnz __Div24by24loop
push ix
pop hl
ret
1478
« on: February 16, 2011, 06:48:28 pm »
I haven't tested it myself, but try this? It appears to me that it should work, and it doesn't require any scratch memory. And by my count, it's only 43 bytes.
Div24by24:
ld b,a ;INPUTS: ahl = dividend cde = divisor
push hl ;OUTPUTS: cde = quotient ahl = remainder
pop ix
ld l,24
push hl
xor a
ld h,a
ld l,a
__Div24by24loop:
add ix,ix
rl b
adc hl,hl
rla
cp c
jr c,__Div24by24skip
jr nz,__Div24by24setbit
sbc hl,de
add hl,de
jr c,__Div24by24skip
__Div24by24setbit:
sbc hl,de
sbc a,c
inc ix
__Div24by24skip:
ex (sp),hl
dec l
ex (sp),hl
jr nz,__Div24by24loop
pop de
ld c,b
push ix
pop de
ret
1479
« on: February 16, 2011, 01:59:58 pm »
Found some uploads for day 2! Part 1(Feel free to skip to 4:25, the first part is just an IBM plug) Part 2(Shorter IBM plug this time, only until 2:40)
1480
« on: February 16, 2011, 01:47:44 pm »
Yay, double post! But it's been almost a day and I have a pretty good question/suggestion. This relates to the screen display commands. This was brought to mind when squidgetx made a post mentioning something I had discovered a while ago when documenting the speed of Axe commands. What he mentioned is that DispGraphr actually runs faster than DispGraph. Here's a quote of my response to that: I see you've been reading up on my Commands documentation, eh squidgetx? Yeah, that's an interesting thing I discovered when speed testing the display commands. On calculators like mine with the old, "good" screen drivers, the screen driver delay seems to be pretty low and constant from calculator to calculator. DispGraph could run just as fast or faster than DispGraphr on these calculators. However, due to inconsistencies with the screen drivers in newer units, the routine may run too fast for the driver on some calculators, causing display problems, so Quigibo had to add a portion of code to pause the routine until the driver says it is ready. However, this pause itself adds some overhead time, making the routine slower.
Quigibo, the DispGraphr routine doesn't have any throttling system in place, yet no problems have been reported with it on newer calculators. Could you just remove the throttling system from the DispGraph routine and add one or two time-wasting instructions to make each loop iteration take as many cycles as each DispGraphr loop iteration?
EDIT: Hmm I don't know if Quigibo reads this thread and would see that, so I'm probably going to post that in a major thread he reads or send him a message about that.
The second paragraph is my suggested optimization. The 3-level grayscale routine doesn't have a throttling system, yet there have been no reports of display problems from anybody. Wouldn't this suggest that all the screen drivers can handle routines that have as much delay as this? The data copying loop in the 3-level grayscale routine takes 72 cycles per byte output, so could delays simply be added to the normal screen display routine to make its loop at least 72 cycles?
1481
« on: February 16, 2011, 01:21:46 pm »
I see you've been reading up on my Commands documentation, eh squidgetx? Yeah, that's an interesting thing I discovered when speed testing the display commands. On calculators like mine with the old, "good" screen drivers, the screen driver delay seems to be pretty low and constant from calculator to calculator. DispGraph could run just as fast or faster than DispGraphr on these calculators. However, due to inconsistencies with the screen drivers in newer units, the routine may run too fast for the driver on some calculators, causing display problems, so Quigibo had to add a portion of code to pause the routine until the driver says it is ready. However, this pause itself adds some overhead time, making the routine slower.
Quigibo, the DispGraphr routine doesn't have any throttling system in place, yet no problems have been reported with it on newer calculators. Could you just remove the throttling system from the DispGraph routine and add one or two time-wasting instructions to make each loop iteration take as many cycles as each DispGraphr loop iteration?
EDIT: Hmm I don't know if Quigibo reads this thread and would see that, so I'm probably going to post that in a major thread he reads or send him a message about that.
1482
« on: February 16, 2011, 01:04:12 pm »
Darl, I think I fixed the smoothscrolling problems! I got it working right literally 4 minutes after you left last night. Here are the things I modified, and I tried my very best not to optimize anything: - Adjusted the placement of the If statements inside shifting code
- Changed the offsets to range from ⁻3 to 0 instead of 0 to 3, and then changed the drawing code to add the offsets instead of subtract them
- Increased the maximum bound of the For() loops that draw new tiles by 1
- Changed the occurrence of +360 to +384
With any luck those changes should make it work! I have put a side-by-side comparison of your code and the changed code below so it hopefully shouldn't be too difficult to track the changes I made. :.DTILEMPR
:[F0F0F0F000000000]→Pic0N
:[A0A0505000000000]→Pic1J
:[6040206000000000]→Pic1S
:[6040604000000000]→Pic1F
:[9000009000000000]→Pic1R
:[A050A05000000000]→Pic1D
:[000C030000000000]→Pic1W
:DiagnosticOff
:"vTIOLVL"→Str1
:GetCalc(Str1)→P
:Return!If P
:conj(P,L1,384
:0→N→O→I→J-1→E
:.I and J are coordinates of top left corner
:.N and O are tile offsets
:
:ClrDraw
:.draw init image
:For(Y,0,15
:Y*4→T
:For(X,0,23
:X*4→S
:E+1→E
:sub(DRW
:End
:End
:DispGraph
:Repeat getKey(15)
:Repeat getKey(0):End
:If getKey(54)
:ClrHome
:.display stuff
:Disp "random info",i,"I",I►Dec," J",J►Dec,i,"N",N►Dec," O",O►Dec
:While getKey(54):Pause 10:End
:End
:
:If getKey(1) xor (getKey(4))
:.vert movement
:
:If getKey(4)
:Vertical +
:O+1→O
:If O>>3
:J-1→J
:O-4→O
:For(A,0,23
:A*4-N→S
:0-O→T
:J*24+I+A→E
:sub(DRW
:End
:End
:End
:
:If getKey(1)
:Vertical -
:O-1→O
:If O<<1
:J+1→J
:O+4→O
:For(A,0,23
:A*4-N→S
:64-O→T
:J*24+I+A+360→E
:sub(DRW
:End
:End
:End
:
:End
:
:If getKey(2) xor (getKey(3))
:.horiz movement
:If getKey(2)
:Horizontal +
:N+1→N
:If N>>3
:N-4→N
:I-1→I
:For(A,0,15
:0-N→S
:A*4-O→T
:J*24+I+(A*24)→E
:sub(DRW
:End
:End
:End
:If getKey(3)
:Horizontal -
:N-1→N
:If N<<1
:N+4→N
:I+1→I
:For(A,0,15
:96-N→S
:A*4-O→T
:J*24+I+(A+1*24)→E
:sub(DRW
:End
:End
:End
:
:
:
:End
:DispGraph
:End
:
:
:Lbl DRW
:Pt-On(S,T,Pic0N
:Pt-Change(S,T,Pic0N
:.pt-on stuff
:!If {L1+E}-1
:Pt-On(S,T,Pic0N
:Else!If {L1+E}-2
:Pt-On(S,T,Pic1J
:Else!If {L1+E}-3
:Pt-On(S,T,Pic1S
:Else!If {L1+E}-4
:Pt-On(S,T,Pic1F
:Else!If {L1+E}-5
:Pt-On(S,T,Pic1R
:Else!If {L1+E}-6
:Pt-On(S,T,Pic1D
:Else!If {L1+E}-7
:Pt-On(S,T,Pic1W
:End
:.Return
| | :.DTILEMPR
:[F0F0F0F000000000]→Pic0N
:[A0A0505000000000]→Pic1J
:[6040206000000000]→Pic1S
:[6040604000000000]→Pic1F
:[9000009000000000]→Pic1R
:[A050A05000000000]→Pic1D
:[000C030000000000]→Pic1W
:DiagnosticOff
:"vTIOLVL"→Str1
:GetCalc(Str1)→P
:Return!If P
:conj(P,L1,384
:0→N→O→I→J-1→E
:.I and J are coordinates of top left corner
:.N and O are tile offsets
:
:ClrDraw
:.draw init image
:For(Y,0,15
:Y*4→T
:For(X,0,23
:X*4→S
:E+1→E
:sub(DRW
:End
:End
:DispGraph
:Repeat getKey(15)
:Repeat getKey(0):End
:If getKey(54)
:ClrHome
:.display stuff
:Disp "random info",i,"I",I►Dec," J",J►Dec,i,"N",N►Dec," O",O►Dec
:While getKey(54):Pause 10:End
:End
:
:If getKey(1) xor (getKey(4))
:.vert movement
:
:If getKey(4)
:Vertical +
:O+1→O
:If O>>0
:J-1→J
:O-4→O
:End
:For(A,0,24
:A*4+N→S
:O→T
:J*24+I+A→E
:sub(DRW
:End
:End
:
:If getKey(1)
:Vertical -
:O-1→O
:For(A,0,24
:A*4+N→S
:64+O→T
:J*24+I+A+384→E
:sub(DRW
:End
:If O<<⁻3
:J+1→J
:O+4→O
:End
:End
:
:End
:
:If getKey(2) xor (getKey(3))
:.horiz movement
:If getKey(2)
:Horizontal +
:N+1→N
:If N>>0
:N-4→N
:I-1→I
:End
:For(A,0,16
:N→S
:A*4+O→T
:J*24+I+(A*24)→E
:sub(DRW
:End
:End
:If getKey(3)
:Horizontal -
:N-1→N
:For(A,0,16
:96+N→S
:A*4+O→T
:J*24+I+(A+1*24)→E
:sub(DRW
:End
:If N<<⁻3
:N+4→N
:I+1→I
:End
:End
:
:
:
:End
:DispGraph
:End
:
:
:Lbl DRW
:Pt-On(S,T,Pic0N
:Pt-Change(S,T,Pic0N
:.pt-on stuff
:!If {L1+E}-1
:Pt-On(S,T,Pic0N
:Else!If {L1+E}-2
:Pt-On(S,T,Pic1J
:Else!If {L1+E}-3
:Pt-On(S,T,Pic1S
:Else!If {L1+E}-4
:Pt-On(S,T,Pic1F
:Else!If {L1+E}-5
:Pt-On(S,T,Pic1R
:Else!If {L1+E}-6
:Pt-On(S,T,Pic1D
:Else!If {L1+E}-7
:Pt-On(S,T,Pic1W
:End
:.Return
|
I tried my best not to optimize anything to keep it understandable. But if you want me to try optimizing it, just tell me.
1483
« on: February 15, 2011, 04:01:39 pm »
Some improvements to MemKit! Next(): 2 bytes and a few cycles saved. Also, isn't the end-of-VAT check in the wrong place? I could be wrong because my VAT experience isn't too great, but because this routine checks for the end of the VAT at the start, wouldn't this command advance the VAT pointer to the end of the VAT and not recognize it as the end until the next Next()? This would cause problems with programs reading garbage VAT data for the last "entry." If I'm right about this (which may not be the case), the third block of code I posted should hopefully recognize the end of the VAT as soon as it hits it and never advance the VAT pointer to point to the end.
ld hl,(axv_X1t)
ld de,($982E)
or a
sbc hl,de
ret z
add hl,de
ld de,-6
add hl,de
ld e,(hl)
inc e
xor a
ld d,a
sbc hl,de
ld (axv_X1t),hl
ret
| |
ld hl,(axv_X1t)
ld de,($982E)
or a
sbc hl,de
ret z
add hl,de
ld de,-6
add hl,de
ld a,(hl)
cpl
ld e,a
add hl,de
ld (axv_X1t),hl
ret
| |
ld hl,(axv_X1t)
ld de,-6
add hl,de
ld a,(hl)
cpl
ld e,a
add hl,de
ld de,($982E)
or a
sbc hl,de
ret z
add hl,de
ld (axv_X1t),hl
ret
|
Dim()rr: Fixed the page offset.
ld ix,(axv_X1t)
ld l,(ix-6)
ld h,0
| |
ld ix,(axv_X1t)
ld l,(ix-5)
ld h,0
|
Print(): n*16-13 cycles saved, n=name length. Assuming an average name length of 4.5 characters, 59 cycles saved.
ld ix,(axv_X1t)
ld b,(ix-6)
Ax6_Loop:
ld a,(ix-7)
ld (hl),a
inc hl
dec ix
djnz Ax6_Loop
ld (hl),b
ret
| |
ex de,hl
ld hl,(axv_X1t)
ld bc,-6
add hl,bc
ld b,(hl)
ex de,hl
Ax6_Loop:
dec de
ld a,(de)
ld (hl),a
inc hl
djnz Ax6_Loop
ld (hl),b
ret
|
1484
« on: February 15, 2011, 01:59:42 pm »
I don't know if you did this for debugging purposes or just for the effect, but you may not want to store the bullet data in L6. I can see it at the top of the screen. But it looks good!
1485
« on: February 15, 2011, 01:37:11 am »
A compressor or a decompressor? A decompressor shouldn't be too complex, although a Huffman compressor would probably be a decent amount harder to write for a calculator. I guess it's possible, though.
Pages: 1 ... 97 98 [99] 100 101 ... 153
|
Show Posts