Learning NES Pixel Art with restrictions

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by tokumaru »

Fjamesfernandez wrote:
Also, how in the world do you plan on accomplishing that translucent bumble bee thing?
I just did that for sure. if through code you can fade things in and out im guessing this will be okay. if not then you can flicker it to show that its spawning and solid when you can start attacking it.
Fading is completely different from translucency. Fading is accomplished by darkening/brightening the colors, and while this may look like transparency revealing the black color underneath, this is not actually the case. Alpha transparency is a very complex concept, that even the SNES and Genesis struggle with, and there's certainly nothing like that on the NES.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Drew Sebastino »

tokumaru wrote:Alpha transparency is a very complex concept, that even the SNES and Genesis struggle with
Well, it's a hardware feature on the SNES, even if it is relatively limited. It's generally better suited for BGs than sprites, and I can think of plenty major commercial games that use it, most notably the DKC games. However, I can't think of many games that use alpha channel sprites. One kind of cool, although limited, effect is found in Firepower 2000 which always has transparency for sprites on is that whenever an explosion happens, it is at first opaque, but then uses the transparent palette for when it is fading away. palettes 4-7 are exactly the same as 0-3 to allow effects like this. However, I've never understood the Genesis's shadow and highlight modes. I think I remember hearing something about how it either halves the color values of something or doubles them. Also, does this only work for sprites, because I remember messing with the Sonic 3 and Knuckles debug mode and moving around a transparent waterfall slap sprite.

But yeah, the NES doesn't have anything like this in hardware. In fact, I'm pretty sure that even most "16 bit" arcade machines didn't. If the Neo Geo had SNES alpha transparency capabilities for sprites, it would be totally useless, because it would clip through everything. :lol:
User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by darryl.revok »

what I meant when i said 128x128 was the 8x4 box (the color palette radius) so I really mean is the what is it 250x240 players view. So think 250x240(view) x 4(view panels for scrolling)
I'm not sure what you mean by this, but you can use a different palette for every 16x16 area on the background.

You can use a different palette for every 8x8 sprite.
Yeah I was trying to avoid having too many sprites on screen, but I guess it will be fine as long as I place the spawners in a way that wont cause scan limitations.
You don't have to actually have an associated sprite to make it an object hitbox instead of a background collision. You could have the spawner in the background and just have a hitbox above it that the player won't see. Just an invisible box over where the spawner is in order to test for collisions.
It was driving me crazy that it couldnt have its own palette to begin with
It can. As I said, a 16x16 area is the smallest background area that can have a color defined.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by tokumaru »

Fjamesfernandez wrote:Yeah I was trying to avoid having too many sprites on screen, but I guess it will be fine as long as I place the spawners in a way that wont cause scan limitations.
Whether an object is drawn with sprites or background tiles is just a detail of its graphical representation. The object should be spawned regardless of how it's drawn. It can have a hitbox and its own behaviour even if doesn't use any sprites.

As for making a background object flash, there are several ways that can be done. The most obvious is to redraw the tiles at the same rate of the flicker. If the object is small enough and you're not using much of the vblank time for other things, this should be easy. Another option would be to make sure that the colors used by the object itself are not used anywhere else in the background, and then you could simply change the palette to make the object flash white, or whatever color you want. Yet another option is to overlay white sprites with the same shape as the object over it, only when necessary, so you only affect the sprite count temporarily.
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

tokumaru wrote:Fading is completely different from translucency. Fading is accomplished by darkening/brightening the colors, and while this may look like transparency revealing the black color underneath, this is not actually the case. Alpha transparency is a very complex concept, that even the SNES and Genesis struggle with, and there's certainly nothing like that on the NES.
Gotcha, was trying to see if i can trick this :D
Espozo wrote:But yeah, the NES doesn't have anything like this in hardware.
So in all honesty flickering it in for a spawn animation would do best.
I'm not sure what you mean by this, but you can use a different palette for every 16x16 area on the background.

You can use a different palette for every 8x8 sprite
This is what i meant. each square is the coloring radius for the BG. refer to the attachment :P I may be overly complicating things on this.
tokumaru wrote:As for making a background object flash, there are several ways that can be done.
Yeah I was running that through my head of the things youve mention. If it was BG it would had shared that palette because of how I made the BG itself. so making it a sprite would be the best thing to do. its kinda crazy how its easy for me to make an over head BG but when it comes to side scrolling BG for some reason i get stuck. that makes no sense to me lol
Attachments
radius-sample.png
radius-sample.png (1.15 KiB) Viewed 10350 times
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by tokumaru »

The only problem with outright making them sprites is that there's one on each side, and if the player and the bees happen to be up there as well, there will definitely be significant flickering. If you don't mind that, it's OK.
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

yeah dont worry it was just a mock up. it wont be like that. I was just trying to get my ideas out on paper or should i say photoshop :D
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

