It is currently Wed Oct 18, 2017 3:22 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 109 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 8  Next
Author Message
PostPosted: Fri Dec 18, 2015 8:30 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
thefox wrote:
I think if you keep certain constraints in mind, you can start with MMC5 for ease of development, and if if/when the game is completed and it turns out that the game doesn't utilize the mapper fully, you can convert it to another, simpler mapper (e.g. one with CHR-RAM). If it's only the big CHR-ROM that you're after, such conversion should be fairly simple (depends on how many of the other MMC5 features are used, of course).


Yeah, when reading all these comments, that's what I've been thinking. Writing this type of game, how the background is scrolled and updated sounds like the absolute simplest part of the whole project, I'm sure that part of the game engine could be converted, if needed. Handling the AI and all those sprites, making it fun to play, sounds like the challenging part. I don't even like football, but I've played the hell out of Tecmo Bowl and TSB.

Anyways, if it can't be played on an NES cart easily, big deal, it's not like this type of game could safely have some kind of big commercial release as it is. With the massive amount of licensing involved, plus EA still has exclusive rights for making any NFL games (lame!). I've seen plenty of Tecmo Super Bowl hacks being sold apparently without a problem, but I have a feeling that's only because it's Tecmo's game and they haven't bothered to complain about it. A totally new game however, could be in new territory.


Top
 Profile  
 
PostPosted: Fri Dec 25, 2015 3:00 am 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
The reason I am dead set on MMC5 is because of the huge CHR ROM, huge PRG ROM (great for sound samples), 16384 bg tiles available simultaneously (allows for first down/line of scrimmage, referees, etc. while keeping sprites free for the players), and certainly the individual attributes per background tile. The end zones and midfield logos are strategically sized and placed so that each is vibrant with almost no compromises (except teams like the Titans, Ravens, Redskins to name a few) and this would be heavily compromised by any other mapper. Again, not worried about playing it on an actual cartridge for now because it's a long way from complete and I haven't given up hope that someday, somewhere, someone will figure out how to print some flash MMC5 cartridges. The goal of this one is best quality + fewest compromises.

I've run into a technical problem that I can't diagnose and I'm sure you will spot quickly. All this version of the game can do so far is scroll left/right and switch back and forth to a rudimentary menu by pressing start. On initialization, the field looks fine. Switching to the menu, the menu is doing as I expected (didn't change the attributes yet) but when switching back to the field I get some random garbled crap. The obvious reason would be that writes to the PPU are taking place outside VBlank but what I can't figure out is why the garbling doesn't happen on initialization and why it does when I return to the field from the menu.

I tried experimenting with the placement of my $2000 and $2001 writes, namely turning NMI off/on and rending background off/on in strategic locations. I tried to sprinkle in a VBlankWait in there and still nothing. Any suggestions?


Attachments:
NFL.chr [256 KiB]
Downloaded 87 times
NFL.asm [19.02 KiB]
Downloaded 89 times
NFL.nes [384.02 KiB]
Downloaded 94 times
Top
 Profile  
 
PostPosted: Fri Dec 25, 2015 1:18 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
raydempsey wrote:
and this would be heavily compromised by any other mapper.



No, it wouldn't be.


Top
 Profile  
 
PostPosted: Fri Dec 25, 2015 2:56 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3071
Location: Nacogdoches, Texas
I imagine it wouldn't even be compromised at all. Although more difficult to implement, we talked about how this could work on other mappers (like swapping out graphics down the field). A football game simply just isn't that taxing graphically.


Top
 Profile  
 
PostPosted: Sun Dec 27, 2015 2:34 am 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
Any thoughts on why the field draws ok during initialization but not ok when it returns to the field from the menu (by pressing start twice)?


Top
 Profile  
 
PostPosted: Sun Dec 27, 2015 3:32 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
In the DrawField routine, it looks like you jsr to PPUoff, clear the nametables, jsr to PPUon, then write the data to the nametables. So maybe the screen is rendering while being written? In any case, I tried it on Nintendulator and the field always shows up corrupted, coming back from the menu or not, until you scroll it off the screen. And the corruption is different when you do a soft reset instead of a hard reset.


