LASEReyes

[Jedi QuestMaster]

Hey, guys! Has there ever been a laser-eye-shooting action puzzle before?



Though this isn't an NES game (yet), I'd like to stick to the NES limitations as close as possible. My biggest issue is with the 8 pixels per scanline limit. The player is never not shooting a laser, so looking horizontally without any obstacles would normally flicker on an NES:



I'm planning to add obstacles and a goal. I'd also like to eventually add a four-player Bomberman-like battle mode somehow.

Here's an EXE demo: https://drive.google.com/file/d/1zeVInW ... sp=sharing

[Pokun]

Heh I had some ideas using beams in a maze puzzle game, though not the same way you seem to do it.

You could probably do the beam with BG characters instead of sprites so you don't have the sprites/scanline problem. It's fully possible to update a row of characters or two every frame. From the screenshots it looks like the game isn't scrolling, which means you probably don't have a lot of other BG updates going on. You could probably also have it animate.

[Dwedit]

I can think of a way to get a long horizontal laser working on the NES by using nametable switching (horizontal scrolling) and raster effects.

[lidnariq]

Huh, now that you mention that, I'm reminded of certain recent experiments with blargg's nmisync code, and that could let you switch nametables with sliver accuracy.

Horrific overkill, but also absolutely delightful.

[Drag]

I'll second what Pokun suggested, drawing the laser on the BG seems like the way to go, especially as you start adding other players who also need to shoot lasers. The Bomberman series on NES can help since it needs to animate an entire lattice if one bomb explodes into another bomb, and it draws all of that using the BG map.

Edit: It's not a shoot-laser-from-eyes puzzle game, but the game Panic Space on the FDS is a puzzle game which also uses a laser as the central mechanic, except you're a robot who pushes stuff around the room to try to get the laser to point at something.

[rainwarrior]

The row of background tiles suggestion makes a lot of sense to me. I guess you might need a variation of the tiles for each thing they can overlap. Maybe sprites at the ends to cap it off... Needing to put the same 2 colours for the laser in every palette is a drawback though.

[Jedi QuestMaster]

You could probably do the beam with BG characters instead of sprites so you don't have the sprites/scanline problem. It's fully possible to update a row of characters or two every frame.

I feel like this is too much movement for background tiles to handle:


Because the player snaps to a 16x16 grid, would it be feasible to have the player and laser be background tiles while standing still and transition to sprites while moving?

I can think of a way to get a long horizontal laser working on the NES by using nametable switching (horizontal scrolling) and raster effects.

I wish I could understand this.

Edit: It's not a shoot-laser-from-eyes puzzle game, but the game Panic Space on the FDS is a puzzle game which also uses a laser as the central mechanic, except you're a robot who pushes stuff around the room to try to get the laser to point at something.

Cool! I'll check that out.

I guess you might need a variation of the tiles for each thing they can overlap. Maybe sprites at the ends to cap it off... Needing to put the same 2 colours for the laser in every palette is a drawback though.

Urgh! I just realized: the laser overlaps part of the 'ground' tile and 'pillar'/'brick' tiles at the same time when horizontal:


I already shrunk the player by 2 pixels because the perspective made him look taller than the pillar:




I based the character sprite off Bomberman 2 proportions, but in Bomberman 2, the characters are clearly taller than the blocks. So the pillars and bricks had to be 16x24 that way the player doesn't look like he's shooting over them.

[Dwedit]

I was looking at the screen.

lasereyes_background_1.png (6.64 KiB) Viewed 1859 times

First off, it is using an attribute resolution of 16x8 pixels rather than 16x16 pixels. Normally that can't be done on the NES using a simple background layer, but it can be done with scrolling trickery.

====
Using Scrolling Trickery to get 16x8 attribute region
====

Use two nametables. Even rows on the left (0,2,4,6,8...), Odd rows on the right (1,3,5,7,9...) Each row is 8 pixels tall.

lasereyes_nametables_1.png (9.55 KiB) Viewed 1859 times

Then every 8 scanlines, do horizontal scrolling to pick which row is visible.
Presto, you now have a 16x8 attribute area without using an MMC5.

An illustration of these two composited: (every other row is a displayed at a different brightness level so you can see how they fit together)

lasereyes_composite.png (7.11 KiB) Viewed 1859 times

