Demptronic NFL Football

I am building an NFL game from scratch. It is obviously influenced by Tecmo Super Bowl. I will try to use the full power of the MMC5 to maximize the quality of the game by using 1024 PRG ROM and 1024 CHR ROM. Many of my graphics choices are expensive but I assure you they are worth it. My initial estimate for time until completion is 2-3 years. Here are two fields I have built. My immediate goals are to:
1) Build a few more NFL fields and get the game to scroll horizontally. Eventually, all 32 teams will have fields as well as playoff and Super Bowl graphics.
2) Design kickoffs and field goals to have the feel I want.
3) Design a player to run around on an open field.
The goal of the game is to be hands down the best NFL game for the NES. I want to fix the things in Tecmo Super Bowl that need fixing as well as modernize the game to align to current rules (2-pt conversions, 15-yard line extra pts etc)
I will keep everybody updated when I reach milestones.

Many of the things in TSB that are outdated or broken can or have been fixed but good luck to you.

Building a football game from scratch with just one person will be a major project.

Woahhhhhhh, this looks awesome. Good luck. Go falcons

Creating more fields while developing the basic scrolling field. Many more to come.

This is not a game that making it MMC5 makes any sense. It just means you never want it on real hardware, honestly. But good luck anyway.

I think someone someday will figure out how to manufacture something for MMC5 homebrews. It's not like I can legally profit from this. I just want to make the best NFL game on the NES. MMC5 is the best way to have so many field graphics available at once.

The problem with MMC5 is that it is simply so big and complex that it will most likely never be economically worthwhile to reproduce in its entirety. (Heck, Nintendo didn't really find the MMC5 worthwhile to produce originally)

If you stick to a subset of MMC5, such as, say, just large (≥ 512KiB) CHR-ROM banking ... getting that put into new hardware is plausible.

If you ever want to see this on more than a small handful of hand-made donor-using reproductions, I promise that any mapper simpler than MMC5 that's using large (≥ 32KiB) CHR-RAM is more suitable. You can even get new COOLBOY carts (MMC3-shaped) with 128 KiB CHR-RAM and ludicrous amounts of PRG-ROM for a quite reasonable price.

Looking at the actual graphics now, those end zones look highly compressible to me. Right of the bat you can cut the amount of memory they use in half if you do the mirroring in software, while copying from PRG-ROM to CHR-RAM. On top of that, even a simple compression scheme like RLE would probably save you at least another 20%. This leads me to believe that this game could be done with a simple 512KB PRG-ROM + 8KB CHR-RAM mapper, without any funky stuff like larger CHR-RAMs (which are not well supported in emulators) or the overkill that's the MMC5 (which can't really be made in hardware).

Here are a few more I made. Each team gets two colors + white.

.

.

.

.

.

.

.

These are the last ones. I realized that I need to change one color in one standard background palette so the Redskins sideline numbers reflect that change. Next phase: the tedious task of implementing from Photoshop to my game!

Finally a Falcons one, I love it. Although this is a lot of gfx data, compression and recycled tiles could probably get the game smaller than needing an MMC5, doncha think?

There's something to be said for drawing all the assets and then figuring out what's needed...

And that's exactly why I encourage newcomers who post "let's make a game; I need a programmer" to provide mock screenshots.

All of the graphics data is exactly why I need MMC5. I plan to have a line of scrimmage and a first down line in the game, and that would mean I need to have 56K of tiles just for that. I understand everyone tries to avoid MMC5 because of the cartridge thing, but if I did, then it wouldn't be the best possible NFL game for the NES now would it?

You could easily fit all those graphics in nearly any standard MMCX mapper, MMC5 isn't needed. And because MMC5 doesn't provide the best game, it provides the best way not to run anything on an NES because nobody will hack a game for it, and your code won't even work correctly because MMC5 is sketchy in some areas.

I'm fully with 3gengames on this one. Unless you really need 8x8 pixel attributes, the MMC5 doesn't improve the graphics of anything, (still 2bpp, still 32 palette entries, still 8 sprites per line) it's more like it just improves the amount that you can do, and in this case, there's no need. It's like this: A puzzle game for the PS2 vs. the PS4 isn't going to look any better, (aside for running at a higher resolution) but a first person shooter game will, simply because the PS2 can handle all that you could reasonably have in a puzzle game. It's that same reason I still think Super Monkey Ball looks good, because it isn't overly ambitious. You would have to do a lot more to make something like Twilight Princess look PS4 quality than Super Monkey Ball. Basically, just because something is using the MMC5 doesn't automatically make it look better, only in certain situations, none of which are prevalent in a football game. I still think row scroll would be a great idea though. I might actually create a little mock up for it.

I think the main reason he went with the MMC5 is that it allows up to 1MB of CHR-ROM, something that no other (official) mapper does. He has a lot of graphics and is concerned that he won't be able to fit it all in ROM sizes supported by more conventional mappers. Also, the ability to address 16384 tiles at once, which could maybe simplify the process of drawing each field.

