Game complete: Blurred Lines 2048 by Demptronic

Game complete: Blurred Lines 2048 by Demptronic
by on (#151522)
My first NES Homebrew game is now complete. Basically, it is a remake of the popular mobile game "2048" but enhanced with the music of Blurred Lines. It is a shot-for-shot recreation of the music video complete with dancing half-naked ladies and music that is very accurate to the original song. I will be creating a YouTube video the compares the game's video to the actual music video so people can see the shot-for-shot intricacy of everything built.

The game is meant to be a novelty - people will probably play it through once and then show a friend. I started this game last year and have been working on it off and on since then.

Let me know what you think! Yes I understand many people hate this song. I used to like it somewhat but after having to hear it 1000 times to study it, I don't want to hear it anymore.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151523)
Ha ha this is quite bizarre. Well put together, and pleasant sound.

The only thing I'd suggest is that the music should just loop instead of stopping and restarting, kinda killed the moment for me when it just stopped in the middle of a game. (I guess this is a bit of a conflict between being background music for a game, and an accurate representation of the music video?)
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151525)
Cool, but please remember to initialize your memory. :)

Also, don't use the color $0D!
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151539)
love it, raydempsey,

it's my new favorite NES cover song. (My old favorite was Sweet Child on DPadHero).

Great samples. What program did you use to convert them to DPCM? Mine always come out a bit quiet (with Famitracker).
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151541)
thefox wrote:
Cool, but please remember to initialize your memory.

Does NDX's random RAM generation thing actually occur on a real NES?
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151545)
Nestopia complains that it is a "Corrupt file!"
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151548)
nicklausw wrote:
thefox wrote:
Cool, but please remember to initialize your memory.

Does NDX's random RAM generation thing actually occur on a real NES?


Looks and runs fine on an Everdrive.

Nice job dempsey, you put lot of craft into this!
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151556)
thenendo wrote:
nicklausw wrote:
thefox wrote:
Cool, but please remember to initialize your memory.

Does NDX's random RAM generation thing actually occur on a real NES?

Looks and runs fine on an Everdrive.

The Everdrive and PowerPak both initialize RAM before loading and starting a ROM.

If you put it on a cartridge by itself, RAM would be "random" on power-on. It's random with a very uneven distribution, but unpredictable nonetheless. Any given bit could be 1 or 0 on power-on.

What NDX does is evenly distributed, I think, so it's not a good statistical model, but it is sufficient to demonstrate what could happen on a real NES.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151557)
rainwarrior wrote:
Nestopia complains that it is a "Corrupt file!"
The header marks 512 KiB of CHR, but only 256 KiB is present ... nevermind that MMC3 can't address more than 256 KiB.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151566)
Great use of samples. Any chance that the same engine could be used for #WORDCRIMES as well? But that might take some more samples: 9 different "good girl" instead of 2.

raydempsey wrote:
I will be creating a YouTube video the compares the game's video to the actual music video so people can see the shot-for-shot intricacy of everything built.

Would the publishers who represent Marvin Gaye and Robin Thicke object to such a video? I wonder if sync licenses are even made available to amateurs.

rainwarrior wrote:
The only thing I'd suggest is that the music should just loop

Instead of stopping, it'd go back to "If you can't hear"/"If you can't write".
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151567)
nicklausw wrote:
thefox wrote:
Cool, but please remember to initialize your memory.

Does NDX's random RAM generation thing actually occur on a real NES?

Nope, but I didn't try to model what would happen on a real NES in NDX. The purpose of the randomization is to make it easy to notice if your (or somebody else's) program relies on uninitialized memory, which is almost always a bad idea. Most emulators paint a too optimistic picture (from homebrewer's point of view) by zeroing out memory and initializing mappers into an NROM compatible state.

(I'm not randomizing mapper register state just yet, but I've planned to add an option for that as well.)

EDIT: And by "nope" I meant: no, it doesn't happen exactly like that on real NES, but the implications for the program you are developing are the same.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151572)
dougeff wrote:
Great samples. What program did you use to convert them to DPCM? Mine always come out a bit quiet (with Famitracker).
I used Audacity to create the samples. Problem I found was that no matter how hard I tried, I couldn't see to get the samples to reach the full 4095 byte size. I think each ended up being 4082. This made it so when I played them back to back, there was a brief pause between them. Not sure how to get that correct. After I produced them in Audacity, I used FamiTracker next and that created the ultimate files that I used.

The next thing I need to accomplish is to transfer the game to a cartridge I bought (TKROM 512) that can be flashed. Problem is that the program I used asked me to separate the file so that the PRG file is separate. I have a .chr file, and I have the file that I program with that is compiled using NESASM but I don't know how to save just the PRG to a separate file.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151574)
To get just the PRG data, remove the first 16 bytes in a hex editor.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151585)
raydempsey wrote:
Problem I found was that no matter how hard I tried, I couldn't see to get the samples to reach the full 4095 byte size. I think each ended up being 4082. This made it so when I played them back to back, there was a brief pause between them. Not sure how to get that correct.


