Calculator Community > TI-BASIC
Collision Detection Explained
Radical Pi:
Aww, I was hoping you had some kind of great tilemap compression-via-better-data-type routine. I'm sure everyone could use something like that ;)
meishe91:
What do ya mean exactly? Maybe I could try making one :P
DJ Omnimaga:
Well at least it is quite good so far. Compression would be cool, though, altough it might be a bit slow for people who want their games to load map fast and take longer to edit maps, since you would need to decompress them, edit them, recompress them, debug, and repeat. This is the reason why Illusiat 13 won,t use any compression for string maps. Plus the task of compressing, when you got 800 areas in your game (which is the case of Illusiat 13), and boolean logic scattered among them, can be a major pain. I guess it depends what kind of game you are making, though.
Also, for those who use instring( for collision detection, while it is much smaller, it can be considerably slower than checking the map character type
Radical Pi:
meishe91: I guess something like this... Imagine you're storing your 8x16 map in a matrix. That's 1163 bytes, but it can hold a huge amount of different possible tiles in any space (How many digits of accuracy can you get on a number? Yeah, a lot), but you probably won't be using that many different kinds of tiles. So consider a string, length 8x16=128 = 139 bytes. That string can have up to (however many different characters you can access) different tiles.
None of that really matters for 8x16 maps, because all the possible ways to store it are still simple and small. But what about, say, a 50x50 map? What's the most efficient way of storing that? And what's the fastest way of accessing it during the program, if it's different than how it's stored?
See what I'm saying?
meishe91:
Unfortunetly...no...:( Sorry, I'm just not following what you said very well.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version