Smoothscrolling Tilemap
Moderator: MaxCoderz Staff
Smoothscrolling Tilemap
Would it be hard to make a smoothscrolling tilemap in Assembly? I know there are some out there but I would like to make my own custom one so I can easily manipulate and understand all the inner workings of it. If someone could help me out or lead me on the right path to creating a smoothscrolling tilemap that would be awesome.
-
threefingeredguy
- Calc King
- Posts: 2195
- Joined: Sun 27 Mar, 2005 4:06 am
- Location: sleeping
- Contact:
-
tr1p1ea
- Maxcoderz Staff
- Posts: 4141
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: I cant seem to get out of this cryogenic chamber!
- Contact:
CrASH_Man's is fast, but it has a lot of restrictions. Also the whole 'pre-rotate the tileset' before drawing gets slow if you have a larger tileset (not to mention the buffer requirements).
There are actually lots of methods for writing smoothscrollers, like shifting screens and filling edge, drawing to a buffer larger than the lcd (1 tile w/h) and shifting that around, pre-rotating tiles ... Recently i wrote a fast mapper that uses a 2KB LUT on a similar principal as the pre-rotation method.
There are actually lots of methods for writing smoothscrollers, like shifting screens and filling edge, drawing to a buffer larger than the lcd (1 tile w/h) and shifting that around, pre-rotating tiles ... Recently i wrote a fast mapper that uses a 2KB LUT on a similar principal as the pre-rotation method.
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."
lol, duno if 100+ FPS is even necessary though XDDwedit wrote:First write your code, then optimize it until it turns into Crashman's routine.
if you use Crash's, you'll have to write your own sprite routines, since the buffers are vertically aligned like the screen. That means that sequential bytes of RAM are in the same COLUMN as opposed to normally being in the same ROW.
ultimately, writing your own routine will probably allow you to optimize and fuse the game engine into the mapper itself so that things work smoothly.
-
tr1p1ea
- Maxcoderz Staff
- Posts: 4141
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: I cant seem to get out of this cryogenic chamber!
- Contact:
CrASM_Man did rewrite one of his fast sprite routines so that it workd with the screen setup required for his mapper. Its v4.0 of his sprite routine.
Last edited by tr1p1ea on Fri 23 Feb, 2007 6:28 am, edited 1 time in total.
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."
How could I spell it wrong with how many times people said it
Actually, the routine requires considerable modification, and is harder to integrate into programs than most routines. I have integrated it in before, so I could help out with anything there.
The first big issue is 256 byte alignment, so I've made a Memory Rearrangement System. It consists of some routines which let you rearrange the saferam of the TI83+ into a nice big 2560 size memory block aligned to a 256 byte boundary. Just run the program with interrupts disabled, and don't use romcalls. If you need to use romcalls, you can call something to undo the memory rearrangement, then re-arrange the memory back again.
The next big issue is that the graph buffer used by crashman's routine is vertical, not the usual horizontal arrangement. This means when you add one to the graph mem address, you get the next row. Add one at the last row to get the next column. So your standard text display code won't work anymore, but you still can use something like bub_font to turn text display into multiple calls of a sprite routine. And sprite routines are faster than the rom's built in text display.
Also, you don't have to directly feed your main tilemaps into the tile renderer. You can instead use a mini-tilemap which holds a little more than a screen's worth of map. When you want to scroll the minimap past its edge, you instead move all the tiles inside over, then update one row or column of the minimap. It may seem silly to use a separate mini-map from the main tilemap, but then you get some benefits, like the ability to have the main tilemap huge and compressed. I did this for the "DW2 Demo" program I made earlier, which lets you move around a 256x256 tile map, but gives a 16x16 map to crashman's routine.
Or you could just use a giant tilemap, for example, reserve 8k of RAM for the map. You can fit a 256x32 tilemap into 8K. (Super Mario 3 on the NES does this The levels can still be compressed, then they get loaded into the giant tilemap, but then you gain the ability to change tiles in the map, and remembering such changes. For example, you could collect coins, break blocks, and the changes wouldn't go away after scrolling off and on again.
Of course, the biggest problem is monster LCD blur, which is basically why I stopped coding for calcs.
Edit: The routine is at http://www.ticalc.org/archives/files/fi ... 17880.html
You will not be using this unmodified.
The first big issue is 256 byte alignment, so I've made a Memory Rearrangement System. It consists of some routines which let you rearrange the saferam of the TI83+ into a nice big 2560 size memory block aligned to a 256 byte boundary. Just run the program with interrupts disabled, and don't use romcalls. If you need to use romcalls, you can call something to undo the memory rearrangement, then re-arrange the memory back again.
The next big issue is that the graph buffer used by crashman's routine is vertical, not the usual horizontal arrangement. This means when you add one to the graph mem address, you get the next row. Add one at the last row to get the next column. So your standard text display code won't work anymore, but you still can use something like bub_font to turn text display into multiple calls of a sprite routine. And sprite routines are faster than the rom's built in text display.
Also, you don't have to directly feed your main tilemaps into the tile renderer. You can instead use a mini-tilemap which holds a little more than a screen's worth of map. When you want to scroll the minimap past its edge, you instead move all the tiles inside over, then update one row or column of the minimap. It may seem silly to use a separate mini-map from the main tilemap, but then you get some benefits, like the ability to have the main tilemap huge and compressed. I did this for the "DW2 Demo" program I made earlier, which lets you move around a 256x256 tile map, but gives a 16x16 map to crashman's routine.
Or you could just use a giant tilemap, for example, reserve 8k of RAM for the map. You can fit a 256x32 tilemap into 8K. (Super Mario 3 on the NES does this The levels can still be compressed, then they get loaded into the giant tilemap, but then you gain the ability to change tiles in the map, and remembering such changes. For example, you could collect coins, break blocks, and the changes wouldn't go away after scrolling off and on again.
Of course, the biggest problem is monster LCD blur, which is basically why I stopped coding for calcs.
Edit: The routine is at http://www.ticalc.org/archives/files/fi ... 17880.html
You will not be using this unmodified.
You know your hexadecimal output routine is broken when it displays the character 'G'.
-
Delnar_Ersike
- Sir Posts-A-Lot
- Posts: 153
- Joined: Mon 22 Jan, 2007 3:05 am
- Location: UNATCO Headquarters
Actually, there was a GBA cloning library on ticalc.org not long ago. It can do smooth scrolling and makes it easier to set a tilemap. You can find it here:
http://www.ticalc.org/archives/files/fi ... 39478.html
The documentation is in French, but there are some translations of it on Omnimaga. You can find one made by (I think) cartj here:
http://docs.google.com/View?docid=dcd4c ... _published
http://www.ticalc.org/archives/files/fi ... 39478.html
The documentation is in French, but there are some translations of it on Omnimaga. You can find one made by (I think) cartj here:
http://docs.google.com/View?docid=dcd4c ... _published
Yeah Delnar_Ersike but I am usually not good at learning someone else's code and usually(like now) do not have the time. I like to know the inner workings and I want to fuse my smoothscrolling tilemap with The Massacre engine to support efficient 2 to 3 frame animations. I usually write a lot of stuff on paper in study halls so that's why I want to make my own.
Summary of how crashman's routine works:
* Pre-shifting. This is where you divide the tile graphics into a left half and right half, each pre-scrolled by the amount of pixels you want to scroll. The first set gets the left half filled and the right half white, the second set gets the right half filled and the left half white. Later each column will have the left side drawn on from one set of graphics, then the right set of tiles drawn on from the other set of graphics.
* The inner drawing loop takes the left half of the column, and ors it with the right half of the column.
Here you can see one of the inner-loops of crashman's code:
LD A,(BC) ;get old graph mem byte
OUT ($11),A ;output to screen
LD A,(DE) ;load from left tileset
OR (HL) ;OR with right tileset
LD (BC),A ;write to graph mem
INC C ;next byte...
INC DE
INC HL ;the code doesn't require use of 16 bit increments, I think it does those for the LCD_BUSY effect.
And where do these register values come from? It stores 8-bit addresses of tile graphics into the tilemap, to avoid multiplying tile numbers by 8, and to avoid adding a base address.
So you require tile graphics data to be aligned to a 256 byte boundary, have the High byte already set, then load the low byte from the tilemap. Genius! The low byte is independent of whether it's the left graphics set or right graphics set.
* Pre-shifting. This is where you divide the tile graphics into a left half and right half, each pre-scrolled by the amount of pixels you want to scroll. The first set gets the left half filled and the right half white, the second set gets the right half filled and the left half white. Later each column will have the left side drawn on from one set of graphics, then the right set of tiles drawn on from the other set of graphics.
* The inner drawing loop takes the left half of the column, and ors it with the right half of the column.
Here you can see one of the inner-loops of crashman's code:
LD A,(BC) ;get old graph mem byte
OUT ($11),A ;output to screen
LD A,(DE) ;load from left tileset
OR (HL) ;OR with right tileset
LD (BC),A ;write to graph mem
INC C ;next byte...
INC DE
INC HL ;the code doesn't require use of 16 bit increments, I think it does those for the LCD_BUSY effect.
And where do these register values come from? It stores 8-bit addresses of tile graphics into the tilemap, to avoid multiplying tile numbers by 8, and to avoid adding a base address.
So you require tile graphics data to be aligned to a 256 byte boundary, have the High byte already set, then load the low byte from the tilemap. Genius! The low byte is independent of whether it's the left graphics set or right graphics set.
You know your hexadecimal output routine is broken when it displays the character 'G'.