Sprybug

Actually, native Washingtonian and resident of Oregon for the last 11 years. I lived in Vancouver, BC for a year when I went to VanArts. Got my passport submitted and expedited, now just waiting for it to come in, and once that comes in send the ID to the studio so they can send me another ID to use with a Canadian government site to login with to get my work permit processed.

Thanks guys. Just giving an update! I figured out how to do Nibbles! So, this is going to allow me to add some better play control by adding momentum moving left and right, so the controls aren't so touchy! I need to start implementing nibbles because I am out of RAM, so I am going to split up what I can. I have several variables that never go over 16, so I'm wasting valuable bits! Not sure how much I'm going to be able to work on it the next month and a half because I got a big announcement. I got a great new animation job at a studio in QUEBEC, CANADA. I AM MOVING. So I've been very busy working on my move, learning French, and working with them remotely in the meantime. I plan on moving there next month. I am so excited....and nervous!

Yeah, this one isn't an exact clone of any game actually. It take elements from other games like Kirby and Mega Man for sure, but add a rogue like element to it all and you get Robot Zed.

Talking this out with you reminded me of something. After the demo, I was going to go back and start changing a few variables that only use values 0-16 and splitting them in two, making them essentially 2 nybbles. The reason why I mention this, is because I have already used all my ram. I have one variable that is for gravity momentum when you fall or jump. It never exceeds 6. Make that a nybble, and then I can use the other half as another momentum nibble for starting a walk/run. When the screen scrolls 4 pixels at a time, there's nothing you can do about it. You're locked at 4 pixel movement. HOWEVER, if you're still and you're just starting to move, the screen will not scroll, so you can build up a little bit before you take off again. Looking back, this is how Princess Rescue worked, and it worked pretty darn well then, I just have to go back and make quite a bit of adjustments to the code to make this happen. This should help give it more of a Princess Rescue movement vibe. Not exactly, but close.

Good suggestion, and like with Zippy, I'm doing 2 screen draws for every game cycle, already putting me at 30 FPS. I split the two so I can fit in more CPU cycles to do more things. Princess Rescue used 3 for 20 FPS, but since then I was able to refine some things. The only downfall with your suggestion though, would be a noticable speed down and speed up every time you moved, which would also mess with the speed of the soundtrack. I've been thinking about using a bit to make your increments 2 pixels instead of 4 when you start moving as a momentum buildup, and then when you move twice under that you go back to a full 4, keeping your increments even. It shouldn't throw off my platform checks and it won't do a screen scroll, which by in of itself eats a lot of cycle time.

Haha Haha! I was playing it yesterday and trying to break stuff and the same thing happened to me, but it just advanced me to the next part of the level. You were probably just one level away from getting to the boss already at that point. This is one of the bugs I'll need to fix.

Yes, the movement speed is difficult to try and tack down, because I changed the method from Princess Rescue, to be more efficient on how it checks screen memory for platforms to save on CPU cycles, but it also assumes that you move 4 pixels at a time, which is the length of each playfield block. Since the playfield scrolls at 4 pixels per scroll (and there is no way around it), I thought it'd make sense to match that rate, but it also makes the movements pretty touchy. I added a stop when you land from a certain height or change direction to try and help out, but it only lasts a frame or two. Maybe I need to make it last longer.

It's the robot you rescued. Each one has a certain ability that will allow you to get through a different upcoming level and also use the power in the level. Like Sky Way you have to fly, Sea Way you need to have the water suit ability to be able to "float", etc, and etc. I'm going to create a sort of Overworld level, where you can enter the other levels in a side scroller platformer like any other level, but you can only access these levels if you have that robot's power, so it's up to you to discover which power will allow you entry. It's random, adding to the rogue like element, on which one you rescue, so it's going to be different every time you play it.

UNO CART? Okay, never heard of this one, now I gotta do some research, because I'll need something like that to test the game on the real deal as I progress. My Harmony cart of course, won't play it. I just saw a video on how to make your own. Okay, gonna go watch this video now. TTYL!

Really?! Wow! When I edited the code to go back to regular controller for this, I didn't realize I left in full Genesis controller functionality. That's great to know. I'll be sure to go back and add full support then in my next update, which will also include an experiment I am doing to make a sort of 2.5D background with dark color bars to make it feel like you're in a room and the perspective will shift on the bars depending on how high or low you are on the screen.

