mikegerwitz
/
lasertank-js
1
0
Fork 0
Code Releases Activity
lasertank-js/test/ltgloader-demo.html

239 lines
6.5 KiB
HTML
Raw Normal View History

Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
<!DOCTYPE html>
<html>
<head>
<title>LtgLoader &amp; TileMasker Demonstration</title>
<style type="text/css">
#bitmaps img {
border: 1px dotted black;
margin: 0.5em;
}
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
canvas {
float: left;
}
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
dt {
font-weight: bold;
text-align: right;
padding-right: 1em;
width: 7em;
height: 1.5em;
float: left;
}
dd { height: 1.5em; }
</style>
</head>
<body>
<h1>LtgLoader &amp; TileMasker Demonstration</h1>
<noscript>Please enable JavaScript.</noscript>
<div id="bitmaps">
<img id="bmp_game" />
<img id="bmp_mas" />
</div>
<input type="file" id="ltg" />
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
<input type="file" id="lvl" />
Added ability to render other maps after having rendered another (demo file now allows for map selection by id)
2012-03-17 16:09:08 -04:00
<select id="lvl_id"></select>
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
<dl>
<dt>Name</dt>
<dd id="ltg_name">(No LTG Loaded)</dd>
<dt>Author</dt>
<dd id="ltg_author">&nbsp;</dd>
<dt>Description</dt>
<dd id="ltg_desc">&nbsp;</dd>
<dt>Id</dt>
<dd id="ltg_id">&nbsp;</dd>
</dl>
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
<canvas id="canvas" width="250" height="400">
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
Your browser does not support the canvas element.
</canvas>
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
<canvas id="canvas_map" width="512" height="512"></canvas>
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
<script src="../scripts/ease.min.js"></script>
<script>
window.ltjs = {};
Abstracted tile definition
2012-03-12 21:14:39 -04:00
window.Class = easejs.Class;
window.Interface = easejs.Interface;
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
ltgloader-demo will now alert the user on all uncaught exceptions
2012-03-16 19:14:11 -04:00
// alert the user on all uncaught errors
window.onerror = alert;
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
var ctx = document.getElementById( 'canvas' ).getContext( '2d' ),
ctxmap = document.getElementById( 'canvas_map' ).getContext( '2d' ),
ltg = document.getElementById( 'ltg' ),
lvl = document.getElementById( 'lvl' ),
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
ltgloader-demo now clearing previous MapRender instances
2012-03-16 19:43:41 -04:00
render = null,
ltgloader-demo will now animate tiles with frames This is exciting, as it begins to bring the game to life.
2012-03-14 21:10:11 -04:00
// animation timer
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
ianim,
tile_set;
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
ctx.font = '7pt Arial';
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
ltg.addEventListener( 'change', ltgChange, false );
lvl.addEventListener( 'change', lvlChange, false );
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
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
function ltgChange( event )
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
{
if ( ltg.files.length === 0 ) return;
ltgloader-demo will now animate tiles with frames This is exciting, as it begins to bring the game to life.
2012-03-14 21:10:11 -04:00
clearInterval( ianim );
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
var file = ltg.files[ 0 ],
reader = new FileReader();
reader.onload = function( event )
{
Abstracted tile definition
2012-03-12 21:14:39 -04:00
var loader = ltjs.LtgLoader(),
masker = ltjs.TileMasker( ltjs.ClassicTileDfn() ),
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
meta = loader.fromString( event.target.result ),
bmp_game = document.getElementById( 'bmp_game' ),
bmp_mask = document.getElementById( 'bmp_mas' );
bmp_game.src = meta.tiles;
bmp_mask.src = meta.mask;
// display metadata
for ( var name in meta )
{
if ( ( name === 'tiles' ) || ( name === 'mask' ) )
{
continue;
}
document.getElementById( 'ltg_' + name ).innerHTML = meta[ name ];
}
masker.getMaskedTiles( meta.tiles, meta.mask, function( tiles )
{
// clear canvas to erase any previous LTG contents
ctx.clearRect( 0, 0, ctx.canvas.width, ctx.canvas.height );
ltgloader-demo will now animate tiles with frames This is exciting, as it begins to bring the game to life.
2012-03-14 21:10:11 -04:00
var i = 0,
anim = [];
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
tile_set = tiles;
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
for ( var tile in tiles )
{
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
var x = ( ( i % 5 ) * 50 ),
y = ( Math.floor( i / 5 ) * 50 ),
ltgloader-demo will now animate tiles with frames This is exciting, as it begins to bring the game to life.
2012-03-14 21:10:11 -04:00
cur = tiles[ tile ];
Using circular linked lists for tile animations This will drastically simplify animations and allow for a more basic mapping of "game objects" to tiles
2012-03-14 20:37:31 -04:00
ctx.putImageData( cur.data, x, y );
ctx.fillText( tile, x, ( y + 43 ), 50 );
ltgloader-demo will now animate tiles with frames This is exciting, as it begins to bring the game to life.
2012-03-14 21:10:11 -04:00
// is this tile animated?
if ( cur !== cur.next )
{
// add to animation list
anim.push( [ cur.next, x, y ] );
}
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
ltgloader-demo will now animate tiles with frames This is exciting, as it begins to bring the game to life.
2012-03-14 21:10:11 -04:00
i++;
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
}
ltgloader-demo will now animate tiles with frames This is exciting, as it begins to bring the game to life.
2012-03-14 21:10:11 -04:00
// animate tiles with multiple frames
ianim = setInterval( function()
{
var i = anim.length;
while ( i-- )
{
var data = anim[ i ],
img = data[ 0 ].data,
x = data[ 1 ],
y = data[ 2 ];
// clear tile area (in case masks differ) and render the
// next frame
ctx.clearRect( x, y, img.width, img.height );
ctx.putImageData( img, x, y );
// advance the frame
anim[ i ][ 0 ] = data[ 0 ].next;
}
}, 200 );
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
// trigger map change (in case of page refresh or tile set change
// after map is already loaded)
lvlChange();
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
} );
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
reader.onerror = function( e )
{
alert(
'Error reading file: ' + e.message + '\n\n' +
'Are you viewing this page locally? Try using a webserver.'
);
};
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
};
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
reader.readAsBinaryString( file );
}
function lvlChange()
{
if ( lvl.files.length === 0 ) return;
var file = lvl.files[ 0 ],
reader = new FileReader();
reader.onload = function( event )
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
{
ltgloader-demo now clearing previous MapRender instances
2012-03-16 19:43:41 -04:00
var map_set = ltjs.MapSet( event.target.result, ltjs.ClassicMap );
// clean up any previous render and create a new one to render the
// chosen level with our chosen tile set
render && render.freeCanvas();
render = ltjs.MapRender( ctxmap, tile_set );
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
render.render( map_set.getMapByNumber( 1 ) );
Added ability to render other maps after having rendered another (demo file now allows for map selection by id)
2012-03-17 16:09:08 -04:00
var lvlsel = document.getElementById( 'lvl_id' ),
count = map_set.getMapCount();
lvlsel.innerHTML = '';
for ( var i = 1; i <= count; i++ )
{
var option = document.createElement( 'option' );
option.value = i;
option.innerHTML = i;
lvlsel.appendChild( option );
}
lvlsel.onchange = function( event )
{
render.render(
map_set.getMapByNumber( event.target.selectedIndex + 1 )
);
};
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
};
reader.readAsBinaryString( file );
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
}
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
// invoke immediately, as we may have a filename prefilled from a refresh
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
ltgChange();
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
</script>
Abstracted tile definition
2012-03-12 21:14:39 -04:00
<script src="../lib/TileDfn.js"></script>
<script src="../lib/ClassicTileDfn.js"></script>
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
<script src="../lib/LtgLoader.js"></script>
<script src="../lib/TileMasker.js"></script>
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
<script src="../lib/MapSet.js"></script>
<script src="../lib/Map.js"></script>
<script src="../lib/ClassicMap.js"></script>
<script src="../lib/MapRender.js"></script>
Initial commit illustrating LTG loading and masking This project -- creating a LaserTank clone in JavaScript -- deserves some discussion before diving into the implementation details (you may skip to the separator below for implementation details without the history). LaserTank is a game that has a special place in my heart. Not only is it a witty and enjoyable game, but it is in fact the reason I began programming as a young boy in the first place. While it is likely that I would have eventually picked up a programming book for some other reason, I owe that point in time entirely to this game. Allow me to explain. At the age of 10, I would spend much of my time on the Internet downloading various games and demos that may satisfy my interests (the old days of CNET's download.com showed me many of those, I believe). One of those games that immediately captivated me was LaserTank, but not purely for reasons of gameplay. It had this wonderful feature that added so much potential (and replayability) to the game -- a map editor. I found myself enthralled with the map editor to the point where I spent all my time creating maps rather than playing the game. What fascinated me was the ability to essentially create portions of the game -- to tell the game what to do and how to function. I was not able to create my own game using this editor, but I felt like I was creating portions of it. That said, I soon realized that it wasn't enough; I needed to do more. It was the limitations of the map editor and the enjoyment of creating the maps that caused me to convince my parents to take me to Barnes and Noble to purchase my first programming book - Learn to Program with Visual Basic 6 by John Smiley (N.B. Visual Basic is proprietary and I cannot recommend using it. I had no knowledge of the evils of proprietary software back at that point in time.) My parents had their doubts, but that only pushed me even harder to learn. Ironically, the book was about creating a business application. I found this process very enjoyable and began focusing more on conventional desktop software rather than gaming. I did create a couple games (bop-a-mole and breakout among others), but my focus was never game development. Eventually, I moved on from Visual Basic and got into web development. Following that, I discovered GNU/Linux and began getting more and more into lower-level systems and languages (such as C and ASM) and began adopting the hacker ethic. That brings us to where I am today -- nearly 13 years later. It would only seem fitting to bring my hobby-turned-career full circle by cloning the very game that started everything. When I say "clone", I mean nothing more; there will be no additional features or modifications to the original gameplay, menus, graphics, etc. It will support all original file formats (I will develop none of my own). The only differences between the clone and the original game will arise from the obvious issues introduced by cloning the game on a web platform. Specifically, the user will have the option to load files from either their local box or a remote resource, and I may provide pre-masked tile sets for browsers that do not support the canvas element (a fallback mode, if you will). No matter what the change, though, the gameplay will remain identical. That said, the library resulting from the clone will be built with extensibility in mind. If a user (or myself) wishes to create a derivative work by hooking or extending the library (for example, to support larger maps, add additional blocks/enemies, multiplayer support, etc), that should be fairly trivial to do. However, those works will be entirely separate from the clone and clearly distinguished. I think the original LaserTank is perfect the way it is. Remember, it has a special place in my heart (aww) and I would like to preserve the game as I remember it back then. --- Alright; now that we have a great deal of unnecessary history out of the way, let's get into the implementation details for this commit (if you're reading this as a blog entry, see the first commit). This commit represents a proof-of-concept showing that the LTG files (containing the LaserTank graphics) can be properly loaded and their masks properly applied. This was the first major concern for the project and, if a workaround were needed, would have prevented me from creating a full clone (as it would not support loading LTG files without having them first sent to the server, processed, and returned in a different format). The LTG file contains some metadata (including the name, author and description) as well as two bitmaps (BMPs) -- the game tileset and the associated mask. The game bitmap's position was static, but its length and the offset of the mask bitmap were provided by the four bytes immediately preceding the game bitmap (the TLTGREC struct in LTANK.H of the original sources represented this value as a DWORD, which represents a 32-bit integer). The only challenge with converting this value into an integer that we could use is its endianness -- is the most significant byte at the beginning or end? Windows programs (of which LaserTank is) generally write in little-endian format, but to be sure we can simply open up the LTG file in your favorite HEX editor (I simply use `xxd`). In the case of the original tileset, the four bytes immediately preceding the bitmap header (as identified by 'BM', or `424d`) were `7a f5 00 00`, which on its own clearly indicates little-endianness. We can verify by searching for 'BM' once again, and finding that it begins at location `f5 7a` (if your HEX editor displays in big-endian format). To convert into a number, we can simply add up each byte individually, left-shifting by 8N bits, where N is the 0-indexed byte position. Loading the BMP files was then fairly trivial; the file could be loaded into memory (read from disk using FileReader) and we could cut the relevant portions of the binary string out. The bitmaps could then be base64-encoded and the "src" attribute of an Image object set to 'data:image/bmp;base64,B', where B is the base64-encoded BMP. This could then be rendered however we please - CSS sprites or to a canvas. The problem with CSS sprites is that we need to apply the mask and there is no reliable way to do this without a canvas; transparency in the browser is normally handled using GIFs or PNGs. As it turns out, the canvas performs masking using the alpha channel as well, so I would have to create my own masking algorithm to manipulate the alpha channel of the tileset. To complicate matters even more, certain tiles had no mask, and they did not consistently represent the mask with all black (black is used in LT to indicate opacity), meaning that the algorithm would have to understand what tiles should be skipped entirely. The solution was to simply loop through each tile and set the alpha byte of each pixel relative to the respective pixel on the map. Because the images were created out of data in memory, the canvas is not tainted when the image is rendered before using getImageData(). To help speed up the process, since we know that the mask can only contain black and white, we need only check one of the channels; we do not need to calculate brightness. This process successfully returns each individual tile, properly masked, which can be rendered to the canvas using putImageData(). Crisis averted. With that major concern out of the way, the clone should no longer be a problem. I go into more detail in the comments within LtgLoader and TileMasker. This is going to be an exciting process, both because of the LT clone itself and because this is my first experience working with the canvas element. As aforementioned, I seldom create games and I have had no use for the canvas thus far. Hopefully this project will be well-received by both those who have played LaserTank in the past and the original developer of the game (Jim Kindley, JEK Software). LaserTank is a fairly old game and is not likely to be well known anymore, but the game itself is a blast (no pun intended) and bringing it to the browser, where it can be used on any platform (including mobile devices), should allow everyone to enjoy it. The source code is released under the GNU AGPL to ensure that the users' freedoms are preserved even if this game is rendered or in any way run server-side.
2012-03-11 21:38:06 -04:00
</body>
</html>