NintendoAge http://nintendoage.com/forum/ -Sqooner Nerdy Nights Sound: Part 5 http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=23452 2016-11-20T03:21:27 -05.00 MetalSlime 11 Nerdy Nights Sound: Part 5 http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=23452 2010-05-08T09:35:15 -05.00 MetalSlime 11 Originally posted by: rizz

Hi MetalSlime/Thomas,

First & foremost, your sound lessons are fantastic. I've been liking the extra tips that you throw in as well, and your simplicity makes it easy to envision other areas of code that can benefit from your examples.


I'm writing to ask about this part of your code, which manually deals with 8-bit addition:
clc
adc stream_ptr_LO, x ;add Y to the LO pointer
sta stream_ptr_LO, x
bcc .end
inc stream_ptr_HI, x ;if there was a carry, add 1 to the HI pointer.


As far as I know, this could be done instead:
sta stream_ptr_LO, x
LDA stream_ptr_HI, x
ADC #$00
STA stream_ptr_HI, x

Was there any specific reason why you chose to check a branch condition?

Thanks.  Glad you find the tutorials helpful.  As far as branching vs. adding 0, I didn't really have a specific reason to use one over the other.  I'm just more accustomed to doing it the bcc way.

But now that I think about it, branching is probably slightly better performance-wise.  A "bcc" and an "inc abs,x" take up 5 bytes of ROM space.  "lda abs,x", "adc", "sta abs,x" takes up 8 bytes of ROM space.  Most of the time the carry will be clear, so skipping instructions in the most common case saves some cpu cycles too.  Even when the carry is set, the INC takes fewer cycles than the LDA/ADC/STA combo.

By the way, I had to look that up just now.  I'm not a cycle counter so I don't know any of this stuff off the top of my head .  I never considered any of this when I wrote the code.   The savings are negligible, so it seems like a pick 'em to me.
]]>
Nerdy Nights Sound: Part 5 http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=23452 2010-05-08T02:28:27 -05.00 MetalSlime 11
First & foremost, your sound lessons are fantastic. I've been liking the extra tips that you throw in as well, and your simplicity makes it easy to envision other areas of code that can benefit from your examples.


I'm writing to ask about this part of your code, which manually deals with 8-bit addition:
clc
adc stream_ptr_LO, x ;add Y to the LO pointer
sta stream_ptr_LO, x
bcc .end
inc stream_ptr_HI, x ;if there was a carry, add 1 to the HI pointer.


As far as I know, this could be done instead:
sta stream_ptr_LO, x
LDA stream_ptr_HI, x
ADC #$00
STA stream_ptr_HI, x

Was there any specific reason why you chose to check a branch condition? ]]>
Nerdy Nights Sound: Part 5 http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=23452 2009-10-03T23:15:37 -05.00 MetalSlime 11
Turning off the NMI is done by clearing bit 7 of $2000, and will stop the NMI from interrupting the game at the beginning of each vblank.

Turning off the PPU is done by clearing bits 3 and 4 of $2001 (background and sprite rendering) and it will stop the PPU from rendering background tiles and sprites. In other words, turning the PPU off will mean that nothing gets drawn to the screen at all (black screen).

You can turn the PPU off and still have the NMI running. Any graphics updates you do while the PPU is off won't show until you turn it on again, but if you have any non-graphics code in the NMI (sound engine being a common example), it will still get run when it needs to be run.

Yeah, if you are loading a full 256 tiles all at once, turning off the PPU is the only way to do it. You can make it look smoother by fading your palettes to black before you turn the PPU off.

Anyway, to address your original problem, it is very possible to load the background circles once, and then be able to update the smaller insides without turning off the PPU. It just might take more than one frame depending on how many tile updates you have. You might have to do something like this:

update box 1
wait for next frame
update box 2
wait for next frame
update box 3