Yep! It's already in the code. I just have to add the part of the code that will auto detect it and set it, which doesn't take much to do. I did it when it was demo'd at PRGE in 2018. You could play it with a Genesis controller, in fact it's preferred. I rem'd it out for this demo because you're playing in Stella and unless you know how, it won't auto default to it and you have to set it up. Playing with a keyboard too makes up for fire not much of a hassle. It will have Genesis Controller support for sure in a later demo release, and of course in the full version. Just like Princess Rescue!

Yes! It's finally here. The playable Demo of Robot Zed. Years in the making! I spent all day trying to figure out this game breaking bug that's been plaguing me for months and finally figured it out. Now I can finally release this thing. You're a cute little robot that can obtain the powers of certain enemy robots once you defeat them. You can use those powers in your quest to rescue all of your Robo Buddies! This is just the opening level that everyone plays before you get access to any of the other levels. This game is also a rogue like with inspiration from Mega Man and Kirby. Here are the control instructions: Left / Right - Moves in that direction Up - Fires current weapon power Fire Button - Jumps Fire Button AND Down - Cycle through your powers to select (if you've obtained any). You only have one life and an energy status. Every hit by enemy fire, an explosion, or even running into an enemy will knock it down. To the right is the your power ability number. Every time you use one of your selected abilities, it will drain this. Once you are down to zero, you will return to normal power Zed. You can obtain life energy from the regular bots that don't give you any special powers. You can obtain special powers from the robots with special abilities. You receive their ability plus 10 power ability points. If you already have their ability, you will receive 5 power ability points instead. When you lose all your life energy, it's game over. When you destroy an enemy, it will release their power module and will follow you until you collect it. The regular bot won't always give you life energy. So, have fun, tell me what you think, and if you run into any crazy bugs. I will also be updating this demo with additional window dressing so to speak, to make it look even better. Once I make any additions, I will upload the new version. Note: Quick edit. Minutes after uploading I realized I forgot to remove a recent bug checker I added to the code. I removed it and have uploaded the correct version. RobotZed_07.bas.bin

I finally put a video up on youtube of the Robot Zed demo, complete with boss fight. I will post the downloadable demo here very, VERY soon. There are just a few little bugs I want to fix, one of which breaks the game. Enjoy!

Just thought I would share this. Getting really close to getting a demo finished! Zed_Boss_Fight_Music.bas.bin

