1
0
Fork 0
lasertank-js/lib/Map.js

96 lines
3.1 KiB
JavaScript
Raw Normal View History

Initial map rendering support The next major step for the clone is the loading and parsing of LVL files (maps). This is especially imporant for the purpose of ensuring that users can continue to use the maps the know and love (and possibly created themselves), rather than having to recreate them in the clone. The maps are concatenated into a single fixed-width file and loaded (in the original sources) into the TLEVEL struct (LTANK.H). The main thing to note about this data is the manner in which the object data (the playfield) is stored. The TPLAYFIELD type (defined as a 16x16 multidimensional signed char array) is formatted as [x][y], meaning that it is an array of *columns*, not rows. While at first confusing, this does not complicate matters any. This commit adds initial rendering support for the playfield via MapRender and is demonstrated in the same demo file as LtgLoader. After loading a tile set, the user can load an LVL file. The rendering is done using two canvas elements, the second of which is created by MapRender itself and overlayed atop of the original canvas. Unmasked tiles are rendered to the bottom canvas and masked tiles to the upper, allowing us to move game objects without having to redraw underlying tiles. This is also necessary as the context putImageData() method overwrites any existing data rather than leaving values corresponding to the transparent pixels in tact. This commit also added support for tunnel coloring - each set of tunnels has its own distinct color. The color values were taken from ColorList in LTANK2.C in the original sources rather than using CSS color names (e.g. 'red', 'blue', 'magenta') because different environments may assign slightly different colors to those values (as an example, FireFox does not use #00FF00 for 'green'). Tunnels themselves are identified by a bitmask (0x40), so we can get the tunnel id by XORing with that mask. The ids are incremented by two in the LVL data (e.g. 0x40 for index 1, 0x42 for index 2), so we can then divide by two and take that index in the color array. This color is used to fill the tile with a solid color in the lower canvas. We can then paint the tile on the upper canvas, which will allow the color of the lower canvas to peek through the transparent pixels. Animation support has not yet been added (but animations are still visible in the demo to the left of the map rendering). This is an exciting start, as we can clearly see what the game will look like in the browser. This commit also does not cover any additional level metadata (e.g. author, difficulty, hints); that will be addressed in future commits and added to the demo.
2012-03-15 23:30:20 -04:00
/**
* Represents a map (level)
*
* Copyright (C) 2012 Mike Gerwitz
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU Affero General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Affero General Public License for more details.
*
* You should have received a copy of the GNU Affero General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*
*
* The details on exactly how the map data is stored is left to specific
* implementations. However, the following is common to each file format:
*
* - All game objects for the playfield should be returned in columns rather
* than rows. This is an artifact from the original game and is left as is
* because it is no more difficult to work with than rows (just less
* natural).
* - Tunnels are identified by the bitmask 0x40 and their id can be calculated
* by XORing with the bitmask and then dividing by two. For example, a
* tunnel identified by index 0 is 0x40, index 1 is 0x42, and so on.
*/
/**
* Represents a map (level)
*
* Maps simply act as basic wrappers around a set of maps, returning only the
* data associated with the requested map. This allows the data to be lazily
* sliced out of the map file.
*
* Note that this interface specifies a constructor definition; this allows it
* to be used in place of a separate Factory class.
*/
ltjs.Map = Interface( 'Map',
{
/**
* Initialize map with map data and the given id
*
* @param {ltjs.MapSet} set map set data
* @param {number} id 1-indexed map id
*/
__construct: [ 'set', 'id' ],
/**
* Retrieve game objects
*
* The game objects are expected to be returned in a manner consistent with
* the original sources - in columns, not rows. The reason for this is that
* the original game uses a multi-dimensional array [x][y], which creates
* an array of columns (TPLAYFIELD, LTANK.H).
*
* @return {Array.<number>} array of game objects
*/
'public getObjects': [],
/**
* Retrieve map dimensions
*
* @return {Array.<number>} width and height in tiles
*/
'public getDimensions': [],
/**
* Retrieve map of object codes to their appropriate tiles
*
* @return {Array.<string>}
*/
'public getObjectTileMap': [],
/**
* Retrieve tunnel colors
*
* These colors will be rendered in the background and will bleed through
* the transparent portions of the tile. A total of eight colors should be
* returned. They may be specified in any CSS format, but explicit values
* are recommended since color names (e.g. 'green') can vary between
* environments.
*
* @return {Array.<string>}
*/
'public getTunnelColors': []
Initial map rendering support The next major step for the clone is the loading and parsing of LVL files (maps). This is especially imporant for the purpose of ensuring that users can continue to use the maps the know and love (and possibly created themselves), rather than having to recreate them in the clone. The maps are concatenated into a single fixed-width file and loaded (in the original sources) into the TLEVEL struct (LTANK.H). The main thing to note about this data is the manner in which the object data (the playfield) is stored. The TPLAYFIELD type (defined as a 16x16 multidimensional signed char array) is formatted as [x][y], meaning that it is an array of *columns*, not rows. While at first confusing, this does not complicate matters any. This commit adds initial rendering support for the playfield via MapRender and is demonstrated in the same demo file as LtgLoader. After loading a tile set, the user can load an LVL file. The rendering is done using two canvas elements, the second of which is created by MapRender itself and overlayed atop of the original canvas. Unmasked tiles are rendered to the bottom canvas and masked tiles to the upper, allowing us to move game objects without having to redraw underlying tiles. This is also necessary as the context putImageData() method overwrites any existing data rather than leaving values corresponding to the transparent pixels in tact. This commit also added support for tunnel coloring - each set of tunnels has its own distinct color. The color values were taken from ColorList in LTANK2.C in the original sources rather than using CSS color names (e.g. 'red', 'blue', 'magenta') because different environments may assign slightly different colors to those values (as an example, FireFox does not use #00FF00 for 'green'). Tunnels themselves are identified by a bitmask (0x40), so we can get the tunnel id by XORing with that mask. The ids are incremented by two in the LVL data (e.g. 0x40 for index 1, 0x42 for index 2), so we can then divide by two and take that index in the color array. This color is used to fill the tile with a solid color in the lower canvas. We can then paint the tile on the upper canvas, which will allow the color of the lower canvas to peek through the transparent pixels. Animation support has not yet been added (but animations are still visible in the demo to the left of the map rendering). This is an exciting start, as we can clearly see what the game will look like in the browser. This commit also does not cover any additional level metadata (e.g. author, difficulty, hints); that will be addressed in future commits and added to the demo.
2012-03-15 23:30:20 -04:00
} );