Each frame is only a fraction of a second, so the player won't be able to tell. ]]>
Nerdy Nights Sound: Part 5 http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=23452 2009-10-03T13:43:33 -05.00 MetalSlime 11
I would think I could save a lot of PRG space if I only have to .db a few lines instead of a whole screen full of tiles. You know, like loading say 50 tiles instead of 256.

I know all about the flash from the disable/enable of NMI. It happens in my BattleBall game cause that's the way the Neardy Nights showed you how to do it. Also, I'm loading a full 256 tiles for every screen change, so I pretty much had no choice.

I'm just trying to plan out some more efficient ideas for my next game. If this works it'll save space and not have the screen flashes. ]]>
Nerdy Nights Sound: Part 5 http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=23452 2009-10-01T03:53:32 -05.00 MetalSlime 11 Originally posted by: udisi

As I was saying I was looking at how you did the text strings, but I have a few questions about them to see if I can use the idea in my next game. Below is a screen shot from Wizardry and it uses the type of display I want to use.0

I want to split the screen with the red circles and be able to update the red lines within those circles independently.

The top left would be used for some picture graphics, top right would be some test like the example, and the bottom would be some status and inventory info.

1) Now your text loading doesn't load a bunch of tiles. it pretty much just loads "playing", "not", "disabled", etc...so like maybe 10 tiles. I'm wondering is there a limit to the amount of tiles I can load using your method, or will I run out of vblank time. Kinda like how you can only load 64 sprites per frame?

2) You don't load any other background besides the text in your tutorial, so the background just fills the other space with $00. I want to put a border in like in the example with the white lines. Can I load the border once, and then just update the lines within the border? I know I can make strings that start and terminate at the spots I want, but I don't know if I can have a static border or not?

Pretty much that's all I want to do. Have that static boarder, and then be able to use text/graphic strings to fill in the areas of the boarders independently. You're code seems like it can be modified to do such, but I don't know if there's any hardware limitations to it.


To answer question 1, yes you can run out of vblank time if you fill your buffer with too many tile writes.  You will probably have to stagger all of your text writing across several frames.  Write some tiles, wait for the next frames, write some more, wait til the next frame, write some more, etc until you've written all the data you need to write.  Use trial and error to figure out how many tiles you can safely write before you spill out of vblank.

Alternatively, if you don't mind the screen flashing black for a second, you can turn the PPU off, write everything at once and then turn it back on.  If the PPU is off you don't have to pay attention to vblank at all (except for palette updates I think) so you can write as much to the screen in one go as you like.  This would be an ok solution if the text inside the boxes wouldn't change after displaying it, like pressing the select button to load up a static stats screen.  It would be a bad solution for something like a character selection screen, where pressing the d-pad left and right would select the next character and update the text with their individual stats.  You'd get an annoying black flash in between every character.

For question 2, yes you should be able to draw the border once and then just update the lines within the borders.  As long as you don't draw something in the same space as the border, or turn off the PPU or mess with the scroll, it should stay put.
]]>
Nerdy Nights Sound: Part 5 http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=23452 2009-09-29T14:22:23 -05.00 MetalSlime 11

I want to split the screen with the red circles and be able to update the red lines within those circles independently.

The top left would be used for some picture graphics, top right would be some test like the example, and the bottom would be some status and inventory info.

1) Now your text loading doesn't load a bunch of tiles. it pretty much just loads "playing", "not", "disabled", etc...so like maybe 10 tiles. I'm wondering is there a limit to the amount of tiles I can load using your method, or will I run out of vblank time. Kinda like how you can only load 64 sprites per frame?

2) You don't load any other background besides the text in your tutorial, so the background just fills the other space with $00. I want to put a border in like in the example with the white lines. Can I load the border once, and then just update the lines within the border? I know I can make strings that start and terminate at the spots I want, but I don't know if I can have a static border or not?

Pretty much that's all I want to do. Have that static boarder, and then be able to use text/graphic strings to fill in the areas of the boarders independently. You're code seems like it can be modified to do such, but I don't know if there's any hardware limitations to it.
]]>
Nerdy Nights Sound: Part 5 http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=23452 2009-09-17T22:36:19 -05.00 MetalSlime 11 Originally posted by: udisi