Top
 Profile  
 
PostPosted: Sun Dec 27, 2015 8:46 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10054
Location: Rio de Janeiro - Brazil
Isn't the MMC5 ExRAM weird in that it needs to be written to DURING RENDERING, the exact opposite of regular VRAM?


Top
 Profile  
 
PostPosted: Sun Dec 27, 2015 9:04 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
tokumaru wrote:
Isn't the MMC5 ExRAM weird in that it needs to be written to DURING RENDERING, the exact opposite of regular VRAM?


Yeah that's what I've heard, the code I was looking at was writing to $2007 though. Then it writes to ExRAM after that. Screen was already on, after the writes it turned the screen on again, which made me think it might have been a mistake.

Also, looking at it again, it looks like it doesn't wait for the PPU warm-up. You should have two LDA $2002 / BPL - loops soon after reset. I don't know if that's something that usually emulated, but could be the problem maybe?


Top
 Profile  
 
PostPosted: Sun Dec 27, 2015 3:22 pm 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
I'm just not sure. I tried adding a few JSR VBlankWait 's in there right after the reset code and it didn't seem to do much. Also, I tried breaking up into smaller chunks the looping code in DrawField that draws the black tiles on top so that writes entirely take place in VBlank, but that didn't work. I also tried to make any writes to $2000 and $2001 take place only in VBlank but that didn't help. I've been trying to diagnose this problem for days!


Top
 Profile  
 
PostPosted: Sun Dec 27, 2015 4:03 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19096
Location: NE Indiana, USA (NTSC)
The vblank wait code appropriate before the PPU has warmed up differs from the vblank wait code appropriate after the PPU has warmed up. Before the PPU has warmed up, you want to spin on bit 7 of $2002. After the PPU has warmed up, you want to enable NMI and then wait for the NMI handler to set a variable.


Top
 Profile  
 
PostPosted: Sun Dec 27, 2015 5:16 pm 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
Thanks Tepples. I read what you were talking about here: http://wiki.nesdev.com/w/index.php/NMI#Race_condition
Sounds like I need to restructure my NMI label so that it is only
Code:
NMI:
  INC nmidetect
  RTI

As of now, looks like I need to abandon this structure:
Code:
Forever:
  JMP Forever
NMI:
  JSR UpdatePPU
  JSR ReadController
  JSR Rendering
  RTI

I'll see how it goes.


Top
 Profile  
 
PostPosted: Sun Dec 27, 2015 5:37 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19096
Location: NE Indiana, USA (NTSC)
Super Mario Bros. uses the latter structure with everything in NMI without any noticeable problem.


Top
 Profile  
 
PostPosted: Sun Dec 27, 2015 6:13 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10054
Location: Rio de Janeiro - Brazil
tepples wrote:
Super Mario Bros. uses the latter structure with everything in NMI without any noticeable problem.

Well, except for the ocasional glitchy scanline that results from toggling the NMI bit in $2000.


Top
 Profile  
 
PostPosted: Sun Dec 27, 2015 7:44 pm 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
OK I fixed most of the problem from your suggestions. I've tried experimenting with placements of the JSR NMIwait to get rid of the quick temporary glitchy screen when transitioning between field and menu - with no luck. I thought I would just turn the PPU rendering off before completely filling the screen with new background tiles and then turn it back on when done but I'm still getting a quick temporary glitch. How's it really supposed to be done? You can see what I mean when you run the game in slow motion.


Attachments:
NFL.nes [384.02 KiB]
Downloaded 95 times
NFL.chr [256 KiB]
Downloaded 90 times
NFL.asm [18.89 KiB]
Downloaded 105 times
Top
 Profile  
 
PostPosted: Mon Dec 28, 2015 1:50 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
Yeah, usually you wait for vblank, turn the screen off, wait for vblank, turn the screen on. Just noticed PPU_On is called just before you call DrawField. That must be it, screen is on while waiting for that first vblank.

There's something else weird. The field shows up in FCEUX, but FCEU and Nintendulator just shows a solid green screen. Nestopia says it's a corrupt file and doesn't run it. NESten says the "ROM image is smaller than required", then crashes.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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