, , ,

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

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).

7 8 9
4 5 6
1 2 3

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!