While I do see that the MMC5 offers some advantages over the more traditional mappers, there are cases when it's absolutely necessary and cases when it just makes things a bit more convenient for the programmer, and I personally feel like this is a case of the latter.

I'm of the opinion that even though there are a lot of graphics in this, much of it is redundant. With CHR-RAM, you wouldn't need two copies of each team's end zone art, since you could simply flip the data when copying to VRAM. Also, since a lot of this art is actually composed of letters, there's a fair bit of localized redundancy and flat areas, which could be exploited with RLE or any other simple compression scheme. If you used extra WRAM (which is a hardware improvement much more reasonable than the MMC5) you could even use more complex compression schemes to achieve better compression ratios and buffer the uncompressed graphics and the flipped versions there, so you could blast them to VRAM as fast as possible during the match as needed.

I assume that the actual code for a football game wouldn't be extremely complex, so you could probably fit it in 128KB or less (probably less!), which would leave you with 384KB of a 512KB ROM where to store compressed graphics. With a good compression scheme and without the redundant graphics, those 384KB of compressed data could easily expand to 768KB worth of tiles, which is more than any common CHR-ROM mapper will allow, and is fairly close to the 1MB of the MMC5.

You seem pretty set on using the MMC5, despite the fact that this might reduce your target audience. What's the point of making the "best possible NFL game for the NES" if most people won't actually be able to play it on the NES, just on emulators? "the best possible game" should also be a game that people can actually play. In the end, this is your decision, so there's not much left for us to say.

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).

But not still four sets of 64 tiles per screen. It's not the 8x8 pixel color areas as much as the 8x8 pixel bank switching. The particular use here (end zone at left using one set of tiles, center emblem at right using another) looks like it could be achieved with MMC2 or MMC4, but those are even less common than MMC5, though the MMC2/MMC4 circuit has been cloned in discrete logic and would likely fit into a reasonable CPLD.

None of those would be visible at the same time though, which matters most. Just swap out graphics at different parts of the field.

Tecmo Super Bowl's PRG size is 256KB and its CHR size is 128KB. But about half of its PRG area is used for data (player abilities, game simulation data, playbook data, player command script data cut-scene and various screen scripting data, music, etc). And all of this data is pretty heavily optimized for space.

So ya the actual code takes up roughly 128K of he 256KB. So not a bad estimate on the code part.

Yes. You have 13 yards where no logos are displayed, and you can load an end zone into CHR RAM in that time.

An American football field is 120 yards (360 feet) long, including the end zones that are each 10 yards deep, and 160 feet wide. The graphics are scaled at 8 pixels per yard horizontally. For some reason they're also 168 pixels tall from top sideline to bottom sideline, though 160 would be 1 foot per pixel. I'll assume for a moment that each 8x8 pixel tile represents 1 yard by 8 feet.

Except for the Bengals with their stripes, the end zone graphics appear to occupy a 6 yard by 160 foot area, or 120 tiles each. The center emblems are 10 yards by 40 feet, or 50 tiles. This means no logos from the 0 to 45 yard line, or a 13-yard margin to swap in tiles. That's more than enough for CHR ROM or 32K CHR RAM using an MMC3-class mapper.

But with the standard 8K CHR RAM, you'd need to copy in about 10 tiles per yard. The fastest scrolling would be about 10 yards per second, based on the airspeed of a punt or the ground speed of Deion Sanders' 40 yard dash. This means the engine has 13 yards or 1.3 seconds or 78 NTSC* frames to get 120 tiles into VRAM. If no sprite cels are dynamically updating, that much data can be easily copied within 15 frames.

* They don't play a lot of American football in PAL regions.

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.

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?

No, it wouldn't be.

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.

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)?

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.

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?

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!

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.

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

As of now, looks like I need to abandon this structure:

I'll see how it goes.

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.

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.

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.

As you can see, the menu has progressed but the field doesn't reflect the options selected yet. My next steps will be:
1) make the top three rows of the field stationary (never did this is a game before, reading Nerdy Nights to see how)
2) figure out why the screen still temporarily tweaks out when I write to the PPU

I thought I was following a basic principle: wait for VBlank then make writes to the PPU during Vblank. The subroutines that are causing the tweaks are DrawArrow and DrawSpeed. You can see the quick glitches by navigating the menu and making adjustments to the wind speed or wind direction. The correct background tiles are being placed but always with a quick screen tweak. It almost seems like my JSR NMIwait 's aren't doing anything.

Why is this still happening? Thanks for the advice.

It looks like it's not resetting the PPU address with $2006 after updating VRAM. You should set it to $0000 before vblank ends.

