Map loading & scrolling: is my theory right?

SGDK only sub forum

Moderator: Stef

Post Reply
KillaMaaki
Very interested
Posts: 58
Joined: Sat Feb 28, 2015 9:22 pm

Map loading & scrolling: is my theory right?

Post by KillaMaaki » Wed Jan 18, 2017 10:10 pm

While waiting for help with my PCM code, I also want to work on my map loading & scrolling. I'm sick and my mental capacity is sort of shit right now, so I want to get a second opinion on whether what I'm thinking is correct.

So, I'm thinking of having my tilesets be stored as paletted PNGs storing 16px chunks, which my custom content tool as mentioned in the other thread converts into a dump of 8px tiles (each 16px chunk is converted into four 8px tiles, laid out from left to right, top to bottom). Then my map file stores the 16px chunk indices (probably going to write a converter for Tiled maps, and in Tiled just have it treat the tileset as a 16px tileset), which at runtime when I go to load a map is converted into SGDKs Map structure, having it convert each chunk index into actual tile indices (so for example if my game map was 32x32 chunks, the resulting Map structure would be 64x64 actual tiles).

Then, to implement scrolling, I can reference this code: https://github.com/kcowolf/GenScrolling ... llingMap.c
So that the idea is I store buffers for rows and columns, and when the camera moves by one tile I retrieve each tile of the row or column from the Map structure into the appropriate buffer and then DMA that into a 64x64 tile plane in VDP.

The nice thing is that I actually plan to only support moving a tile at a time (old school JRPG style), so I can probably simplify the scrolling code to just load a new row/column when the routine to move by one tile is triggered (rather than checking the camera's pixel position).

Does this sound correct and reasonable? I think it's probably sound but then again I've got a bad mental fog right now and I'm more used to working with Unity/C# than with C and SGDK.

djcouchycouch
Very interested
Posts: 672
Joined: Sat Feb 18, 2012 2:44 am

Re: Map loading & scrolling: is my theory right?

Post by djcouchycouch » Thu Jan 19, 2017 12:28 am

KillaMaaki wrote:Does this sound correct and reasonable?
Yep! Try it out. See how far you get.

User avatar
Stef
Very interested
Posts: 2627
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Map loading & scrolling: is my theory right?

Post by Stef » Thu Jan 19, 2017 3:54 pm

That sound good to me as well :)
At some point i plan to add some basic "scrollable level" features in SGDK but that will take time :p

KillaMaaki
Very interested
Posts: 58
Joined: Sat Feb 28, 2015 9:22 pm

Re: Map loading & scrolling: is my theory right?

Post by KillaMaaki » Thu Jan 19, 2017 9:33 pm

It'd definitely be neat, although honestly probably not strictly necessary. Having to write my own scrolling code means I can also optimize it for my specific use case anyway ;)

User avatar
Stef
Very interested
Posts: 2627
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Map loading & scrolling: is my theory right?

Post by Stef » Fri Jan 20, 2017 9:38 am

Yeah this is definitely not a must have feature because as you said, a lot of people will prefer to develop their own engine adapted and optimized for their needs. Still a generic engine could help for beginner :)

Miquel
Very interested
Posts: 180
Joined: Sat Jul 30, 2016 12:33 am

Re: Map loading & scrolling: is my theory right?

Post by Miquel » Sat Jan 21, 2017 11:24 am

- You are working with less than 4 palettes of 15 (16) colors, so directly working with one file and then transforming to <4 palettes doesn't work, unless you give some other input, or bring with several files, or some other custom solution.

- (A niggly thing:) If you plan to share method/code for tiles and sprites: better from top-to-down first.

- Having a separate object (variables) representing the camera or obtaining it from the main character is basically the same, go for the camera option, is a more flexible option. (It's the same effort just try either option)
In fact in some situations you will need a camera, no way avoiding it, for example corners (or you can extract it, but is just the same). The advantage is, with a camera working on it's own, games feel much more solid and enjoyable to the eyes.

- Regarding scrolling the planes, moving at 60*8 pixels per second is faster than eye can catch, anyway uploading to vid mem N columns/rows is just calling N times the same function.


But the thing that worries me the most is you are not thinking about collision info. It's not he same as graphical data (unfortunately) but I'm adamant it should be as intertwine as possible.
Are you talking about the "monolith"? I'm in communications with them, just tell me the question or ask yourself. If it's about it's movement: yes it really moves, but at a tremendous speed! From the Sun to Jupiter in less than 2 seconds!

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest