This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

use the background or sprites?

use the background or sprites?
by on (#17996)
here is a picture:

problem.jpg

how does Harry get across the pit alive? any suggestions whether i should use the background or sprites to render the vine. i'm leaning more towards sprites, but i really don't want to waste them on a vine.

by on (#17997)
Use sprites, when they're laid out verically, you don't encounter sprite limits per scanline. I can't think of anything else which would need sprites, since the crocodiles don't move.
If you want to do it with BG tiles, you might have to update a lot of tiles per frame, cutting into your vblank time.

by on (#17998)
How does Donkey Kong Country do it?
Re: use the background or sprites?
by on (#17999)
never-obsolete wrote:
how does Harry get across the pit alive?


Maybe it's one of the screens where the swamp will just disappear if you wait a while? :lol:

But yes, I'd also think sprites would be better suited :)

BTW: A friend of mine once reverse-engineered Pitfall, if you haven't seen it yet: http://www.bjars.com/source/Pitfall.asm

I have written several VCS games myself, so I could possibly help understanding concepts from that source code.

by on (#18002)
What Dwedit said. An example is Circus Charlie, using sprites for such an effect in the rope level, without shimmering:
http://home.planet.nl/~haps/crap/ninten ... harlie.png

by on (#18012)
Battletoads cycles the sections of the rope so as to not waste many sprites with this:

Image

I don't think this is your case, though (and a vine will look worse than a rope when flickering). There aren't many sprites on the screen (meaning you can use a good deal of them for the vine), and since the vine is mainly vertical, you won't get any flickering from sprite cycling.

As for how you arrange the tiles, the easiest way would be to use circles, but that looks kinda odd for a vine. I guess that having a few line patterns in different angles would make the best impression. The vines in Sonic 3 on the Megadrive/Genesis looks pretty good. I don't remember exactly how they do it, though...

by on (#18013)
The best way graphically would have to pre-render the wine with different angles, but it would waste pretty much a lot of sprites.
Donkey Kong Country does everything with sprites, but the SNES has a lot more sprites than the NES has.
I think use several different tiles with different angles can look more or less good in function of how you use them (I think the clocks in the second level of CastleVania III looks wrong).

Doing it in BG may seem harder, but it seems like a quite interesting technical challenge, and that is fun too.

by on (#18014)
The walker in Battletoads achieves smooth leg movement with only four different 8x8 tile images: vertical, one split down the middle, two splits (giving uneven 2-3-3 sections), and four:
Image

by on (#18015)
Bregalad wrote:
Doing it in BG may seem harder, but it seems like a quite interesting technical challenge, and that is fun too.

Nah... waaay too much trouble for that. If the background (behind the vine) was completely empty, I guess it would be an option. But since the vine waves in front of the trees, it would be too complicated, would use a lot of tiles (since you have to account for different part being overlaped) and would be hard to update on the name table (because of the irregular shape).
Re: use the background or sprites?
by on (#18021)
Dwedit wrote:
I can't think of anything else which would need sprites, since the crocodiles don't move.

they actually use sprite because i may need them to move. i haven't decided if this is going to be a straight port or not. in which case i may need the extra sprites the vines use.

Cybergoth wrote:
Maybe it's one of the screens where the swamp will just disappear if you wait a while? :lol:

that screen actually is one, but i used it as an example anyways.
Re: use the background or sprites?
by on (#18024)
never-obsolete wrote:
in which case i may need the extra sprites the vines use.

I was looking at some 2600 screenshots of Pitfall, and the vines don't start from the top of the screen as I thought they did (you probably know that, 'cause you're the one doing the port and you must have studied the original a lot!). That means that the area covered by the vines is actually pretty small, so I believe it can be represented with few sprites. I guess it would be at most some 48 pixels tall, wich would need only 6 8x8 sprites (making the vines out of 8x16 sprites would be more complicated, IMO), and that's not much at all.

If you make them somewhat "pixelated", as they used to be on the 2600, you could have 4x4 "pixels" within each tile, and just a few patterns such as these:
Code:
...o  ...o  ..o.  ..o.  .o..  o...  o...
..o.  ..o.  ..o.  ..o.  .o..  .o..  .o..
.o..  .o..  .o..  ..o.  ..o.  ..o.  ..o.
o...  .o..  .o..  ..o.  ..o.  ..o.  ...o

could be enough to make all the needed angles. One half could even use the same patterns as the other, and just flip the sprites when needed. So I guess only 4 patterns is enough.

I don't know how you'd code this animation, though. I can't think of any logic that would define the correct tiles to use for each section, and how much to displace them in relation to the previous section based on the angle, so maybe this animation will have to be hard-coded... Or maybe you could have some sort of line drawing algorithm, so as you calculate the "ideal" line with it, you check how much the line dislocates within each section (4 "pixels") and you can pick the appropriate tile to use there, one that displaced just as many pixels. Just an idea.

by on (#18038)
tokumaru wrote:
I don't know how you'd code this animation, though.


i have a variable that contains the frame index into the animation and the direction. the data for the animation is just an array of Y,T,A, and X values for each sprite of each frame. there are five in all which are then mirrored to go the other way. seeing how i have an abundance of prg-rom, storing 5 frames of data rather than calculating it wasn't a problem.

by on (#18039)
You could go the semi-lazy route and just keep the same tile for every sprite, that being a completely straight vertical line. It'd look a little terrible, but not SO terrible. You can have some predefined path for the rope, like this:

swing:
.db $01,$08,$02,$07,$03,$06,$04,$05,$05,$04,$06,$03,$07,$02,$08,$01
;This is for the first half of the rope swing

Where each byte alternates between x and y pos additions for 1 sprite. At the beggining, it adds 1 to the X pos, and 8 to the Y pos to get the first frame of animation. Then it adds 2 to the X pos, and 7 to the Y pos for the next, and eventually you'll either have to have a routine that subtracts these values instead of adding them for the second half of the rope swing, or you'll have to add like $FE to the Y pos to get the same result as -2 to the Y pos. And for every sprite going up the rope, subtract an animation from each end. It's just an idea I whipped up. If you don't understand, and you want to understand, I can try explain it in different words if you'd like.