potatohead

Very cool! I'm actually interested in supercats scheme the most. I know we don't have hardware just yet, but when we do I think it's gonna be great. From a programming standpoint, it's got a lot to offer with the biggie being ordinary RAM writes. I'm thinking this will enable a fairly sane Bb / cart combination. Since I'm new, and only using some assembly at the moment, I'm going to defer to others here as to which scheme is better, popular, etc... Kind of looking forward to my next game after Ooze. Thanks a bunch for heading this direction.

I would like to see an 8bitter with an added chip or feature set to allow for homebrew / new games. Whatever they do, it should have a cart port and said port should be open. The homebrew scene is really good right now, but it really depends on old hardware. The FB2 brought a nice refresh, if a bit buggy, to the classic crowd and the price was good! $30 is a steal! IMHO, this is all about the classic feel. The 2600 embodies that, but is a bit limited. My FB2 has seen a lot of play from the kids and a few interested adults. Well worth the dollars. If the price were, say $50, but carts could be added and it brought a few extensions to the table, Atari may well find that they have opened a door long thought closed. I think the whole thing depends on expectations set. The FB works because the old Atari is remembered and it has a feel that is unique. The games have a real time element because of how the games had to be written. Rather than escalate this by moving up the chain to full computer capability, (400 / 800 style) I would add a coupla features to the 2600 way of doing things that enable better games that preserve the overall feel. IMHO, the 2600 defines classic. Go newer and the expectations quickly rise. Unless they are properly set, people won't get the same enjoyment out of the whole thing. Make the machine too good, and it then gets seen as modern and limited. Kind of like a game boy or NES that connects to the television. Maybe that's the way to go. I'm not sure, but it would not be the same and it gets a lot more expensive to produce. I would love such a system though as there are a ton of 8bit computer games that are very fun. How to incorporate them is the problem. Cart only keeps a lot of games off the table. Save states & other such things become a part of the equation, which detract from the simple, turn it on, choose your game and have fun factor. If it were me, I would keep the focus on 2600 style games. These games are simple, yet fun and can be rewarding. I would add a feature or two to allow better productions to happen and contract out a coupla of the better developers here to showcase the new stuff.

Why not just define all the sprite pieces and use an on-goto to sort 'em out at run time? Either way, the data sits in ROM, it's just how you address it. eg: player0: %00100010 %01110111 %01111111 end on bottomhalf goto 10 20 30 10 player1: %00100010 %01110111 %01111111 end goto skiphalf 20 player1: %00100010 %01110111 %01111111 end goto skiphalf 30 player1: %00100010 %01110111 %01111111 end skiphalf (rest of game)

Because they can't be pushed in quite the same way. They are flexible, but not in the same fashion. Expectations are higher too. The computers are capable of some pretty nice visuals. Maybe I'm going out on a limb, but the limits of the 8bitters is known. We have not yet seen all the 2600 can do. I'm not saying it's more powerful, but it is way more flexible than any other classic system. That flexibility really is the attractor for me anyway. Seeing the innovations year after year is just great. Look at the Boulderdash game posted here a while back. Holy cow! That's one powerful piece of programming. The end result would be trivial on the computers and that's what makes it so great to see on the 2600. There just is no environment like it.

There are a ton of working 2600 machines. Not so many 800's. Personally I would like to see the 7800 get more attention than it does, but there is the same problem --lack of machines. Re: Gameplay. Can totally relate to this. The simple nature of the 2600 makes for interesting games --there is a feel to a well done 2600 game that's just cool. Having to sync everything is a big part of that.

BLinkenlight? Yes. Somebody will use the darn light for something, just as they do everything else. Cost -vs- functionality? How much would a finished cart be? Having read / writes work as they should is a big deal, if that is traded for cost, it's a mistake IMHO.

Can't you get this by just holding down reset while turning the machine on? Of course, that brings me to another question: Can this behavior be replicated in the emulators?

Very interesting. I love the hardware aspect of the 2600. Any chance at allowing program execution from RAM (read / write)? I'm thinking of self-modifying code. I know it's supposed to be a no-no, but it had it's merits on the 8bitters. With all the room this scheme allows, self-modifying code would not be important for game logic stuff, but may well permit exotic kernels.

