Sprybug

Okay, another update, and something for you to have fun with. I think this might also be a good opportunity to explain how I did this too, for people that might want to make something like this. After going through it all again and programming things, I discovered that, yes, I actually do have 54 possible paths to make a level with. With 8 possible sections to put into 4 slots, this gives almost an unlimited amount of combinations. You could probably run this program over and over and over again and never get the same combo of paths and level parts put together to from one complete level. There are some problems, in it though. Not all the open passage ways link up like they are supposed to. Probably an error on my part with the bit calculations, so I just need to go over each path again and see how I inputted the gates incorrectly. When I designed each level section, I originally did it in X's and .'s in Notepad ++, thinking, oh I could do what I did in Princess Rescue and ZIppy the Porcupine and make the levels in a text editor and then write a program to convert the text into level data that the program could use, but then I stumbled across "Graphics Converter" in VbB. It pretty much did the converting that I needed. So I loaded up a very old version of Paint Shop Pro I have that you can still do accurate pixel art with, and designed my sections in perfect square pixels, like it would be in the game (and blown up about 10X so I could accurately place each pixel). The level section was 32 pixels wide and 64 pixels tall. All the walls were done in black pixels, and the background was all white pixels. I saved to BMP and then ran the Graphics Converter program which converted that BMP into data I could actually use in my program. First, you go file open, open your BMP file. You'll see it in the preview. Click the Backcolor if it isn't the proper color, and use the eyedropper to select the proper background color (in my case, white) so it converts it correctly. Make sure you have your width and height, the proper size. Output Settings on batari BASIC. Click the "Create Image" Button and you will see the typical playfield code generated. Then click File, go to Save Code (I believe if I recall correctly), and make sure that you put an extension on the file you save. Make sure it is PLA. Also make sure you save it in the same working directory as your game. This way, when you have your project open in VbB, you'll see it come up in your playfield list. From that point, you can do whatever you want with it. I converted it from that to a data file (8-bit playfield sections), so I could store it all as table data that I can access at any time, at any point, and do what I need to do with it. This worked like a charm and was pixel perfect! So, with this program you can scroll up and down, and hit left and right to go through the different sections of a level. As I said, some of the paths are incorrect and I am going to work on fixing that soon. Robot_Zed_64KSC.bas.bin Robot_Zed_64KSC.bas

Done and done. Thanks for everything you do, RT. Without your documentation, none of my games probably would have been possible. Here's wishing you the best of luck.

Okay, so goofball dorky me overlooked a few things, but it was nothing major that was going to really change anything drastically. I didn't think during that whole process that, oh, yeah each level is going to be 1K of ROM space. 4 rows at 256 bytes. Yeah 1K. Plus I had to remind myself I was working in 3 screen columns and not just screen to screen. So each data table would have to be one of those rows of 3 columns. Meaning those would always be the same and I can't just piece together 3 screens to make one vertical scrolling part using this method. I could if I really wanted to, but that would require Zippy the Porcupine levels of level construction and cross referencing tables. Would rather leave that out on this one if I don't need to do it. That was pretty tough to make it all work properly. Now with that all said. Still a rogue like. Still 4x3 (12 screens total) grid. Still multiple possible themes and still a random element to how the levels are constructed. I've been working more with it, and here's what I have figured out: I recounted the possible level configurations from start to finish and it was actually 51 and not 54, but still that's a lot of different combos! But don't worry that doesn't mean I'm going to have 50K worth of levels to have in ROM. These are just "pathways". Each one of those things you saw on graph paper would be 12 bytes each (each screen representing a number) These numbers would be a reference to the pathways that lead out of that screen. So I would design each row (3 screens high almost) to act as if it is all closed off screen to screen. Then it would look at that number and figure out, oh, I need to have this part of the wall open so you can get to the next part over and would delete those closed off blocks. Designing this way means that these rows can be put in any configuration 1-4 as long as they line up at possible openings, so that is something I need to keep in mind and have already set in my template. So for themes, I have about 10 to choose from. It would pick one and that level would be made with it in mind. So any level can be any theme, and each theme has it's own boss. So level one could start you on the base level, or the laboratory level, or the underground lava level, or the open forest level, etc. I would like to have 8 possible rows to choose from when putting together a level, so that's 2K per theme. 10 possible themes = 20K of ROM space for all possible level rows. That should be good enough. Now back to the 50 possible ways a level could be tunneled. 12 bytes per possibility is about 600 bytes, so I'm not worried about using up a whole lot of space to give you guys a different experience virtually every time. The difficulty will ramp up as the stages increases, so it won't matter what the theme is. The enemies will be harder in further levels regardless. There will be tables for that as well, and that won't take up a whole lot of space either. So I think this is going to work now, and how the levels for Zed are going to be randomly generated for a different experience every time.

