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

All times are UTC - 7 hours





Post new topic Reply to topic  [ 81 posts ]  Go to page 1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Thu Dec 11, 2008 8:36 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19116
Location: NE Indiana, USA (NTSC)
I just bought a PowerPak, and my little cousin has been using it to test his SMB1 level/graphics/music hack.

My block game works perfectly on every modern emu I've tried it on (fceuxd sp, nintendulator, nestopia). On my NES, it works with two problems. First is that pieces occasionally appear to spawn one cell to the right after a 4 line clear due to the recently discovered interaction between DPCM and the controller clock signal. (That's fixable by reading each controller twice and using the previous frame's keypresses if they don't match.) But I didn't expect the other problem: the fourth block of the next piece flickers. The flicker happens more often when the player tries to do something like move or turn the piece, and it gets much worse once both players have joined. But commercial games don't flicker any more than they do on the emulator or on authentic Game Paks. I've posted my cc65 source code; can anybody tell me where to start debugging to look for differences between NES and emulator behavior? Or is this a known defect in the PowerPak, and I need a ReproPak and a Willem programmer to get perfect behavior?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 11, 2008 10:34 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 1517
Location: Fukuoka, Japan
I do not own a PowerPak so this will be more a personal comment on the subject.

I think there are good chances that your educated guess is right. The powerpak in it own is a nice tool but we should not forget that it's technically an emulator running on the real hardware. So the chance of errors are higher. Or it could be that now the powerPak is showing you something that the emulators didn't.

Don't get me wrong, I'm not saying that the PowerPak is crap or something like that. I think it a nice "geek" gadget for testing some game that you want to play again, now playing some nsf and fds files. But for home brew, it may have some limitation (just look at the MMC5 mapper for example).

In the end you may have to test it on a dev-cart to be able to confirm your issue. I guess your game is an nrom (didn't check the code yet, will check later) so maybe some people in the community may be able to test it for you. I may make a NROM cart soon so if I can find the time I may be able to confirm it.

Edit:

I tried to make a quick hack and convert your game to a MMC3 CHR-RAM, the only dev-cart I have at the moment. It works well on emulators but not on the hardware. I guess I must have done an error in the bank switching code again. I guess I'm too tired. I will try to make it work another day.

Edit2:

It was annoying me that I could not make it work on my dev-cart. My mistake is that I put by accident the code for banking in the banks that needs to be banked (duh).

Test results: If I play 2 players at the same time, the blocks at the top flickers. They seems to flickers more when you move the joystick. I don't think the MMC3 could have any impact on the test results.

Conclusion: The Powerpak seems to reacts like the real hardware. The emulators doesn't. Now on how to fix it... I don't know but at least you can do all your test with your powerpak (if you look at the bright side of things).

If you want the mmc3 version I can post it back but it's just a quick and dirty hack: I'm sure you could do it anytime since you know more than me about the nes :)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 12, 2008 7:25 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19116
Location: NE Indiana, USA (NTSC)
The extent of the flicker changed from one run to the next. (This means the flicker might depend on the phase of the moon^W CPU and PPU clocks upon power-up.)

Strange #2: Holding Select changed the flicker pattern due to the way controller reading and autorepeat were coupled. So I decided to rewrite the controller reading code to fix the DPCM glitch. Right then, the flicker in 1-player mode disappeared entirely, and the flicker in 2-player mode became less distracting. But some flicker remains, and I wish I had someone to help me find what's causing it.

Uploaded version 0.31


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 12, 2008 8:31 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 1517
Location: Fukuoka, Japan
tepples wrote:
The extent of the flicker changed from one run to the next. (This means the flicker might depend on the phase of the moon^W CPU and PPU clocks upon power-up.)


That's a nice comment :) But you may not be wrong in a way: something external (PowerPak) could cause the difference. Maybe I should try to test it more on my dev-cart to see if I can reproduce the same behavior. I just need you to give some example on how different the flickers were from one run to the other.