Setting things up on the first stage. Im trying my best to plan things out so that it doesnt go crazy with the palettes. Stupid question but will that door be easy to operate for a BG? the colors arent final i know that ladder will cause issues if thats a BG tile. im just using any color then change it later.
Attachments
planning.png
planning.png (3.66 KiB) Viewed 10288 times
User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by darryl.revok »

Not necessarily easy, but it could be done. I imagine you'd have to keep track of where those tiles lay in the nametable and update them each frame. You'll have to store tiles for every position in which the door will be. So you'd need a tile for each pixel movement. It doesn't look like a door that would move quickly.

The moving collision detection would take a little work. One method would be to put a moving object over top of the door. I haven't personally done ejections from objects though, so I'm not sure how that works. Ejection from tiles is usually done by determining the distance to the next multiple of 16 pixel location. I suppose you could use the width of both hitboxes to determine a suitable ejection location for x axis and likewise with hitbox heights and y axis.

I've never done this personally so I wonder if anyone has any other suggestions. I don't think it would be too hard.
User avatar
dougeff
Posts: 3078
Joined: Fri May 08, 2015 7:17 pm

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by dougeff »

moving object over top of the door
Yes. I suppose you could make the very bottom of the door a sprite (a few sprites). That would smooth the door's movements, and you could calculate collision based on the sprite. But, now that I look at your door, that wouldn't look right...only if it was a plainer looking door. For your door, it will probably have to be a background object.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by darryl.revok »

I believe that's how they draw the beams in Quick Man's stage.

The spikes on the side of the door make this one a bit different though. It wouldn't really work quite like that.

I was thinking more like the sides of Battletoads lvl 2 or kind of the way Metal Storm does parallax.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by tokumaru »

Is a 2-tile wide door really worth the trouble? Is there an actual reason to make it part of the background?
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

So you'd need a tile for each pixel movement. It doesn't look like a door that would move quickly.
Nope would move slowly.
The spikes on the side of the door make this one a bit different though. It wouldn't really work quite like that.
Those aren't spikes on the door so you dont need to make any hit colisons there. Its only the bottom that has the spikes, but i can take the two spikes off from the bottom.
Is a 2-tile wide door really worth the trouble? Is there an actual reason to make it part of the background?
I can make it one tile wide. I just made it two so that I can add more details like the bolts in the middle and I would think making it BG and not a sprite would be better so we can add more stuff sprite wise. but things can change. everything isnt set in stone :P im just planning it out atm.

And just incase people are wondering, NO the BG wont be black its just a transparent color im working with right now. all of that will be filled. I am putting all the obstacle stuff out there first.
User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by darryl.revok »

Those aren't spikes on the door so you dont need to make any hit colisons there. Its only the bottom that has the spikes, but i can take the two spikes off from the bottom.
I wouldn't take them off. The ones on the bottom aren't really an issue either way.
I can make it one tile wide.
I don't think you need to reduce the size of it to make it a sprite object. I think was Tokumaru was saying is that it would very easy to move on the screen if it was a sprite object. It can still be two tiles wide.

Moving an object inside of the background is a relative pain vs. moving an object, and to move a background object smoothly requires a lot of graphics.

Two tiles isn't that bad for the 8 scanline limit. That's probably going to be the width of most enemies and the player. A little bit of flickering is almost inevitable for most action games.

I guess if you got done with the game and had plenty more room for graphics and enough time to work on little tweaks, you could move it to a background object to reduce flickering, but I would push it to the back of the goals.
And just incase people are wondering, NO the BG wont be black its just a transparent color im working with right now.
If you want to find some inspiration for organic style backgrounds, two examples that come to mind are R-Type and Lifeforce
User avatar
Fjamesfernandez
Posts: 57
Joined: Thu Oct 01, 2015 5:34 pm
Location: NYC

Re: Learning NES Limits, Pixel Art, & wat can & can not be d

Post by Fjamesfernandez »

I don't think you need to reduce the size of it to make it a sprite object. I think was Tokumaru was saying is that it would very easy to move on the screen if it was a sprite object. It can still be two tiles wide.
Gotcha, I did resize it and took off the bottom spikes but I always have the original design in a seperate layer any ways in cause I got back to that.
I guess if you got done with the game and had plenty more room for graphics and enough time to work on little tweaks, you could move it to a background object to reduce flickering, but I would push it to the back of the goals.
Yeah its a bit tricky but worth to try both and see what happens instead of ruling it out.
If you want to find some inspiration for organic style backgrounds, two examples that come to mind are R-Type and Lifeforce
Cool Ill check those out. Been a while since ive seen R-type

ignore that pink outline. thats just a note for me to where the Door needs to stop. If you see when opening the door it blocks you from the chest but keeping it closed after you go through you wont be able to make that jump. Though there will be some power-ups throughout the stage to help you in situations where you need to fill in that gap.
Attachments
planning2.png
planning2.png (3.93 KiB) Viewed 10225 times
Post Reply