In these days quite a lot of things happened in the development area.
While chatting with the user Trefall , many things were cleared, the first one is that the names i’m using are totally wrong.
So Viewport is wrong, the problem is that i have no idea on how to name it. for the moment
In the last post i was writing about the map generation, and handling the map.
In my case, i want the player to be in a large environment,not a dungeon-like system, not because i don’t like that, but simply because my objective would be to model a city with the correct proportions.
One of the problem of this approach is the map size: i cannot load a full map in memory.
After the usual chatting time, the correct approach was decided: i had to create a viewport.
Act I – The map
I wanted to see something on the screen: what i was doing.
One of the things i developed , thanks to my friend Jak , was a fac-simile of a town: with some random “streets”.
This is very far from a decent map. But for the test purposes i have in mind it’s more than enough.
I had a map to show.
First random map
This isn’t based on anything, simply split the map in halves and decides randomly if creating a street horizontally or vertically.
Random “noise” could be added to move the streets from the exact middle point.
But for now it’s ok as it is.
Act II – The viewport
A viewport is a thing that handles the camera and the maps close to the player.
addendum: viewport is a wrong name.
A camera (or screen) is a thing that shows the player the exact amount of tiles that the window permits.
So if the window is 20×20 chars, the camera(or screen) is an object which selects and shows 20×20 tiles, given a starting x,y coordinate.
My viewport will keep in memory 9 maps, disposed as a keypad , and the player is in the middle one ( the 5).
When the player moves east,for example, 3 new maps are loaded and added to the right side, while the 3 leftmost (1,4,7) maps are unloaded.
This had a lot of consequence: every map must be “positioned” in a coherent world-system coords ( in opposition to local-map coords ) , therefore joining the map means that the next one must be positioned with the correct coords.
This also means that, if the player, from the center travels N-E , at a certain point, the camera will have to load tiles from the maps 5,6,8 and 9.
This caused me some troubles.
The viewport must handle this stuff too, therefore i lost a lot of time on thinking how to “join” the maps.
Solution: I didn’t.
Having the way to transform global coords to local map coords, i had my engine simply iterate all the tiles needed by the camera.
I’m not fully satisfied with this approach: for each tile i have to find in which map it is by doing divisions, and therefore this is not the best for optimization purposes.
After thinking about it i used the general purpose strategy of “who cares. I’ll check it if i’ll need it”.
Act III – Moving the camera
Thanks to the keyboard handler i developed a couple of weeks ago, moving the camera has been a task of no more than 5 minutes: with everything set up, the camera moves.
For now it’s been tested just with the middle map, but i’ll soon be loading all 9 random maps and check if everything works.
More stuff to do!