Now that you've made your level in a text editor and ran the TXT2LEV program to covert it to a DAT file, we're ready for step 2. First, open up the attached file at the bottom in Batari BASIC. This is a program you can use to test out your level with and scroll through Second, open that DAT file you created, with your favorite text editor. I just use regular notepad for this. Third, Copy all of the contents (Select All, then Copy). Fourth, go to the bottom of the program in Visual bB where the Level1 Data Table is and replace the data table there (from Princess Rescue Level 1A), with the data from the DAT file you copied. Fifth, Be sure you indent each line in the table with a space, or else it will error on compile! Sixth, Save, Compile, and Run! Use left and right to scroll through your level. If you don't replace the data, you can still run the program with the data that is in there. It's level 1A from Princess Rescue. Alright, so what's going on here? Let's examine. I won't go into kernel stuff as you probably already know about that. I want to first mention that there is a known bug in bB, where, unless you use COLUPF in the game loop, you must use your pfcolor data table in the game loop, or the first line will not be the correct color. That is why the pfcolor tables are in loops. If you're not using pfcolors, then you don't need to worry about it. rem scroll level in Level_Pointer=0 PopulateScreen rem make pfcolors black so we don't see the start of the level scroll in pfcolors: $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 end gosub scrollleft drawscreen if Level_Pointer<32 then PopulateScreen Here we black out the screen so we don't see the contents of the level get scrolled on at the beginning. We use the scrollleft routine to get the start of the level on there, instead of writing a whole new routine to do it in one blow. Save ROM space by doing so. Once that pointer hits beyond 31 (the last column on the right of the screen), then it advances to the main loop so we can scroll through the level with our joystick. GameLoop rem Now colorize and show pfcolors: $84 $86 $86 $88 $88 $8A $8A $8C $8C $8E $8E end if joy0right && Level_Pointer<128 then gosub scrollleft if joy0left && Level_Pointer>32 then gosub scrollright drawscreen goto GameLoop Alright, so now we colorize all the rows so you can see it, and you can set these to whatever colors you want. You don't have to keep them the way I did. This part polls the joystick for left or right movement. Left will scroll the level left and right will scroll the level right. The additional conditional check of the Level_Pointer variable is there so you don't scroll BEYOND the data table. scrollleft pfscroll left x=Level_Pointer*2 y=Level1[x] x=x+1 z=Level1[x] if y{0} then var3 = var3 | 128 else var3 = var3 & 127 if y{1} then var7 = var7 | 128 else var7 = var7 & 127 if y{2} then var11 = var11 | 128 else var11 = var11 & 127 if y{3} then var15 = var15 | 128 else var15 = var15 & 127 if y{4} then var19 = var19 | 128 else var19 = var19 & 127 if y{5} then var23 = var23 | 128 else var23 = var23 & 127 if y{6} then var27 = var27 | 128 else var27 = var27 & 127 if y{7} then var31 = var31 | 128 else var31 = var31 & 127 if z{0} then var35 = var35 | 128 else var35 = var35 & 127 if z{1} then var39 = var39 | 128 else var39 = var39 & 127 if z{2} then var43 = var43 | 128 else var43 = var43 & 127 Level_Pointer=Level_Pointer+1 return scrollright pfscroll right x=(Level_Pointer-32)*2 y=Level1[x] x=x+1 z=Level1[x] if y{0} then var0 = var0 | 128 else var0 = var0 & 127 if y{1} then var4 = var4 | 128 else var4 = var4 & 127 if y{2} then var8 = var8 | 128 else var8 = var8 & 127 if y{3} then var12 = var12 | 128 else var12 = var12 & 127 if y{4} then var16 = var16 | 128 else var16 = var16 & 127 if y{5} then var20 = var20 | 128 else var20 = var20 & 127 if y{6} then var24=var24 | 128 else var24=var24 & 127 if y{7} then var28 = var28 | 128 else var28 = var28 & 127 if z{0} then var32 = var32 | 128 else var32 = var32 & 127 if z{1} then var36 = var36 | 128 else var36 = var36 & 127 if z{2} then var40 = var40 | 128 else var40 = var40 & 127 Level_Pointer=Level_Pointer-1 return Now this is the heart of the beast. These are the two routines that will scroll the level left or right. Let's break it down. In batari BASIC, the standard kernel uses 48 bytes of RAM as screen memory. It is labeled from Var0 - Var47 (Var44-Var47 are in a non-visible 12th row). Each variable of course is 4 bytes across (32 bits). So, for example, the first screen playfield row is going to consist of var0, var1, var2, and var3. The 2nd will consist of var4, var5, var6, var7, and so on. Now that we know this, we can check for the edges of the screen using these variables, instead of the time consuming batari BASIC commands and functions that will do this for us. This helps save on cpu cycle time! Whenever you use the command pfscroll (left or right), you'll notice that it scrolls the screen like it's suppose to, but it ends up wrapping the old data on the other side, giving you an endless loop. But we don't want that, so we need to replace the edges ourselves, manually. After the screen scrolls, what the rest of this routine does is, read the 2 bytes from the data table and then checks bit by bit of those 2 variables to see if the new screen data is going to have the playfield bit on or off. It then sets the bit in the screen memory appropriately with the var screen variables on the edges. After each row is checked and altered, we advance (or subtract) the level pointer counter and return to the main game loop. Pretty simple, huh? It actually is! Now, you'll notice that we didn't do anything about those spawn in objects that we put in our level on line 12 of our text file. We'll tackle that later, so don't worry about it at the moment. Right now we're just scrolling through our first made level and making sure it looks good! Screen_Scroll_Lesson2.bas