Now from here on, getting a Grid Aligned 16x8 laser pattern on the background shouldn't be too hard to do, but it would be 8 tall instead of 6 tall.

[Dwedit]

====
The Next Challenge - not aligned to the grid anymore
====

The next challenge is to allow a non-grid-aligned 16x6 laser pattern, and there's a way to do this too, but it's much harder than simply using aligned 8-tall lasers.

Let's start with a backrgound:

lasereyes_unaligned_nolaser_background.png (6.8 KiB) Viewed 1849 times

Add a 16 pixel tall Laser: (The white laser inside could be drawn anywhere in that 16 pixel zone with no trouble)

lasereyes_unaligned_laser_background.png (6.75 KiB) Viewed 1849 times

Then we want to mask it off so we get a 6 pixel tall laser (Mockup of what masking would look like)

lasereyes_unaligned_nolaser_masked.png (6.8 KiB) Viewed 1849 times

----

So we build the nametables again...
We now have a new background element for the laser, let's put it in the first two rows (not displayed normally)

lasereyes_unaligned_laser_interleaved2.png (10.54 KiB) Viewed 1849 times

Now the tricky part is re-compositing. We can't simply use the change every 8 pixels rule anymore.

lasereyes_unaligned_laser_composed.png (7.24 KiB) Viewed 1849 times

at Y = 172, we do full scrolling to put the Laser Tiles in there.
at Y = 176, we do full scrolling to put the bottom half of the laser tiles in there (because of 16x8 attributes)
at Y = 178, we end the special scrolling area for laser tiles, and proceed back to the normal composed tilemap.

This gets you a non-grid-aligned 6 pixel tall laser, along with 16x8 attributes everywhere else.

Complicated stuff for a NES to do, but possible.

[calima]

That's a nice trick, though hard to program, and would waste roughly half the cpu on just drawing. Keeping the bg 16x16 aligned would be preferable, if possible.

[Pokun]

But you would still need MMC3 or something with scanline interrupts.

You could probably do the beam with BG characters instead of sprites so you don't have the sprites/scanline problem. It's fully possible to update a row of characters or two every frame.

I feel like this is too much movement for background tiles to handle:

Ouch, I didn't understand that you could strafe. If you use CHR-RAM you could do pixel-precise updates to tiles but that would be a lot more VRAM writes than just updating a row of tiles in the nametable so it's maybe not possible to do each frame.

Alternatively you could just have multiple patterns for each metatile in your patter table, each with various degrees of overlapping laser. This will limit the types of tiles you can have per level, but in your screenshots you have only about 5 types of metatiles anyway. If you are OK with a bit choppy movement you could make it move 2 or 4 pixels at a time or so to reduce the number of duplicate metatiles you need to have. If you want to have a status bar, just make sure you have enough patterns left for characters or whatever you want to display there (or draw it using sprites).

CHR-ROM bankswitching is another idea.

Because the player snaps to a 16x16 grid, would it be feasible to have the player and laser be background tiles while standing still and transition to sprites while moving?

But wouldn't you easily hit the sprites/scanline limit when you move in that case which is what we are trying to avoid? It might be a flickerfest of a game otherwise.

I can think of a way to get a long horizontal laser working on the NES by using nametable switching (horizontal scrolling) and raster effects.

I wish I could understand this.

Dwedit is suggesting to use two nametables (background screens) besides each other and change the scroll coordinate to the other nametable at specific points in time when the screen is being drawn by the TV's electron gun. This way you will have a screen that is composed of parts of both nametables alternately. You need some way to detect when the scanline has drawn however much of the first nametable you want so you can switch the scroll coordinate in time so that the other nametable is drawn instead for the following number of lines. This and other similar techniques are called raster effects because you mess with the rasterline (AKA scanline) drawing to get the results you want.
Ways to detect where the gun currently is at a given time is using sprite 0 collision detection (which SMB1 and many other games does to prevent the statusbar from scrolling) or some kind of scanline counter hardware in the cartridge (MMC3 has this). There are also other methods like abusing the broken sprite overflow flag.

[Jedi QuestMaster]

Now the tricky part is re-compositing. We can't simply use the change every 8 pixels rule anymore.
lasereyes_unaligned_laser_composed.png

