jbs30000

OK, I settled on using single defs for each attribute. def True=1 def False=0 def Mario_is_Large=a{0} def Mario_has_FirePower=a{1} My main goal is to have other people (as well as I) be able to look at the code, and with little to no REM statements easily know what's going on because there's going to be a lot of code and it could get confusing easily if it's not immediately clear what the code does. Mario_is_Large=False isn't the best way to say that Mario is small, but it works.

The way it will work is that Mario starts out with a{0}=0. When he gets a mushroom then a{0}=1. I want to express that in English so that the program is easy to read. So far I'm just going with the consts since I read on Random Terrain's board that you can have 500 of them.

I have re-started my Mario game using the DPC+ kernel. This time I'm off to a great start and the code to dim my variables is a lot neater, cleaner, and easier to read than before. Because of the limited amount of variables I used DEF a lot, but ran into the 50 DEF limit. So I've come up with a new way to set values, but I'm curious if there's an even better way. First, a sample of how I was doing it: def Make_Mario_Small=a{0}=0 def Make_Mario_Large=a{0}=1 def Mario_is_Small=!a{0} rem ******************** def Make_Mario_Normal=a{1}=0 def Make_Mario_FirePowered=a{1}=1 def Mario_is_Normal=!a{1} So, to make Mario large, all I'd have to type is Make_Mario_Large. To check Mario's size all I'd have to type is if Mario_is_Small then x else y. How I'm redoing it is like this: macro Poke {1}={1}&{2}|{3} end def Setup=callmacro Poke rem ******************** rem * Mario variables. * rem ******************** dim Mario=a rem ******************** const _Size=%11111110 const _Small=0 const _Large=1 rem ******************** const _Power=%11111101 const _None=0 const _Fire=2 So here, to make Mario large I go Setup Mario _Size _Large. To see if he's large I go if Mario&!_Size=_Large then x. So, this works, but is there an even better way to do this?

Thank you.

I thought I saw it before, but I can't find it now, so I just want to verify. DF0FRACINC-DF3FRACINC only are for vertical resolution, right? Horizontal is fixed at 32 pixels?

I rarely used the old multisprite kernel, but I'm pretty sure that you couldn't use collision(playerx, playerx) for sprites 2 and above. So yeah, it's a lot easier than before.

Apologies if I'm typing something you guys already know. I did lots of searching on virtual sprite collision detection and didn't find much so I did my own experiment. I placed sprites 0 and 3 on the screen and then programmed the joystick to move sprite 0. I put, if collision(player0, player3) then reboot and every time they touched the program rebooted. I changed all references from sprite 0 to sprite 5 and it still worked. This is awesome.

OK, I right clicked and changed backgroud color and that did the trick for the black background in the sprite editor. Sorry I didn't think of that sooner. I just never had this problem before and so never had to deal with changing the background color.

OK, I'll send you the error later. Right now I'll give the values. _DEFAULTBACKCOLOR = 0E _DEFAULTPLAYERCOLOR = 00 _DEFAULTPLAYFIELDCOLOR = 00

When I click on any square using any color, nothing happens. Also, when I choose PF colors I get

Strange. I deleted the other vbB, put the new files in the directory, and some of the settings were already set, such as my projects. The only difference is before I was starting vbB from a shortcut, whereas this time I opened the program directly. OK, when I bring up the sprite editor and playfield editor everything is black. Well, not the whole screen, just the grid and the preview.

Up until a few months ago I was working on VS. Super Mario Bros. I got pretty far, but as I had to fix problems and add more details, programming got more difficult so I took a break. I decided to start over with the new DCP+ and downloaded the 557 version of VbB. First, each time I start it the settings from before aren't saved and I keep getting the, "It looks like you're running VisualbB for the first time" screen. Second, on the playfield and sprite editors some of the top checkbox options overlap. The second one isn't a big deal, but the first means I keep having to re-add my projects. I'm using Windows 7 64 bit if that makes a difference. Thanks.