The maximum DPCM sample length is 4081 bytes. (255 * 16 + 1)

See: http://wiki.nesdev.com/w/index.php/APU_DMC
It's an 8-bit length value (max 255), shifted by 4 bits (x16), and the DPCM unit always reads one extra sample (a mistake in the implementation, IMO).
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151630)
♪ I found a new bug ♪
You're not rereading
The keys I'm feeding
When drums are beating
♪ It makes a clock glitch
Spurious right presses
Need to be addressèd
'cause the game feels messy
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151660)
In case the poem is unclear, you have to use a different controller reading routine if you're playing DPCM samples, because they cause a conflict with the read (usually showing up as incorrectly pressing right now and then while samples are playing). This is kind of disastrous for 2048 gameplay.

Many emulators don't emulate this conflict. If you need an emulator to test the problem on, I would recommend Nintendulator.

I think puNES also attempts to emulate this conflict, but it doesn't appear to like your ROM at the moment.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151695)
Nice job, this is definitely a unique and skilled creation; I woulda rented it as an NES game as a kid, maybe even bought it.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151702)
rainwarrior wrote:
In case the poem is unclear, you have to use a different controller reading routine if you're playing DPCM samples, because they cause a conflict with the read (usually showing up as incorrectly pressing right now and then while samples are playing). This is kind of disastrous for 2048 gameplay.

Many emulators don't emulate this conflict. If you need an emulator to test the problem on, I would recommend Nintendulator.

I think puNES also attempts to emulate this conflict, but it doesn't appear to like your ROM at the moment.


Tested on FCEUX during development. How should the controller reading routine be changed?
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151708)
What a lot of games do is read the controller twice in a row, and only act on it if both reads were exactly the same. The sample DMA will only corrupt one read. Or just keep reading it in a loop until it gets two of the same result in a row.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151720)
Dreamwriter wrote:
...just keep reading it in a loop until it gets two of the same result in a row.

This is the approach I prefer. There have been some lengthy threads on the most optimal/clever thing, etc. but this method is very simple and easy to implement if you already have a regular controller read, and it works quite well.

It's also what Super Mario Bros. 3 and a number of other games do. Here's a quick disassembly of SMB3's method:
Code:
        jsr poll_controller  ; 0F:FEB9:20 0B FF  JSR $FF0B
reread: lda controller       ; 0F:FEBC:A5 00     LDA $0000 = #$00
        pha                  ; 0F:FEBE:48        PHA
        jsr poll_controller  ; 0F:FEBF:20 0B FF  JSR $FF0B
        pla                  ; 0F:FEC2:68        PLA
        cmp controller       ; 0F:FEC3:C5 00     CMP $0000 = #$00
        bne reread           ; 0F:FEC5:D0 F5     BNE $FEBC

FCEUX does not emulate DPCM conflicts, so you'll never catch it if it's your only testing emulator.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151725)
Seems simple enough. I'll make the change today and repost. I would have definitely noticed something was wrong when I attempted my first transfer to cart coming soon. Is there any risk that it could get caught in a loop that ends only at the start of the next Vblank or will it surely be resolved within a few small loops?
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151730)
Nestopia is another emulator that emulates the glitch.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151732)
It was decided that the highest number of rereads is (practically speaking) five, if a person changes what button they're pressing just after a glitch:
- correct, old
- corrupted, old
- correct, old
- correct, new
- correct, new
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151743)
In practice, two reads should be enough because

And while you're at it, are you making sure to read both D0 and D1 of $4016? Famicom owners would appreciate it, as D0 is for hardwired controllers and D1 is for plug-in controllers on that system.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151752)
tepples wrote:
In practice, two reads should be enough because