Hey Darrel. Yeah, Draconian was top notch. Your stuff always has a very fine polish on it. Maybe one day I can be good at assembly. As I've said, I know the basics of it, but I'm not good enough with it to do anything really useful, yet. With Batari doing all the really hard video timing stuff for me, I'd much rather have it take care of the dirty work, while I strictly focus on the game code and mechanics. Keep working on CDF and if you guys gets that working on Batari, the games that people could make, I'm just imagining. I mean, I was super impressed with the CDF demo at PRGE, and that Bomberman demo. Holy crap. If you showed that to me just on a TV screen and didn't tell me the system it was on, I would have said probably Intellivision, maybe the 5200? I never would have thought it would have been the good ol' 2600. Hope all is well over there, and I'm gonna write up a little update post next.

Okay, I've got it all figured out and here's the update! Robot Zed is going to use 64K SuperChip. This will allow me to keep the current playfield resolution of 22 lines (4x4 even playfield blocks). I needed the 64K, which is why I made the jump. Of course this means that I won't have multiple enemies on the screen at one time, but I'm okay with that because of the changes I made and it won't murder my CPU cycles trying to swap a lot of data between hardware. Also the SuperChip option not only gives me the higher resolution, but also gives me more RAM to play with, which is a sweet, sweet thing. The downgrade is, only one enemy on the screen at the same time, which actually works well with this new iteration. Also the sprites are back to their single color and double row heights (I wanted multi color playfield, background, with keeping at least one missile for the enemy's fire). Now, with that, and Kevin I think you'll like this, I decided to bring back getting different powers from the enemies you defeat. This will make the game mechanics a lot like the original iteration of the game. With this resolution, using a 256 byte data table (It's going to scroll two ways so I have to use the limited 8-bit data table). I can get almost 3 screens tall. Each line is 4 bytes of data. So 22x4=88 bytes per screen. Well 88x3 is a little more than 256, so I can do 20 for the top screen and 22 for the other two. Now, each level is going to have this TIMES 4 screens wide. So 12 screens in total per level. Starting point and ending point are always random, keeping that Rogue Like element. Never the same game twice. In fact, I figured out all my configurations: I got 54. So, does that mean there's only 54 possible levels? NOPE. There are also themes per row! Each level you can divide into 3 rows. There are multiple possible themes that can be applied. Maybe the top row will be the base theme, so they are rooms. Whatever the first row gets assigned will effect what the next two rows will be. So there could be a stage that's all a building, or a building with a basement. Maybe it's a cavern stage, or a cavern stage with a lava bottom, or it's an outside stage with a lake at the bottom, etc. Lots of possibilities for level themes, especially when you divide it up by 3's. And each theme can have differently designed screen levels each as well (take advantage of that 64K space), so the game can be virtually different every time you play. And I would like to have at least 8 different levels, and boss battles as well. Also back is the soundtrack of course. I know CDF is making strides, but I want to get this done, and this seems to be the way to go. In the future, I may be able to do something cool with CDF. So, that's where I'm at right now with Zed, thought I would let you guys in!

Hey guys, back to bring this topic back from the dead. I do have one question. I'm experimenting with all Batari options available to me to be able to do everything I want with my game. Will the 64K kernel work with the SuperChip? Also does Melody emulate the Superchip, so when the game goes into production, we'll be able to use Melody boards for it? My main reason for doing DPC+ was to achieve a higher playfield resolution and multiple enemies on the screen at one time. I know I can achieve the playfield resolution I want with the Superchip. As for multiple enemies, that's something I'd have to look into outside of DPC+. Just exploring all my options here. In order to do everything I want, I NEED 64K, and so far I'm not seeing any progress with DPC+ to achieve it. I've been on hold on my game waiting to see if anyone is even bothering to look into it, and I see no signs of it. So, if anyone could answer my questions that I had in the beginning of this reply, it'd be greatly appreciated! EDIT Okay, after looking at previous posts, even the original, I basically answered my questions. YES, it does support Superchip at 64K and YES, Melody emulates it. For anyone with the same questions, there are your answers. This is good news.

