|
Post by Syniphas on Jan 21, 2009 0:24:31 GMT -5
oompa loompa, do it fgt
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Jan 21, 2009 3:16:00 GMT -5
hey all, what's everyone's preferences on how maps are arranged? like, do people prefer tiles that are ordered from left to right and then top to bottom. i have a routine for left->right, then top->bottom, but no top->bottom, then left->right what's fgt?
|
|
|
Post by Tiido on Jan 21, 2009 9:35:47 GMT -5
fgt means you prefer the hole in the rear end of a man
|
|
|
Post by Mairtrus on Jan 21, 2009 11:17:07 GMT -5
I think that Left->Right, then Top->Bottom is the best choice. Is the cleanest way to work with the maps. My engine uses this way.
|
|
|
Post by ScroGer on Jan 21, 2009 11:27:39 GMT -5
I think that Left->Right, then Top->Bottom is the best choice. Is the cleanest way to work with the maps. My engine uses this way. agreed!!! ;D
|
|
|
Post by ScroGer on Jan 21, 2009 11:35:23 GMT -5
haven't touched the code in years, but i could work on it (just like what i did with sgtd). optimized octree was the mainstream back then too BTW.. thanks again for updating SGTD, not having to manually fill in the surrounding pixels makes things 95% faster and funner
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Jan 23, 2009 15:30:36 GMT -5
what's the typical map size of a sonic 2/3 map? i'm asking because i'm trying to decide whether to always have map word sizes either 8 bit, or 16 bits (2 bytes). 2 bytes for one map cell would speed up the routines (i don't have to do moveq.w #0,d0), but would require more memory. 2 bytes would also allow for more detailed maps as well (with 8 bits, you're restricted to only 256 different tiles for your map, and you won't be able to use hardware h/v flipping, and different palettes) also, did the sonic games ever compress the maps? it seems like the limiting factor to the sonic games were the map sizes i'll call these routines blast processing haha, since that what it seems like (eg BLAST_SCROLL, BLAST_DRAWTILES, BLAST_ONWALL). btw, i am working on the routines a you can see , just be patient. i'll release it......... when it's done .
|
|
|
Post by Mairtrus on Jan 23, 2009 17:28:10 GMT -5
In Sonic 1, the map is stored on blocks of 256x256, which in turn refer to blocks of 16x16 that refer to the tiles in the VRAM. In Sonic 2 is the same, except that the blocks are of 128x128. Both only drawn the 16x16 blocks as the camera change. Those block are 8 bytes long (2 per each tile), and they are stored on the block as 2 bytes per each one ($400 max, 10 bits per each one, the higher 6 bits are used for store variables used by the collision engine). And yes, the blocks use a huge amount of memory; 41984 bytes to be exactly (more that the half of the RAM!! )
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Jan 24, 2009 2:04:11 GMT -5
thanks for the info Mairtrus i think i've made a decision on how i'm going to implement these new routines (well, i've already made the decision a long time ago , i'm just a little late on the forums ): - Maps will be ordered going from top->bottom, then left->right. I know that it isn't the "norm" to do this, and I like left->right, then top->bottom better, but the big benefit of the other way is speed. It saves me a lot of cycles reading from memory, and then writing to the VRAM when drawing the tiles that are on the left and right borders of the map because I can use longword writes. I think that for most games, there will be more movement from left to right, rather than top to bottom. There's also a possibility to use fast DMA copying to speed things up, but I think using DMA isn't going to help at all, since the routines will only be writing 80 bytes of data . DMA benefits when I'm writing more than 128 bytes or so because of the setup time - Tiles in a map will be represented by 2 bytes. I guess if people want huge maps (megabytes big), they'll have to partition the map into sections, and then compress those sections into rom. the partitions have to fit in RAM. Memory is cheap now these days, so uncompressed maps in rom shouldn't be any problem (like 2 megabytes flash carts should only cost at the most $10 now to produce) I'm working on collision detection routines . Having all these routines in assembly, and then easily accessible by basic should really speed up games. games could then spend their time worrying on AI, rather than shoving as many bytes as they can through the video controller
|
|
|
Post by Tiido on Jan 24, 2009 2:30:26 GMT -5
I use top -> bottom and left <-> right, with RLE like decompression on the fly, maps are stored in vertical strips to say so, the taller the map, the more CPU power and memory is needed to display the map.
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Jan 24, 2009 3:34:32 GMT -5
oh wow, i never thought about RLE compression at first. i think i'll try to implement RLE compression on the fly as well (as a second routine), that sounds like a really good idea because most maps have lots of empty space
|
|
|
Post by Syniphas on Jan 24, 2009 19:46:04 GMT -5
i think that the only thing that needs fixing in imagenesis is changing the output from DATAINT to DATA, else the tiles get some nasty spacing between each one, and there's also this problem that if you use more than 255 tiles, you need more than one tilemap (I know it because I had to do that for the Airstriker 2 title screen, pain in the ass but was totally worth it), but that might also be a BEX problem. Well, you're the guy who knows it, just go and fix
|
|
|
Post by ScroGer on Feb 26, 2010 5:29:16 GMT -5
good thread
|
|
|
Post by Alex Khan on Mar 2, 2010 0:21:39 GMT -5
STARGASM!!! Thanks Mairtrus! )
|
|
|
Post by Alex Khan on Mar 3, 2010 9:14:23 GMT -5
Free Source Code for Engine ... When hehehheeh When ? When ?
|
|