# Mapmaking Discussion & Philosophy (WIP/Critique) > Software Discussion >  Tilesystem

## CRasterImage

http://members.cox.net/shawnriordan/tilesystem.htm

This is a program I wrote a couple years ago.   

The basic idea is:  You create maps using image tiles that are defined in a tileset.   A tileset is an XML file (a text file) that has links to a bunch of JPG or PNG image files.  The map can then be exported to an image.

It was originally used for designing maps for Doom: The Boardgame.   Then I made a half-hearted attempt to create a tileset for Space Hulk.  Which I later pulled down, since it wasn't finished.   

Others have used it to create tilesets/maps for the Descent boardgame and similar endeavors.   The most notable of which is this:
http://www.muinimula.de/Muini/de/2nd...ystem-3_x.html

These guys have cataloged all the hallways and rooms produced by the DwarvenForge company.   They make sculpted terrain.   The fans using the software have created map-like tilesets for all the parts.   Plus photo-based tiles for most of the parts.   Example:



The program has an OpenGL rendering mode.   Something most modern video cards can handle.

It is a free program and I am open to suggestions from the community.  I worked on several features with the DwarvenForge enthusiasts.

One thing I think it could do better is:  Make it easier for people to add, remove or edit tileset entries.   Right now, you have to edit the tileset file by hand.  Which means there is a learning curve and a chance to mess things up.   I have often contemplated creating a tileset editor.

----------


## CRasterImage