tepples wrote:
Strange #2: Holding Select changed the flicker pattern due to the way controller reading and autorepeat were coupled. So I decided to rewrite the controller reading code to fix the DPCM glitch. Right then, the flicker in 1-player mode disappeared entirely, and the flicker in 2-player mode became less distracting. But some flicker remains, and I wish I had someone to help me find what's causing it.


In my case, using both joystick at the same time changed the extend of the flickers. Not using them and the flickers where few. So it could be related to some code near the joystick reading.

Once I can find time (it's not easy with a very young child) I will try to use your new code and test it back on my dev-cart to see how much different it is. If you don't mind, instead of making "a new branch",I would like to insert in your project a few extra line so I can compile easily for MMC3 CHR-RAM and you could merge it after. I guess it could be made so it can be compiled for a NROM or MMC3 very easily.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 12, 2008 11:52 pm 
Offline

Joined: Thu Oct 27, 2005 1:44 pm
Posts: 449
Location: CA
tepples wrote:
The extent of the flicker changed from one run to the next. (This means the flicker might depend on the phase of the moon^W CPU and PPU clocks upon power-up.)


Don't have any answers, but I ran v0.30 on an NROM eprom board and saw the same thing. Flicker rate changes between power cycles and changes with button input. Might be helpful to know which sprite number that is that's having problems and which sprite numbers are fine. At least you now know its not just your NES, and not the PowerPak :)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 13, 2008 2:05 am 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
Well, I don't quite understand the technical stuff with the controller reads/DPCM glitches, but it seems that your problem only happens when blocks are moved or buttons are pressed, right? Perhaps try artificial button presses with no actual player interaction. What I mean by that is have AI move and turn blocks randomly to see if the glitch is still there, with no reading/writing to the controller registers. If it is, you can be pretty sure that the problem doesn't lie in reading the controller. If the flickering stops, you can be pretty sure the problem lies in reading the controller. That could greatly narrow down where the problem lies. Sorry if that doesn't help.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 14, 2008 1:23 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 1517
Location: Fukuoka, Japan
bunnyboy wrote:
At least you now know its not just your NES, and not the PowerPak :)


Great to hear. So we can focus now on scanning the code only.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 14, 2008 9:08 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 1517
Location: Fukuoka, Japan
I recompiled the new code and tested it on my dev-cart.

Like you mentioned, first player mode flickers are gone. As for 2 players mode, they seems to happens only when the 2 players at the same time have a block at the top. But since I had to test it alone, it was a little bit harder to have good test results. Were you able to have more flickers in other conditions?

I couldn't really scan the code yet but the impression is like more than 8 sprites are on the same line, making flickers in your sprite rotation routine? Does the next block + the one you're moving are sprites? When it started to flicker, it give the impression of an overlay block and the flicker was going down at the same time the player's block was moving downward, disappearing one scan line at a time. Once the player block was not over the next block, the flicker was gone.

I'm still new to nes programming but I will try to scan the code and see if I can find anything. Debugging is always good for improving your experience anyway :)


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 14, 2008 3:28 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19116
Location: NE Indiana, USA (NTSC)
Banshaku wrote:
I recompiled the new code and tested it on my dev-cart.

Like you mentioned, first player mode flickers are gone. As for 2 players mode, they seems to happens only when the 2 players at the same time have a block at the top. But since I had to test it alone, it was a little bit harder to have good test results. Were you able to have more flickers in other conditions?

On my PowerPak, I sometimes get flicker in one player's next piece even once both players' falling pieces are near the bottom.

There are ordinarily 17 active sprites at any time:
  • sprite 0 used to turn the screen off 10 lines before the vblank NMI
  • 4 sprites for player 1's falling piece
  • 4 sprites for player 2's falling piece
  • 4 sprites for player 1's next piece
  • 4 sprites for player 2's next piece
Ordinarily, the falling pieces should never interfere with each other because there are four for one player and four for the other, and neither should the next pieces when they're at the top. But when we have two next pieces and one falling piece near the top, one of the next pieces might flicker. So if player 1's falling piece is lower on the playfield than player 2's, it draws player 1's next piece first; otherwise, it draws player 2's first. This way, the falling piece is more likely to cover up any sprite dropouts in the next piece.

