It is currently Sat Apr 21, 2018 2:31 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1443 posts ]  Go to page Previous  1 ... 59, 60, 61, 62, 63, 64, 65 ... 97  Next
Author Message
PostPosted: Wed Feb 06, 2013 2:51 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
tokumaru wrote:
Are you using a mapper? Have you selected the appropriate CHR-ROM banks? If you're using the MMC1 in 4KB CHR mode you might get the same 4KB mapped twice if you didn't explicitly switch the 2 4KB pages you want to use.

Thanks tokumaru. That ended up being the problem... figured this out during lunch... it all works correctly now! :)

---
It would be good right now for me to start with a version number like Kasumi suggested a while ago...


Top
 Profile  
 
 Post subject: Re:
PostPosted: Fri Feb 08, 2013 3:10 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
Kasumi, on page 36, wrote:
.... Even something simple like this is good.
Version 1:
Added animations.
Add movement.
Version 2:
Added horizontal scrolling.
Added 16bit movement for sprites.

I backup my entire source folder for every major change, and keep track of changes. This allows you to only check what was changed when you have an issue. "It was working. I added X, and changed Y. Now it's not. The problem is probably in X or Y, so I'll look at their logic." This also means if you REALLY screw up, you can just copy over the last backup.

Also, never write super large portions of code without checking them. For an example of something you've done before (tile updating), you could write something that gets the two right most 8x8 tile numbers of a known 16x16 metatile and writes them to ram. Run it, and check to see the write values are written to RAM. Then you write something that writes a whole known column of the tiles to RAM. If it doesn't work, or breaks your program you know exactly what to check. Then, you make your NMI write the tiles to $2007. Then you make it so can write a column at X position. If you write a single routine that does the equivalent of all that without checking any of it, you're in REALLY deep. Especially if you have to rewrite it ALL instead of just fix it.

And if you have no idea what was changed, you basically have to check the entire program.

So I guess those were debugging tips, because I have no idea about the actual problem with the information given. It's time to get your hands dirty! :D

Thank you, this post is very wise... you are very wise Kasumi! :D But I only mean to respond to that small yellow part I highlighted. Your entire source folder? You have a folder just for your source code? That sounds interesting. My folder has the name "nesD" cause the year is 2013. It holds all of my nes stuff from 2013. How do you have a folder for just your source code? How could I build a nes file using something like that and asm6?


Last edited by unregistered on Fri Feb 08, 2013 3:23 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri Feb 08, 2013 3:18 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1124
Animated GIF:
Image
Just keep all the things you need to build your program in a folder. When you want to make a backup, copy that folder. There are better methods than this, but this is probably good enough for a solo project.

Edit: Inside the main source folder I have another folder named "Notes" where I keep a file called "changes.txt" that keeps track of changes in great detail, and a file called "general notes.txt" which is where I put possible ideas for the game/current bugs/a todo list. When the backup is made, these files are copied as well of course. So it allows me to see what I was working on in each version, which is sort of fun to look back on.

It's better to keep things like NES specific documents separate. I would say as a general rule that anything not made by you that is not needed to assemble your rom should not be in your source folder.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Fri Feb 08, 2013 3:32 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
In your animated gif... the folder names are quite long... that would make the nes rom take a long while to build... right?

edit: I mean it would take a while to type out the folder name... and it would be lots of mistakes... for me at least. :)


Top
 Profile  
 
PostPosted: Fri Feb 08, 2013 3:47 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1124
Quote:
In your animated gif... the folder names are quite long... that would make the nes rom take a long while to build... right?

The NES is not even 2 MHz, and could parse like 8,000 characters in a 60th of a second. Your computer is probably thousands of times faster than this. I mean... maybe it takes longer, but it's not something I think about. Any C program takes longer.

Also, long folder names like "GalaxyNES 22 With Reworked Debug Mode, Faster Speed Curve and Greens that don't randomly die" (hah) are not even used to assemble the rom. They're backups. The actual folder I build from, is just "GalaxyNES". When I make a major change, I copy the GalaxyNES folder and give it a long descriptive name. (Which you don't have to do. You could just number/date it and keep track of what each dated folder is in a separate file. In fact, I recommend doing this.) If I want to restore it, I just copy it again, get rid of my old "GalaxyNES" folder and rename the "descriptive" one back to GalaxyNES.

Quote:
edit: I mean it would take a while to type out the folder name... and it would be lots of mistakes... for me at least. :)

Except you do it once every month, or whatever. I did it a lot in GalaxyNES, but that's because the entire thing took only like 4 months start to finish. My current project only has a backup every month to three months, unless I'm trying to really tricky stuff.