Better yet: reset the scroll by writing to $2000 (to select a name table) and $2005 (to set X and Y scroll), which are the registers designed for this. Setting $2006 to $0000 works in some cases, but that doesn't fully set the scroll (the fine X scroll can only be changed through $2005), so it's safer to use $2000/$2005, and since you'll be doing that, writing to $2006 becomes redundant.

I'm still not sure how to change my code based on your suggestions because I am new enough that I don't understand VBlank as much as I thought. This is the code my other program uses:

I know what each bit does in $2000 and $2001 and I use horizontal scrolling but I never understood why this code was so important, especially because in my other program there was no scrolling at all but removing the STA $2005 code caused bad things so I left it alone. Is this it?

It's affecting scrolling because basically all PPU registers are a copy of a single register when they're written to. You have to restore the register internally by writing the correct scroll as the last thing you do in Vblank.

This is the basic format of how I read lots of data in my programs. I know it is inefficient because I have to wrestle with hand calculating indirect addresses. If data needs to be adjusted, especially when the number of bytes is increased or decreased, this causes me to recalculate indirect addresses and it is annoying. Is there a better way?

Yeah, replace the Indirect0 and 1 tables with something like this. I haven't used nesasm in a while so I'm not sure what the equivalent syntax is, check the docs. Honestly, I'd advise using a different assembler because of bad experiences I've had with nesasm (having it assemble bad code instead of giving an error message), but you can probably get by anyways, and that topic is covered in several other threads.



edit: Also, if you need to know the size of a table, you can do stuff like this:


Or you can use that same expression as the immediate operand of a CMP instruction or whatever. I'm kinda veering off-topic here, but anyways..

I am not all that fond of NESASM3 as an assembler and I've heard mostly complaints about it so I'd be willing to convert my game to Asm6 if it isn't too difficult. Will that be hard to do?

It wouldn't be too hard. The main thing would be changing the way the memory is banked/padded. I haven't used ASM6 for a large project, but I think it would go something like this:



and so on. When you gets to the CHR data, then of course the .org doesn't matter. Just .incbin your CHR file, and it's all good as long as it started at the right offset. I'm not sure how you'd want to handle your unused/blank PRG banks, if it was me I'd probably just make some kind of skeleton file and .include it repeatedly for each bank. Or you could try just using a big .pad directive, I don't know if it'll take a larger than 16-bit address though, could try it. Maybe someone else would have a better suggestion.

The rest of the conversion should be simple text search-and-replace. Changing indirect [ to ( and ] to ), and for local labels, . to @

I'm going to give conversion a shot and show everything I did. I will have the before and after posted as I do. I converted to lowercase letters and that's about it. I really don't know what to do but so far I put the .iNES header above as .byte code. Not sure if that's right. Not sure what to do with the .bank 15 type stuff because it is my first error in ASM6 so far. I'll keep grinding at this until I get it.

Yeah that sounds reasonable, I seem to recall my earliest programs always had the opcodes in caps, but I soon switched to lowercase probably because it was easier to type. It somehow looks cooler or more "official" in caps, but it's hardly worth any trouble. Actually, looking at my current project, for PIC16, it's all in C except maybe 12 lines of assembly, and it looks like I had typed those asm opcodes in caps just for looks I guess, heheh.

I always type constant values in caps though (expressions and stuff that are defined with EQU or = and such, often used for immediate # operands), it's always good practice to distinguish those from variables.

OK so I've been looking at my NESASM3 code and trying to convert in to ASM6-ready code but I really don't know what to do exactly. I looked at the .NES file to retrieve the header, which I rewrote at the top of my program. I'm getting the following errors:
1) 'Illegal instruction' errors only on my .bank code.
2) 'Value out of range' errors on jmp's and jsr's
3) I'm getting tons and tons of 'PC out of range' errors on just about every line. My current code has two spaces before each thing. Should there be a tab or something?
I converted my local labels from .Skip to @Skip and will wait until it runs to implement + and - looping labels. I converted square brackets to round brackets. How do I complete the conversion?

ASM6 doesn't have a .bank command. You can use .base to start a bank instead, and .org to pad each bank until the end. Here's what a mapper 2 program with 4 PRG-ROM banks could look like in ASM6:


As for the remaining errors, it's possible that they're being caused because of the .bank errors, which are preventing addresses from being resolved. Fix the .bank thing first and then look at the errors again to see if things got any better.

I cleared up the error notifications from ASM6 but there is still something wrong. This is what I have so far taking tokumaru's advice. As you can see I am really close. First, I don't know if I have the right header because when I look at the .nes file produced, the header takes up 32 bytes for some reason. Any suggestions from here?

I assembled it, the header looks OK to me. Looking in a hex editor, the code starts at offset $E010, which shows the header added 16 ($10) bytes.

It looks like you need to add more banks or change the header, the header shows 8 * 16kB PRG banks, but the asm file only creates 4 16kB PRG banks.

