jbs30000

They're all defs Here are a few lines of code rem ************************************************** rem * Make or check if Mario is small or large. * rem ************************************************** def Shrink_Mario=a{0}=0 def Mario_is_Small=!a{0} def Grow_Mario=a{0}=1 def Mario_is_Large=a{0}

I should also note that I played with the path, even putting in include c:\Atari2600\bB\includes\SMarioM.h It still doesn't work.

I decided to rewrite my Super Mario program because the code desperately needs to be cleaned up. So first I made definitions for all of the variables of "a". Then, in order to make things look neater, I put them in a file named SMarioM.h and put the file in the bB\includes folder. I then put include SMarioM.h in my main program. When I compile it seems to be OK, but if I try to use any of the definitions they aren't recognized, so obviously my include file isn't be read. Here's what my main code looks like: rem Rebuilding Super Mario Bros with hopefully better code. include div_mul.asm set kernel_options player1colors pfcolors no_blank_lines set romsize 32kSC const pfres=32 set smartbranching on rem ************************************************************************************************** rem * This file uses all the bits in variable "a" to set or check on various attributes about Mario. * rem ************************************************************************************************** include SMarioM.h bank 2 bank 3 bank 4 bank 5 bank 6 bank 7 bank 8

Hey, great game. It's pretty cool.

On second though, for large Mario I might use those sprites after all. Thank you.

TrekMD, thank you. It's not turning out as well as I had hoped, but it should get better as I work on it. PAC-MAN-RED, thank you, but I think I'll stick to what I have for now. Except maybe the sprite used when you're pressing down on the joystick. theloon, I'll check the program again, but I didn't have that problem. I'll walk Mario from the beginning to the end and see what happens.

Updated program. default.bas.bin After this it will probably be a few weeks or a couple of months before any more updates.

Thank you. If you're thinking of vertical scrolling, I came up with a way to do that flicker free. The thread is here and the best sample program is in post #5. CurtisP added some code to make it scroll smoothly. Horizontal scrolling is harder. As for Mario, he's both player0 and player1. The enemies come in pairs of two, player0 is one enemy and player1 is the other. Making the enemies playfield bricks wouldn't look as good, and would be almost impossible for me to program.

October 19, 2010 One more minor update before working on the more major ones. I made it so that if one or both enemies are on the screen and the screen is scrolling, it will scroll twice to make up for the slowdown of having the draw the screen once for Mario and once for the enemies. The screen is still kind of jerky, but the scrolling is a lot better now. See the third post for the file. ========================================================================================== OK, Super Mario Bros is coming along. The project is a little ambitious, so it hasn't been easy, but I'm slowly getting to the end. Here's a list of improvements, and a couple of setbacks, which I'm working on. Improvements The floor is a different color than the blocks. There's a lot less flicker when the screen scrolls. Press down on the joystick while walking, jumping, or falling, and Mario scrunches down (you'll see). The sprite isn't great, but I'll work on a new one when the program is finally ready. There are Goombas and Turtles now (well, only one turtle). They don't move yet and if you touch them, you won't die. Those features are what I'll be working on next. Setbacks When enemies are on the screen things slow down because I have to use drawscreen twice. I speed Mario up so he moves about the same speed, but scrolling is slowed down. I have an idea on how to fix it though. Even though there's less flicker when Mario is walking, if the screen is scrolling while he's jumping, falling, or scrunched there's a little more flicker for some reason. A problem I think I fixed, sometimes when Mario is at the very right of the screen he becomes part Mario part Goomba. But like I said, I think I fixed it. So, anyway, what's left is to have the enemies move, kill them if Mario jumps on them or kill Mario if he walks into them, make power-up bricks give mushrooms, fire plants, or invincibility stars, and have other bricks get destroyed if mushroom Mario hits them. Oh, and work on speeding up the side scroll when enemies are on screen. If you check out what I have so far, then to start the game hit the fire button. To jump, press up on the joystick. And finally, be careful of gaps in the floor. You need to jump as close as possible because enemies are on the screen and it makes it harder to clear the gaps. default.bas.bin