Sorry to ask, but can I get the source so that I can compile for Linux? If it's messy or whatever, let me know and I'll run it in the win32 environment. Nevermind... just understood what I was looking at! Yeah, the "source" is actually just a lex grammar file... Not long... I got a cup of coffee and started writing, and I was done before the coffee was cold (Though the last swig was a little tepid.) Probably less time and more accurate than doing Ooze by hand. 926662[/snapback] Well, that's exactly why I am not a programmer by trade. Takes too damn long! I bow before your Kung-Fu! Feeling Ok this morning. I'll play a little and post what happens.

Ok, I'll take the hint! --Thanks. I'll give this a whack soon. Kind of dismayed about the reduced avaliable space though. I believe the game was floating around ~200 bytes free. Oh well, the functions, improved bit ops and proper gosub should free most of that back. Need to finish current work project first though. (money first, games second!) 926631[/snapback] The compiler compiled on Linux, so that's a good sign. Haven't tried the code converter yet, but will soon. The little scripts I wrote to compile things didn't bring me much joy using the included sample.bas file. Which shipped with some bad lines in it... were those for testing? The new sample should compile as-is, the problem is there are more compile steps. EDIT: I said "binary" when I meant "source" In the source distribution, there is a shell script included that should do what you need, 2600basic.sh I think. 926657[/snapback] That did the trick. Ran the code converter. It made a coupla mistakes, but nothing major. Got some lines that looked like this p(s{3} = xx. Only two of them, easily fixed. So it compiles, but is -89 bytes down from ~+154. Not too bad. I think the improved bit operators will help out quite a bit in this area as well as if-then-else will too. I missed those two the most, with a working gosub being a close third. The rest of 0.2 worked nicely for me, IMHO. First things first though. I'll read the help and see what my options are and go from there.

Sorry to ask, but can I get the source so that I can compile for Linux? If it's messy or whatever, let me know and I'll run it in the win32 environment. Nevermind... just understood what I was looking at! Looks like it worked for me first time. I'll get the compile loop done in the morning and go from there! Thanks a bunch for this! I'm not sure how long you spent writing it, but I know I would have spent many hours converting the code manually. Well done and much appreciated.

Ok, I'll take the hint! --Thanks. I'll give this a whack soon. Kind of dismayed about the reduced avaliable space though. I believe the game was floating around ~200 bytes free. Oh well, the functions, improved bit ops and proper gosub should free most of that back. Need to finish current work project first though. (money first, games second!) 926631[/snapback] The compiler compiled on Linux, so that's a good sign. Haven't tried the code converter yet, but will soon. The little scripts I wrote to compile things didn't bring me much joy using the included sample.bas file. Which shipped with some bad lines in it... were those for testing? This is what I was doing for version 0.2: ./2600bas<ooze.bas>sample.asm cat 2600basic.asm sample.asm 2600basicfooter.asm > test.asm ./dasm test.asm -f3 -oooze.bin stella ooze.bin I made the filename change from 2600bas to 2600basic and let the rest go. Before I go posting a bunch of crap, can someone briefly summarize the compile steps? Something has changed and I should know what that is before I start the next version of Ooze in Bb0.35. I just had some minor surgery that will keep me at home for the next day or two. Just the perfect time to futz with this! Before I do too much, I'll be reading the help docs this late evening as well to catch up on the many changes discussed over the last few weeks. Man, you think you have a handle on it, but you just don't until the process of using it begins!

Ok, I'll take the hint! --Thanks. I'll give this a whack soon. Kind of dismayed about the reduced avaliable space though. I believe the game was floating around ~200 bytes free. Oh well, the functions, improved bit ops and proper gosub should free most of that back. Need to finish current work project first though. (money first, games second!) Scratch that... I've finally let the drugs wear off. I'm not doing much of anything tomorrow morning. Time to rebuild Ooze.

Yes! That is a great example and one that I bumped into as well when getting the interaction between the ooze and the bullets working properly. Another one for me was when to draw new ooze. Done at the wrong time, it was impossible to know just what a collision did exactly. Being able to read playfield pixels directly would have mitigated some of these problems. However I thought it good to practice completely understanding the game state at any time. The code is more solid that way... Sounds like we all might get something out of this tutorial! Looking forward to it.