at Y = 172, we do full scrolling to put the Laser Tiles in there.
at Y = 176, we do full scrolling to put the bottom half of the laser tiles in there (because of 16x8 attributes)
at Y = 178, we end the special scrolling area for laser tiles, and proceed back to the normal composed tilemap.

This gets you a non-grid-aligned 6 pixel tall laser, along with 16x8 attributes everywhere else.

Complicated stuff for a NES to do, but possible.

Okay, I guess I should just stick with my original player height; the laser would only cover one row of tiles:


Or I could try drawing the player at a more top down perspective (closer to Gauntlet) to bring the laser down at least 4 pixels?

But I still feel like the laser would work better as flickering sprites. Maybe.

Would now be a bad time to mention I was planning on having four different laser colors for each player? I already have two palette sets for the player (brown, tan, white / brown, tan, black:



The third would encompass players' 1 & 3 lasers and the fourth would encompass players' 2 & 4 lasers using different sprites to utilize the different colors.

However, I'm already using three background palettes for the ground, pillars, and bricks.

Would flickering lasers really be all that bad?

All four players standing on the same y-plane would take 8 sprites, but if they all faced horizontal, at least two will be dead. Unless they're between pillars.

[Pokun]

You have 4 BG subpalettes and 4 sprite subpalettes, each with only 3 colors, so you can't have lasers use other colors than what the tile uses, unless if you make the laser cover the whole metatile.

Also the attribute table for determining the colors of the BG tiles. Updating it isn't really more expensive than updating the BG tiles themselves, but each attribute covers an 2x2 metatile area (since your metatiles are 2x2 tiles large), so if one player has a blue laser over one metatile and its palette is changed accordingly, an adjacent tile will also be affected by the palette change (attribute clash).

The problem with using sprites and letting it flicker is that the laser will not flicker evenly. Each sprite takes a turn to flicker so it will not be a long semi-transparent beam, but rather a bunch of beam-shaped squares that flickers at different rates. And not all of them will flicker.
I guess you could try it and see how it looks. Oh I made a sprite-multiplex demo somewhere... Here is is! Here only the first and last sprite flickers because how I designed the multiplexing (just filling OAM forwards and backwards alternatively).

I guess one idea is to always flicker the laser sprites no matter what, but I'm not sure if that would look better.

[Drag]

Before this rabbit hole gets any deeper, I want to point out, step 1 is "get a basic implementation working".

It may turn out that a simple implementation with sprites (following whatever flicker patterns are necessary) gives a perfectly acceptable result in practice. If it doesn't, that's when it's time to experiment with hardware trickery.

The reason I'm pointing this out is, it's fun to try to come up with ways to bend the NES's hardware in ways you don't normally see, but if you get too far off-track, it might seem like there's a mountain of work and complexity ahead of you in order to get something simple working, which may eat all of your motivation, where if you had ignored all of that and just used the "mundane" way, you'd have finished already.

So, the most barebones simple way I can think of to draw a laser beam is to use sprites. You can try flicker, or you can try something like individual line sprites that "shoot" out of the player, and move at (for example) 4px each frame, to form kind of a "marching ants" effect. Start with a really trivial implementation such as this one, observe what shortcomings you're seeing, and use that to figure out what you want to try next, or if it's even necessary.

[Jedi QuestMaster]

Just wondering, has anyone actually downloaded the EXE? Just curious is all.

Edit: Also, I'm willing to alter details to make this more feasible to program. I'm in a transitioning phase where I have to start all over because I began working on this in GameMaker 5.0 but now I realize I want to use features in GameMaker Studio 2. The only things written in stone are:

• player has to shoot laser beams out of his/her eyes
• multiplayer mode
• top down perspective
• laser must be a constant beam (not like shooting bullets)

Things I don't want to change, but might have to (but I hope not)

• strafing (I mean, c'mon! I will fight this.)
• different color lasers on multiplayer
• two subpalettes for player sprite

Things I'm openly willing to change:

• overlapping beam on background sprites
• player's head overlapping on background sprites (make him even smaller/change perspective)
• width of the beam

I'm curious as to how choppy making the player/laser background tiles might be. Would it be feasible to speed everything up to make it look less choppy? I'm planning on this using MMC3 mapper (I like lots of animation).

One idea I had was not having laser tiles at all, but just change the background tile colors as if a beam is going over them.

Also, thanks for the ideas, everyone!