jbs30000

This game reminds me of Centipede .

I'm curious, will there be any advantages using this, instead of getting a bigger playfield by using the superchip option?

Since the even numbered bytes are backwards from the odd numbered bytes, the, for the top row, for example, you'd need to shift bytes 0 and 2 to the left, I think, and bytes 1 and 3 to the right.

Can you have as many def statements as you want, or is there a limit, like there is for dim ? Thank you.

Thanks.

Ok, say I have 5 variable, Misc1, Misc2, Misc3, Misc4, Misc5. Is there a difference between if Misc1>=Misc4&&Misc1<=Misc5&&Misc2=Misc6 then and if Misc1>=Misc4 then if Misc1<=Misc5 then if Misc2=Misc6 then

Well, part of the reason I’m thinking of leaving the lines in, is that the shapes look a little bit better. With no blank lines, some objects look kind of square when they’re not supposed to. Of course also, all the objects look solid, which is nice. As you can see, I’m making the question-mark-blocks hollow, and the other blocks solid. Unfortunately, I don’t have enough playfield pixels put question marks inside of the blocks. I thought about trying to make it scroll, but for a lot of reasons I’m not going to. Also, this is only going to be World 1-1 more than likely. If it turns out OK, I might go back and try to improve it, as well as do the other levels. But, except for the scrolling, I’m going to try and make this level as faithful to the original as possible, if I can. I think it would be nice to use the ball-sprite for the blocks but then you could only have one block per screen... Hmmm, or I could draw the screen more than once, and each time place the ball in a different location, but I'm afraid that's what I'm going to have to do with the other player sprite if there's more than one enemy on the screen at the same time. Anyway, just making the question mark boxes hollow works. And they won't flicker like they would if I used the ball.

Texture?

As I'm working on my game and working out the bugs, one thing I can't decide on, should I use no_blank_lines or not? I'm leaning against it, but I'm curious what others think. Below are a couple of snapshots, including one from the actual arcade game that I'm basing this game on. What looks better, lines or no lines?

Holy crap, I think I found a simple way for "Mario" to not interact with background objects. I'm not going to say how, for fear of jinxing it, but it works, it'll be one huge obstacle that's out of my way.

I'll probably make the game look nicer by using no_blank_lines if I think I can do without missile0. Anyway, if anybody can help make me a better looking player sprite, I'd appreciate it.

I'll probably have to get rid of most of the background images, except for the clouds. Anyway, I'll really be interested in seeing yours when it's done. Maybe someday when I have more time, I'll learn Atari 2600 asm myself.

Awesome looking Mario. I assume you're doing this using asm. I'm thinking of going ahead and doing this within the limitations of batari Basic, even though, when you're done with your version, I'm sure it will blow mine away.

I was going to try and create an original game...but...well, long story short, I'm starting to make another arcade clone. The original Super Mario Brothers. However, I'm not far into the game, and I'm already running into problems: The player sprite isn't very good looking. The player can interact with the background because it would take a ton of code to rewrite my collision detection routines to differentiate between playfield blocks that I want him to interact with, and those I don't. His vertical jumps need improving. Here's what I have so far Two screens (playfields) No enemies yet When he jumps into a block of playfield pixels, they bounce up and settle back down again. This happens kind of fast, and I need to slow it down. If I finish the game, I'll add in a routine, so that if he eats a mushroom, he can "break" the blocks and make them fall off of the screen. "Mario" can walk left and right, jump up, up/left, and up/right. If a playfield pixel is at "ankle" level, he can't move forward. So background images kind of look like they're hovering, that way "Mario" can walk past them. Anyway, if you think I should work on this to the end, let me know. Or, if you think I should quit and work on something else, let me know too. And, if you have any programming suggestions, they are more than welcome. Thank you. Edit: Finally, I'm able to add the bin and bas files. default.basdefault.bas.bin

The only problem I had was a multi-sprite kernel game I gave up on writing, where the jumps kept going out of range. Anyway, I won't worry about the errors. VbB still works, so that's fine.

I'm making a game using the superchip. I'm using a screen size of 32x32. When I expand the playfield editor size to 32x32 it says in red, on the top of the screen 256 pixels high - 168 pixels too high! I'm guessing it's no big deal, but is it a bug, or something I'm doing wrong? Second, how do you set the background color. After selecting the whole background, when I right click to set it, I get an error Unhandled exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately. Current cell cannot be set to an invisible cell. But after I click continue it brings up the color menu, and then I can choose a color. This is running on Vista.

A memory map with the variables is Here Scroll down and you'll get to the Multisprite Kernel Memory Map. Hope that helps.

OK, that's what I thought. [Home Simpson]D'oh![/Homer] That's right. Thank you.

First off, I just say to tell you jwierer, now that I'm able to use your visual IDE, I think it's great. You've really put a lot of work into it. And Batari, a statement, then two questions. First, I love the improvements on the latest bB release, especial the addition of on gosub Question 1 - Can you jump from a macro to a label outside of the macro? I tried, and got compile errors. I made a macro with an on gosub statement, but when I compiled it, the compiler gave an error that it didn't recognize the labels I told it to jump to, even though they were legit. Question 2 - In the post titled "Topic has attachments10-25-08 bAtari Basic build?" it was stated that you could dim a bit value, but when I tried it, I got a compile error. So, is that feature not available yet, or is this a bug that needs to be worked out? Thank you.

Weird, I posted a reply, or at least I thought I did, but it didn't post. Just as well, I posted about a problem I already solved. Anyway, it seems to be working just fine. I'll play around with it some, and maybe even try to think of program to write.

I found an even better work-around. Virtual Vista (I'm running it virtually because I don't want to actually use it as my OS). bB works fine now. Crimson Editor works fine now. And finally, I'm going to attempt Visual bB. It didn't for me before, but maybe it will on Vista. Wish me luck.

Yeah, I was pretty sure the visual IDE wouldn't work under 98. No problem. And I registered the .sys file, and still no go. It's no big deal. Thanks for the suggestion though.

Have you tried Visual batari Basic: http://www.atariage.com/forums/index.php?showtopic=123849 http://www.randomterrain.com/atari-2600-me...-basic-vbb.html Will it work with Windows 98?

Well, I found a way to work around the problem. I put a virtual Windows 98 machine on my computer. bB on that machine works great. Crimson Editor on the other hand....The CEDT.EXE file is linked to missing export MFC42.DLL-6877 Even downloading the MFC42.DLL file doesn't make a difference. But no biggie, there are other editors I can use, and I finally got bB working again.

If you're talking about This, then yes. But I typed in the preprocessor part by itself preprocess.exe < .\samples\draw.bas | 2600basic.exe -i %bB% > bB.asm bB.asm only contains: Bad Command or file name