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 - squidgetx
Pages: 1 ... 11 12 [13] 14 15 ... 123
181
« on: October 24, 2012, 08:58:15 pm »
The Strokes
182
« on: October 23, 2012, 04:34:33 pm »
Hm, I'll start off with a pure Axe approach of using 4 8x8 routines, and see whether I need the speed bump. Thanks for offering, though 
183
« on: October 23, 2012, 12:25:13 pm »
Ergh, still not working... Does anyone know a good utility to convert whole asm programs to hex, or should I just grab a hex editor or something? I changed that missing-2-byte line and adjusted the two relative jumps accordingly: EDIT: Just realized a pretty major bug, that register a is never intialized properly EDIT2: Runer just pointed out that this routine doesn't clip...uh oh  Sprite(X,Y,Buff,Pointer)
r2*12+(r1/8)+r3+2 -> r3
r1^8->r2
r4
Asm(
E5 DD E1 - push hl \ pop ix
2A A7 83 - ld hl, ($83A7)
45 - - - ld b, l
2A A9 83 - ld hl, ($83A9)
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
28 07 - - jr z,$+9 (skipspriteclip)
CB 3A CB 1B
1F 10 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
20 E4 - - jr nz, $-26 38d (drawPlayerLoop)
C9 - - - ret
184
« on: October 22, 2012, 01:18:26 pm »
Thanks, MGOS also pointed this out to me. I'm testing with coordinates 0,0 though, and it still doesn't work =/
.TEST
[hex]->Pic1
DrawT(0,0,L6,Pic1)
DispGraph
Repeat getKey
End
Return
Lbl DrawT
...
185
« on: October 22, 2012, 12:41:29 pm »
Well I guess I should explain what the code is (supposed) to do (btw, changing it to ld b,l makes it crash anyway).
I calculate the position in the gbuf with the first axe line: r2*12+r1+r3+2, where r2 is the Y value, r1 is the X value, and r3 is the buffer to be drawn to. I store this value to r3. Then I take r1 mod 8 (the offset) and store that into r2 ($83A7). Then I take r3 (the gbuf) and put it into r1 ($83A5). Finally, I call r4 (the sprite pointer) and put it into hl.
That's the axe "prep." So I have all the pieces the routine needs; the position to draw to (in $83A5), the offset (in $83A7), and the sprite pointer (in hl). I just need to move them to hl, b, and ix respectively.
So what follows is 5 lines of asm before the original routie, push hl / pop ix to get the sprite pointer to ix, ld hl ($83A7) / ld b, l to get the offset into b, and ld hl ($83A5) to get the draw position into hl
186
« on: October 21, 2012, 05:43:39 pm »
As the title says, I'm having trouble converting Chickendude's 16x16 (really 16xN) sprite routine so I can use it with Axe. 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  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
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
I modified it slightly to draw 12 rows, and changed the jumps to relative jumps. Then I added a couple lines at the beginning so it could read in values passed to it in the r variables ($83A5). .Axe code
DrawT(0,0,L6,Pic1)
...
Lbl DrawT
r2*12+r1+r3+2->r3
r1^8->r2
r3->r1
r4
Asm(stuff)
.Assembly stuff
E5 DD E1 - push hl / pop ix
2A A7 83 - ld hl, ($83A7)
44 - - - ld b, h
2A A5 83 - ld hl, ($83A5)
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
28 03 - - jr z,$+7 (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
20 E7 - - jp nz, $-23 (drawPlayerLoop)
C9 - - - retRight now, it just crashes on run. I'd be super grateful if anyone could help  *Edited to make the bottom two code boxes show up*
187
« on: October 21, 2012, 10:24:10 am »
Personally, I never use that option =/ since I'm kinda overparanoid about linking my facebook to all my forum profiles. Some people might like it though; but I don't think it'll be a huge consideration.
188
« 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. //Subroutine takes arguments in sub args, at $83A5, in the form X,Y,Buffer,Spriteaddress
(Axe code):
r2*12+r1+r3+2->r3
r1^16->r2
r3->r1
r4
(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
189
« 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
190
« 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?
191
« 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...)
192
« 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)
193
« on: October 14, 2012, 05:30:55 pm »
Squidgetx, just wondering - do you have extra data that stores your enemies, NPCs, and whatnot? Or is it all built into tiles on the tilemap?
This will be stored outside the tilemap 12x12 should only be the same as 12x16, though you could store them compacted then extract them to saferam before drawing the map. There aren't any tiles that are shared throughout maps? Why not have a basic tileset that is shared throughout all maps and then give each map a certain number of individual tiles. Or you want to keep each tile reduced to a nibble? RLE compression tends to work really well for tilemaps (there are so many repeated tiles) and it's pretty simple to write a "decompressor".
Yeah, but once it's extracted it takes the same amount of RAM as 16x16 which is what I'm worried about (unless someone wants to write an axiom that supports 12x12 tiles or something). Also, I could also have tiles shared between maps, but from my mapdesigning experience it's not completely necessary (maybe a very basic subset could be done)
194
« on: October 13, 2012, 01:56:31 pm »
I can't decide whether I want to use the same tile/map scheme as I did before, where the tiles were nibbles and each map had its own nibbleset. I remember feeling constricted by only having 16 tiles. I can't have every map able to access every tile, though (not enough RAM for practical use). Thoughts?
Just for reference, a set of 16 12x12 (same as 16x16) 4scale tiles is 1024 bytes. I think that having each map limited to 32 tiles is sufficient, but it seems like a massive waste when you realize that then that means every map doubles in size =/
Actually, I might just go for that, since I was going to RLE the maps anyway...
edit: Over the course of writing my post I ended up deciding what I was going to do, lol
195
« on: October 11, 2012, 09:00:33 am »
I think this version had some issues loading the health properly-- did it change after you had quit and then loaded?. If it just "randomly" changed to 426% then I'm not entirely sure what could've caused it... As for continuing, I'm currently working on another project but might come back to this if I have time/need a break from Ash:Phoenix. Thanks for the report, and it's nice to know people are enjoying my game
Pages: 1 ... 11 12 [13] 14 15 ... 123
|
Show Posts
