### Author Topic: [A:P] Documentation  (Read 8191 times)

0 Members and 1 Guest are viewing this topic.

#### squidgetx

• Food.
• Project Author
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +503/-17
• rawr.
##### Re: [A:P] Documentation
« Reply #15 on: October 15, 2012, 03:57:38 pm »
Eh, I'm pretty set on using 12x12 tiles; I feel like 8x8 is too small graphics-wise, but 16x16 is too large =/

My 12x12 tilemapper is pretty much going to be a 16x16 mapper that draws extra tiles, so it'll be a bit slower. I don't think speed is really going to be a huge concern, though since it's an RPG, and the battles will be triggered and turn based as opposed to a game like Zelda (or Embers, for that matter)

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55829
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: [A:P] Documentation
« Reply #16 on: October 15, 2012, 04:00:51 pm »
I thought 16x16 was actually faster than 12x12? (that's assuming of course you don't use 16x16 as some sort of cheat)

As for speed I was more worried since in the demo the FPS was like 8 or something and grayscale suffered when scrolling. Was that improved?
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF

#### leafy

• CoT Emeritus
• LV10 31337 u53r (Next: 2000)
• Posts: 1554
• Rating: +475/-97
• Seizon senryakuuuu!
##### Re: [A:P] Documentation
« Reply #17 on: October 15, 2012, 06:17:51 pm »
16x16 is the same speed as 12x12, it's just that the bits on the edges are kind of wasted space and time. Axe can only draw sprites in multiples of 8, so 16 would be the natural choice when working with 12x12 tiles.
In-progress: Graviter (...)

#### chickendude

• Posts: 816
• Rating: +90/-1
##### Re: [A:P] Documentation
« Reply #18 on: October 15, 2012, 07:46:55 pm »
Ah i didn't know Axe could only do multiples of 8. It's kinda silly since it's super easy to draw extra Y tiles, unless there's some weird trick he's using. One of my projects now has a 16x16 sprite drawing routine i've written for it. Changing one number turns it into a 16x12 sprite drawing routine It could easily be a 16 x any number routine. I don't know how to write an Axiom and it's likely what i write ends up being less optimized than what Runer wrote. Ah and i am clueless when it comes to grayscale, are you using grayscale? And really, for a tilemap, it's usually more efficient to implement the sprite drawing into the mapper itself, not keeping the x and y coordinates on the screen but rather your position in the buffer, that way you don't have to recalculate your position in the buffer each time you go to draw a tile.

And squidgetx, unpacking the sprites would take the same space in RAM, but it would save space in your program. And it wouldn't even take up the user's RAM, just saferam. And you wouldn't have to have every map's set of sprites unpacked at the same time, just your current set. It might not be worth the trouble, but it'd save you 6 bytes (or 8, if you're using 16x16 sprites) per sprite.

@DJ: I think 16x16 is generally faster since you don't have to do as many calculations (it's faster to draw one 16x16 sprite than it is to draw 4 8x8 sprites)
« Last Edit: October 15, 2012, 07:50:52 pm by chickendude »

#### squidgetx

• Food.
• Project Author
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +503/-17
• rawr.
##### Re: [A:P] Documentation
« Reply #19 on: October 15, 2012, 08:17:29 pm »
Ah i didn't know Axe could only do multiples of 8. It's kinda silly since it's super easy to draw extra Y tiles, unless there's some weird trick he's using. One of my projects now has a 16x16 sprite drawing routine i've written for it. Changing one number turns it into a 16x12 sprite drawing routine It could easily be a 16 x any number routine. I don't know how to write an Axiom and it's likely what i write ends up being less optimized than what Runer wrote. Ah and i am clueless when it comes to grayscale, are you using grayscale? And really, for a tilemap, it's usually more efficient to implement the sprite drawing into the mapper itself, not keeping the x and y coordinates on the screen but rather your position in the buffer, that way you don't have to recalculate your position in the buffer each time you go to draw a tile.

And squidgetx, unpacking the sprites would take the same space in RAM, but it would save space in your program. And it wouldn't even take up the user's RAM, just saferam. And you wouldn't have to have every map's set of sprites unpacked at the same time, just your current set. It might not be worth the trouble, but it'd save you 6 bytes (or 8, if you're using 16x16 sprites) per sprite.

@DJ: I think 16x16 is generally faster since you don't have to do as many calculations (it's faster to draw one 16x16 sprite than it is to draw 4 8x8 sprites)

Chickendude, if you can translate your 16x12 routine into asm opcodes I'd be happy to experiment with it.