Thanks and thanks guys for making me aware of the VbB's Bookmarks. I'm gonna take a look into that. There are so many times in my large code where I have to hunt when I need to fix or add things. The time I waste doing that let you me tell ya.

Impressive! I'd love to see the code on how you did it. 4 way scroll would be great for games I'd like to make!

I think I see where you are going with this, and it might work well if it scrolled in one direction and didn't go back, but with my games they scroll in both directions, which would mean when the data going the other way would have to be different to compensate, which would probably add to the size of the tables, sacrificing ROM space to gain a few CPU cycles. I know this is a constant game you play with programming on the Atari 2600. Sometimes you need more CPU cycles, and since you got the ROM space, do some pre-calculations so the CPU doesn't have to. And sometimes you need more ROM space, so you let the CPU do a little more work to produce the data you need. I tend to do one or the other depending on what's on my plate. It's a very delicate balancing act, that's for sure!

I'm not sure what you mean by that exactly. The level data is simply like this. Every 2 bytes represent the playfield from the top to the bottom vertically. Since Batari's resolution is 11 rows (12 if you count the invisible one, that I don't use). This leaves 5 extra bits that I use for enemy/object spawn in information. So the first byte is row 0 to row 7. So if one of this bits is on, on the screen (held in the varxx variable), that playfield block will be on, and if that new data shows that one bit in that one row is off, then it'll flip it or vice versa (it's off on the screen and will be flipped to be on). If it's the same then don't do anything. There's no need to. The first 3 bits of the second byte represent rows 8-10 and you repeat the same checks.

I should start using that. The way I've done it over the years is keep a lot of hand written notes handy! XD I still have all my old Princess Rescue and Zippy the Porcupine notes. I wonder if anyone would be curious in seeing them. I can always scan them in. Nothing really special to see, but maybe someone would be curious?

I've learned how the DPC+ stack works, but it's such a CPU cycle eater as I have found out in my game. Zed in its current form, calls to read and write to the stack a couple times at least every game cycle, and man does it really eat CPU cycles. To get the demo done in time for PRGE, I had to slap on a bunch of drawscreen band-aids which really slowed down the game. My redesign would bring scrolling back, which would space out the enemies more. But if we could get more variables without eating a lot of CPU time, you know what I could do with that? So much! I would love it!

Love the BS in the cat number. XD

Hey guys. After talking with Albert on here and at PRGE, along with others, it seems that we can get more space out of DPC+, which is something I will need for my game. I've redesigned it one more time, but now I am set on my redesign, which will actually take advantage of the levels stored in data tables rather than graphic tables, which is currently at a 1 bank limitation. This will allow my levels to be large and I have developed a routine that can scroll this data on, just like my other games. The thing is, in order to get all these nice juicy levels, along with advanced enemy AI (which I want to have to expand the enemy's behaviors), I'm going to need more than 32K (20K of which is only available to me). If I'm going to have these things, along with a soundtrack, and added features such as more power-ups, flying stages, and different boss fights, then I'm going to need to have at least 64K. From what I understand, after PRGE, it would be possible to do more than that (512k if I remember it right). Now my question is, what do we need to do to make this a reality?

My next game is using DPC+. Right now we're trying to get the Batari and Harmony/Melody developers to expand it, so we can use more of the ARM that will allow 64K and up games, something I will need to do everything I want in Robot Zed.

If you want to see how I did horizontal scrolling in Princess Rescue, just go to Random Terrain's Batari site, and he has my source code for it there, along with added documentation. You can find how I did my scrolling in there with the ScrollLeft and ScrollRight routines. I did use pfhscroll, but with some added code. When new data needed to show up, it would look at the new data I had in the level data table, using a pointer, to pick up the 2 new bytes, and then it would compare bit by bit with what the var screen variables had on the edge of the screen. If it didn't match up, it would flip the bit, saving time so it didn't redraw every bit on the edge of the screen.

You know what I would love seen implemented in this? The ability to play 2+ player games online over the internet against someone. How cool would it be to play a game of 4 player Warlords with 3 other people across the globe?

A friend of mine, PugNippets, did this for a game he had where you can mod things called "else heart.break()" He added this: Thought I would share

I know this game's been long in development. Finding time at times has been hard, plus I started over when I wanted the game to have a whole better look than what I originally came up with. It's now using DPC+, with a higher playfield resolution and more enemies on the screen at one time. It's also going to be more of a Rogue like like Binding of Isaac / Rogue Legacy. You will still get power ups but now you purchase them with energy modules before every level, so you can customize your robot before going into a level. You'll also be able to randomize a level again, if you have to start over and didn't like the configuration you had, otherwise it's locked down every time you go into it. Because it's DPC+, I have less space to code, which means I had to do away with some stuff, plus if It looks like I can only fit one song in this thing, unless somehow we can get DPC+ to do 64K! If so, not only will I be able to incorporate more music, but I can do more with boss battles, and have more screens to pick from to generate a level with.

No problem, in fact I FINALLY FIGURED IT OUT. It's interesting how when you go and take your laptop somewhere else and work on something, it changes your focus. I discovered that the stack was being written too correctly, but it was changing to wrong values somewhere in the gameplay. So I took my test routine to show the stack values in my score and put it in a place to see if the values were right or wrong. Every time it was correct, I'd move it further down in the code until it finally showed incorrect values. Once it did that I looked at the code in the area and discovered that an old line of cold still existed that was messing it up. The ObjectR and ObjectW routines were new. However when it came back from ObjectW (Writing) in the enemy 0 routine, it did ANOTHER push k e m s (which was an old line before I did the routines) causing it to do another stack write further down, messing up Enemy 1's values. Once I took that out it behaved properly. Now I have one more issue to try and figure out and it just might be another forum post. For some reason, missile 1 is only 1 pixel wide, where missile 0 is 8 pixels wide like it should be. Haven't figure out why it's doing that yet.

To verify, yes it does ran backwards from the spot, so 0DA5,0DA4,0DA3,etc. I can see the pattern and see just how wrong the values are in there. Looking at my code, I can not for the life of me figure out why it's doing it though. I made a test routine, that once it loads all the sprite information that I want to those stack locations, I can use the score to show me what the first value is of that stack read, and it's just...wrong. I'm using it like I'm supposed to. For example I have a data table full of the enemy information. When loading up the level it reads the table and assigns the values to variables for each one of the enemies/sprites. After it loads the info, it then runs an ON K GOSUB routine to the proper initialization routine for each enemy. It goes to the right one because I can see them set up properly on screen, so I know it's reading the data table correctly. In those routines, I also set up a bit. Enemy 0 will have b{0} set as 1 so it knows that player1 is in use and should run its routines. Same goes for enemy 1 that uses b{1} and all the way up to {7}. That's all correct, but once I go and write the values, including K to the stack, things mess up and I have no idea why. I run my test after it loads and I use the score to check each K value that it reads from the stack and they are just wrong. I'm doing exactly what you are supposed to be doing too. For the writes, you set the stack up at its highest point for example on enemy 0, it's Stack 255 then next line is push k e m s When I read, I use Stack 251 next line pull k e m s But something is going wrong. I'll put in some of my code in this initialization process: ReadO2 if !x then var4=OSLG[c] if x=1 then var4=OSLB[c] if x=2 then var4=OSLR[c] c=c+1 if !x then var5=OSLG[c] if x=1 then var5=OSLB[c] if x=2 then var5=OSLR[c] c=c+1 if !x then k=OSLG[c] if x=1 then k=OSLB[c] if x=2 then k=OSLR[c] e=3 c=c+1 m=0:s=0 on k gosub Init0 Init1 Init2 Init3 Init4 Init5 Init6 Init7 Init7 if c<z-3 then goto ReadO2 gosub test bank5 var4=SwitchData[y] y=y+1 var5=SwitchData[y] y=y+1 var6=SwitchData[y] if var6 then NUSIZ9{3}=1 player9x=(var4*4)+8 player9y=var5*8 gosub Switch_Color bank6 gosub Switch_Off bank6 a=0:c=0 drawscreen return otherbank Init0 player1x=(var4*4)+8 player1y=var5*8 b{0}=1 gosub Enemy0Color bank6:gosub Standard1 bank6 stack 255 push k e m s return thisbank Init1 player2x=(var4*4)+8 player2y=var5*8 b{1}=1 gosub Enemy1Color bank6:gosub Tosser1 bank6 stack 250 push k e m s return thisbank Init2 player3x=(var4*4)+8 player3y=var5*8 b{2}=1 gosub Enemy2Color bank6:gosub Archer1 bank6 stack 245 push k e m s return thisbank And of course it goes all the way down to Init7, but it would be redundant for me to put it all in. BTW, when it is gosubing to bank6 there, those are only sprite color and sprite graphic tables its loading. Nothing else. As for the reads when running the enemy routine. Let's take Enemy Player2 for example: ObjectP2 x=1:gosub ObjectR bank6 NUSIZ2{3}=0 if player0y>player2y && (player0x-32)<player2x && (player0x+32)>player2x && !m{1} then m{1}=1:s=0 if player0x<player2x then NUSIZ2{3}=1 if a<8 && s<8 then gosub Tosser1 bank6 else gosub Tosser2 bank6 if !m{1} then OP2R s=s+1 z=0 if player0x>player2x then m{0}=0 else NUSIZ2{3}=1:z{2}=1:m{0}=1 if s=8 then x=player2x:y=player2y:gosub InitEnemyFire bank4 if s=48 then m{1}=0:s=0 OP2R x=1:gosub ObjectW bank6 return thisbank EB2 temp2=(y+1)/8 if m{0} then temp1=(x-15)/4 else temp1=(x-11)/4 if !pfread(temp1,temp2) then gosub ECD goto OP2R The routines ObjectR and ObjectW are Stack Read routines and Stack Write routines....for example: ObjectR on x goto ObjectR1 ObjectR2 ObjectR3 ObjectR4 ObjectR5 ObjectR6 ObjectR7 ObjectR8 ObjectR8 ObjectR1 stack 251 pull k e m s return otherbank rem goto pullobject ObjectR2 stack 246 pull k e m s return otherbank rem goto pullobject ObjectW on x goto ObjectW1 ObjectW2 ObjectW3 ObjectW4 ObjectW5 ObjectW6 ObjectW7 ObjectW8 ObjectW8 ObjectW1 stack 255 push k e m s return otherbank rem goto pushobject ObjectW2 stack 250 push k e m s return otherbank rem goto pushobject I have no idea what is going on. Funny thing is, that as you see, in the firing routine in the Player2 enemy routine, it uses S as a counter. That magically somehow stay correct because it DOES count up and fire like it's supposed to, meaning that it is storing and reading the S variable correctly, but not the K one. I have no flippin' clue what is going on. I've been spending days on this and have gotten absolutely NOWHERE. It's kinda driving me bonkers. I know K is not correct because looking in the stack tells me, but when I run the firing initalizing routing of the enemy to fire the missile it depends on reading that K variable from the stack to determine the kind of shot that the enemy is doing, and it ALWAYS picks the wrong one. The Tosser is supposed to shoot an arcing shot, and it never does. Not just that, but any time it uses missile1, the length of the missile is just one pixel instead of 8 pixels long and I'm not doing ANYTHING with those NUSIZ variable other than the 3rd bit that flips a sprite. It's strange, It used to work before I made a big change to my game, but I can't see what went wrong, at all. If anybody wants to look at my Batari BASIC code, and it's pretty big, let me know.

Got it. I figured it went something like that, but I just needed some clarification. This definitely helps me out trying to troubleshoot. Yeah, the DPC+ in Batari is a bit tricky because of the reverse order when you pull things, which is why I want to look at how it's doing something to see if it's something I am doing wrong, although the funny thing is, I actually had it working at one point until I changed how it initialized fired missiles from the enemies. It uses Stack Space to store some information about the missile, like momentum, direction, etc. And it did work until I made that change. Funny thing, is it seems to work fine on enemy 0 that uses Player1 and Stack 255, but for some reason Player 2 and Stack 250 isn't returning the 1 value of the enemy type like it's supposed to, yet Player1 enemy type is, so it's something for me to work out. That change I made messed it up, but reviewing it over and over and over again, I can't seem to figure out what I did to mess it up. It's so bizarre to me. I've looked through everything several times. Hopefully, this will help me try to troubleshoot it.

Thanks for the quick response, Darrell. I got DDA5. Not sure how that works.

Hey Guys, I'm trying to get my new Zed demo done in time for PRGE, but am running into a weird problem that I can't track down. One of the enemies values is doing weird things. I do a lot of push and pulling of the DPC+ stack because there are so many enemies on the screen at one time. I've been through the code several times and can not for the life of me figure out what's going on. Was using Stella to see if I could use the debugger to look at the DPC+ stack, where I push and pull a lot of these values to see if I could see what's going on, but I have no idea where the DPC+ stack is in the debugger, or even if it is available for me to look at in debug mode. Any help would be greatly appreciated!

Very nice! It reminds of MegaMania with powerups!