Edit: Ideally, you never even use the backups. I've had to restore to a previous version I think once. I'm really glad I had the option that one time, though. They're also good to refer to as well when you're rewriting stuff. I do that quite a lot.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Fri Feb 08, 2013 3:56 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
Kasumi wrote:
Quote:
In your animated gif... the folder names are quite long... that would make the nes rom take a long while to build... right?

The NES is not even 2 MHz, and could parse like 8,000 characters in a 60th of a second. Your computer is probably thousands of times faster than this. I mean... maybe it takes longer, but it's not something I think about. Any C program takes longer.

Also, long folder names like "GalaxyNES 22 With Reworked Debug Mode, Faster Speed Curve and Greens that don't randomly die" (hah) are not even used to assemble the rom. They're backups. The actual folder I build from, is just "GalaxyNES". When I make a major change, I copy the GalaxyNES folder and give it a long descriptive name. (Which you don't have to do. You could just number/date it and keep track of what each dated folder is in a separate file. In fact, I recommend doing this.) If I want to restore it, I just copy it again, get rid of my old "GalaxyNES" folder and rename the "descriptive" one back to GalaxyNES.

Quote:
edit: I mean it would take a while to type out the folder name... and it would be lots of mistakes... for me at least. :)

Except you do it once every month, or whatever. I did it a lot in GalaxyNES, but that's because the entire thing took only like 4 months start to finish. My current project only has a backup every month to three months, unless I'm trying to really tricky stuff.

Edit: Ideally, you never even use the backups. I've had to restore to a previous version I think once. I'm really glad I had the option that one time, though. They're also good to refer to as well when you're rewriting stuff. I do that quite a lot.


Wow, this is so amazing!! Thank you for these detailed responses! :D
They will be helpful!!!


Top
 Profile  
 
PostPosted: Fri Feb 08, 2013 4:19 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1124
Here's how I organize my changes. The oldest version is at the bottom. The date to the right of the version number is the assemble time. This alone is enough to keep track of which versions are which, but I also do the long folder names because I'm lame. :lol:
Quote:
Version 5 (4/4/09 12:51 PM)
Sprites can now be linked, have small offsets every fourth frame

Version 4 (4/4/09 7:30 AM)
Rewrote Animations/big sprite handler from scratch. (Currently only supports sprites that animate themselves)

Version 3 (4/1/09 10:26 PM)
Fixed a glitch where the animations didn't give the proper attributes to their individual sprites.

added a way for follower sprites to keep the animation of their leader sprite


Version 2 (4/1/09 7:05 PM)
Basic Animation Handler Added


Version 1 (3/31/09 4:02 AM)
Just a simple dual sprite viewer.

When I finish out a version, I put a new version number on top with "(Current Version)", instead of the build date. This lets you see what bug fixes/features you'll lose by going back a few versions. I keep track of the file formats I've written as well. If they change, the current format is still documented with the source folder that uses it.
Image
Keep track of stuff you're currently working on, and possible idea for how to fix problems you don't have time for right now.
Image
See the "If Optimizations Are Desparately Needed" file in the GalaxyNES folder. :D

The bottom line is to keep organized. You don't have to do it this way, (I'm sure there are better ways that blow this out of the water) but make it so that if something terrible happens you'll have a safety net. Make it so that if you stop working on the program for a couple of months or years, you won't have to read through ALL of the source code to figure out what you were doing. Anyway, that's all I got. Keep it up!

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
 Post subject: Git
PostPosted: Fri Feb 08, 2013 7:28 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19927
Location: NE Indiana, USA (NTSC)
Kasumi wrote:
The bottom line is to keep organized. You don't have to do it this way, (I'm sure there are better ways that blow this out of the water)

Perhaps Git or Mercurial might be a good match to your way of working.


Top
 Profile  
 
PostPosted: Tue Feb 12, 2013 3:01 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
Kasumi wrote:
Here's how I organize my changes. The oldest version is at the bottom. The date to the right of the version number is the assemble time. This alone is enough to keep track of which versions are which, but I also do the long folder names because I'm lame. :lol:
Quote:
Version 5 (4/4/09 12:51 PM)
Sprites can now be linked, have small offsets every fourth frame

Version 4 (4/4/09 7:30 AM)
Rewrote Animations/big sprite handler from scratch. (Currently only supports sprites that animate themselves)

Version 3 (4/1/09 10:26 PM)
Fixed a glitch where the animations didn't give the proper attributes to their individual sprites.

added a way for follower sprites to keep the animation of their leader sprite


Version 2 (4/1/09 7:05 PM)
Basic Animation Handler Added


Version 1 (3/31/09 4:02 AM)
Just a simple dual sprite viewer.