Here is a pic of the Space Hulk tileset I was working on:
http://www.shackpics.com/viewer.x?fi...e09ugdvzas.jpg
(I couldn't get the IMG tags to display it.)

----------


## Steel General

First off...Welcome Aboard!

That program of your definitely has some potential.

Also, you can embed files directly in a post by clicking on 'Go Advanced' and clicking the 'Manage Attachments' button, that way you don't need to worry about the <IMG> tags.

----------


## CRasterImage

Ah, thanks.  I'll keep that in mind for the next time.

Some of the ideas I have considered for the future:

- Create an API that allows multiple instances of Tilesystem to be synchronized over the internet.   Allowing a map to serve as a game board for gaming.

- Add lighting with bump maps, height maps and specular properties.  This is something I have already worked on.  But I need to rethink the rendering logic so that it will work on lower end machines.  

It would be cool to be able to move your guys around with torches in their hands.   Illuminating the scene properly.   

The big problem with such an idea is:  Making Map tiles and objects and figures would require the artist to also create heightmaps for each.   This is no easy task and may be more than most people can chew.

----------


## ukgpublishing

Thats a pretty damn cool program, and would be especially useful to anyone who has a good set of tiles already. The use of XML is nice too, with the help file giving me all I need to create my own sets.

To be honest this is probably better than some commercial mapping packages I have seen, especially for the none artist mapper who just wants to throw a map together quickly. The key of course would be having a good selection of quality tiles. 

I may have to play with this  :Smile: 

Nice opening contribution.

John

----------


## CRasterImage

Thanks!   I have been considering some of the features that the professional programs have.  Like a vector region that is filled with a repeating pattern.   Haven't made up my mind about it though.

For a demonstration of what I mean about lighting, here is a screenshot of the Space Hulk tileset back when I had lights, bump mapping and height mapping implemented:

----------


## CBDroege

That's really great looking. Is the program 'understanding' the difference between walls and floors for dynamic lighting, or is it something else?

----------


## Redrobes

Interesting app (or apps plural I think) you have there. I write a similar one with text based tile defs and opengl front end. I should have gone xml too but I didn't think I needed the full potential of it - so far I haven't needed any more than some simple params but there are some things I could expand on with a more complicated definition. Will be interesting to see more of your app and how it progresses.

----------


## torstan

You should definitely check out maptool - a program that allows you to do very similar things with light and shade. It has different coloured light sources and vision blocking areas built in and allows areas to be revealed/hidden depending on what the lighting conditions are. I'll try to put together a screenshot later today when I'm not at work. The code is open source so it may be possible to look at that for some of the structure in this -  know that the lighting calculations were one of the aspects the developer (trevor) spent a LOT of time on, so if you are tackling the same problem this might avoid the hassle of reinventing the wheel.

Currently it does not do 3D - as you say it's a bit of a headache for people to do height maps when creating their maps.

----------


## CRasterImage

Every image (be it floor tile, wall tile, door, figure) includes addtional images.   

- One image is the color image you normally imagine.

- Another image is the "height map".  This is a greyscale image where each pixel describes a height.   In this case, black equals a height of 0.  While white equals a height of about 8 feet.

- Another image is the "bump map".  This is an image where each pixel describes the angle of the surface at that point.  X,YandZ data are encoded as R,Gand B values in the image.   Technically, this image could be deduced from the height map.  But I had it setup so the artist had to generate it manually.

- Yet another iamge is the "specular map".  This is greyscale image where black (0) = a matt surface.  Rough like cement.  Not shiny.  While white (255) = shiny surface.  (like metal, or a polished wood, or water).  So you could give each pixel a specular propery in the range from 0 to 255 to describe how shiny that pixel was.

Since a light exists at a particular X,Y,Z coordinate, the program could deduce the angle in which the light hits each pixel.   Since you can determine the X,Y,Z coordinate for any given pixel. (X and Y = pixel coordinate while Z = height above ground).   Once you know the light's location, the pixel's location and the angular facing of the pixel, you could determine how much light was hitting the surface of that pixel and adjust it's natural color up or down to indicate darkness or brightness.  Specular calculations factor into it because matt and glossy surfaces use different equations to determine how bright they are.

When you hear people talk about "bump mapping" or "Dot 3 normal mapping" in video games, this is the tech they are talking about.

It all looks pretty cool in action, but it isn't simple for artists to deal with.  Which is why the whole thing isn't part of the current version of Tilesystem.  I suspect most people are happy being able to just use their image artwork as-is.   Adding more complicated functionality will reduce the number of people who can/will contribute content.

If I go forward with the lighting stuff at some point, it would have to be an optional thing.

----------


## CRasterImage

Nice App Redrobes!   The terrain stuff is amazing!  I will have to try out the demo when I get home.

Torstan, yes I have seen that program before.  Is is very cool.   It might have been part of my inspiration at the time.   I use something I call "shadow casting" in a similar effect.  I forgot to mention the shadow aspect of lighting.  It can be tough to do efficiently when there are a dozen light sources active in a scene.

----------


## Redrobes

> Nice App Redrobes!   The terrain stuff is amazing!  I will have to try out the demo when I get home.


Thanks, try the demo and the free utils too - DragonFlight is OpenGL too.




> Torstan, yes I have seen that program before.  Is is very cool.   It might have been part of my inspiration at the time.   I use something I call "shadow casting" in a similar effect.  I forgot to mention the shadow aspect of lighting.  It can be tough to do efficiently when there are a dozen light sources active in a scene.


If the light sources dont move - i.e. not torches being held by characters - then you can do it pretty efficiently by storing the shadow maps on offscreen buffers. If your using the nVidia shadow extension then you would need to do this in any case. If you can work out which ones are moving then you only need to recalc those each time.

----------


## CRasterImage

I have tried several experiments and entertained several ideas.   One that is similar to what you are describing is:  Generate a map-wide image that contains the occluded light results for all static (non-moving) lights.   However, the image becomes invalid when a moving object (a figure) enters the area.  Or when a nearby door opens.   That object, or door, ends up changing the occlusions in the scene.  Making the saved image invalid.

One work-around is:  treat moving occlusions differently than static occlusions and handle them in a different pass.  However, introducing shadows later, doesn't always generate the correct effect.   Since a shadow is particular to a light source.   By that point, all the lights have added their contributions to the environment.   Adding any shadows at that point wouldn't be able to undo contributions of a particular light source.

Currently, I am doing something similar to what you are describing.  All static lights are in two entire-map-sized saved images and handled in a single pass.  One image contains the amount of light at that pixel.   While the other stores the angle of the light at that pixel.  Kind of like an inverted normal map.  This world-lighting pass is done without any shadows...   While moving lights, like the spotlight on the Terminator's shoulder, are handled in individual passes, with occluding shadow-casters factored in.  One pass per light.  They have to be handled separately since an occlusion map has to be generated for each light, on every rendering.  Making parallelization difficult to pull off.

Lighting can be quite the pain in the butt.   The flawless method of doing each light in a separate pass adds rendering speed problems, while attempts to combine the lights sacrifices correct behavior.  Gah!

----------


## helium3

> I have tried several experiments and entertained several ideas.   One that is similar to what you are describing is:  Generate a map-wide image that contains the occluded light results for all static (non-moving) lights.   However, the image becomes invalid when a moving object (a figure) enters the area.  Or when a nearby door opens.   That object, or door, ends up changing the occlusions in the scene.  Making the saved image invalid.


I have a question that I'm not sure how to ask. What "language" or "application" are you using to do this in?

----------


## CRasterImage

> I have a question that I'm not sure how to ask. What "language" or "application" are you using to do this in?


Sorry, I didn't mean to run off on a geeky tangent.   

To answer your question: The Tilesystem program is written in C/C++ and uses the OpenGL library.  (and only runs in Windows.  Apologies to those who use Mac or Linux. ) 

The subject of the post was how to write code that can render shadows efficiently (quickly) in situations with multiple light sources.

----------

