That looks pretty awesome. I guess this is a redraw every frame aligned map ?
Thanks! And I do not know what you mean. It redraws whenever an animated tile goes to its next frame and it only draws to 8x8 regions (so there are 96 tile locations on the screen). For my purposes, this is enough (I will be using smooth-scrolling in the way Pokémon games did it by scrolling in a whole tile, 1 pixel at a time). However, for a project such as what Hot_Dog had in mind, it would be useful to have an option for drawing the map at any pixel offset.
Also, I just compared my sprite drawing routine to the one in Axe and my speed estimate was really far off (I massively overestimated how long it would take). Anyways, my method did turn out faster >.>
It's at 6MHz, too The other nice thing about this is that if the interrupt were activated during a BASIC program, it could work (it would slow down the BASIC code significantly, probably). The main difficulty would be in making an interface so that BASIC programs could access the appropriate memory areas, but that could be done with a parser hook.
Anyways, the goal of such a program is to make it very easy and straightforward to use sprites and tilemaps in assembly and I think this makes it pretty easy You don't even need to call the tilemap routine!
I just googled "how fast are sprite drawing routines TI-84+" to see if anybody has already done some calculations when I found this page again and it actually happens to be relevant. I completely forgot about this, but I am glad I found it!
In one of my projects, I have it so that my interrupt routine and the interrupt table are in the app (I know this sounds like a bad idea and I need to be sure not to swap out the page without turning off interrupts). The interrupt is actually what I use to handle LCD updating and drawing the tilemap. All I have to do is write the tileset pointer, tilemap location, width, and height to a spot in RAM, and as well, the current (X,Y) offsets into the map. Then set a flag saying that it is in tilemap mode, and another flag saying that the tilemap needs to be rendered and the interrupt will render it. Since the interrupt is also handling the keyboard, my code uses a bunch of halt instructions, ensuring that the tilemaps are updated smoothly. The other tasks include animating the tiles and if any tiles move to a new frame, the tilemap is automatically updated on the LCD. This is an example code and the screenshot of it:
Continue: call whilekey call loadtestmap moveloop: halt ld a,(curkey) or a jr z,moveloop cp 15 jp z,softreset cp 9 jr nz,testmove testtileevent: jr moveloop testmove: ld hl,(yoffset) ld de,(xoffset) dec a jr nz,$+3 inc hl dec a jr nz,$+3 dec de dec a jr nz,$+3 inc de dec a jr nz,$+3 dec hl ld (yoffset),hl ld (xoffset),de jr moveloop In order to make this code better for more general use, it would have to have the interrupt reside in RAM and make it easy for the user to link their own interrupt code.
I am still working on refining the tilemap routine and sprite routines (as you could probably tell from the Google search). However, here is all of the code in my interrupt currently, as well as relevant subroutines and a little documentation (I didn't have it prepared):
Interrupt: ;4242h push bc push de push hl push af ; interrupt stuff ;Note that I am using push/pop instead of the exx and ex af,af' ;instructions so that I can use shadow registers for other ;intensive routines ; Tasks to handle: ; Sound ? ; LCD refreshing, if a specific flag is set ; Key ports
call GetKey ld hl,843Fh ;valid for the 83+/84+ calcs. This is where the OS stores its key values, too ld (hl),a inc l cp (hl) jr z,LoadSameKey ld (hl),a inc l ld (hl),128 jp KeysUpdated LoadSameKey: inc l dec (hl) jr z,ReloadKey xor a jp KeysUpdated ReloadKey: ld (hl),32 KeysUpdated: inc l ld (hl),a ;key debounced bit mapmode,(iy+textflags) jr z,mapupdated ld hl,8000h ;this is where I have an LUT to store the current sprite frames and timers AnimUpdLoop: dec (hl) jr nz,NextAnimUpd inc l set drawmap,(iy+asmflags) ld bc,Tiledata ld e,(hl) ld d,0 ;DE is the tile number ex de,hl add hl,hl inc l add hl,hl ;tile data is 4 bytes, .dw loc \ .db new \ .db time add hl,bc ld a,(hl) ld (de),a dec e ld l,a ld h,0 add hl,hl inc l add hl,hl inc l add hl,bc ld a,(hl) ld (de),a ex de,hl NextAnimUpd: inc l inc l jr nz,AnimUpdLoop MapUpdated: bit forcedkey,(iy+asmflags) jr z,EndInterrupt ;code for key macros EndInterrupt: bit drawmap,(iy+asmflags) call nz,Tilemap bit lcdupdate,(iy+asmflags) call nz,UpdateLCD ld a,8 out (3),a ld a,10 out (3),a ld a,15 out (3),a pop af pop hl pop de pop bc ei ret TileMap: res lcdupdate,(iy+asmflags) ld hl,(yoffset) ld (ycur),hl ex de,hl ld bc,(mapwidth) call DE_Times_BC ld de,(tilemapdata) add hl,de ld de,(xoffset) add hl,de ld (tileptr),hl ld hl,(mapwidth) ld bc,-12 add hl,bc ;amount to add to pointer every Y increment ld (adjust),hl xor a ld (y),a yloop: xor a ld (x),a ld hl,(xoffset) ld (xcur),hl xloop: ld hl,(xcur) ld bc,(mapwidth) or a sbc hl,bc jr c,$+7 ld hl,blacktile jr drawtile ld hl,(ycur) ld bc,(mapheight) or a sbc hl,bc jr c,$+7 ld hl,blacktile jr drawtile loadtile: ld hl,(tileptr) ld e,(hl) ld d,0 ld hl,curframe add hl,de add hl,de inc hl ld e,(hl) ld d,0 ex de,hl add hl,hl add hl,hl ld de,tiledata add hl,de ld e,(hl) inc hl ld d,(hl) ex de,hl drawtile: ;HL points to the sprite ex de,hl ld a,(y) add a,a \ add a,a add a,a \ add a,a ld c,a ld b,0 ld h,b \ ld l,c add hl,hl add hl,bc add hl,hl ld bc,(DrawBufPtr) add hl,bc ld a,(x) add a,l ld l,a jr nc,$+3 inc h ;HL points to where it gets drawn ;DE is the sprite layer ld bc,12 ld a,8 ex de,hl ; 32 ldi ;128 ex de,hl ; 32 add hl,bc ; 88 inc c ; 32 dec a ; 32 jr nz,$-7 ; 91 ;now we need to increment X,tileptr,xcur ld hl,(tileptr) inc hl ld (tileptr),hl ld hl,(xcur) inc hl ld (xcur),hl ld a,(x) inc a ld (x),a cp 12 jp nz,xloop ld hl,(tileptr) ld bc,(adjust) add hl,bc ld (tileptr),hl ld hl,(ycur) inc hl ld (ycur),hl ld a,(y) inc a ld (y),a cp 8 jp nz,yloop
UpdateLCD: ;(chooses monochrome or 3-level gray based on a flag) ld hl,(primarybufptr) bit gray,(iy+asmflags) jr z,monochrome exx ld hl,89F0h+asmflags ;89F0h is where the OS keeps IY ld a,(hl) ld bc,256*graybitmask+55h xor b ld (hl),a and b jr z,$+4 rlc c
ld de,12 ld hl,(secondarybufptr) exx ld de,12 ld a,20h col3: out (16),a ex af,af' ld b,40h row3: exx ;4 ld a,(hl) ;7 and c ;8 rlc c ;8 add hl,de ;11 exx ;4 or (hl) ;7 add hl,de ;11 bit rvideo,(iy+asmflags) ;23 jr z,$+3 \ cpl ;11 out (17),a ;11 djnz row3 ;13 dec h dec h dec h inc hl exx dec h dec h dec h inc hl exx in a,(16) \ rlca \ jr c,$-3 ex af,af' inc a cp 2Ch jr nz,col3 ret
monochrome: ld de,11 ld a,20h col: out (16),a push af ld bc,4011h row: in a,(16) \ rlca \ jr c,$-3 outi add hl,de jr nz,row in a,(16) \ rlca \ jr c,$-3 pop af inc a dec h dec h dec h inc l cp 2Ch jr nz,col res lcdupdate,(iy+asmflags) ret ;=============================================================== GetKey: ;=============================================================== ;Outputs: ; a is a value from 0 to 56 that is the keypress ; bc is also the key press ; d has a bit reset, the rest are set (this is the last key group tested) ; e is a divided by by 8 ; hl is not modified ;=============================================================== ld bc,0 ;010000 ;10 ld de,$7FFF ;11FF7F ;10 KeyLoop: ; rlc d ;CB02 ;8 ld a,d ;7A ;4 out (1),a ;D301 ;12 inc e ;1C ;4 sub 7Fh ;D67F ;7 ret z ;C8 ;5|11 nop ;00 ;4 in a,(1) ;DB01 ;12 inc a ;3C ;4 jr z,KeyLoop ;28EC ;7|12 dec a ;3D ;4 inc c ;0C ;4 rra ;1F ;4 jr c,$-2 ;38FC ;7|12 ld a,e ;7B ;4 rlca \ rlca \ rlca;070707 ;12 add a,c ;81 ;4 ld c,a ;4F ;4 ret ;C9 ;10 The code I have for setting up the animation LUT (for the tile number and timer) is in this routine:
loadtestmap: ld hl,23 ld (mapwidth),hl ld l,13 ld (mapheight),hl ld l,0 ld (xoffset),hl ld (yoffset),hl ld (ymapcoord),hl ld (xmapcoord),hl ld h,80h ;HL = 8000h, this code loads the 128 tiles and their counters are all set to 1. The next interrupt sets them to 0, and updates them accordingly. xor a ld (hl),1 inc l ld (hl),a inc a inc l jr nz,$-6 ld hl,testmap ld (tilemapdata),hl set mapmode,(iy+textflags) ret
This code is still under construction and I am working out a lot of details. For example, I plan to have 3 layers-- the tilemap, and a masked layer on top of that (for things such as the player sprite and NPCs). I also have been thinking about storing to the graph buffer differently and organising it in columns, but I am still in the process of analysing the respective performance gains and hits. (which is what the original Google search was for). If anybody knows, I have 3297 t-states for my worst case drawing of an 8x8 sprite with XOR logic and 236 t-states for drawing a tile ^^. Shifting the LCD for smooth scrolling is what I am really worried about.
TileData: tile_blank: addtile(blank, tile_blank, 0) tile_flower1: addtile(flower1,tile_flower2,16) tile_grass: addtile(grass, tile_grass, 0) tile_bush: addtile(bush, tile_bush, 0) ;a small tree (8x8) tile_vine: addtile(vine, tile_vine, 0) ;instead of that silly tree to cut down tile_water1: addtile(water1, tile_water2,10)
I have some potential bugs and suggestions: I tried to upload an image and it is instead recognising it as a duplicate. I think it is because the starting frames are identical.
Suggestions: The ability to delete ore replace old images. I am currently keeping a project updated in my signature with a single screenie, so it would be cool to be able to update it in the image uploader and have it updated in my signature. I now have a few duplicate uploads cluttering the "previous uploads" which is why I was suggesting the delete option.
Hmm, you cannot get CopyProg to work? What isn't working? I tried the line reading and that works, and copying from one var to another worked for me, as well as the GetName instruction works for programs and whatnot (I just tested it and there is an issue with strings and whatnot, but it still returns strings in an appropriate format).
I am starting to change some things around, like the look-up routine to find a function. To speed up the search a little in most cases, I had the names stored alphabetically. Now I have a 52-byte LUT to jump to a given spot in the table based on the first letter of the function.
I was also thinking that it might be a good idea to store folders and files alphabetically. While that may sound like a pain to actually code, I realised earlier that it should actually be quite easy and it would make searches faster. Instead of checking every file in the folder to find out it doesn't exist, it only needs to start where the first letter matches and go until the first letter no longer matches. This will mean that users can get an alphabetically sorted list of names. This should make it possible to have folders indexed in a similar way as how the function list is indexed. These all together should make lookup speed a bit faster than the system that TI uses and long program lists will be able to load just as quickly as short ones. (tl;dr : files and folders can be accessed faster and new files can be created faster -- the code is already there)
I also wrote the brunt of a routine to tokenise source codes. This doesn't help much for speed, yet, but if control structures like loops are implemented later, this should greatly improve speed (by a gazillion-fold).
Hopefully all of this will make it easier to add variable support
DivAHLby10: ld bc,$180a sub a DAHLLoop1: add hl,hl rl d rla cp c jr c,DAHLLoop2 sub c inc l DAHLLoop2: djnz DAHLLoop1 ret That saves only 3 bytes and 12 cycles. If you want to squeeze a little more speed out of the routine without fully unrolling it, you can unrll the first 3 iterations since 3 bits will never be >=10 :
DivAHLby10: ld bc,$150a sub a add hl,hl \ rl d \ rla add hl,hl \ rl d \ rla add hl,hl \ rl d \ rla DAHLLoop1: add hl,hl rl d rla cp c jr c,DAHLLoop2 sub c inc l DAHLLoop2: djnz DAHLLoop1 ret The cost is 12 bytes and you save only 87 cycles. I am trying to think of a better approach to get speed out of this.
EDIT: This routine gets a minimum of 966 tstates, average of 984.5, and max of 1002, making it almost 300 t-states faster at its slowest than the previous routine at its fastest. The downside is that it is 35 bytes, compared to the 15 it could be:
Show Posts
The other nice thing about this is that if the interrupt were activated during a BASIC program, it could work (it would slow down the BASIC code significantly, probably). The main difficulty would be in making an interface so that BASIC programs could access the appropriate memory areas, but that could be done with a parser hook.
You don't even need to call the tilemap routine!
). I definitely enjoy doing this kind of coding, though!