Because...? Come on tepples, the suspense is killing me! :mrgreen:
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151757)
...because a Threes clone isn't as twitchy as, say, Street Fighter series. Read twice and if they disagree, use the previous frame's presses.

Sorry, I got distracted by real life while composing that post.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151773)
lidnariq wrote:
It was decided that the highest number of rereads is (practically speaking) five, if a person changes what button they're pressing just after a glitch:
- correct, old
- corrupted, old
- correct, old
- correct, new
- correct, new

The worst case is very slightly worse than that. For most controller read loops, the DPCM at is fastest will be dormant for at least 2 passes through the poll routine, but it might be able to corrupt a 3rd consecutive one. So the worst case is really six:
- correct, old
- corrupted, old
- correct, old
- correct, new
- corrupt, new
- correct, new
- correct, new

Of course, you have to be lucky/unlucky to even get a conflict in the first place. It won't corrupt EVERY third loop, just ones where the $4016 read aligns with the DPCM read. I think it's normally like once per hundreds of frames. For it to happen twice consecutively would be exceedingly rare, and then on top of that you'd have to manage to press a button during, so... rare * rare * rare = has it ever happened ever?

raydempsey wrote:
Is there any risk that it could get caught in a loop that ends only at the start of the next Vblank or will it surely be resolved within a few small loops?

Not really. It's quite robust in any use I've seen. SMB3 seems pretty stable to me, I doubt the controller read loop ever caused a problem.

Like, if you hooked a machine up to the controller port that changed the input on every strobe, it would hang the game in the controller loop, but this is kind of pathological. I don't think anyone would do that except if they were trying to build a turbo-button controller and didn't know that many games will read in a loop like this.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151804)
I used Nintendulator to observe the problem you were describing about the DPCM creating false right button presses. I fixed it the way rainwarrior suggested and it works better now. Here is the new uploaded version. Thanks for finding the bug. I didn't even know that was a thing. I'll let you know how uploading to cart is coming as I attempt it.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151808)
My first attempt to upload BlurredLines2048 to a cartridge has failed. I have a TKROM 512 PRG 256 CHR flash cart WRAM w/ battery pack and I am attempting to use INL retro-prog v1.1 beta. Before I uploaded it, I trimmed a copy of my .nes file down so that the first 16 bytes went away causing the file to be 16 bytes shorter. Do I have to upload the PRG and CHR separately? I don't know if the file extension makes a difference but I tried uploading it when it was saved as both .nes and .bin but still no luck. No matter what I try to do, the program instantly crashes the moment I attempt to write to the cart. I never did this before.

I bought it from here: http://www.infiniteneslives.com/kazzo.php
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151810)
raydempsey wrote:
Do I have to upload the PRG and CHR separately?
Yes.
Quote:
No matter what I try to do, the program instantly crashes the moment I attempt to write to the cart.
That's weird, but I'd assume it's because the resulting file isn't a power of two.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151813)
Quote:
That's weird, but I'd assume it's because the resulting file isn't a power of two.


I tried uploading my 256 KiB CHR file to it and no matter what I do with that or anything it just seems to crash. Not sure what next.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151815)
Have you tried uploading the PRG+CHR from any other MMC3 game, such as the Holy Diver Batman test ROM?

(Also I noticed you haven't corrected the header or cleared the nametable.)
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151839)
tepples wrote:
Have you tried uploading the PRG+CHR from any other MMC3 game, such as the Holy Diver Batman test ROM?

(Also I noticed you haven't corrected the header or cleared the nametable.)


What needs to be corrected about the header, and how/why would I clear the nametable?
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151840)
raydempsey wrote:
What needs to be corrected about the header?

lidnariq wrote:
The header marks 512 KiB of CHR, but only 256 KiB is present ... nevermind that MMC3 can't address more than 256 KiB.


raydempsey wrote:
how/why would I clear the nametable?

Clear the nametable because its contents are unpredictable at startup on hardware. Kinda surprised that you're asking "how" after successfully making an animated ROM, but here's code anyway:
Code:
clear_nametables:
   lda $2002
   lda #$20
   sta $2006
   lda #$00
   sta $2006 ; PPU latched to $2000
   sta $2000 ; to set PPU address increment to single byte (just in case)
   tax
   tay
   : ; write 4096 zeroes to wipe all nametables
      sta $2007
      inx
      bne :-
      iny
      cpy #16
      bcc :-
   rts