Quote:
When it started to flicker, it give the impression of an overlay block and the flicker was going down at the same time the player's block was moving downward, disappearing one scan line at a time. Once the player block was not over the next block, the flicker was gone.

That's how it shows up on the PC-based emulators, and occasionally, I can get it to show up that stable on the PowerPak. But sometimes, the PowerPak has more flicker.

I could start by putting in some code to hide the "overlay block" problem somewhat.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 14, 2008 7:38 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 1517
Location: Fukuoka, Japan
I have a few questions regarding what you mentioned. Of course my questions are more from a beginner's perspective but it could point out things (or maybe not) that we may have not think about.

You said that there is only 17 sprites at the same time on the screen. Ok, I can see that but what about the 47 that are not in used at the moment? Could they have an impact on your next block if they're not initialized properly?

Second question, wouldn't it be possible to put the next block in the background instead of a sprite? I guess one of the reason it was not done must be because of palette limitation and/or the problem that you can only update it when the screen is off but I still want to know why we cannot do that.

I will try to scan your code tonight (if my kid let me...) to learn what is going on at the moment. I will try to see if I can reproduce the other flicker with my dev-cart when both block are almost on the same scanline but closer to the bottom.

Edit:

I did a quick debug session on a break and in the SPR memory there was not more than 3/4 sprites per line. There was 17 of them. After 17, 3 of them with extra data but located at $F0. All of the rest where located at $F0 with 0 for the data. So sprites memory seems fine.

Hmmm.. Could be the wait for refresh code the cause, who knows. I may experiment tonight, I have a few ideas to test.

Edit2:

I'm testing all kind of thing and found a bug. When the block is almost touching the bottom, if you press very fast A/B, the block will go up 1 row, then continue to go down, then go up one row, etc indefinitely.

Maybe not related to the refresh bug but I will continue to test.

Edit3:

Was able to reproduce the bug. It happens for most block (except the square) when it's near to have an impact. It's like the block is trying to re-ajust itself depending of it's environment. Because of that, you can cheat in some conditition by bringing the block back up.

I will stop to check this bug and investigate more regarding the display bug.

Edit4:

Did a lot of testing, changed some code around. Still there. Tested with emulator for now. Always happens at the top only. Cannot reproduce elsewhere. Looks like a bug similar to more than 8 sprites on the same line but it shouldn't be the case. Too tired, will do more debugging tomorrow if I can find the time.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 15, 2008 8:59 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 1517
Location: Fukuoka, Japan
I think I found it, not in the code but at least a proof.

Here's a memory dump of the OAM when it flickered:
Image

If you look properly, 12 sprites Y location is at $2A. So this mean you have a case of more than 8 sprites per scan line bug.

How to fix, good question. Maybe you will need to do some sprite cycling to reduce the effect but I'm still no expert on the nes to give any good advices yet.

Hope this information will help you find a proper solution. Now I need some sleep ;)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 15, 2008 10:26 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19116
Location: NE Indiana, USA (NTSC)
Banshaku wrote:
You said that there is only 17 sprites at the same time on the screen. Ok, I can see that but what about the 47 that are not in used at the moment?

Right after drawing all the sprites, it sets the rest to y=$F0.

Quote:
Second question, wouldn't it be possible to put the next block in the background instead of a sprite? I guess one of the reason it was not done must be because of palette limitation

Correct. I'm at work on break at the moment, so I don't have access to the source code, but it goes something like this:
$3F01: grays
$3F05: unused
$3F09: player 1 frame (dark, medium, light)
$3F0D: player 2 frame (dark, medium, light)
$3F11: player 1 falling piece (dark, medium, light)
$3F15: player 2 falling piece (dark, medium, light)
$3F19: player 1 next piece (dark, medium, light)
$3F1D: player 2 next piece (dark, medium, light)

In fact, I had to leave out hold piece and multiple previews, which are required in the Tetris Guideline since 2001, purely because of palette limitations.

