Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Hot_Dog on November 13, 2012, 06:06:11 am
-
How much scrap RAM is needed to use Jim E's tilemapper? Does it make a difference if I simply redraw the map every time?
-
Hmm, what is "Jim E's Tilemapper" ?
-
It's the tilemapper Jim e wrote, it's fast and can handle large jumps (from 1 pixel to... i dunno how many, maybe 255?). Hot_Dog, i was under the impression that it redrew the map every time, i dunno how else he would've done the parallax scrolling demo with all the animations. I've never actually used it and it's been ages since i looked at it, do you have a link to it somewhere?
-
It's the tilemapper Jim e wrote, it's fast and can handle large jumps (from 1 pixel to... i dunno how many, maybe 255?). Hot_Dog, i was under the impression that it redrew the map every time, i dunno how else he would've done the parallax scrolling demo with all the animations. I've never actually used it and it's been ages since i looked at it, do you have a link to it somewhere?
Unfortunately I don't. I do know that you can redraw the map every time or simply have it scroll (because it uses a buffer)
-
Jim's mapper uses a buffer for the sides, right? (to scroll in from left/right) I assume that means you need gbuf + an extra 64 bytes (8x8) or 128 bytes (16x16). It's probably all contiguous though.
Btw, i found this:
http://web.archive.org/web/20061010131750/http://www.revsoft.org/phpBB2/viewtopic.php?t=423&postdays=0&postorder=asc&start=75
I don't know if that's how the final version was handled but it seems like animated tiles are redrawn every frame but everything else is left alone. I think redrawing the entire map every frame would give you a more even frame rate and would still leave you with a nice speed, but i dunno.
Btw, i also found this quote:
When I want to scroll my code calls certain functions like this depending on the number of pixels to move
1: Scroll_Left_1
2: Scroll_Left_1,Scroll_Left_1
3: Scroll_Left_4,Scroll_Right_1
4: Scroll_Left_4,
5: Scroll_Left_4,Scroll_Left_1
6: Scroll_Left_4,Scroll_Left_1,Scroll_Left_1
7: Shift_Bytes_Left,Scroll_Right_1
Any value greater than 8, I simply shift the bytes. Scrolling 4 bytes I make use of the RRD and RLD opcodes.
The data in the blank areas is then filled with an optimized tile drawer.
EDIT: Grammar
-
From what i recall Jim's mapper prerotates the tileset for speed. It would require RAM proportional to how many tiles you had in this case.
Im sure i have it at home, ill look when i finish work.
It works on the same principal as DWedit's mapper, but Jim added layers etc.
EDIT - Didnt calc84maniac write a layered mapper as well?
In the past ive used a 2KB LUT to save on having to rotate each tile byte, basically each combination of 0-255 prerotated. Then just mask out the bits you dont need when copying. You could save on the masking with a 4KB LUT but that might be overkill for the benefit.
-
Was it a tilemapper using the Revsoft grayscale package?
-
tr1p1ea, how do you get a LUT of 2kb? If each tile is 8x8, 256*8=2048, and that's just the basic tiles, non-rotated... CrASH's mapper did something similar, too, i believe (prerotating the tileset).
-
I think he's prerotating all possible values from 0-255, not the tileset itself.
-
Ahhh that makes much more sense. That's clever :)
-
What I usually do, which saves a bunch of memory, is use SMC to generate a rotation of A by an arbitrary amount. The amount of rotation doesn't change for the entire frame, assuming the map is a multiple of 8 pixels wide. Basically I reserve 4 bytes and copy a 4-byte chunk from RRCA \ RRCA \ RRCA \ RRCA \ NOP \ NOP \ NOP \ NOP \ RLCA \ RLCA \ RLCA, which covers any rotation amount in 16 clock cycles.
-
Thats how my sprite routines usually work (if its a project that doesnt use a LUT).
-
That's exactly what i do, too :) I rotate the screen in my fastcopy routine, so my main mapper is really small/simple since it's always drawing aligned tiles. It makes layers pretty easy, but i guess parallax scrolling isn't really possible with my mapper.