When I finish out a version, I put a new version number on top with "(Current Version)", instead of the build date. This lets you see what bug fixes/features you'll lose by going back a few versions. I keep track of the file formats I've written as well. If they change, the current format is still documented with the source folder that uses it.
Image
Keep track of stuff you're currently working on, and possible idea for how to fix problems you don't have time for right now.
Image
See the "If Optimizations Are Desparately Needed" file in the GalaxyNES folder. :D

The bottom line is to keep organized. You don't have to do it this way, (I'm sure there are better ways that blow this out of the water) but make it so that if something terrible happens you'll have a safety net. Make it so that if you stop working on the program for a couple of months or years, you won't have to read through ALL of the source code to figure out what you were doing. Anyway, that's all I got. Keep it up!
Many thanks this has been and is incredibly helpful for me! :D

tepples wrote:
Kasumi wrote:
The bottom line is to keep organized. You don't have to do it this way, (I'm sure there are better ways that blow this out of the water)

Perhaps Git or Mercurial might be a good match to your way of working.
Thanks tepples; I spent some time reading about Git... but it got too complicated and I am returning to my quest for scrolling beyond two screens. Now there's this super cool "general notes" text file 8-) that Kasumi gave me and it has become important! :D


Top
 Profile  
 
PostPosted: Fri Feb 15, 2013 2:55 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
Kasumi, on page 59, wrote:
unregistered: Seems about right. If I already have rendering disabled and am updating the PPU outside the NMI, having the NMI interrupt this task is kind of useless. Is that more clear? Well... maybe not totally useless. If you have a total playtime counter and use the NMI to time it, you'd still want them enabled.
How do I update the PPU outside of the NMI? I seem to be doing this... am recieving a black screen though... so how do I update the PPU outside of the NMI without recieving a black screen? The Name table viewer of FCEUX shows an almost correct updated nametable as the screen goes black... and until I reset the NES.


Top
 Profile  
 
PostPosted: Fri Feb 15, 2013 3:06 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1124
unregistered wrote:
How do I update the PPU outside of the NMI? I seem to be doing this... am recieving a black screen though... so how do I update the PPU outside of the NMI without recieving a black screen?

You disable rendering by writing 0 to $2001, update the PPU, then reenable rendering by writing something like #%00011000 to $2001. If the screen is black, but the game hasn't really crashed I would assume you're just forgetting to turn rendering back on.

Edit: Disabling rendering makes it so your screen is not drawn, so you can only write bytes to the PPU this way in between levels, not during gameplay when the player needs to see what's happening.

The super simplified explanation is that you cannot write bytes to the PPU while it's trying to draw the screen. It's not doing so for ~2,270 cycles after an NMI fires which is why you can write bytes then. It's also not doing so when the screen is not being drawn.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Fri Feb 15, 2013 3:41 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19927
Location: NE Indiana, USA (NTSC)
Kasumi wrote:
Disabling rendering makes it so your screen is not drawn, so you can only write bytes to the PPU this way in between levels, not during gameplay when the player needs to see what's happening.

Unless you're making a flip-screen platformer like Sivak's Battle Kid or thefox's port of Podunkian's Streemerz. Then you can turn rendering off for five whole frames to draw the new screen without the player caring.


Top
 Profile  
 
PostPosted: Fri Feb 15, 2013 3:44 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
tepples wrote:
Kasumi wrote:
Disabling rendering makes it so your screen is not drawn, so you can only write bytes to the PPU this way in between levels, not during gameplay when the player needs to see what's happening.

Unless you're making a flip-screen platformer like Sivak's Battle Kid or thefox's port of Podunkian's Streemerz. Then you can turn rendering off for five whole frames to draw the new screen without the player caring.

Ahhhhhhhhhh thank you Kasumi! :D


So tepples, since our game is will be a flip-screen platformer vertically could we do that?

edit.
edit2.: Sorry for messing this post up. :(
edit3.


Top
 Profile  
 
PostPosted: Sat Feb 16, 2013 6:12 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10417
Location: Rio de Janeiro - Brazil
unregistered wrote:
since our game is will be a flip-screen platformer vertically could we do that?

If it's flip-screen it can't be vertical or horizontal. Flip-screen means that there's no scrolling at all: when the player leaves the screen, it goes blank for a couple of frame (while the new screen is drawn) and then the new screen appears, with the player on the opposite edge. Concepts like "vertical" or "horizontal" don't mean anything in this case, so there must be some misunderstanding here.


Top
 Profile  
 
PostPosted: Sat Feb 16, 2013 6:27 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19927
Location: NE Indiana, USA (NTSC)
Lots of games are flip-screen vertically but scrolling horizontally. Castlevania is one when going down or up stairs. Super Mario Bros. is one when going down or up the pipe in 1-2. Super Mario Bros. 2 is another when going down or up the vine at the right side of 1-1.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1443 posts ]  Go to page Previous  1 ... 59, 60, 61, 62, 63, 64, 65 ... 97  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


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

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