Honestly I think those look more like ice cream than the original's :P Never occurred to me they could look like... you knowDrag wrote: ↑Mon May 22, 2023 10:42 pm They look like stalagmites, but if you're self-conscious about someone making a ha-ha, try making them skinnier, or give them a similar pattern to the walls.
Edit:
stalagmites.png
After playing with it some more, it seems to help to keep the "bands" very thin; too thick and it starts looking like swirly ice cream.
LASEReyes
Moderator: Moderators
- Individualised
- Posts: 310
- Joined: Mon Sep 05, 2022 6:46 am
Re: LASEReyes
Re: LASEReyes
Oops! (Oops.)
- Jedi QuestMaster
- Posts: 688
- Joined: Thu Sep 07, 2006 1:08 pm
- Location: United States
- Contact:
Re: LASEReyes
I followed your advice, but I ended up making them much more rocky-looking than the walls. Mockup:
Wow, that's good! I was also planning on reusing these tiles for an ice cave.
Re: LASEReyes
I've made a test rom to try to make the laser using background tiles.
It's instantaneous unlike the one in your demos, but that wouldn't add that much more complexity.
There's more than enough vblank time for 4 lasers, their attribute updates, and for other things like the bombs or pushable blocks. This looked like it was going to be a lot more complicated than it actually was!
I also want a chocolate stalagmite now.
It's instantaneous unlike the one in your demos, but that wouldn't add that much more complexity.
There's more than enough vblank time for 4 lasers, their attribute updates, and for other things like the bombs or pushable blocks. This looked like it was going to be a lot more complicated than it actually was!
I also want a chocolate stalagmite now.
- Attachments
-
- LaserDemo.nes
- (96.02 KiB) Downloaded 57 times
- Jedi QuestMaster
- Posts: 688
- Joined: Thu Sep 07, 2006 1:08 pm
- Location: United States
- Contact:
Re: LASEReyes
I just realized--I don't know how lasers are going to overlap. Whether they cancel each other out or go right through each other, when two lasers are near enough, they occupy the same tile space before they intersect I'm already using 53 tiles for lasers. I can't imagine how many more are needed for every combination of overlap.
On another note, maybe the floor color shouldn't share a sprite color that's also an outline: Or does this still work? Regardless, I made another underground palette: What you think? Does this look darker?
- Jedi QuestMaster
- Posts: 688
- Joined: Thu Sep 07, 2006 1:08 pm
- Location: United States
- Contact:
Re: LASEReyes
I wanted some stone houses to go along with a creek stage to create a sort of rural town ambience:
One problem I had involved the roof textures: The top and bottom roof panels need to tile horizontally, (for long houses) and the left and right roof panels need to tile vertically (for vertically long houses). As they are right now, they tile perfectly, but I'm not sure they look great when they connect diagonally with each other (see top image). I may need to shift the roof tile textures to get them to look right or just modify the unique tiles so they look perfectly connected (I might just do this) so the roof panels don't look 'broken.'
Also:
That way there's no room for two parallel lasers to intersect the same tile space without colliding.
Here's some textureless models to show how they could be made bigger:
This next part is going to be hard to explain, but I'll try:One problem I had involved the roof textures: The top and bottom roof panels need to tile horizontally, (for long houses) and the left and right roof panels need to tile vertically (for vertically long houses). As they are right now, they tile perfectly, but I'm not sure they look great when they connect diagonally with each other (see top image). I may need to shift the roof tile textures to get them to look right or just modify the unique tiles so they look perfectly connected (I might just do this) so the roof panels don't look 'broken.'
Also:
I didn't want to have to do this, but I could just make multiplayer stages have pillars on every other 16x16 grid:Jedi QuestMaster wrote: ↑Mon Jun 05, 2023 10:22 pmI just realized--I don't know how lasers are going to overlap. Whether they cancel each other out or go right through each other, when two lasers are near enough, they occupy the same tile space before they intersect I'm already using 53 tiles for lasers. I can't imagine how many more are needed for every combination of overlap.
That way there's no room for two parallel lasers to intersect the same tile space without colliding.
- Jedi QuestMaster
- Posts: 688
- Joined: Thu Sep 07, 2006 1:08 pm
- Location: United States
- Contact:
Re: LASEReyes
So obviously the "Creek" stages are going to have a creek, and I'd like to have flowing water that the player can't traverse but be able to shoot their laser over:
Seeing as the laser tiles are bg tiles, and they must overlap the water, what's a good way of going about this?
I feel like creating more background tiles just for this would not only limit how many frames and colors the water can have, but I feel like I'm pushing the limits of how many background tiles I have already.
What if I use sprites where the laser overlaps the water? As long as I don't make the width of the water too long, flickering shouldn't be a problem. I just need to keep a subpalette free (4 players might be an issue).
What other options do I have?
(warning: the two-frame placeholder water tiles suck!)Seeing as the laser tiles are bg tiles, and they must overlap the water, what's a good way of going about this?
I feel like creating more background tiles just for this would not only limit how many frames and colors the water can have, but I feel like I'm pushing the limits of how many background tiles I have already.
What if I use sprites where the laser overlaps the water? As long as I don't make the width of the water too long, flickering shouldn't be a problem. I just need to keep a subpalette free (4 players might be an issue).
What other options do I have?
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: LASEReyes
30hz flickering would appear semi-transparent and would be enough, imo
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
- Jedi QuestMaster
- Posts: 688
- Joined: Thu Sep 07, 2006 1:08 pm
- Location: United States
- Contact:
Re: LASEReyes
Three weeks later and all I have to show for is a slightly better water animation:
Though I feel like this needs work, at least it has the depth I want to convey.Re: LASEReyes
Water animation is a typical thing that can be done very cheaply with palette cycling. You just need a single set of BG characters for the metatile(s) and use the colors in a way that changing them in two or more animation frames will give the impression of animation. Then by simply cycling the subpalette (the 3-color palette of the tile) you are both saving video memory (like pattern table memory) and time (updating the palette is much faster than redrawing a CHR RAM tile pattern), and it can be done without a mapper (unlike bank switching), so it might be a good alternative if you are running out of tiles. I'm using it myself in my game for water animation.
Of course everything on the screen using the same subpalette will have its colors change the same way, so you need to keep that in mind if you want to go for this method. So one of the 4 subpalettes for tiles will probably have to be dedicated to water, unless you are OK with it cycling colors.
Hmm I guess it won't work so well with your current design since part of the ground edge will also color cycle.
Of course everything on the screen using the same subpalette will have its colors change the same way, so you need to keep that in mind if you want to go for this method. So one of the 4 subpalettes for tiles will probably have to be dedicated to water, unless you are OK with it cycling colors.
Hmm I guess it won't work so well with your current design since part of the ground edge will also color cycle.
- Jedi QuestMaster
- Posts: 688
- Joined: Thu Sep 07, 2006 1:08 pm
- Location: United States
- Contact:
Re: LASEReyes
No, and I've already maxed out on subpalettes: If we go with cycling the tiles, would updating every single tile at once be slow?
So far the animated water is just 3 tiles, and only one tile is ever present at one time: I see that SMB3 cycles tiles in the name table. Could that work here to make room? (I still need to add vertical creek tiles.)
Re: LASEReyes
Yes, if your virtual system uses bankswitched video memory, you could alternate between banks to create animated tiles. As a fun fact, the Neo Geo's video hardware has a feature where it can do that automatically.
If your virtual system does not use bankswitching, but uses RAM instead, then it'd be up to you to upload new tile bitmaps for each frame of animation, but you usually run into bandwidth issues which would limit you to maybe 1-4 tiles per update. Link's Awakening and Final Fantasy Legend II (both on GB) have their own ways of getting around this; GB Adventures of Lolo animates water using a completely different technique, where it continually sweeps the tilemap from top to bottom (one line per frame) to advance each water tile's animation frame.
If your virtual system does not use bankswitching, but uses RAM instead, then it'd be up to you to upload new tile bitmaps for each frame of animation, but you usually run into bandwidth issues which would limit you to maybe 1-4 tiles per update. Link's Awakening and Final Fantasy Legend II (both on GB) have their own ways of getting around this; GB Adventures of Lolo animates water using a completely different technique, where it continually sweeps the tilemap from top to bottom (one line per frame) to advance each water tile's animation frame.
Re: LASEReyes
Are you using those blue colors for beams or anything? If not you could cycle those two blues only and remove the green one from the water tile. Palette cycling doesn't necessarily need to use the whole subpalette.
Here are all the methods I could think of and their pros and cons (that I could think of):
I have never tried the bank switching method myself but I suppose that's what SMB3 is using. It is very powerful as it can do full-screen animations in a single register write, but it requires a mapper (though there are cheap mappers that can be made using discrete logic).
One reason I opted for palette cycling in my own project was that I didn't want to start thinking about mappers yet. Another was that I've always wanted to try the method, and it ended up working so well.
Here are all the methods I could think of and their pros and cons (that I could think of):
Code: Select all
Tile cycling
Using one tile per animation frame that is changed each animation frame.
+No mapper required
-May take up many tiles in the pattern table
-Can only animate a few tiles on the screen
Palette cycling
Using only a single tile and changes part of its subpalette each animation
frame.
+No mapper required
-Requires dedicated subpalette entries for the animation
-The tile's pattern must be carefully designed to work with this method
CHR bank switching
Switch out a whole CHR bank with new tiles each animation frame.
+Fast
-Requires a mapper that allows the needed amount of bank switching
-Affects all tiles in the switched bank so a lot of duplicates may be needed
CHR RAM animation
Modify the tile's pattern data each animation frame.
+Unlimited (as long as ROM space allows) number of animation frames
+No mapper required
-Slow (unless very few pixels are overwritten)
-Requires CHR RAM
One reason I opted for palette cycling in my own project was that I didn't want to start thinking about mappers yet. Another was that I've always wanted to try the method, and it ended up working so well.
What about a Dragon Ball-style beam clash? They could meet on the middle when close enough, protecting both sides from the respective opposing beam. You'd just need an extra tile or so for the beam knot where the two (or more) meet.Jedi QuestMaster wrote: ↑Mon Jun 05, 2023 10:22 pm I just realized--I don't know how lasers are going to overlap. Whether they cancel each other out or go right through each other, when two lasers are near enough, they occupy the same tile space before they intersect lasereyes_laser_overlap.png I'm already using 53 tiles for lasers. I can't imagine how many more are needed for every combination of overlap.
- Jedi QuestMaster
- Posts: 688
- Joined: Thu Sep 07, 2006 1:08 pm
- Location: United States
- Contact:
Re: LASEReyes
But then I'd only have two colors for the water, which I already did here, which hurts my eyes just looking at:
...unless I add more animation tiles, which defeats the purpose of this method (right?).
I looked at SMB3's pattern table on the map screen, and the animations are all happening there (there's even more stuff there that's not on the map!) I was already planning on using MMC3. If this method already lets me animate all the tiles, I might as well use this to fix the static part of the water that falls on the cliff edge tiles: What I had before:Pokun wrote: ↑Mon Aug 21, 2023 3:43 pmI have never tried the bank switching method myself but I suppose that's what SMB3 is using. It is very powerful as it can do full-screen animations in a single register write, but it requires a mapper (though there are cheap mappers that can be made using discrete logic).Code: Select all
CHR bank switching Switch out a whole CHR bank with new tiles each animation frame. +Fast -Requires a mapper that allows the needed amount of bank switching -Affects all tiles in the switched bank so a lot of duplicates may be needed
One reason I opted for palette cycling in my own project was that I didn't want to start thinking about mappers yet. Another was that I've always wanted to try the method, and it ended up working so well.
That could work. Instead of tiles, I'd rather use a sprite where the lasers meet, like this:Pokun wrote: ↑Mon Aug 21, 2023 3:43 pmWhat about a Dragon Ball-style beam clash? They could meet on the middle when close enough, protecting both sides from the respective opposing beam. You'd just need an extra tile or so for the beam knot where the two (or more) meet.Jedi QuestMaster wrote: ↑Mon Jun 05, 2023 10:22 pm I just realized--I don't know how lasers are going to overlap. Whether they cancel each other out or go right through each other, when two lasers are near enough, they occupy the same tile space before they intersect lasereyes_laser_overlap.png I'm already using 53 tiles for lasers. I can't imagine how many more are needed for every combination of overlap.
Re: LASEReyes
You can have about as many animation frames you want with color cycling. I just realized that this effect probably works best with all 3 colors after all, otherwise you might only be able to do that type of repetitive flashing patterns. You could use one static color and two animated colors that you change each animation frame (at about any rate you like). The static color can work like a background and by setting an animated color to the same as the static one you can make the animated one disappear if needed in an animation frame.
In your case you could use the green color as the static "background" and the two blue ones forms the changing foam patterns, so the green shore doesn't need to participate in the animation.
It should be fully possible to do the animation you've already done using palette cycling. You are not even limited to the 3 colors you have chosen, the two animated colors can have any color you want at any animation frame.
Also if you are not planning to have any sprites to be behind the background, you could use the backdrop color as a 4th color. It will show up at transparent pixels of the tile.
It might be easiest to simulate it in a pixel art image editor with an animation tool like Graphics Gale or GrafX2, and try various patterns.
But if you are sure you will use MMC3 you might as well go with that. MMC3 is not easy to use if you want to produce carts however since it's a custom chip.
And yeah a sprite for the beam clash is probably fine.
In your case you could use the green color as the static "background" and the two blue ones forms the changing foam patterns, so the green shore doesn't need to participate in the animation.
It should be fully possible to do the animation you've already done using palette cycling. You are not even limited to the 3 colors you have chosen, the two animated colors can have any color you want at any animation frame.
Also if you are not planning to have any sprites to be behind the background, you could use the backdrop color as a 4th color. It will show up at transparent pixels of the tile.
It might be easiest to simulate it in a pixel art image editor with an animation tool like Graphics Gale or GrafX2, and try various patterns.
But if you are sure you will use MMC3 you might as well go with that. MMC3 is not easy to use if you want to produce carts however since it's a custom chip.
And yeah a sprite for the beam clash is probably fine.