Quote:
and/or the problem that you can only update it when the screen is off

The game already turns the screen off 10 lines early to be able to fit a 200-tile update into NTSC vblank. If VRAM update time were the issue, I could just delay preview updates until the line clear animations ended. But palette space is the issue.

Quote:
I'm testing all kind of thing and found a bug. When the block is almost touching the bottom, if you press very fast A/B, the block will go up 1 row, then continue to go down, then go up one row, etc indefinitely.

The behavior you're seeing is called floor kick. Have you tried doing the same thing in Tetris DX (for Game Boy Color) or Tetris DS (for Nintendo DS)?

Quote:
Was able to reproduce the bug. It happens for most block (except the square) when it's near to have an impact. It's like the block is trying to re-ajust itself depending of it's environment.

Yes. In general, such adjustments are called wall kicks, and they have become common in recent block games.

Quote:
Because of that, you can cheat in some conditition by bringing the block back up.

This "cheating" is even worse in Guideline games such as Tetris DS. See one of the things TDS allows and why.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 15, 2008 7:13 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 1517
Location: Fukuoka, Japan
tepples wrote:
Right after drawing all the sprites, it sets the rest to y=$F0.


After posting my message I scanned the code and saw it. But in the game loop it reset the sprite every time, which seems a little bit overkill but doesn't have any impact on the display bug (I commented the code to see how it would react in an emulator).

tepples wrote:
The game already turns the screen off 10 lines early to be able to fit a 200-tile update into NTSC vblank. If VRAM update time were the issue, I could just delay preview updates until the line clear animations ended. But palette space is the issue.


After my last post regarding the more than 8 sprites on a scan line, I don't think anymore that blanking is the cause. I made on purpose the blanking go wild, removing some code and changing the order of it, making the screen flash (etc) and the bug on those blocks was still there.

What I want to try during lunch (if I do have time) is to create a check the nmi counter flag and if it's a odd value, write the sprites in ascending order and when it's not, descending. It's not a "great" sprite cycling algorithm but enough for debugging purpose. I want to see how much it will impact the display because of sprite priority.

Regarding the wall/floor kick, I didn't know :) I only played tetris on the nes and the old game boy so I have no knowledge about these new rules. I tested it back on an emulator this morning and all of the nes ones doesn't have this behavior.

And I checked how did they avoid the more than 8 sprites per scan line issue because of the next block:

- Tengen tetris just put them at the top and never let the player's current block overlap
- Nintendo tetris 1 is one player so this issue never happen
- Nintendo tetris 2 cover the players block at the top with the background one's so they will never overlap
- BPS tetris is only one player so no issue again
- BPS second one does have the same issue as tetramino (next block and current block overlap) but it flicker like hell in other case so I would say there is more chance that is a poor coding issue in that case

If I can test it during lunch (sprite cycling), I will tell you my results.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 15, 2008 9:55 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19116
Location: NE Indiana, USA (NTSC)
The misbehavior you describe is similar to the misbehavior I see on emulators, where the PowerPak has even more flicker.

Banshaku wrote:
Regarding the wall/floor kick, I didn't know :) I only played tetris on the nes and the old game boy so I have no knowledge about these new rules.

Interesting.

Quote:
- Tengen tetris just put them at the top and never let the player's current block overlap

I was going to do something like that (put previews slightly up from where they are), but at the time, I was unsure how much safe area I could be assured of. But now that I've read up on the issue:
  • In previous topics, we have determined that an NTSC-compatible 240p picture is the size of 280x240 NES dots, and PAL-compatible 288p is 280x288.
  • The NES generates a 256x240 pixel picture, centered vertically but off-center to the right by a couple pixels.
  • TVs draw the picture slightly bigger than the screen, hiding a margin called overscan.
  • Important information must not be displayed in the overscan. TV engineers have come up with sizes for a "safe area" that won't end up in overscan on the vast majority of TVs, which can be expressed as a percent of the width and height. The BBC recommends using 90 percent; a major gaMe conSole maker recommends 85 percent.
  • So the center 240x208 pixels should be visible on most NTSC TVs.