I'm using asm6 v1.51 BTW, kinda old, if that matters. loopy's site moved, I'm not sure where to get the newer version.

edit: yep, I changed 8 prg pages to 4 in the header, and it runs again.

I tried changing the 5th byte of the header from $08 to $04 and I'm still getting grey screen. What else needs to be done? Could you upload your change that works again if it's something else?

Another reason not to use MMC5. Nobody knows wtf is wrong with the mapper when the mapper rejects the configuration, and we're seeing another mapper issue here, more than likely.

tokumaru said he got it running again with just a change of the header though...

asm file attached, I only changed the header.

I have to say I think it's kind of cool that somebody's finally tackling MMC5. If this project gets finished then perhaps there will be knowledge gained from it.

For a first project though, there's going to be a few more headaches than not using MMC5. It's dangerous to go alone.

Think you'll try to use all of the MMC5 features? Vertical split scroll? Perhaps use the multiplication processor for calculating ball trajectories?

OK great it works! Thanks a bunch for all your help it would have taken me too long on my own to figure this out. There was something happening that I wasn't aware of at first: ASM6 compiles it into .bin and I thought it was compiling it into .nes like NESASM3 does.

What I want to do before doing more programming is to make use of the features of ASM6 and jazz up my code. Does anybody have an example .asm file that I can look at that has a good mix of things in it so I know the types of things I can implement in my program? I have seen the README for ASM6 and it would be easier to compare that to some code.

Thanks again!

I use ASM6 and my programs have always assembled into an .NES file.

I simply have a batch file that reads this:



It should just be assembled into binary data so the extension, as far as I know, only has meaning when a program tries to read it. Just put .nes instead of .bin when you output.

These are just file names. ASM6 defaults to .bin because it isn't NES-only, but if you can define your own output file name with the .nes extension.


Looking at your source file, there are some things you can do to improve maintainability, but they aren't necessarily ASM6 exclusives. The first thing you should do is declare your variables dynamically, rather than manually assigning the address of each one of them. This is how you should define variables in ASM6:


Instead of manually writing the address of each variable, you start a block somewhere in RAM and just specify how long each variable is. This way you can easily shuffle variables around or change their size, without having to edit tens of addresses by hand, which is not only tedious but also error-prone.

Another thing that could potentially increase readability and maintainability is to break up the code into separate files and arrange everything using includes in a "master" .asm file, rather than using a monolithic .asm file with everything.

OK I changed my variables definitions to the .dsb 1 format and I can see how helpful it is. There is a lot of syntax that I am unfamiliar with or not aware of its existence so it's good to learn these things. Any good links for a comprehensive explanation of all that asm6 has to offer?

I'm just wondering what you would suggest for a compiling batch file. I am using the following:

There are problems with this batch file:
1) It doesn't open up the game right after the .bin file is produced and so I have to do two actions: run the batch then open the file it produces.
2) When there is an error in my code, it deletes the old .bin file.

This is what I would like my batch file to do every time I use it to compile:
1) It produces a .nes file instead of .bin. Notice I didn't select the file extension .bin; ASM6 produces that on its own. Still runs, but... ya know.
2) It deletes all open occurrences of the previous emulator and command prompt when I run the batch file so that at most one of each will be on the screen at a time.
3) When there are no errors compiling, it exits the command prompt. When there is an error compiling, the command prompt stays open and doesn't delete the previous .bin file (or .nes if the file extension is fixed)

Any ideas or suggestions?

ASM6 comes with a README file. You really should read it, it's not long.

This one should do everything except for "deletes all open occurrences of the previous emulator". In the case of a successful build, the command prompt window will close when the emulator finishes. In the case of an unsuccessful build, the command prompt window will close when the pause command detects that the user has pressed a key.


Say you're developing your NFL game, and you're taking a break by playing some Thwaite. then you pause the game with the intent of coming back to it later. Do you want the Thwaite session to be closed just because your NFL build succeeded?

Thanks tepples that is pretty close to what I want my ideal batch file to do.

DEMPTRONIC NFL STADIUM TOUR 2016 FEATURES
Field view and menu view.
All 32 NFL fields.
Extra field logos (NFL Play 60, Salute to Service, etc).
Super Bowl 50 field.
Wind from 0 - 39 mph in 16 wind directions.
Fair, rain, and snow weather conditions.
Rain and snow intensity 0 – 9; each reacts to wind speed + wind direction.
Goal post flags react to wind speed + wind direction.
Dome teams have no weather.
Hold B + direction for faster field scrolling or wind speed selection +/- 10.

Here is my first release of the demo for my game. Let me know what you think! Next steps will involve players on the field. More to come soon!

Will you have enough sprites left for the players with the amount of sprites the heavy rain and snow take up?

No. When the game gets going, there will likely be no sprites available for weather. The ball will react to rain/snow/wind without the player seeing it. I anticipate at first the following:
2 for goal post flags
22x2 = 44 for players
1 for football
1 for shadow of the football
1 for goal post where the ball passes through it on field goals.