It will be nice having multiple sprites built in to the kernel but not having to use a mirrored playfield to do so.

A month ago I started a new job. That, and a few other things that have happened, along with the problems in my program have made me lose my interest in continuing this program. I wasn't planning on it, but I might just wait until an official version of the DPC+ version bB comes out. It should make programming easier for me, and I think I'll be able to avoid two problems that I seem to be having with the current standard version of bB.

Well, I think it is.

Well, don't I feel like an idiot. Anyway, I don't know if much work will be done on the standard kernel or if everybody who helps work on kernels will be focusing their effort on the bB 1.1 kernel.

The screen is mirrored in the multisprite kernel though.

Dang it. The collision code was only written for Mario touching an enemy. There are only ever two enemies on screen, Enemy 1 and Enemy 2. Enemy 1 can also be a power-up item: mushroom, fire plant, star, or coin; So I rewrote the collision code to take the appropriate action if Mario hits a power-up item. The only problem now is that if Enemy 1 is a Goomba, if it hits Mario he becomes large, as if Enemy 1 was a mushroom. I made a couple of minor tweaks to make sure that what kind of enemy or power-up item Enemy 1 is, is done correctly, but I still have the error. This sucks.

I did it on purpose. I didn't notice Mario's chin. It should be the same on all of them. I'll check that out. Thank you.

No. Future games I make will use the new bB, but I'm completing the game on the current version. I think I said this before, but from time to time I get errors or problems that nobody else gets. I want to wait until all of the bugs are worked out of the new version before I use it. I don't want to annoy people by posting a lot of problems and asking, "Is it just me or is it a bB bug?".

Thank you. I forgot to mention that when falling you'll occasionally see a bar under Mario's feet. That's the ball (I can't use Missile 1 or 2 since I'm using player1colors and no_blank_lines). It looks a little annoying at times, but it helps make sure that Mario lands on pipes, bricks, or the ground properly. Also, I need to make a routine to make the ball a "fire ball" that Fire Mario can shoot.

Thank you SpiceWare. That is an improvement.

OK, after struggling to rewrite my game with decent code, descriptive variables, and adding a bunch of things I left out of my first game, I am now finally at the point when I decided to rewrite the game. (Hope you understood all that). The game is written under the standard kernel and not the DPC+ kernel. Here's some improvements from when I wrote the game the first time. Landing on a Goomba or turtle will make Mario bounce, just like in the official games. Landing on the turtle will flip him on his back and he won't move. Landing on the turtle again will flip him back and his feet and he'll walk away. Unfortunately you can't push the turtle and make him slide into and kill Goombas. [*]When Mario dies it's the way he dies in the arcade and NES games (minus the music). There are some glitches with the collision routine. Sometimes Mario will kill a goomba simply by walking into it and other time he'll land on a Goomba and it walks away unharmed. Here's what I still need to add. Jumping into a power-up brick and causing a mushroom, fire plant, star, or coin to pop out (I have a plan on how to do that). Large Mario jumping into and empty brick and destroying it. Causing Mario to lower the flag and walk into the castle when he reaches the end of the game. One or two other things I'm forgetting right now. OK, now that the code is decent I'll post the project (I'm using Visual bB) for anybody who is interested. If you have any suggestions on how to improve the code, or wonder how or why I did something I'm happy to listen to you or give you whatever information that you want. Oh, and PAC-MAN-RED, I hope you like the sprites. If not, tell me what you think would improve them, and I'll try it out. Edit: I forgot to add the files. Here we go Main.bas.bin Super Mario 2.zip

Oh yeah, I already figured out that pressing the fire button changed which number to move. I was just confused about the mouse because I thought it was set to emulate a paddle, not the joysticks.

Silly question, but I just want to verify that my copy of Stella is working right. I took the version in the link about the new bB and replaced the files I already had. Anyway, when I run the sample program msdpc.bin here's what it looks like: Also, if I move my mouse across the playfield it moves the number 1 and messes with the foreground. I don't know if it's just me or not.