Totally agree that any tutorials should target the latest release. Batari: I'm in the not using it camp at the moment. It's gonna take a while to move my code over to 0.35. (sorry) On the tutorial: Learning how to do something simple, then building on it in stages works well. The very best introduction to a new language, for me at least, happened to be the O'reilly Perl books. It started out with very simple things, then just kept adding on until something great eventually was all documented. I would shoot for that, if it were me. Also, comment your sample code and your game code. Err on the side of too many comments. Learning how the language works is not too difficult, IMHO. Making it easy for folks to parse your code is golden. Language and hardware limits aside, the tough part is all the subtle things that need to work together. Here is a short list of things that ended up being very important while I continue to work on Ooze: - the order of things is very important. Simple questions like, do I update a variable, then draw a playfield block, or draw the playfield block, then update the variable? The answer to this question was the difference between a lot of buggy code and far less code that ran well. Doing things in the right order can sharply reduce the number of extra, unplanned conditions the gamecode must handle. -every last bit counts. At first, the memory limitations do not seem significant. It's easy to get something up and running. Refining it and handling all the little issues that come from that consume a *lot* of memory. Using bit comparisons to better leverage every avaliable bit is a big deal if the game has any level of complexity at all. I ended up doing a coupla rewrites as I ran into this issue over and over. I'm gonna have to do another one before it's all over. The earlier you realize this, the fewer times you will run out of storage. -comment your code. I find that I already forget some of the little hows and whys behind my own code. (And it's not been that long.) Verbose comments written to your future self really help changes you don't know you are going to make yet happen easier with fewer bugs. -task seperation. At first, it seems like you can just write your game with few worries. Soon, game complexity becomes an issue. Breaking down tasks into specific chunks allows for easier changes and clarity. The earlier one can develop some program structure, the easier this all will be. -loops. Because the game logic runs every frame, the program needs to be able to execute almost everything all the time. Breaking down the game elements into little chunks that know when they need to act, based on the actions of other chunks is very important. The bit flags are invaluable here. An example (that I've yet to do) would be sound. One game element interacts with another and sets a flag that tells the sound element to go ahead and make the sound. -what really needs to be in ram? Using the ROM space for game data, with the data statement really is important too. Some things just don't need to be variable. If these things can be found out and placed in the ROM, you have just that much more RAM for complexity. -reusing variables. An example is a pointer to a data element. I found that I could waste RAM by setting up a coupla variables to point to different things in the data, or I could access the data, one element at a time, while incrementing the same variable as a pointer. The result was the need for fewer general purpose temporary variables and more room for complexity. I listed these here because these are the things that people are really gonna struggle with. Learning the language limits is one thing, putting together programs that have any level of complexity is another. Ideally a solid tutorial can at least hint at that. I plan on documenting some of my experience when I have some free time and my project is up and running on 0.35... Either way, the more the merrier. I've learned something new from each and every program posted so far, and that's the coolest part for me.

I personally think having some sound is important because it will help flesh out the simple visuals. Sounds for indicating successful movement and encounters with the various objects and pirate, and sounds for winning and dying. So really I'm thinking you only need a handful of simple yet fun little sounds. 921207[/snapback] I totally agree about the sounds. Making them is light code too. You can use your game loops and data statements to make pretty interesting sounds that change with a variable...

Gave this a shot just now. I'm seeing a lot of flicker as if the game does not always have enough time to draw the frames, or the background color is always changing. Didn't get a chance to look too closely, but I see more than one drawscreen. (maybe it's just the colore and my monitor timing clashing. Ignoring that, I checked out the various rooms, avoided the monster and had some fun. Like the sprite shapes.

I'm liking this idea for a more flexible playfield. You can claim the playfield memory this way: dim extravariable=playfield+44 {45, 46, 47} One question I had was this: Assuming extravariable has been defined as shown above, is extravariable[index] now legal?

I investigated and found the source of the bug - it crept up because I changed the way I handle || (logical OR) in if-thens. It was an easy fix. Unfortunately, until I post the fix, you can only use || once per program or more mismatches will occur. Come to think of it, I think a good way for me to find bugs is to try existing programs in 0.3a, so I'll go ahead and try F-4 and Ooze tonight. 917512[/snapback] No new bugs found from compiling F-4 and Ooze... They both compiled after changing bit accesses to use {braces}. I also changed all of the > in F4 to >= and inverted the accesses to bits 0-5 and it seems to play fine under 0.3a as well. Ooze had hundreds of bit accesses so I didn't invert the bits, but it does compile nonetheless. A good sign, I hope - that the new features didn't totally break the old stuff. Please keep bug reports coming! 917567[/snapback] I'll be sorting through all of those this coming weekend... Every bit counts! Thanks for your hard work. It will be nice to get the core language issues worked out. I kept a log of the bit operations and which would need to flip when the comparisons got fixed. Should not be too big of a deal.

I'm all for a release as well, but am not time sensitive. We have a nice body of code to compile now in search for bugs. I'm going to probably rewrite Ooze to work with 0.3. Hoping some of the new features will let me scrunch the code down to free some room to really complete the game. I won't get to that for a little while yet. I'm up for some quick testing of new things however. The eariler they are fixed the sooner we move on to bigger and better things.

Pretty cool little game. I played it a coupla times and had some fun. It took me a bit to really understand what you were trying to convey with the direction blocks. Once I groked it, things went fine. Like the use of the dual display areas to communicate game information.

I think you could do Adventure right now. Was kicking that around the other day and I think it's doable. If you go the block route for the character, you are left with two sprites to display things. Multiple items are going to flicker, but that's easy to do in bb. There is the other missile too. That gives you three things to interact with. The ram based playfield could do interesting things as well. Touch a wall (marked by the missile maybe) and another one opens allowing you to pass... 915753[/snapback] Cool. So now that I know a little more about the Atari 2600, E.T. didn't have flicker because it only had 2 sprites on the screen at the same time. As you said, if you make a missile wider, that could be the player and the two sprites could be anything from enemies to treasure to scenery and the other missile could be something like a sword or a treasure chest. After the next version of bB comes out, I may never sleep again. I might even try to recreate E.T. for the fun of it if we can ever do multicolored sprites with bB. 915779[/snapback] Well, if you are willing to either double up the sprites every other frame for two colors, or live with single colored sprites, you can get some pretty decent stuff done right now. Here is a little code segment that demonstrates what would be needed to make this work. It's rough, but maybe might generate some ideas.... rem adventure.bas by Doug Dingus rem this code is licensed under the GPL rem rem Written for Atari 2600 in Batari Basic rem for more info: [email protected] rem rem Compile with Alpha 0.2 --later versions will require rem bit comparison tweaks... (Noted within) rem v0.1 core display kernel rem smartbranching on rem i, t, u tempoary vars rem draw some stuff to bump into: for i = 0 to 34 t = playdata[i] : i = i + 1 : u = playdata[i] pfpixel t u on next data playdata 10,10,11,10,12,10,12,9,12,8 20,03,21,03,22,03,23,03,23,04 23,05,23,06,23,05,22,06,21,20,05 20,04 end rem setup both sound channels AUDV0 = 0 : AUDV1 = 0 : AUDC1 = 12 : AUDC0 = 8 AUDF0 = 0 : AUDF1 = 0 rem s = game flags rem s(7) = display toggle, odd and even frames rem s(6) = multi object toggle on / off set to display 4 or two things. s = 0 : s(6) = 1 rem set initial player position x = 50 : y = 50 gameloop rem CXCLR = 0 missile1height = 10 : missile0height = 4 NUSIZ0 = %00100000 : NUSIZ1 = $0 COLUP0 = 34 : COLUBK = 2 : COLUPF = 14 : scorecolor = 55 : COLUP1 = 34 player1x = 20 : player1y = 20 player0x = 40 : player0y = 40 missile1x = 60 : missile1y = 40 : missile0x = x : missile0y = y rem toggle sprite shapes to allow 4 things on screen if s(7) then goto oddframe player0: %00000000 %00000100 %00000010 %11111111 %00000010 %00000100 %00000000 %00000000 end player1: %00111100 %00011000 %00011000 %00111100 %01111110 %01100110 %01000010 %01000010 %00000000 end goto framedone oddframe rem kind of messy, but just wanted to show how it might be done. rem should control things with variables, set it all, then pick shapes rem for best space usage. missile1height = 10 NUSIZ0 = %00100000 : NUSIZ1 = $0 COLUP0 = 88 : COLUBK = 2 : COLUPF = 14 : scorecolor = 55 : COLUP1 = 21 player1x = 90 : player1y = 40 player0x = 110 : player0y = 60 player0: %00000000 %11100000 %10101010 %11111110 %00000000 %00000000 %00000000 %00000000 end player1: %00000000 %00000000 %00000000 %01111110 %01111110 %01100110 %01000010 %01000010 %00000000 end framedone rem draw the picture 60 times / second drawscreen rem GameCode --have ~2500 cycles per frame to work with rem dealing with gosub bug, using gotos for right now... rem game logic lives here, per frame goto displaytoggle displaytoggle1 goto moveplayer moveplayer1 goto gameloop rem Subroutines Live below Here ------------------------- moveplayer u = y : t = x if joy0up then y = y - 1 if joy0down then y = y + 1 if joy0right then x = x + 1 if joy0left then x = x - 1 i = CXM0FB : i = i & 128 if i <> 128 then goto dontmove if y = u then goto checkx if y > u then y = y - 2 if y < u then y = y + 2 checkx if x = t then goto dontmove if x > t then x = x - 2 if x < t then x = x + 2 dontmove goto moveplayer1 displaytoggle if !s(7) then s(7) = 1 : goto flip if s(7) then s(7) = 0 flip if !s(6) then s(7) = 0 goto displaytoggle1

I think you could do Adventure right now. Was kicking that around the other day and I think it's doable. If you go the block route for the character, you are left with two sprites to display things. Multiple items are going to flicker, but that's easy to do in bb. There is the other missile too. That gives you three things to interact with. The ram based playfield could do interesting things as well. Touch a wall (marked by the missile maybe) and another one opens allowing you to pass...

Definitely. You also chose a good sound effect to accompany it. Would it be possible to implement the bouncy bullet and stun feature randomly or possibly reserve the bouncy bullet for the earlier levels and the stun feature for the later levels or would that gobble up too much memory? If you do eventually use the stun feature, it'd be great to make it obvious with a sound or color change as Thomas suggested earlier. 915217[/snapback] Adding a sound is no biggie. Adding a visual indicator of stunned status is on the to-do list. Was thinking about slowing the ship slightly, and changing it's color. I'll be thinking about what sound makes sense. Early feedback indicated pure random is bad. Too much chance marginalizes skill and level progression. I've got the level data tabulated so that I can set & reset options on a level by level basis, making your by level idea a good one. Again, another few bytes to toggle the bouncy flag (when it gets written that is) on and off is doable. One other point of discussion remains the target. Right now, the code is there to put target on screen and have hitting it do things. The whole fuel idea sucked and was tied to the target. If I am careful about space (and scrunch a coupla more things), the target can appear as a power up. Powerups possible: knock back all ooze, extra ship, game state change [fast bullets, bouncy ones, etc...], extra level time, less level time, level warp... If possible, I would like the target to be used in the final game. Seems a shame to waste a perfectly good sprite....

I'm thinking this might end up being a powerup, or game variation. I've not had any contact with Albert yet, though I did submit the game using the in development form. It's ready for that level of attention at this point. More feedback would be just great. Totally agree we have too small of sample right now. I like the stun feature better too. More game challenge and it keeps the player from just camping on the fire button. When that happens, the game becomes a lot easier. Started out with a latch that forced the player to ask for each shot, but it's too much and too tiring. ---something will have to happen here to keep game balance in check. Camping on the fire button just won't cut it. Graphically, the bouncy bullet looks great though! Agreed, and thanks. Once I got it to a playable state, I played it often looking for ideas. The kids have played this version a lot actually. I set it up in Stella fullscreen, with a gampad running through USB. They will just sit there and blast the ooze. I'm considering one long level where it's not a cake walk, but enough of a challenge to let the player just zone on the ooze for a nice long while before moving on to the next levels. This would be a chance to get some good scores as well, as an experienced player could choose to walk the edge and let the ooze come down farther for the points alone. More risk, more reward. Greets back! ---one at a time. This one sucked me in huge! Before starting anything else, a lot of polish remains on this one. Core game logic works well, but play balance is still iffy.