It is currently Sun Oct 22, 2017 9:27 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 24 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed Jun 29, 2016 6:29 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19116
Location: NE Indiana, USA (NTSC)
I have an NTSC NES + PowerPak. This means I too can perform tests that don't involve PAL, power-up state, or open bus.


Top
 Profile  
 
PostPosted: Wed Jun 29, 2016 6:34 am 
Offline
User avatar

Joined: Tue Jun 11, 2013 1:04 pm
Posts: 49
dougeff wrote:
Regular game play for the first 180 -ish lines. Sprite zero hit, rendering off for about 8 lines, X and Y scroll changed, rendering back on...HUD displayed for 32 lines, then rendering off to the bottom of the screen

When your sprite0-check is at the bottom of the screen, you must make sure that your main game loop does not take too much time, right? Or do you have a trick to avoid this need?


Top
 Profile  
 
PostPosted: Wed Jun 29, 2016 7:10 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19116
Location: NE Indiana, USA (NTSC)
I know of two ways to keep a bottom status bar rock solid on a mapper without a PIT:

  • Estimation
    For each actor handler, estimate how long it will take in the worst case, using data from an emulator instrumented as a profiler. Add the estimated time of all actor handlers to a counter. If the next actor's handler won't fit, spill the remaining computation over to the next frame and wait for sprite 0. I think Gradius uses this.
  • DMC as timer
    Don't play sampled drums or sound effects. During the NMI handler, start a silent sample on DMC timed to finish just above your status bar, and have it fire an IRQ on completion. Wait for sprite 0 in an IRQ handler. I think Time Lord uses this.


Top
 Profile  
 
PostPosted: Wed Jun 29, 2016 7:34 am 
Offline
User avatar

Joined: Tue Jun 11, 2013 1:04 pm
Posts: 49
Yes, ok, I know of the DMC timer. (which is probably the way to go)
For a game like Gradius, the estimation code could count the amount of enemies and bullets. Intersting idea, but painful... :)


Top
 Profile  
 
PostPosted: Wed Jun 29, 2016 8:16 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1787
Location: DIGDUG
Re-uploading all the demos. All were tested in emulators and real NES. All are stable.

Demo 1. Midscreen X/Y scroll split, producing glitches. Press 'start' to hide glitch with sprites. I reduced the sprite count to 3.

Demo 2. Midscreen X/Y scroll split, no glitches. Timed with a sprite zero hit. Split occurs during Hblank to avoid glitches. Up/Down moves the sprite zero position.

Demo 3. Midscreen rendering off for several lines, then midscreen X/Y scroll split, no glitches. Timed with a sprite zero hit. Split occurs during Hblank to avoid glitches. Up/Down moves the sprite zero position.


Attachments:
Glitch2.zip [6.79 KiB]
Downloaded 27 times

_________________
nesdoug.com -- blog/tutorial on programming for the NES
Top
 Profile  
 
PostPosted: Wed Jun 29, 2016 8:25 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1787
Location: DIGDUG
Interesting side-note. There is a slight audible buzzing sound (Powerpak to NES) when the sprite zero was in a certain range on the screen. I'd say between scanlines 210-230.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Wed Jun 29, 2016 8:32 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1787
Location: DIGDUG
Quote:
When your sprite0-check is at the bottom of the screen, you must make sure that your main game loop does not take too much time, right? Or do you have a trick to avoid this need?


In the current project I'm working on, there is too much logic that occurs before sprite zero hits, and also not enough V-blank time to do all the PPU updates I need, so I've dropped down to 30 fps, and I do half the things each frame.

V-blank - half of the PPU updates
top screen - half of the game logic
sprite zero hit - screen split
a little more logic at the bottom

V-blank - second half of PPU updates
top screen - second half of game logic
sprite zero hit - screen split
a litte more logic at the bottom

And I update sprite movements every frame, so it still runs as smooth as 60 fps.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Wed Jun 29, 2016 9:01 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5732
Location: Canada
dougeff wrote:
Interesting side-note. There is a slight audible buzzing sound (Powerpak to NES) when the sprite zero was in a certain range on the screen. I'd say between scanlines 210-230.

Most likely you're hearing the video signal as audio, as it tends to bleed into the audio channel a bit. Example: https://www.youtube.com/watch?v=hsxxeJlmn1U

Other stuff can interfere with the audio signal too, but crosstalk from the PPU is a common culprit.


Top
 Profile  
 
PostPosted: Wed Jun 29, 2016 9:22 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1787
Location: DIGDUG
Yeah, that was the buzzing sound, but not so loud, and only sometimes. I'm using the coaxial cable output from NES. I should probably go get an RCA cord.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 24 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bavi_H and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group