There are likely others that will come up but that's my immediate list. Not much room for snow and rain.

Hello everyone!

I have been hard at work on Demptronic NFL 16. Major additions to my Stadium Tour demo include having a single football player run around the field doing various football maneuvers (hurdle, stiff arm, spin move, dive, leap, kneel, qb slide), and teaching the game how to recognize things like safeties, touchdowns, 2-pt conversions. The lone football player runs unopposed down the field for now. Teams have home, away, and throwback uniforms. Field changes color and feel with fair, rain, and snow conditions. For example, people have a harder time accelerating in the snow and they slide farther.

The game recognizes situations like "& goal" and "& inches". The line of scrimmage and the first down line are on the field and are background tiles. First down line turns red when it's 4th down. Game clock turns red during the two-minute warning. Play clock turns red when there is 3 seconds left or fewer.

I will likely have an updated playable demo uploaded within a month. Let me know if you have questions about what it can do or what it will do!

Done designing the helmets. Will likely use them on the team selection menu and the team roster & stats menu. Soon I will create some throwback helmets too.

Those look nice.

Thanks! Each helmet will be made with a background palette and a sprite palette. The bg palette must have black, white, and one color. This way, I can have two helmets (not on the same scanlines) on the menu screen at the same time. This frees up two sprite palettes which will be used to preview the uniform colors. Haven't decided yet, but the menu will have a portion that looks like this attached pic.

The menu is just about done. I'm hoping to release a demo soon! A ton of content was added since my demo in April.

Still hard at work on Demptronic NFL! Here is the uniform list for each team.
Each team has Home, Away, Color Rush, and three alternate uniforms.

Here are all 63 selectable NFL helmets.

I really like how this game is coming along. The sprites are amazing looking. Is this going to play similar to Tecmo Super Bowl? Anyway, great work and hope to see this finished.

Demptronic NFL 16 - Super Bowl LI Demo is here!

CURRENT GAME FEATURES:
32 NFL fields including real end zones and midfield logos for all 32 teams.
6 uniform choices for each team: Home, Away, Color Rush, and three alternate/throwback uniforms.
NFL helmets for 32 teams plus 31 additional throwback helmets.
Weather: Fair, Rain, Snow, Dome (for dome teams only). Weather shows precipitation.
Additional field logos: Kickoff, NFL Play 60, Salute To Service, Breast Cancer Awareness, Thanksgiving, Wild Card, Divisional, Championship, and Super Bowl 51.
Super Bowl 51 field the has one end zone logo for each team.
16 wind directions, 00-39 mph, where the rain, snow, and field goal flags react accordingly.
Overall ratings for all 32 teams (meaningless until player stats are implemented)
Active scoreboard
Line of scrimmage and First Down Line react accordingly and are reflected on the scoreboard, including the &INCHES and the &GOAL scenario.
First Down line turns red on 4th down.
Features scoring by safety and touchdown.
Player position accuracte to the 1/256th of a pixel.

FIELD CONTROLS:
A – Dive
Select, A – kneel (when stopped), qb slide (when moving)
Start, A – Leap
B – Hurdle
Select, B – Spin Move
Start, B – Stiff Arm
Select, Start – Change player skin color
Start, Start – Go to MENU
* a player can activate a multibutton move by pressing Select first then quickly pressing A soon after, or pressing A while holding Select.

MENU CONTROLS:
Left/Right – Change parameter by 1.
Up/Down – Change parameter by larger amount.
B – Previous Category
A – Next category
Start – Go to FIELD

More to come soon! This game is only going to get better!

This is impressive. You got every feature in!

What emulator does this demo work with? I'm getting a $0D black screen in Nintendulator, FCEUX, Nestopia, PuNES...

I programmed it in FCEUX on MMC5. Is anybody else having this problem with FCEUX? Does this NFL.nes here fix it?

That doesn't change anything for me, in any of the emulators I just mentioned.

It does seem to run in an older version of FCEUX though. (2.2.2)

Yeah it works for me in FXEUX 2.2.2

I love the acceleration when sprinting! My only contact with american football was at an event where footballers traded experiences and tactics with us roller derbyists, and i've never watched an actual match from beginning to end, but it felt very appropriate for this game adaption.

Extremely excited for this. Demo works great for me.

That's the version I have. What would cause it not to run in the latest version but still run in 2.2.2? Maybe something involving initialization or MMC5 maybe...?

It seems to run on 2.2.3 if I switch to "Old PPU".

The new PPU is supposed to be much more accurate, but I'm not sure specifically in what ways.

The default setting is old PPU, but I think it's mainly that way to provide support for legacy TAS etc. that relies on its behaviour. If you're trying to develop new software, you would probably want to use new PPU.

Briefly playing around with Mesen ....