This code presumes that both nametables are presently connected, as in horizontal or vertical mapping. You may need to initialize the mapper's mirroring mode before doing this.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151849)
Asking why to clear the nametable was what I wanted to know most. If the reason the nametable needed to be cleared was something particularly ornate, then the "how" part would have been necessary especially if the solution was strange too. Since you meant clearing the nametable as in assigning all the nametable tiles to #$00, then the how was unnecessary. Yes I know how to set nametable locations tiles to #$00. As for my header, this is how I have it (set for NESASM3)
Code:
  .inesmap 4   ; mapper 4 = MMC3
  .inesprg 8   ; # of 8KB PRG banks 64KB
  .ineschr 64  ; # of 4KB CHR banks 256KB
  .inesmir 3   ; background mirroring

First 16 bytes of my .nes file:
4E 45 53 1A 08 40 43 00 00 00 00 00 00 00 00 00

What do each of the values mean? Does $04 mean number of 8 KiB PRG banks as set from .inesprg? Does $05 mean number of 4 KiB or 8 KiB CHR banks as set from .ineschr? Is my .ineschr comment incorrect?
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#151851)
raydempsey wrote:
.inesprg 8 ; # of 8KB PRG banks 64KB
.ineschr 64 ; # of 4KB CHR banks 256KB
Whatever gave you those numbers is wrong, the header specifies the # of 16 KiB PRG banks and # of 8 KiB CHR banks.

(Since you seem to have 128 KiB of PRG, 128÷16=8, and 256 KiB of CHR, 256÷8=32)
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152213)
I made a comparison video showing my game Blurred Lines 2048 next to the music video for Blurred Lines. Check it out!

https://www.youtube.com/watch?v=KPS4QvNJrQo
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152267)
I still can't figure out why I'm getting a stack explosion. As it stands, the stack explosion will happen the moment a player presses start. If you erase the contents under the label ClearNametables: then the stack explosion somehow doesn't happen but I need that in the initial part of my program to clear the name tables. I was told that stack explosions only happen if info is abandoned in the stack from things like PHA and JSR but it doesn't explain why my stack explodes just by including the ClearNametables: label. Erase it and compile, you'll see. I tried running a trace logger in FCEUX but I am too much of a noob to be able to interpret it. You guys would probably be able to spot it very quickly.

I attached the .asm file if anybody can help me figure out how to stop the stack explosion. Once this gets figured out, I am ready to upload it to a cart. Thanks!
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152273)
Woah. Single file... that... doesn't use names for the RAM. That... must have been hard to maintain.

You know can actually variable defines, right? Like...

Code:
songTotalPosition = $A0

lda #$82
sta songTotalPosition

You named all your RAM up top, sure. But that doesn't make this easy for someone else to read.

This also isn't the most fun without being able to assemble (since we lack the DMC stuff). Being able to assemble lets us more easily see what labels the addresses in the debugger correspond to.

What eventually ends up happening is that an RTS at $E311 returns to $EB00, where there is no code. Which could mean a JSR was never called before that RTS hit.

The RTS in question is the one below NotZero. I could give this a more in depth look because the problem may be far before NotZero is ever reached. But... is it possible to clean the code up some?
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152275)
Code:
 07:EAF2:A2 00     LDX #$00
 07:EAF4:8E 52 00  STX $0052 = #$00
 07:EAF7:BD 00 00  LDA $0000,X @ $00FF = #$00
 07:EAFA:8D 50 00  STA $0050 = #$00
 07:EAFD:20 9B E2  JSR $E29B
 07:EB00:CA        DEX
 07:EB01:00        BRK
 07:EB02:04        UNDEFINED
 07:EB03:3F        UNDEFINED
 07:EB04:00        BRK
 07:EB05:20 23 C0  JSR $C023
 07:EB08:04        UNDEFINED
 07:EB09:23        UNDEFINED


Looking in the trace logger, with a break point on writes to $0100-$01C0, hits this point. Whatever this subroutine is (I didn't try finding it in the source or assembling it), it's leading the CPU to it's doom.

My guess is something weirder is going on. If you replace the nametable clearing with the same number of NOPs, maybe you would get the same crashing result. It's hard to see how that code PPU init code could be doing anything. In the worst case, it could be one of NESASM's "silent errors". What version of the assembler are you using?

BTW, because NESASM doesn't assume you want to use zeropage (one of the things that annoys me about it), all of your instructions using ZP like STX $52 are actually assembling as STX $0052. This shouldn't have anything to do with your error, but it does make the program bigger and run slower.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152278)
An unrelated thing: You don't wait long enough before you start uploading things (cleared nametables) to the PPU.

