lorom

;these files cover only the sprite data of beams (and missiles), not the behaviour routines, sprite drawing routines, or collision routines.
;I'll include those when I update this to have charged beams and the other projectiles as well.

;beam sprites work on 3 layers of tables:

;beam_sprite_tables: There are three tables that get indexed to determine what animation data to use (uncharged beams, charged beams, and other projectiles), and include every combination of beams.
;These tables point to another set of tables, this time for direction. The first value in the direction table is for the projectile damage, and is the reason that things like spazer+ice have
;separate tables from spazer, even though they point to the same animation/tilemaps. They look a little redundant, with 2 up and 2 down pointers, but it just makes indexing simpler,
;they still point to the same animation data.

;beam_sprite_handlers (might not be the right word for these, but it's the one I'm using): The direction tables point to the animation data tables. These are similar to plm instruction tables, but very simple.
;They start with a Word for frame delay, then a pointer to the tilemaps they use, followed by the hitbox x/y, and the animation number. They end with a pointer to a loop instruction ($8239), and an offset for where
;the loop should begin again. Some of the beams and projectiles only have one frame, in which case they always point back to the start of the sprite handler. Some, like spazer, have an initial animation,
;as the beam exits the gun, but then loop on a single frame. Either way, these sprite handlers point to tilemap data, which is the final layer.

;beam_sprite_tilemaps: This is the raw OAM data used by the sprite drawing routine to draw the beam onto the screen. They index VRAM starting at C000+30*2, and use up to 8 tiles of space (8*$20 bytes). This is not
;a strict limitation however, since the index can call any sprite data in the bottom half of VRAM (00-FF). However, the game will normally only store 8 beam tiles in misc VRAM. Adding more gfx to beams is possible without
;distrupting anything else (see my VRAM map for what's used and unused), but requires more routines to be written (I'll probably release some asm that sets this up at some point, but routines I personally use
;currently account for a sprite based hud, which changes where gfx can be stored). Tilemaps for beams are in the standard OAM format, consisting of a Word for the number of tiles, and 5 Bytes per tile. The tilemap
;file has an explanation of the format.

;the templates file has a few templates for beam sprites, but you should obviously only include the ones you need, not all of them at once, since they use up free space currently
;be careful if you use the templates though, because anything past 1 horizontal tile, 1 vertical tile, and 2 diagonal will cause a problem for charge beam. I included
;a couple however because it's fairly simple to separate charge and unchaged beam gfx if you choose to do so (remember though that it is possible to have charged and uncharged
;on screen at once, therefor you need to have checks in place to ensure that doesn't happen, or make new tilemaps that index unused space in vram, which would be messy)

;incsrc beam_sprite_templates.asm
incsrc beam_sprite_tilemaps.asm
incsrc beam_sprite_handlers.asm
incsrc beam_sprite_tables.asm