You've somehow managed to spin, waiting for a sprite 0 hit in your NMI before you've successfully uploaded sprites the first time.

(Why are you using a sprite 0 hit on a mapper with IRQs?)

Did a random button mashing/holding stress test. Holding a or b means retrigging their corresponding actions. Checking for a previously recorded release in order to re-perform the action may help against these odd-looking movement patterns.

I've never used IRQs before. I just looked up on Nerdy Nights how to get a horizontal banner that doesn't scroll with the background. Not sure how to implement IRQs. Sounds like I should switch. I bet it would be easier to do other effects too. Any thoughts?

That's an easy fix. I also want to randomize the sprites selected during the spin move so spin moves look more realistic. Also, when a player jumps out of bounds, the ball needs to be placed where the ball was last in bounds, not where the player landed. I need to find a good football whistle sound so people know the play is dead. Should just use a quick tone for now. I have not implemented a ball yet so this is on the back burner for now. Each sprite will have an assumed placement of the ball at that moment so touchdowns are detected when the ball crosses the plain etc.

I've spent so much energy on field logos and helmets that I'm excited to get back to programming football physics.

It's basically just like the NMI handler, but rather than only happening at the very top of the frame, in the MMC5's case, you instead tell it to start an IRQ at scanline N. I'm not certain what a programmed value of "0" means here. It could mean the prerender scanline ... or it could mean something else.

You also need to explicitly acknowledge the IRQ source in the IRQ handler (i.e. read $5204), whereas NMIs don't need to be.

(As contrast, the MMC3 starts an IRQ after N scanlines have passed)

It's looking good. I especially like the sprite animation. However, the text at the top would definitely be (at least partially) cropped on my old CRT.

If the wiki is right then

"
IRQ Counter ($5203) = All eight bits specify the scanline number to generate IRQ at

When the MMC5 detects a scanline, the following events occur:
if the In Frame signal is clear, set it, reset the IRQ counter to 0, and clear the IRQ Pending flag
otherwise, increment the IRQ counter. If it now equals the IRQ scanline ($5203), raise IRQ Pending flag

Note the above logic makes it impossible for an IRQ to occur when $5203 (IRQ counter) is set to $00"

I'm pretty sure when I did my MMC3 to MMC5 conversion I remember I had to change almost all the places where it was loading a 00 into the IRQ register into 01's.

I am not familiar at all with working with IRQ's. All I know is they are interrupt requests and I think it's related to creating a stationary banner. Does anyone have some sample code and a little on how it's used?

For your purposes, I think you should just be able to have an IRQ that does something like


In your main thread, make sure you've disabled other sources of IRQs (APU frame counter and DMC completion), told the 6502 to listen to IRQs (CLI), and in your NMI, tell the MMC5 to start the IRQ at the right scanline (LDA #something / STA $5203) and tell the MMC5 to enable IRQs (LDA #$80 / STA $5204)

I need to convert from a Sprite 0 hit banner to a banner created from an IRQ using the MMC5. I'd like the top part of the screen to be scrolled 0 pixels to the right, and I'd like the bottom part scrolled n pixels to the right. I've experimented with the code suggested by lidnariq but I'm not sure where to put it. Here is my init code:


Here is my last VBlank write:


I need to know EXACTLY what code needs to changed or be added here to make the banner happen. I guess it has something to do with writing a value to $5203 and waiting to detect something from $5204 but I don't know where it should happen.

Somewhere in your fixed bank, and the IRQ vector should point to it (next to the NMI and RESET vectors).

After than, setting up IRQs should be as simple as:

* In your main thread:
CLI

* In your NMI
lda #scanline_to_generate_IRQ_at
sta $5203
lda #$80
sta $5204

Above is my last-writes code for NMI.

Above is my IRQ code.

I have been trying unsuccessfully to create a banner. I don't know what the values in A thru F mean. I tried experimenting and I still don't get it. What should I do to make it so I have a banner that starts 32 scanlines down where the top has no vert or horiz scroll while the last of the scanlines look shifted to the right n pixels. What do A thru F mean and what should I put where? What am I doing wrong?

A and B: as long as your NMI is short enough, A and B are the lower 8 bits of the X and Y coordinates of the initial (i.e. top of screen) scroll.

C,D,E,F: This is a messy thing that is an artifact of how scrolling works on the NES.
wiki:PPU scrolling#Split X & Y scroll is an exactingly detailed explanation...

The easy ones:
C specifies the nametable, or equivalently the 256s bit of X scroll and the 240s bit of Y scroll
E and D (notice reversed order) are the same as A and B, but for the scroll values desired after the split.
F needs to be a bit-shifted and combined copy of your X and Y scroll values.

To the best of my knowledge, this thing you already have:
should be enough to make something happen 32 scanlines down.

It would help if you told us what you saw instead...

OK I got it! Thanks for all the help lidnariq!