This is usually handled with something like:
Code:
 BIT $2002 ; to ensure that the NMI flag is cleared if the user hit RESET during NMI
l1:
 BIT $2002 ; wait for 241/291 scanlines to pass
 BPL l1
l2:
 BIT $2002 ; wait for another 262/312 scanlines to pass (although we only needed 22)
 BPL l2
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152283)
I mirror Memblers in asking which version of NESASM you're using.

Here's your code:
Code:
UpdateTiles:
  LDX #$00
LoadBlock:
  STX $52
  LDA $00,X
  STA $50
  JSR IndividualTile
  LDX $52
  INX
  CPX #$10
  BNE LoadBlock
  RTS

Here's the only block that could correspond to:
Code:
07:EAF2:A2 00     LDX #$00
07:EAF4:8E 52 00  STX $0052 = #$00
07:EAF7:BD 00 00  LDA $0000,X @ $0001 = #$00
07:EAFA:8D 50 00  STA $0050 = #$01
07:EAFD:20 9B E2  JSR $E29B
07:EB00:CA        DEX;...?
07:EB01:00        BRK
07:EB02:04        UNDEFINED
07:EB03:3F        UNDEFINED

I know because there's only one place in your code that has lda $00,x right above sta $50. So after that JSR, it should do its thing and return to LDX $52 and INX. DEX and BRK have been assembled there instead. Why is this? Because of this:

Code:
.bank 15
  .org $EB00

  .db $CA,$00,$04                                                                                 ; 00 - initial

Do those 3 bytes look familiar? Yep, they're the $CA (DEX), $00 (BRK), $04 (undefined) bytes showing up where your code should be. What probably happened was the code you added with the nametables made your code large enough to hit the what you had reserved for whatever that other stuff was at $EB00.

Basically, you began your code with .org $E000. But it's larger than $B00 bytes. In the same bank, you have a .org $EB00, so there's a collision.

Now, NESASM absolutely should have thrown an error for the collision. I'd like to know if it's the latest version, because that's bad if things like that still happen.

The simple way to fix it is to save 8 (or 9 if you keep that code absolute) bytes in your code. Like Memblers said, NESASM doesn't assume zero page. So saving the eight bytes in your case will be super easy. To force zero page in NESASM, use <

Code:
UpdateTiles:
  LDX #$00
LoadBlock:
  STX <$52
  LDA $00,X
  STA <$50
  JSR IndividualTile
  LDX <$52
  INX
  CPX #$10
  BNE LoadBlock
  RTS

Or if you decide to name your variables:
Code:
variable = $00;At the top of the file once

lda <variable;Anywhere else

That will save a byte everywhere you do it in your code as well make your code faster. And it looks like your code ONLY used zero page variables, so there are lots of saving to be had. (Note: Don't do it for non zero page variables. For clarity the zero page is the RAM from $0000-$00FF. $0100-$7FFF is non zero page RAM.)
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152285)
You found it! My code was bleeding into a region that was reserved for $EB00. That's why more writes made that happen! Thanks so much.

Other than that, I am using NESASM3. I am currently cleaning up my code for a few reasons:
1) This was my first program so I am noticing a lot of inefficient work.
2) I'm currently naming my variables so it is easier to read.

When I am done, I will repost with the DMC stuff too. I heard before that NESASM3 is more for learning and has definite disadvantages. What compiler is considered the best, and what would I need to do to my .asm file so that it is compatible with the new compiler?
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152286)
NES Assembler 3.1? NES Assembler 3.01? It displays a version when you run it. There are different versions of a file called nesasm3.exe. Does this one also give you a broken ROM without telling you? If so... *sigh*, poor NESasm.

Different people think different things are the best. ASM6 is nearly as simple, and more versatile. Others like CA65/CC65, which are even more versatile, but not as simple. It shouldn't be too difficult to port your code over to asm6 at least. But... if you're planning on doing that, don't use < for zero page stuff.

You'll need to manually create a header, and change some syntax. LDA [$D2],Y becomes LDA ($D2),Y. Most assemblers use () for indirect addressing, actually. I'll let someone else get more specific than that, I haven't used asm6 with mappers too terribly much and don't want to mislead. (I'm still using NESASM, because my project is too large to easily change to anything. My next project will probably use asm6.)
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152309)
I was using NESASM 3.0 but switched to 3.1 with this file.