this is excellent. I actually think week 4 was the big step for me. This one kinda just built off of that one more. I don't understand everything in this one for sure, but I can definitely follow it enough to know what the sections of code are doing. It took me like 10 mins to add my old SFX into this engine and place the updated engine into my game.

Oh good!  I was a little worried that this week might be too much all at once, but I cut it down as far as it would go.  Glad to see that it turned out ok!

I was was thinking about blank notes or breaks and wondering if the easiest way to do it would to be just add a word byte to the note_table.i call BK and have it with a value of $0000. then when writing a song with a rest or something would be like
.byte D3,D4,BK,D4,D3,$FF

That should work for the Squares.  I don't remember the exact number off the top of my head, but the Square channels output silence for any period below $006 or $007.  I think I read somewhere that the Triangle channel will still produce audible output even at a period of $000, so you will have to do something else in the Triangle case.  I'll see if I can fit Rests into the next lesson.  I think the next lesson is a little easy, so adding an extra topic shouldn't hurt.

 I'm learning a lot about pointers, lookup tables, and include from you which is just as useful as the music engine itself. I've always been a bit better at hacking existing code, then designing. I much prefer seeing code in use, then trying to figure out how to design it. After seeing this, it will probably help me a ton on my next game with all kinds of loads. Right now I have seperate subroutines to load my backgrounds and each one of them has the same sets of loops to load the background tiles and attribute table. Now that I kinda see how these lookup tables work, I could cut a ton of code out and use a single loading loop and use a table to decide which backgound and attributes to load.

Great!  Aside from the sound-specific stuff, one of my goals with these tutorials is to introduce some advanced techniques that can be applied to other components of a game.  Pretty much everything carries over.  If you were going to write an RPG textbox engine for example, you'd have the same thing.  You'd have a pointer table to all the text strings in the game.  Talking to a villager would "load" one of the strings from the pointer table.  Your text data would be divided into ranges: one range for characters, one for opcodes (next line, clear the box, play a sound, etc).  Your data reading routine would test the ranges and branch to different sections of code.  The method is the same, just the details are different.

Good call on the background loading routines.  That's exactly how I'd do it.  Setup a pointer table and have a single set of routines that will load and draw your background based on an index (background number).

I tend to be able to always make things work, but I design poorly. These sound tutorials will make me much more efficient in the future.

We all start out that way.  You should see the code of my first project.  It wasn't very pretty .  But you learn a lot just trying stuff and tinkering with things.  Once you get that experience under your belt, you can start looking at other peoples' code and figuring out better ways to do things.  I learned most of these techniques from peeking at commercial games in FCEUX's debugger.  But I wouldn't have been able to do that if I hadn't gotten my hands dirty with my own project first.  I'm glad you are finding these tutorials helpful!
]]>
Nerdy Nights Sound: Part 5 http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=23452 2009-09-16T22:21:45 -05.00 MetalSlime 11
I was was thinking about blank notes or breaks and wondering if the easiest way to do it would to be just add a word byte to the note_table.i call BK and have it with a value of $0000. then when writing a song with a rest or something would be like
.byte D3,D4,BK,D4,D3,$FF

I'm learning a lot about pointers, lookup tables, and include from you which is just as useful as the music engine itself. I've always been a bit better at hacking existing code, then designing. I much prefer seeing code in use, then trying to figure out how to design it. After seeing this, it will probably help me a ton on my next game with all kinds of loads. Right now I have seperate subroutines to load my backgrounds and each one of them has the same sets of loops to load the background tiles and attribute table. Now that I kinda see how these lookup tables work, I could cut a ton of code out and use a single loading loop and use a table to decide which backgound and attributes to load.

I tend to be able to always make things work, but I design poorly. These sound tutorials will make me much more efficient in the future. ]]>
Nerdy Nights Sound: Part 5 http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=23452 2009-09-16T08:24:47 -05.00 MetalSlime 11