Been working hard on the playbook. Here is a screenshot. It shows a lot of how the offensive playbook looks. Unlike TSB, the defense does not try to guess the offensive play but instead has their own set of formations and plays to choose from.

Redesigned the color scheme to make it brighter and easier to read. Will likely complete the playbook within a week or two at the most. The last part about the playbook that needs completion is having the game clock and play clock run realistically.

Creating formations. This is an early preview.

The game captures look great. It's great that you continue with the project after two years since this thread was opened. I love the graphics of the game. Both the design of the uniforms of the members of the teams and the design of the helmets. I hope you upload some new DEMO to test the progress.

I don't have any interest in football (or football games) at all but this is one of the homebrew projects I'm most excited about - it's clearly such a passion project, and it's looking incredibly impressive.

Updates have been made. There is a new feature that allows you to see the overall ratings for each of the 32 teams and to see the 33-man roster of each team and the stats of each player (1056 players in all). The main menu has included overall stats for each team for comparison. The playbook has been enhanced on the border with the positions and player numbers for each set of plays.

I am approaching the pre-snap portion of the programming. I am glad to be done programming menus for now.

Playbook screenshots. Offense picks, then defense.

Need some more updates! So anxious to see this game come to fruition! Looks so incredible.

Had to add a new color mode to the logos on the field. When players are on the full-color logos, things get hard to see. So instead, full-color logos are for the Stadium Tour mode and for cut scenes between quarters. Now as you play on the field, you will still see the logos but they will be shades that are close to the field color.

See the difference in the photos.

The updated uniforms for each team. Each team has 6 uniforms to choose from. Shown are dark and light skin players for each uniform. The rosters have already been updated for the 2018-19 season using Madden launch stats.

I got to say, I usually have zero interest in sport, american football or sport game in general, but I have been following that project from time to time for years and I am surprisingly excited about it. The quality of the graphics and intricate planning of every little details are very impressive and every time I stumble onto that thread, I tell my self "Man, I hope this guy end up really finishing this thing and won't quit, this look like a professional game".

I guess what I'm trying to say is, kudos man, keep up the good work. It's weird to say this about a football game but I can't wait to get to play this.

^ same. I care for two sports: freeform frisbee and roller derby. But i'm always happy whenever there's an update on this and feel enthusiastic about it. Awesome work!

Thank you so much! Every time I am about to get into the part where actual football is programmed, I have to stop and work on some other part of the game (player stats, field, menu, playbook...) . Now I feel like I am tying up those loose ends and will be getting to the part where the players all interact.

I'll be releasing a demo on Thursday Sept 06 to celebrate the start of the regular season.

I just realized today that the Titans will be using a different helmet for the 2018 season. So I put it into the game and have the old helmet selectable as a retro helmet. The Jaguars simplified their helmet so I updated that too.

A glimpse at Stadium Tour mode. Only Stadium Tour mode and the Playbook will show precipitation.

Updated uniforms. This new chart I made shows both dark and light skin tones.

Demptronic NFL 19 Demo is here!

First demo release in 1.5 years. Too many improvements made to count. Built to work on FCEUX. This demo might have minor glitches.

MENU CONTROLS
A+LEFT / A+RIGHT switches to the next category.
LEFT / RIGHT switches options in the same category.
UP / DOWN switches options in the same category by more, or in the uniform selection category, switches skin tone.

FIELD CONTROLS
SELECT go to PLAYBOOK
START back to MENU

PLAYBOOK CONTROLS
SELECT / START switch formations (offense formation will be shown in FIELD mode)

STADIUM TOUR CONTROLS
LEFT / RIGHT scroll down the field.
A+LEFT / A+RIGHT switches team.
B+LEFT / B+RIGHT switches extra field logos.
B+UP / B+DOWN switches weather.
START back to MENU

ROSTER CONTROLS
LEFT / RIGHT switches team
UP / DOWN switches team faster
B switch between offense and defense
A switch to STATS
START / SELECT back to MENU

STATS CONTROLS
UP / DOWN / LEFT / RIGHT switches player
B switch between changing player and changing team
A switch to ROSTER
START / SELECT back to MENU

Hope work on this is still progressing! Can't wait to see more.

After a 3 1/2 month hiatus, I am back to programming. I now have both the offense and the defense on the field at the same time. The next thing is to get the main football engine running, testing it at first on the pre-snap portion of the game.

Let me know if you have any questions!

Super Bowl 53 pics.

Here's a look at my current workload. I am creating all offensive/defensive matchups. This involves the right personnel and that they are in realistic positions. A dime defense is going to have the same personnel regardless of the offense (look down any vertical line of pictures), but the defensive players' positions will depend on the offensive formation selected (look across any horizontal line of pictures). This also means the defensive playbook needs to be expanded, so after settling on all positions of defensive players, I will work to update the playbook.