I figured out how to upload my game to a cart and play it on a Nintendo but there is one problem: the sprites are being assigned the wrong tiles. This doesn't happen on the emulators. Maybe I did something wrong in the installation? What I did was:
1) Took my .nes file and trimmed off the first 16 bytes.
2) I cut it in two and created two .bin files, 128 kB PRG and 256 kB CHR.
3) Since I am writing to a TKROM 512 PRG, I was told to pad the PRG so that it will be 512 KiB going onto the cart. So I make four identical copies of my PRG (as I understood from the instructions) and paste all four back-to-back.
4) Upload to cart successful. Plug into top loading NES. Turn on and everything else is fine but the sprites are using the wrong tile selections.

Also, is there a page on nesdev that is dedicated to homebrew developers software? There is some software I would be interested in if it exists. Photo to tiles in a few clicks. A video converter that creates small 2 second videos at 30 frames per second. A dedicated convert to DPCM. I can do all these things the normal way but has anybody shortened the process a little?
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152311)
raydempsey wrote:
I figured out how to upload my game to a cart and play it on a Nintendo but there is one problem: the sprites are being assigned the wrong tiles.

Most likely cause is that you haven't initialized all of the mapper's CHR registers properly. Emulators will typically initialize the registers to an NROM-compatible configuration, but this doesn't necessarily happen on real hardware and is not something that should be relied on.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152380)
Most likely cause is that you haven't initialized all of the mapper's CHR registers properly.[/quote]

I'm not sure what that means or how I would initialize the mapper's CHR registers. All I did was cut up the .nes file and upload the portions to the cart. What should I have done instead?
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152388)
He means in the software you have to initialize all of the CHR bank select registers. In particular, it looks like you don't actually set the banks at $0000-0FFF, but I think you set all the others. Emulators often set them up with 0 or some other convenient default, but the MMC3 does not initialize it automatically (i.e. it's a bit random or at least unreliable). Just stick this in your reset I guess:
Code:
lda #$40
sta $8000
lda #0
sta $8001
lda #$41
sta $8000
lda #1
sta $8001

It's generally important to initialize every mapper register on startup.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152390)
raydempsey wrote:
All I did was cut up the .nes file and upload the portions to the cart. What should I have done instead?

There's nothing wrong with how you split or uploaded the files, you just didn't fully initialize the mapper in your code. Emulators sometimes do you the "favor" of initializing some things that the real hardware doesn't, so never count on that and always initialize all registers.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152416)
It works fine now that I initialized all the mappers. Here is a copy of the cartridge sticker as it stands. Might change it, might not.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152482)
Personally, I'd alter the appearance of the T rating to not be a fraudulent duplicate of an ESRB rating, but then again I suppose this whole ROM is an unauthorized cover, so this is probably not a concern of yours.

Also I think the spine text at the top looks a little bit too wide to fit an NES cart, but this is only a guess. If you've measured it and you know it's fine, then never mind me.
Re: Game complete: Blurred Lines 2048 by Demptronicf
by on (#152511)
The cartridge I'm using is from infiniteneslives.com and the proportions on certain parts are slightly different. I can't legally sell it and who would buy it anyway so the infringements are for me only. I was thinking of taking it to a copy shop like Kinko's or something but I don't know if they will print it because of legal reasons. I've also heard that photo sticker paper has a tendency to have the ink rub off so I'm not set on how I will print it.
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#152856)
Do you have a recommendation for a brand and type of sticker paper to use for the printed label? I see to only be able to find photo glossy sticker paper online. Is that what I should be using or is there something else that works best?
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#215163)
Sorry for this ultra huge necro post. :?

I just got around to playing this great game on nestopia and was wondering why every 3-4 seconds the graphics become glitchy and garbled with faces everywhere then go back to normal. IS there an updated version or am i missing something?
Re: Game complete: Blurred Lines 2048 by Demptronic
by on (#223760)
*Spitfire_NES* wrote:
Sorry for this ultra huge necro post. :?

I just got around to playing this great game on nestopia and was wondering why every 3-4 seconds the graphics become glitchy and garbled with faces everywhere then go back to normal. IS there an updated version or am i missing something?


I am not sure. I programmed it to run on FCEUX.