My first foray into making cinema displays

[Roth]

Well, my newest game has an intro cinema, and I thought I'd show you guys a video of it. It's not that long. There's no text during the cinema because I don't really think it needs it too badly, as the story itself is simple. Anyway, here is a link to the vid:

http://www.youtube.com/watch?v=M4o7Hskj-ck

[Zepper]

Uh... Resident Evil style isn't my pretty thing.

[strat]

Cool zombie at the end.

[Roth]

Cool zombie at the end.

Thanks man, though it's not my work. Crap, I forgot to post in the original post that my buddy Dave did the art for the screens. He did the intro screen graphics, plus the title screen zombie. He also did the art for the boss, and has so far done one of the ending screens for the game. He's pretty damn pimpin' : )

haha I love working with him, too. He's really laid back about it all, but whips out the graphics quick as hell. Great guy!

[Dwedit]

Don't like the glitches from turning the screen on at the wrong time.

[Roth]

Yeah, as far as I know, it only appears that one time, right?

Also, how do I avoid that? What I'm doing at that point is changing the sprites from the 'guy on the phone' to the 'guy looking at the screen'. For some reason though, no matter what I do, I get this jumping thing happening, and don't know how to work around it. If you have some advice, don't hold back : )

[Dwedit]

Don't turn the screen off during rendering if it's on, wait for an NMI before you turn it off.
If you have the screen off, wait for an NMI before you turn it back on.

I'll just assume you use that really simple NMI handler that just increments a byte in memory then immediately returns, and you are spinwaiting on that number to not be zero to wait for an NMI. Then of course reset the number back to zero right before the wait.

Code: Select all

;'vblanked' is an equate which points to a byte somewhere in the zeropage
nmihandler:
	inc vblanked
	rti
;example of code to wait for NMI
	lda #$00
	sta vblanked
waitloop:
	lda vblanked
	beq waitloop

[Roth]

Well, here is how I wait for a frame to happen:

Code: Select all

wait_for_nmi:						; A routine that we can use
	lda nmi_num						; in the main loop to make 
:	cmp nmi_num						; sure we are doing a frame
	beq :-							; through each loop.
	rts

See, this is something that I find confusing though. I've had a few people tell me 'wait for an NMI,' but I don't really understand how. See, this code above just says that an NMI happened already, not that things are ready to be changed and updated, etc. It's not like I'm in a blanking stage, if you know what I mean. Maybe I am and just don't understand the full gist of it, though. I don't know :/

[tokumaru]

See, this code above just says that an NMI happened already

Yes, the NMI routine is over, but whether VBlank is over depends on what was done in the NMI routine. If all you do is change that number, there certainly is a lot of VBlank time left.

It's not like I'm in a blanking stage, if you know what I mean.

You could be, depending on how much CPU time was used by the NMI routine. Many people don't do anything but change a flag or a counter, in which case the next 2200 or so cycles are still VBlank time.

I'm assuming you are only using that loop to prevent the game logic from jumping to the next frame before the current one is rendered, right? Well, if you do a lot of things in your NMI routine and can't be sure you're still in VBlank when returning from it (as could be the case if you called your music engine from it, for example), you have to find some other way to safely disable and enable rendering.

Maybe instead of directly manipulating the PPU register in the main code, you could use a flag to indicate if you want rendering on or off. Then, somewhere in your NMI routine you are sure is still during VBlank, read that flag and write to the PPU accordingly. That way, your program can issue orders to enable or disable rendering at any time, but they will only be executed at safe times.

[Bregalad]

This looks kind of Ninja-Gaiden style.
It's pretty cool btw but the graphics could be better.

[albailey]

I think it looks good, and I like the style of graphics.
How did you do that scroll part. Are some of those sprites?

Al

[Roth]

This was heavily influenced by Ninja Gaiden, actually. Though of course it's not as stellar as that is, but once again, my baby steps hehe

Thanks Al, and yeah, the main character is all sprites actually. The nametable at $2000 is all blue with the black top and bottom, and and the nametable at $2400 is all blue with the black top and bottom, but also with the zombie shadows in there. This way they can be offscreen, and I can push them onto the screen and also have the main character as sprites to move around. I didn't have any plans to try and insert words during it, so I didn't have to bother with figuring out how to do some zero hit stuff to scroll the cinema area; the entire screen scrolling worked fine for this case : )

[Banshaku]

Nice intro for your first one. I can't wait to make some too! First I need to make the artwork thought (...).

[Bregalad]

This was heavily influenced by Ninja Gaiden, actually.

Yeah, this is really obvious, but still looks cool. I think the main character doesn't look very good, it could be improved I guess, but it's just my guess. The zombie on title screen looks really impressive tough.

I'd like to come with a method of making cinematics on the NES that would be a little different than what Ninja Gaiden does, but for now I can't do any in my current game (else I'd have to change the mapper it uses to get more CHRROM). I'd probably do it in further games.

[noattack]

tough crowd around here, roth. i say great work!