Thank you very much. This information has been very helpful.

Thank you for the code. I have one more question. I put the following code in a test program and got the asm. Although I'm very familiar with Intel asm, and somewhat familiar with 6502 asm, I don't fully understand the asm generated. I'll put the basic code, along with the asm code and my comments on whether I understand what's going on or not. bB w000{0}=r001{7} asm lda r001 - Load the accumulator with the contents of r001 and #128 - AND that value with 128 php - Push the processor status onto the stack - why? lda w000 - Load the accumulator with the contents of w000 - w000 is write only, that probably won't work and #254 - AND that value with 254 plp - Pop the processor status - why? .byte.b $f0, $02 - Don't know what this does. or #1 - OR the accumulator with 1 sta w000 - Store the accumulator value in w000 Anyway, if you could tell me what the php and plp do and what f0 02 does I'd appreciate it. Thank you.

A macro would be a good idea if it's possible. It would be less work than adding the functionality to the compiler. I was going to ask about something slightly more complex, but it dawned on me that I can put in the bB code and examine the asm output myself. But anyway, if you could figure out a macro, that would be great. Thank you.

Would this be possible to ad to the language, or would it be too complicated or not work right? bB lets you use variables - var[index 1], var[index 2], etc... bB lets you set or unset individual bits - var{0}, var{1}, etc... Would it be possible to combine the two so that you could have something like this? dim Counter=a dim myvar=b for Counter=0 to 5 myvar[Counter]{0}=1 next

It's been a while since I've done this so I figured I'd better double check because my memory is crap. If I go dim MyArray=a Then MyArray[0] is a and MyArray[1] is b, correct?

I'm not "good", but I know enough to answer your question. Make a variable a timer, set it to something like 12 or 20 (play around till it sounds right) and have it count down in you main game loop. When it hits 0 turn the volume to 0. Something like Main_Loop Counter=Counter-1 if Counter=0 then AUDV0=0 <game code here> goto Main_Loop Something like that.

Thank you very much for the answers.

I read through the manual, and I don't think I saw this mentioned, but then I might have just missed it. When setting the window for display height, what's the maximum height allowed? An example used a value of 64, is that the maximum? Or can it display up to 96? Thank you.

When a collision is detected the program jumps to a subroutine where the volume is set to 5 and a counter is set to 10. When the program goes back to the main loop, the counter counts down to 0, and when it hits 0 the volume goes back to 0. However, for whatever reason, the sound isn't made until Mario lands on the ground again.

In my Super Mario game when you jump I use channel 0 for the jumping noise. I just added a sound for when Mario jumps up and hits a brick using channel 1, but for some reason channel 1 only plays after channel 0 is through playing. Is that normal? I thought channels 0 and 1 could overlap.

Just an FYI, this can be done by pressing Alt-L while a game is running. And going into the debugger and stepping through each frame shows the same info as well. Thank you for the info.

Well, my version will probably leave a lot to be desired, but I'll do my best.

Both as Playchoice and Vs.(standalone) versions. So, in other words it's just the NES version in an arcade cab? The arcade's a little different but they are very similar.

I'll try the PF0, but I'm not sure it will work since it's for the border around the playfield. I think the playfield would still wrap around to the other side. As for drawing, it only does that every 8th scroll. Or rather the screen will scroll 7 times, and then the 8th time new items are drawn, so that shouldn't really be an issue. I would paste the code (or post the .bas file) but it would probably look sloppy or confusing. At least that's what I'm guessing the reason is in the past when I would post code asking for suggestions or improvements and nobody would respond.

I put in vblank at the end of the program. I ran it with z26 -n (the colors look awful, not even close to Stella) and I couldn't read the scanline count when the screen was scrolling. default.bas.bin

I'll make a small change, but I think that in the arcade game the ground and blocks are pretty much the same color.