This means I could move the fields down by 8 pixels from where they are, down to where Tetяis by Tengen puts them, and they'd still be visible. How close do the fields in Tengen's game get to the edge of your TV, if that's available to you?

There's also the pirate-original "Poke Tetris" whose menus look like Tengen's and whose fields are in the same place.

The one thing that Tengen's game does that I don't want is putting the previews in the corners. I want them directly above where the pieces will come out, like in Arika's Tetris The Grand Master, so that the player can plan how many times to press left or right for the next piece.

Quote:
- Nintendo tetris 2 cover the players block at the top with the background one's so they will never overlap

It also has a shared preview, which the other games don't have. I could do this without a shared preview, but it would push the next piece too close to the score and lines. But if I moved the fields down, I could draw the preview in OAM 1-9 and the falling pieces in OAM 10-17 marked as behind the background.

Quote:
- BPS second one does have the same issue as tetramino (next block and current block overlap) but it flicker like hell in other case so I would say there is more chance that is a poor coding issue in that case

You mean Tetris 2 + Bombliss? That game's 2-player mode has no score/lines indicators, both sides have the same frame color, and the preview is actually half size.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Dec 15, 2008 11:04 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 1517
Location: Fukuoka, Japan
tepples wrote:
The misbehavior you describe is similar to the misbehavior I see on emulators, where the PowerPak has even more flicker.


As for my latest testing, I could only do it in an emulator since my eprom writer is a slug (~4/5 min for 512k...). So the forced vblank bugs and code swapping to see if the flicker was still there was done only in an emulated environment.

Quote:
How close do the fields in Tengen's game get to the edge of your TV, if that's available to you?


The tengen version is not available in japan to my knowledge (I could be wrong). I did my research this morning in the train with an emulator on the DS. From the emulator view, it was not at the top of the screen completly. There was a border in between.

Image taken from emulator:
Image

The next block will never overlap the current block in this situation.

Quote:
The one thing that Tengen's game does that I don't want is putting the previews in the corners. I want them directly above where the pieces will come out, like in Arika's Tetris The Grand Master, so that the player can plan how many times to press left or right for the next piece.


Oh. Didn't read that comment properly. Unless you move the score and line to another location and put there more minimalist (and explain it in the demo screen) so you can put the block higher, hmmm... Not much to do then.

I wanted to do some sprite cycling test but didn't have enough time and wasn't sure if it was done at many place since I don't know the code base well yet. My guess is that I must replace the sprite DMA code only in the main game_loop after the vblank code and see what happens.

The only quick test I did is to add the famitracker sound driver to add an extra stress during the game so I can see if the timed vblank code could be the cause. But... It started, the music was there but crash & burned during the game :P Oh well for the quick test without knowing the code then...

Edit:

Quick question that just came after reading the code. In your nmi handler, you have a variable called vblanked. Everytime a NMI is launched during vblank (this is where I need to be corrected if I'm wrong), the vblanked variable is increased.

This variable is used in the game_loop to check the status of the vblank so you can do some video processing. If my understanding of the NMI is right, why do you need to wait that the variable roll back to 0 to check the status of the vblank? Is it possible that you're could be waiting too much and that could cause the bug? Wouldn't you just need to check if the vblanked variable changed since the content of the previous loop and you may need a "previous_vblanked" variable?

Or my understanding of NMI and your code is wrong?

Edit2:

Removed for fun the wait vblank code. Funky line at the bottom but flickers still there. So waiting too many nmi case is removed.

Changed the code from sprite DMA to normal write. Break the game display timing, sprite are shown and flickers are still there.

My last test was to write the sprite data at $0300, from 0 to 255 on even one (from my counter) and on odd ones I reversed the order. Display timing was broken (expected), priority of tile changed (back became front) but some flicker on the side are still seen.

I will have to think about something else for now.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 81 posts ]  Go to page 1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot], Google Adsense [Bot], Yahoo [Bot] and 8 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