Hey Guys! Random Terrain asked me to make a tutorial series on how to make a game scroll like Princess Rescue. Let me begin by saying it's not as hard as you think. I've heard that some people have had a hard time doing it while still having cpu time to play with. Yes, horizontal screen scrolling can eat up those precious cpu clocks, but if you are making a simple game, you may still be able to do it all within one screen draw. Princess Rescue on the other hand, required 3 screen draws per full game cycle, where as Zippy took only 2 (I refined the method a little). I will be using the Princess Rescue method for the example for simplification reasons, so you can learn and you can take what you learn and build upon it if you'd like. So let's start with this before we even start programming. Let's make a level first! Before we can make a level, we need to know how it's constructed. At the standard kernel, standard resolution, you have a 32x11 playfield block screen. That is 32 across and 11 down. Let's say going across the screen is a row and going from top to bottom is a column. Each column will take 2 bytes of data because it's going to require 11 bits for the 11 playfield blocks you can have in a column. Since we're going to have the ability to scroll in either direction, we will need to use the regular Data statement for the data table. With this, you can use a variable pointer to read data at any point in the level. However, this will limit how much data you can have in one table to 256 bytes, meaning that our level can only be 128 playfield blocks wide, or 4 screens wide. To kind of get around this limitation, I added the feature of going down a pipe at the end of the first half of a level, which sends you to the 2nd half of the level, contained in its own 256 byte table, making each level 512 bytes in total. With this in mind, we are going to design our level in 128 characters across, and you can do this in a TEXT EDITOR! This is how I designed all of my Princess Rescue levels. I used good old fashioned EDIT.COM, however you can use any text editor that saves out a plain Jane text file. Keep in mind that the dimensions of whatever text editor you use, won't look like what will be in your game and will look really stretched out. An X represents a playfield block and a . (period) represents no block. Your text file will be 128x12 characters. What's with the 12th row you ask? The bottom 12th row is your spawn in data. Remember, each column is 11 bits for playfield blocks, meaning we have 5 bits leftover for other things, like information on what item will be scrolled in, using the player 2 sprite. That 12th row will contain rather a . (period) for nothing will spawn there when scrolled in, or a value from 0-F that your program will take and do what it needs with it. Included in this post is a ZIP file that contains the program I wrote in QB64 called TXT2LEV that will take your text file data and convert it into a DAT file that you can open in, let's say Notepad, and then copy and paste the data into a data table in your code. It's a simple program. When you run it, it will ask for the filename of the file you want to convert. Just put the filename MINUS the txt extensions, so for example, level1.txt, you would just type in level1. It will immediately convert and then ask if you want to do another. Since we're doing just 1 level, press N. Be sure all these files are in the same folder! When you unzip this file, just make a new directory somewhere on your hard drive, and put everything there, including your levels that you create. Also included is the 2nd half of the first level of Princess Rescue, so you can see how I did it. You'll notice for the spawn data, I used a long series of the same number/letter. This is because you can only scroll on one thing at a time, and if something else was on the screen it wouldn't scroll it on. So, to remedy this I made the spawn points consecutive to almost insure that one will eventually scroll on. Your Batari BASIC program will determine how high or low it will show up in the column, so you don't need to worry about that right now. Have fun making your level. The next lesson we'll talk about taking your data file that you created, put it in your program, and then writing up some code to interact with it. TXT2LEV.zip Click below for the next lesson! http://atariage.com/forums/topic/288001-horizontal-level-scrolling-in-batari-basic-tutorial-lesson-2/

Ooooh. I can so use this in Zed. does it eat cycle time?

Oh, oh, oh! THANK YOU! I haven't checked back in a while and I saw this. I was hoping someone would do this! I've been using TiaTracker, but without any real way of importing the data into my Batari BASIC program, I shied away from it (also, one of the note values is incorrect and I have to fix it every time manually). This will be fun to play around with. I've been looking for an easier way to implement music into my games. The traditional way with VBB's sound/music keyboard thing was really the only option, but was painfully slow and I had to manually keep track of what every little chunk meant, which made it hard to know what I was looking at exactly.

Hey guys, new update, and new version. As you know I've played around with different ideas, and have made changes when I discovered that I can't do exactly what it was that I wanted to do because of one reason or limitation or another, but I feel that I have finally made the engine that's going to be the final make for this game. Robot Zed will still be a Rogue Like and you will still get different upgrades and powers from the enemies you defeat. Last night I got the engine working with Zed and you can run around all the randomly pieced together levels for a new experience every run until you get far enough to get into the boss room. Now there is no boss yet, and you can't do much once you get there, besides reset or turn off the game, but this will give you an idea of the levels you will have to run through to get to the boss. It will be good practice for when the demo comes out. Have fun! RobotZed_05.bas.bin

Thanks guys for the heads up. I might just keep it the way it is for now then. It should work logically, but making it a not bit check (or just a check for 0) for some reason causes it to not know what to do. It would come back with a Syntax Error on that line and would show me the entire compiled code without indication there what went wrong. That's about all I can really tell you.