The picture I attached is a half-finished first draft on the matchup board. I only labeled the defensive linebackers and secondary. This will be far more detailed later.

Full steam ahead.

A closer look at Pro (offense) vs 3-4 (defense). All formations except punt show 10 yards visible behind the line of scrimmage. I made it so the defense players' positions reflect the offense pretty carefully. This makes it easier to know who is responsible for covering which player (for the most part). Each player's posture tells their position on offense and defense.

Updated matchups board, one with the players positions listed, the other without (but you can tell by their stance). Seeing everything together has helped me fine tune player initial positions.

A few days ago, the New York Jets announced that they are using new helmets for the 2019 season. I just drew them and put them in the game. Here is my drawing of the new helmet and two other retro helmets that are in the game.

Demptronic NFL 19 Update Demo is Here! First demo release since Sep 6, 2018. Built to work on FCEUX. This demo might have minor glitches, but as far as I know it works perfectly. (MMC5)

Since the last demo, the following things have changed…

Offense playbook have been rebuilt:
1) reordered the formations from run-oriented to pass-oriented
2) redrawn plays
3) created consistent pass selections regardless of formation:
A+up: WR1
A+down: WR2
A+left: TE1, or WR3
A+right: TE2, RB2, or WR4
A+select: RB1, WR5, or K
4) field goal attempt distance updated to simpler format

Defense playbook has been rebuilt:
1) completely reimagined defensive playbook format
2) reordered the formations from run-oriented to pass-oriented
3) shows the offense formation next to the defense formation for each defensive play
4) defense playbook reacts to the offense formation selected, creating 50 total matchups by formation, 8 plays per matchup, for 400 total selectable defense plays
5) Special only a selectable formation if the offense selected Special
6) keeps offense personnel on left and right screen borders after offense selects formation/play
7) symbols for players changed to represent their position: D defensive lineman, I inside linebacker, O outside linebacker, C cornerback, T safety, K punt returner
8) the color of each defensive player symbol signifies their job:
Red: run toward the ball carrier
Blue: cover an individual player
Yellow: cover a specific zone
…for now, every defensive player is set to yellow, because I will start writing individual plays a little later and this stage can wait. The titles for individual defensive plays have not been set yet and will be decided later as well, for now each defense formation has the same play titles regardless.

Other additions/fixes:
1) Each player’s posture in FIELD mode signifies their position
2) Both the offensive and defensive players appear on the field at the same time
3) New helmets: New York Jets (home), Miami Dolphins (alt 3)
4) Redrawn helmets: Miami Dolphins (home) updated stripe, Jacksonville Jaguars (alt 2) (better orange to black fade), New York Jets (alt 3) white facemask
5) Various uniforms updates: Jets, Dolphins, Texans color rush
6) Bug fix for STADIUM TOUR mode

For now, the default has the home team on offense, moving from left to right, on the 50-yard line, in the middle of the hash marks. The can handle all possible pre-snap scenarios, but you can’t see them all because of the default settings. Change hex values in the hex editor to see more! (only change hex values while in the MENU)
$0000 – (00) home team on offense, (01) away team on offense
$0001 – (00) offense moves from left to right, (01) offense moves from right to left
$0002 – (7B thru 9A) (7B) offense on upper hash mark, (8A) offense in between upper/lower hash marks, (9A) offense on lower hash mark
$0004 – (0E thru 71) line of scrimmage (40) is the 50-yard line (+1 yard at a time)
$0005 – (00 thru 07) line of scrimmage small adjustment (+1/8 yard at a time)

MENU CONTROLS
B / A switches to the next category.
LEFT / RIGHT switches options in the same category.
UP / DOWN switches options in the same category by more, or in the uniform selection category, switches skin tone.
SELECT+A go to ROSTER
SELECT+B go to STADIUM TOUR
START go to FIELD

FIELD CONTROLS
SELECT go to PLAYBOOK
START go to MENU

PLAYBOOK CONTROLS
SELECT / START switch formations (selected formations will be shown in FIELD mode)

STADIUM TOUR CONTROLS
LEFT / RIGHT scroll down the field.
A+LEFT / A+RIGHT switches team.
B+LEFT / B+RIGHT switches extra field logos.
B+UP / B+DOWN switches weather.
START back to MENU

ROSTER CONTROLS
LEFT / RIGHT switches team
UP / DOWN switches team by more
B switch between offense and defense
A switch to STATS
START / SELECT back to MENU

STATS CONTROLS
UP / DOWN / LEFT / RIGHT switches player
B switch between changing player and changing team
A switch to ROSTER
START / SELECT back to MENU

The updated helmets, uniforms, and matchups.

This is really impressive raydempsey. I hope you see this project through and have a cart release. Is there any possibility this will be done by NFL season? Again, great work.

Take Care
InsertCoin25

Been a couple of years since I checked on this. My oh my! Impressive. You are inspiring me, sir, to get working on my ideas.