I know not what I do. I hardly understand the question I ask. So, forgive me
Can the tile buffer be clipped at the 63rd tile instead of wrapping around at the 64th tile? In other words, I'd like the buffer to appear to be 63 by 63 tiles instead of a full 64 by 64 tiles.
Can the tile buffer be clipped at 63x63 tiles?
Moderators: BigEvilCorporation, Mask of Destiny
-
- Very interested
- Posts: 256
- Joined: Tue Sep 11, 2007 9:10 pm
You can clip the tilemap to 63 tiles vertical using fine scroll option in the scroll table and repositioning the screen for a force wrap (it's commonly done on other systems).
As for horizontal clip to 63 tiles, it really depends on what you're trying to do. If scrolling (assuming it does since the display will never show 64 tiles in H40 mode and there isn't a H64 mode), then you adjust the point to where you write in the tilemap. The only downside is that you have to constantly update the tilemap as it is scrolling (as opposed to just updating the whole thing once, and scroll it and let it wrap without ever touching it), but this is normal most scrolling engines.
As for horizontal clip to 63 tiles, it really depends on what you're trying to do. If scrolling (assuming it does since the display will never show 64 tiles in H40 mode and there isn't a H64 mode), then you adjust the point to where you write in the tilemap. The only downside is that you have to constantly update the tilemap as it is scrolling (as opposed to just updating the whole thing once, and scroll it and let it wrap without ever touching it), but this is normal most scrolling engines.
Thank you for the informative responses!
In the compiler I'm using it's actually faster to draw the tiles in as large chunks as possible. Not because it's highly optimized but exactly the opposite. If I use traditional scrolling engine techniques the smaller but more frequent operations kill performance. My personal challenge was to use as few assembly hacks and prefer built-in routines as much as possible.
Why? Same reason people use Brainf_ck!
My thinking was to treat the tile buffer as 21x21 tile sections. When the player *just* traverses the border of a section the back 21x21 section is off screen and can be updated to the next piece of world map. Alas, with 64x64 tiles there's always a gap.
Thanks for taking my ridiculous question seriously :p
In the compiler I'm using it's actually faster to draw the tiles in as large chunks as possible. Not because it's highly optimized but exactly the opposite. If I use traditional scrolling engine techniques the smaller but more frequent operations kill performance. My personal challenge was to use as few assembly hacks and prefer built-in routines as much as possible.
Why? Same reason people use Brainf_ck!
My thinking was to treat the tile buffer as 21x21 tile sections. When the player *just* traverses the border of a section the back 21x21 section is off screen and can be updated to the next piece of world map. Alas, with 64x64 tiles there's always a gap.
Thanks for taking my ridiculous question seriously :p