Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 24, 2011 8:51:53 GMT -5
The main reason for Sonic using map-chunks is that the levels aren't square, so it's a good way to prevent having a bunch of "unused" data. If your levels are square ( most RPG's for example ), this approach only adds overhead and should be avoided. Chunks are what I'm using so far. I fill the tile buffer with 3x3 chunks of 21x21 tiles. Each area will consist of an array of 21x21 tile chunks. Hopefully I can fit in: Each area will be filled with generic chunks designed to suit a theme (forest, town, cave, etc..) Each of these chunks will have pseudo random number generated accents (flowers, rocks, etc..) Finally, certain chunks will have hand placed customizations to suit the area design. Things like entrances to dungeons and other location specific additions. Another thing I hope is that this combination of generic -> random -> customized can extend to larger and larger parts of the game world. Such that, not only do several screen sized locations use this technique but also territory sized and country sized map data. 2D Daggerfall would be a great thing to aim for! P.S. @moon: Not ignoring your advice on wording for bit-shifting. I just have to edit the BasiEgaXorz Command Reference to put your suggestions in
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 24, 2011 9:19:01 GMT -5
I fill the tile buffer with 3x3 chunks of 21x21 tiles. Hopefully not at once. Re-usability is another good motivation for using "chunks". However, go with chunks of 32x32 or 16x16 cells instead of 21x21. You'll thank me later
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 24, 2011 10:22:48 GMT -5
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 24, 2011 11:36:55 GMT -5
Then your drawing routine is busted
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 24, 2011 12:13:57 GMT -5
Then your drawing routine is busted I was talkin' about just using the SCROLL command. 1. Player sprite in middle of screen crosses left border between chunk A and chunk B. 2. Chunk B gets drawtiles done on it changing it to the next leftmost area. 3. Player stays in middle of screen and the tile buffer gets scrolled to appear like he's moving left. Would it be done differently with 32x32 chunks?
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 24, 2011 12:55:42 GMT -5
Ehm, it sounds like you're drawing a entire 21x21 map chunk at once? You never ever ever want to do that ( while your display is active ) .. unless there is absolutely no other way, like in Zero Tolerance.
|
|
|
Post by sega16 on Jun 27, 2011 9:23:02 GMT -5
21x21 not a good idea here is why. The plane buffer for plane a and b is 512x512 pixels or 64 x 64 tiles 64/21=3.0476 and so on you would want to do someone thing that is divisible by 64 so pretty much 2,4,8,16,32,64
|
|
cdoty
Moldy Popcorn
Posts: 38
|
Post by cdoty on Oct 17, 2011 23:15:27 GMT -5
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Oct 21, 2011 10:34:18 GMT -5
Thanks for the article link cdoty! It's very cool to get a reply from Mr. Frog Feast =) I decided to go 16x16 tile for map data. In order to make sure updated map chunks are drawn off-screen I reduced the resolution to 32 cell mode. I had hair pulling experiences with tile buffer corruption and the drawtiles command. Now I use a sub-routine that does bounds checking before putting a tile on-screen. If I do ever go GBA I'd be forced to go DragonBASIC. Assembly and C aren't for me
|
|