Yes, unpacking the sprites takes the same space in RAM, but due to size (1024 at minimum, and more likely 2048) it has to be user ram (afaik there's no saferam that size...)

#### chickendude

• Posts: 816
• Rating: +90/-1
##### Re: [A:P] Documentation
« Reply #20 on: October 16, 2012, 03:02:26 am »
This is the basic code. First however, you'll need to calculate where to draw the sprite on screen and put that into hl, +2 bytes (since it draws from right to left, we start with the right side of the sprite and draw leftward). I'm not really sure how Axe handles inputs to routines, so if i got a little more information i could add that in for you too. The first line loads the x offset, that is, how many pixels away from 0 we are. If you are drawing at an aligned position (a multiple of 8) b will equal 0. If you are drawing at X=1, b = 1. If X=19, b=19%8=3. C should be how many rows you want to draw. Here it's 16 (10h). If you want 12, you would change 10h to 0Ch. And the address of the sprite should be in ix. I also wrote a quick small aligned 16x16 tilemapper, i'm not sure how you draw your tilemaps. None of this uses grayscale, however, so i don't know how useful it is to you. I'd be happy to help write something for you, though. So:
b = x offset (how many pixels away from being aligned the sprite is)
c = number of rows to draw, this could be changed easily to a variable height sprite routine.
ix = address of first byte in sprite
Code: [Select]
 47 -  -  -   ld b,a 0E 10 -  -   ld c,16 -  -  -  -   -  -  -  -  drawPlayerLoop: C5 -  -  -   push bc DD 56 00 -   ld d,(ix)      ;sprite DD 5E 01 -   ld e,(ix+1) AF -  -  -   xor a B8 -  -  -   cp b CA 71 A0 -   jp z,skipSpriteClip CB 3A CB 1B F9 srl d \ rr e \ rra \ djnz -5 ;rotate sprite - - - - skipSpriteClip: B6 - - - or (hl) 77 - - - ld (hl),a 2B - - - dec hl 7E - - - ld a,(hl) B3 - - - or e 77 - - - ld (hl),a 2B - - - dec hl 7E - - - ld a,(hl) B2 - - - or d 77 - - - ld (hl),a DD 23 - - inc ix DD 23 - - inc ix 11 0E 00 - ld de,14 19 - - - add hl,de C1 - - - pop bc 0D - - - dec c C2 5E A0 - jp nz, drawPlayerLoop C9 - - - ret EDIT: This routine will also slow down a little the further away from being aligned you go. We could unroll the shifting loops which, although taking up more space, would be slightly faster and have a more even runtime, or something like a 12x12 version of what i posted over here: http://ourl.ca/15050 :) « Last Edit: October 16, 2012, 06:40:20 am by Art_of_camelot » #### squidgetx • Food. • Project Author • LV10 31337 u53r (Next: 2000) • Posts: 1881 • Rating: +503/-17 • rawr. ##### Re: [A:P] Documentation « Reply #21 on: October 17, 2012, 09:57:11 pm » Thanks, this will hopefully help a lot. One question though, where do you input the Y position? #### chickendude • LV8 Addict (Next: 1000) • Posts: 816 • Rating: +90/-1 • Pro-Riot Squad ##### Re: [A:P] Documentation « Reply #22 on: October 18, 2012, 04:16:28 am » I'm not sure how parameters are handled in Axe. That routine there requires that the position in the gbuf be calculated beforehand. I think this should work: Code: [Select] 26 00 - - ld h,054 - - - ld d,h6B - - - ld l,e ;hl=de29 - - - add hl, hl ; 219 - - - add hl, de ; 329 - - - add hl, hl ; 629 - - - add hl, hl ; 12 - - - - - - - - ; x / 878 - - - ld a,bCB 38 - - srl bCB 38 - - srl bCB 38 - - srl b58 - - - ld e,b19 - - - add hl,de ; A present on a le decalage dans hl11 42 93 - ld de,gbuf+2 ; Prendre le debut du graphbuffer19 - - - add hl,de ; Puis ajouter le decalageE6 07 - - and07Though the best would be to have a specific 12x12 tilemap routine rather than recalculate the position in gbuf every time you draw a tile.

« Last Edit: October 18, 2012, 04:19:44 am by chickendude »

#### squidgetx

• Food.
• Project Author
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +503/-17
• rawr.
##### Re: [A:P] Documentation
« Reply #23 on: October 18, 2012, 10:04:07 am »
Wait, sorry, I just reread your first post. I think I get it (correct me if I'm wrong) - the (byte) position on the graph buffer is put into hl (+2 bytes), and the offset is put into b. So for example if I want to write a sprite to the coordinates 2,0 on a buffer starting at $8000, I would load the value$8002 into hl and 2 into b.

Thanks, chickendude. I don't need it to be blazing fast, but it sure is a huge step up from using 4 8x8 routines XP

#### chickendude

• Posts: 816
• Rating: +90/-1
##### Re: [A:P] Documentation
« Reply #24 on: October 18, 2012, 11:33:27 am »
Yeah, that's exactly it. If your buffer is 12 bytes wide and you want to draw on the 4th row, you'll need to add 4*12 to the buffer address. The other code i posted above will calculate that for you with e=y, b=x. However, if you can save your position in the gbuf each time you draw a tile, you can save quite a few clocks by not having to recalculate your location in the buffer again.

#### squidgetx

• Food.
• Project Author
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +503/-17
• rawr.
##### Re: [A:P] Documentation
« Reply #25 on: October 20, 2012, 09:19:24 pm »
Just testing the sprite routine after trying to integrate it with Axe subroutines; but it doesn't seem to be working (instant crash)

Any insights?

Edit, realized that the absolute calls were probably messing stuff up.

Code: [Select]
//Subroutine takes arguments in sub args, at $83A5, in the form X,Y,Buffer,Spriteaddress(Axe code):r2*12+r1+r3+2->r3r1^16->r2r3->r1r4(Immediately proceeded by asm code):E5DDE1 push hl / pop ix ;(move r4, the sprite pointer to ix)2AA783 ld hl, ($83A7) ;(load r2, the offset, into hl)45            ld b, l ;(load into b)2AA583        ld hl, ($83A5) ;(load the draw location to hl) 0E 0C - - ld c,12 - - - - - - - - drawPlayerLoop: C5 - - - push bc DD 56 00 - ld d,(ix) ;sprite DD 5E 01 - ld e,(ix+1) AF - - - xor a B8 - - - cp b CA 71 A0 - jp z,skipSpriteClip CB 3A CB 1B F9 srl d \ rr e \ rra \ djnz$-5   ;rotate sprite -  -  -  -  skipSpriteClip: B6 -  -  -   or (hl) 77 -  -  -   ld (hl),a 2B -  -  -   dec hl 7E -  -  -   ld a,(hl) B3 -  -  -   or e 77 -  -  -   ld (hl),a 2B -  -  -   dec hl 7E -  -  -   ld a,(hl) B2 -  -  -   or d 77 -  -  -   ld (hl),a DD 23 -  -   inc ix DD 23 -  -   inc ix 11 0E 00 -   ld de,14 19 -  -  -   add hl,de C1 -  -  -   pop bc 0D -  -  -   dec c C2 5E A0 -   jp nz, drawPlayerLoop C9 -  -  -   ret
« Last Edit: October 21, 2012, 02:18:27 pm by squidgetx »

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55829
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: [A:P] Documentation
« Reply #26 on: October 21, 2012, 11:32:07 am »
16x16 is the same speed as 12x12, it's just that the bits on the edges are kind of wasted space and time. Axe can only draw sprites in multiples of 8, so 16 would be the natural choice when working with 12x12 tiles.
Ah ok I thought that to draw in 12x12 that most older tricks just tried to cut the sprites at 12x12 rather than using 16x16 with unused/wasted space and that it was actually slower that way.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF

#### chickendude

• Posts: 816
• Rating: +90/-1
##### Re: [A:P] Documentation
« Reply #27 on: October 22, 2012, 10:33:24 am »
You're right, either way it'll still be slower. If you are using a 16x16 routine, you will be calling that routine more times than if you were drawing normal 16x16 sprites (essentially the last four rows will be time completely wasted, doing nothing), and calculating the offset every time means a lot more shifting bytes since at least every other tile will be unaligned. But another reason for the slowdown with Sam Heald's Zelda might just be that back then there weren't that many smooth-scrolling games in general.

#### squidgetx

• Food.
• Project Author
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +503/-17
• rawr.
##### Re: [A:P] Documentation
« Reply #28 on: October 25, 2012, 05:31:53 pm »
*Documentation update*

(see first post)
The project is now (almost) officially moving out of spec-writing stage , just going to tighten up the memory allocation meta
« Last Edit: October 25, 2012, 05:43:13 pm by squidgetx »

#### TIfanx1999

• ಠ_ಠ ( ͡° ͜ʖ ͡°)
• CoT Emeritus
• LV13 Extreme Addict (Next: 9001)
• Posts: 6173
• Rating: +191/-9
##### Re: [A:P] Documentation
« Reply #29 on: October 29, 2012, 05:56:32 pm »
Awesome! Also, the documentation is quite nice. ^^
« Last Edit: October 29, 2012, 05:57:01 pm by Art_of_camelot »