I just love to figure out how NES games achieve some great looking effects, that most of the times don't look NESish at all. Effects involving palette changes, bankswitching, sprite priorities, scrolling, timing, etc.
But there are some I just can't figure out. Does any one have a clue on how does the 3D floor in Cosmic Epsilon work? I could see it is more complex than the one in 3D World Runner, wich had only 2 colors and fixed size squares. Cosmic Epsilon actually had patterns on the floor, like streets, oceans and such. I think it involved some bankswitching, but that's it.
It also took me a while to discover how most racing (F1) games used to give the impression of a road moving. I thought: "How does this game change the palette every few scanlines without visible glitches?". But then I learned they switched to a CHR bank wich had the road with the desired colors, instead of changing the palette. I guess this is because in the beginning I had the idea that bankswitching was something slow, and wouldn't be done several times in one frame. But now I now it is not actually "switching", the cart just looks for the graphics/data somewhere else. In fact the word "switching" is very misleading, IMO.
But, still in the subject of special effects, does anyone want to point the ones they think deserve some attention, the ones they like? I like to see how the coders were smart to make it past the obvious limitations of the NES and come up with something that looks good.
If you go to the PD roms competition link on the main site, you can look for Chris Covell's Stretch demo which I gave a 10 out of 10 because that was very very very cool. I'm not sure how he did it, because he does his NES demo's with DASM 2.12 running on Amiga, and um, I'm not to familiar with any of that, because 1, I don't know anything about Amiga, and 2, DASM hates me, and never works for me. But yeah, check that out. He makes a 3D kind of look. It looks crappy on Nintendulator, because there's a whole bunch of lines all over the place, but run it on JNES, and awe at the awesomeness of it. I'm sorry, I just thought it was cool. Check it out.
http://www.pdroms.de/database/files/NES/Techdemos/Stretch%20Demo%20by%20Chris%20Covell.zip
Celius wrote:
It looks crappy on Nintendulator, because there's a whole bunch of lines all over the place
...just as it does on the real hardware. Chris Covell is aware of this, but he didn't want to bother fixing it.
The stretch demo is indeed very cool. There is onother one I also like very much, with a green text in the middle of the screen (I can't remember what's written) that keeps fliping and there is a reflex of the whole thing at the bottom on a surface that looks like water, or something...
Quietust, do you know exactly what causes the glitches in the strech demo? I always thought this demo was so cool that it is a shock to know it does not run well on hardware. So it might be a good thing to know what's wrong...
I'd guess that no mapper = no irq. No irq = crappy scanline timing based effects.
Yet Rare did a good job pulling them off in slalom with no mapper, and very few emulators (nintendulator, nestopia, possibly others) supports slalom's track effect.
I tried to figure how the mega-FF1 orb beam was made. I eventually got that this is pretty easy to do. Just be sure to turn the color emphasis / grayscale bits at a fixed point on the screen, then wait for a few cycles depending on how much large is your beam, to eventually turn it back on. The whole thing would be 113 cycles if you want a beam going one pixel back, or 114 cycles if you want a beam going two pixels further per scanline. Other values are possible for beams that would become closer to the horizontal line. A disaventage of this is to not be NTSC/PAL compatible, without changing the beam's direction.
A cool effect I had in mind would be to split the whole screen in two with a similar algoritm, switching pattern table via $2000.
Another cool effect would be to make clipping, aka to turn the screen off during a scanline and turn it on back in HBlank, to make an effect like when you enter in a battle in the SNES game Fire Eblem 4 - Seisen no Keifu.
Bregalad wrote:
The whole thing would be 113 cycles if you want a beam going one pixel back, or 114 cycles if you want a beam going two pixels further per scanline.
Actually, 113 cycles would go 2 pixels back and 114 cycles would go 1 pixel forward. Remember, the NES CPU executes 113+
2/3 cycles (341 / 3) per scanline.
Right.
Overall, 111 will be 8 pixels back, 112 5 pixels back, 113 2 pixels back, 114 1 pixel forwad, 115 4 pixels forwad, 116 7 pixels forwad, etc...
The whole thing should be rewritten with different timed cycles for PAL format, and probably other beams are possible.
Oh my god. That demo, loopy, was AWESOME! That looked SO COOL! I think if we were back in the day like in 1985, and we saw that shit, we would say, OH MY GOD! BEST GRAPHICS EVER! Okay, a little overboard there. Very very nice job! love it!
Yeah, the demos are really cool, loopy! The firefly one seems very hard to emulate... do you mess with the color emphasis bits twice every spotlight scanline? Timing seems hard on this one...
The "unfinished" demo is very nice too! Love the dancing bars! =)
I'd like to input something like FireFly in a dark RPG place, where the light would follow the hero (scince the hero is always in the center of the screen, this could be simpler). Or for a RPG where the screens stops to move when you walk on a border of the map, the hero will moove then.
I rally can't understand at all what in the world is 5 independant scroll aeras.
loopy wrote:
I made another demo with 5 independant scroll areas (3 vertical strips+2 horizontal). I seem to have misplaced it, unfortunately...
I believe this is the one you are referring to:
http://www.qmtpro.com/~nes/misc/demo3.nes
Interesting, but it actually uses ugly code that will never return from an interrupt, and the tiles that are on-screen aren't very good-looking. I think this one should be improved.
Another challenge would be to use only an UNROM card or something and does this with CHR RAM. I really like games that modify CHRAM to do special effects. I'd like someday to make a game where every player and monster is just some tiles from CHRAM that are getting re-written regulary to allow more animation frames and more flexibility while mazing sprites. I think this is very hard to do, even with the PAL format that can have more VBlank time, it would need precise calculation so a different moving object could be re-calculated each frame, but not all at the same time so the whole thing become possible.
Bregalad wrote:
Another challenge would be to use only an UNROM card or something and does this with CHR RAM.
Pretty much every PC Engine game with parallax scrolling uses this technique. When I first saw demo3, I thought to myself "I can name that tune in five tiles of VRAM."
Quote:
I'd like someday to make a game where every player and monster is just some tiles from CHRAM that are getting re-written regulary to allow more animation frames and more flexibility
I've written
an article about this technique targeting the GBA. A custom mapper that uses data latches to allow writing to VRAM through CPU$5000-$5FFF to simulate GBA style dual-ported VRAM might be useful for this.
tepples wrote:
I've written
an article about this technique targeting the GBA.
me and some friends did a little gba demo for like a year ago using that technique. I thought it was rather common to use it on the gba, is it?
I really ask myself why EVERYONE is speaking about GBA dev in there. You know, here is basically the NES dev thread, and I think it's interesting to compare the NES with different hardware. But why are everyone speaking about the GBA ? I've nothing against the GBA (exept that a blue line of pixels constantly appears vertically on the middle of the screen on mine, and it appeared just after the warranty has been expired, this is pretty much terrible), but I know absolutely nothing about GBA dev, and everyone speaks about the GBA as if GBA dev would be very comon to everyone.
I agree. Why does everyone speak about GBA dev? I've looked for tools for GBA dev, and I've found nothing. No graphics editors, no roms, no emulators, or anything. And everyone's just like, "oh yeah, that's how you do this on gba blah blah blah blah blah". And I'm just saying that this is NESdev, and not GBAdev, so don't speak of it here! No, memblers should probably create a GBAdev forum, and we'll all be happy. I don't know what I'm talking about, so I'm going to stop.
if you're referring to my post then I'm sorry. If I could remove the message I would.
I'm not reffering to any particular post, but it's by far not the fist time this happens. I'm not particulary scared, but rather confused. Many times I saw blah blah balh, just like the GBA when blah blah blah. Some people may be used to gba dev, but not everyone in there. If you want speak about gba dev, just go on
http://www.gbadev.org which is the equivelent to this site for the gba.
I'm not against to compare how thing works on a console or like on another, but I'm against something like "Just do like we do on the gba" like if it was common and understandible for everyone. I think if you go on gbadev's forum and, for example, ask a question about graphics, and say "yeah, it's just like doing sprites with $4014 on the NES", I'm pretty sure that not everyone there will understand, but if you say "the NES also have a similar DMA feature for the sprites, I think it's better than....." it would be better.
Overall, the particular post above isn't much scaring, even if it is not as addictive that it would be supposed to be, but I remember some other thread on the hardware section that would put 3.3 V flash chips "like the GBA", or doing another thing "like the GBA" that I have even no idea what it is. That's rather scaring.
Another confusing thing is that, on the other thread, a discussion about the SNES seems to be prohibed, even if the SNES is a lot closer to the NES than the GBA, but everyone is always talking gba in there. That's just it. Okay, tepples is a guy comon in gbadev and nesdev, but is that enough ?
Sorry, this is RANDOM, and has nothing to do with this forum, but who do you think is the most well known person in the world of NESdev? I'm thinking either kevin horton or marat fayzullin. Maybe y0shi. Who do you think?
Celius wrote:
Sorry, this is RANDOM, and has nothing to do with this forum, but who do you think is the most well known person in the world of NESdev? I'm thinking either kevin horton or marat fayzullin. Maybe y0shi. Who do you think?
Shigeru Miyamoto.
Yeah, but I mean like people in the world of homebrew nesdev. otherwise, he would be very popular.
Even worse than occasionally mentioning parallels to GBA programming is thread hijacking for a different topic, as is happening to this thread right now. This thread is one of the worst:
homebrewn NES game release: NeSnake 2.
blargg wrote:
Even worse than occasionally mentioning parallels to GBA programming is thread hijacking for a different topic, as is happening to this thread right now. This thread is one of the worst:
homebrewn NES game release: NeSnake 2.
LOL you're so right. By the way... what's the universe ?
Sorry for bringing up this old dead thread, but I was just going to say that I was officialy impressed when I saw this game that I borrowed from someone, it's called Al Something jrs Turbo Racing. Oh my gosh. I'm more impressed at this than Cosmic Epsilon. This gives you more 3D than Mario Kart on SNES. There's a concept of hills! You round corners and whatnot. You can go up/downhill. Go download the ROM, you'll be impressed.
since we're back at this, there is one game that got my attention immediatly: Bucky O'Hare.
It is not impressive in a "distortion" or "3D" kinda way, wich is what usually gets more attention. The game is a platformer, (my favorite kind of game!) and applies a lot of little effects to make the NES look less lame when compared to the 16-bit consoles of the time.
The ice level has a nice layer of water that moves, and what's below it has a darker tone, simulating dark water. And if that's not enough, there are some sprites (frozen chunks?) floating by to increase the effect of transparency.
The game does a lot of parallax scrolling and simulates layers by animating background tiles. It combines parallax with sprites so you think huge moving objects can overlap. It has some huge background animations, that you don't usually see on the NES, as it is so slow to update the BG.
I can't even remember half of the cool stuff present in that game. Just run the game and don't even play, watch the demos first. I was amazed. That game is a serious competition to 16 bit games.
And it is not only pretty to look at. As a platformer fan I found that very amusing too. Each level has a unique gameplay, the bosses (the ones I saw) are nice too. You can change characters during the level, characters who have different abilities.
It easily bacame one of my favorite NES games.
Yeah, such effects are interesting.
However, the games looks absolutly impossible to beat even the stage supposed to be the easiest, that I can beat only with using a lot of savestates, and bossbattles looks impossible at all.
Yeah, I could beat levels only by using savestates too. The first boss battle (the guy with the huge rocks) is easy, but the one in the blue planet (aligator with missiles) is just impossible to beat before hitting the spiky ceiling.
I guess I'd be a little frustrated if playing it without the aid of savestates. Still seems to be a really cool game, though. There are some good walkthroughs for it at gamefaqs.com.
Quote: 2, DASM hates me, and never works for me (quote button doesnt work)
Well, compile with switch -f3.
tokumaru wrote:
Yeah, I could beat levels only by using savestates too. The first boss battle (the guy with the huge rocks) is easy, but the one in the blue planet (aligator with missiles) is just impossible to beat before hitting the spiky ceiling.
I guess I'd be a little frustrated if playing it without the aid of savestates. Still seems to be a really cool game, though. There are some good walkthroughs for it at gamefaqs.com.
it was frustrating at times, but not impossible, i remember i did complete it
For real ? Oh man, I can't beat it even using savestates and frame by frame emulation. I'm in a place where everything is black, and it's just impossible to guess where to go without falling.
Bregalad wrote:
For real ? Oh man, I can't beat it even using savestates and frame by frame emulation. I'm in a place where everything is black, and it's just impossible to guess where to go without falling.
On those parts, once you appear on the screen, just start running and jumping where you see you need to. By the time it turns black, you should be around the end of the screen. There's a few screens like that in a row... just keep moving non-stop
Now I'll try and get back on topic... I'm not sure if this would be considered a special effect, but I noticed something cool on the first level of Zen: Intergalactic Ninja. When you are at a certain position on the screen ("closer" to the bottom of the screen) and jump, the sprites switch up to bigger sprites to make him appear to come at the screen. I always thought that was a pretty cool effect.
I'm now in front of the boss just after that black section, actually, using a lot save states makes that section possible, but I canot even imagine beat that without savestates.
Now the boss looks just impossible, damage it is nearly impossible and avoid its mini-missiles attack is even more harder.
About special effects, I always asked how hard would be to make animated BG witout using tile animation via CHRAM or CHROM, but doing it with organized nametable writes. Typically, in my MMC5 RPG, I won't be able to do CHRAM animation because of exgrafix mode, but I'd be able to change the high offset of each tile during a frame (not in VBlank) like Just Breed does and/or to change normal tile index in VBlank.
I'd also like use the fact that a black sprites in backround with higer priority hides a normal sprite in foreground with lower priority to allow my player to pass behid threes and stuff, having it a multi-layered look. The main problem is that with 8-sprites per line limitation and sprite cycling that will be hard to do. Having a 64 byte buffer that would be randomly acceded significantly to assign a correct number to each sprite with still the defined priority would be the only way to bypass it. 64 bytes of RAM is tolerable for a game using SRAM, however it's a lot for a game with only 2kb of RAM without SRAM.
Bregalad wrote:
I'd also like use the fact that a black sprites in backround with higer priority hides a normal sprite in foreground with lower priority to allow my player to pass behid threes and stuff, having it a multi-layered look. The main problem is that with 8-sprites per line limitation and sprite cycling that will be hard to do.
I'm planning on doing the exact same thing in my platformer, so the player can go behind objects AND these objects can have interesting shapes, as long as you use some of the sprite pattern table for the respective masks (or even BG tiles, if using 8x16 sprites).
The problem with this technique, as you said, is the low limit on sprites per scanline. And masks MUST be present if the sprite they're masking is. So, each mask means one less visible sprite (having the masks always present, not including them in the cycling, I guess). It sucks. But I guess the final effect is worth the pain to handle this.
In SMB 3 you can move behind the retangular areas in one of the early stages. You need to find a white rectangle platform and press down for moment, Mario then falls behind the rectangular structures, even the end of the stage background. The effect only lasts a few seconds but it was one of the coolest things I have ever seen in a NES game at the time.
I think that the sprites hiding the players or maybe people of a RPG town or enemies of a platformer may easily be disabled if nobody is behind them. Scince someone is behind them (even only a part), they should be present, and then only the sprites with lower priority should be cycled, anyway, so they'll always be present even if the sprites they're hiding are disabled because of scanline limitation.
I think doing plaing effect should be first set trough the background bit of each sprite's status, and only if the stage's graphics really needs it, to use that method.
Super Mario 3 just uses the Mario sprites' priority bit. Problem with using the priority bit is that you can't have a single sprite both in front of and behind a tile, so you have to make your backgrounds with solid colors in order for it to work that way.
mapper 69: Batman - Return of the Joker, looks nice, using huge sprites, and lots of 'background-over-sprites effects', eg. in the 2nd level.
I agree that Batman Return of the Jocker has impressive graphics, but the gameplay SUCK. I mean, when you press jump, batman takes at least one half of one second to actually jump, and the same for attack. It just sucks. So I'd MUCH preffer smaller sprites, because big sprites (often) ruins the gameplay. What about the failure of Battletoads in battlemaniacs on the SNES ? The games takes the same characters than in the NES battletoads games, but this time your toad will nearly have the same size as your screen does. How fuck.
Also, Megaman 7 is totally ruined by the fact that the sprites are too big, making boss-battles impossible, scince you'll get more hits (megaman is bigger), and you'll get even more hits (the boss is bigger), and you'll take more hits above that (the boss attacks has a bigger range), of course, the screen still have the same size than it was on NES.