Hey guys, as you know I'm working on Robot Zed and decided to use DIMs and DEFs to help keep my code readable and keep my sanity, however I came across something weird. I dim'd all my variables with names, and for bits, I used DEF like you are supposed to. For example I have: dim Extra_Bits = g Then I have underneath all my dims: def Enemy_Direction = Extra_Bits{0} def Ball_Direction = Extra_Bits{1} def Missile_Direction = Extra_Bits{2} def Section_Exit = Extra_Bits{3} def Section_Order = Extra_Bits{4} def Genesis_Controller = Extra_Bits{7} Now this is fine, however in a conditional check on one of these it would error on compile. The line before it is fine: if Section_Order && Level_Section=6 then Level_Section=0:goto LS2 But the line after it gives me a compile error without a reason if !Section_Order && !Level_Section then Level_Section=6:goto LS2 I tried changing it to: if Section_Order=0 && Level_Section=0 and it still error'd on compile. So, I tried changing Section_Order in this line to Extra_Bits{4} and it compiled no problem, so now that line is: if !Extra_Bits{4} && !Level_Section then Level_Section=6:goto LS2 That's fine apparently. So, is there a bug here in the compiler? I can't see any reason why this would happen.

I did some work this weekend.

I know most people like to dabble with making games for the Atari and a lot of times it tends to not go anywhere. Most of the time I work on one though, I intend on finishing it and releasing it. There are only a few other games I've worked on that were never completed (not including my current effort). One was a test and another never got off the ground. I realize my mistake in not contacting you in the first place to ask if I could use them as reference material. I remember when I first started on this, I started scouring the web for anything I could possibly use for an 8 pixel width and not too tall sprite reference and nothing was coming up, until I came across your sprites which were the closest thing I found that I could use as a reference point because they looked close enough to the Sonic brand in that format. I wanted to make Sonic for the Atari as my next project and you gave me something to work with to help make it happen, and I really appreciate all the work you put into making those. I'm not sure if my end result would have been as good if I never saw them, but it did give me a good idea visually on how to make it look good. I do feel like I do need to make it up to you though somehow for not asking in the first place if I could use them for reference. I was talking to my friend today about this, who is a professional artist and she pointed out the mistakes I made and said that I should had at least contacted you about using them for reference. She's right. Although I don't plan on using existing properties for future Atari game ideas, if I ever do something similar again, I'll be sure not to make the same mistake again. Right now as most of you know, I'm working on Robot Zed, and I'm still kinda dabbling with the designs of the enemies. Some are set, but some aren't. They're all robots of various forms (like Mega Man enemies are). If you'd like to make up a few, to help make up for Zippy, I could put them in. Maybe even a few ideas for robot master bosses. Still have to work on those. I'll give you credit in the manual as well for the additional designs, or maybe if you can think of anything else that I could do, just let me know and we'll see what can happen.

Hey guys, Albert let me know about this discussion. I forgot who it was, but someone else let me know about the controversy at PRGE and I went to see if I could find where it was being discussed originally, but wasn't able to find it, but thanks to Albert he clued me in. So anyhow let me set some things straight. When I first started on this project, I was aware of Tokumaru's sprite work and I liked the look of it and planned to use them as reference. However I noticed that there was some pixel liberties that were done that wasn't going to quite work out in the typical Atari sprite hardware's limitations. So I used his sprites as a reference and a model. Yes, the hair did stay the same, however I made changes everywhere else so they would work both vertically and horizontally within the sprite hardware specs, which means I had to change em up. As I was making them, I took some artistic liberties with it, for example I wanted his nose to show, and I wanted the left eye to be fuller, and the body and limbs to be a bit more like a rubber hose character, that you see him as in all the official art work. As you can tell, I didn't have to change much at all when it came to him being hit by something. And as you can also see, I changed up all the other sprites as well for the same reasons I stated before, and because I felt certain things looked better IMO. However, with this all being said, yes, Tokumaru, I did use your sprite set as a reference and model but not verbatim. It gave me a good place to start when making these sprites. I always use references when doing art, in fact it's always a good idea to use references. When I did Princess Rescue, I studied sprite sheets of various SMB games and figured out what I needed to do to make them work on the Atari, which meant I had to do quite a bit of altering and some artistic liberties to make it work. So hopefully this cleared some things up and I want to thank Tokumaru for doing those sprites that gave me a good place to start from. Looking back, I probably should had let you know that I was going to use them for reference and should have given you a special thanks credit in the manual. By the time I did the manual (which I always do last), I couldn't remember who's sprites I used as reference, so I apologize for that.