potatohead

Man oh man! Moving sucks! Well, getting a new and bigger home doesn't, but basically everything else does. One never realizes just how many little tech bits one has until they are all yanked and stuffed into a box! Basically nothing works anymore. My ReplayTV does not work with the new Directv sat receivers, DSL was hosed until today, computers are gonna take forever to reconnect, on and on and on... I think I'm going to be looking for a new 400. Hooked my old one up and it's flaky now. Tried reseating the chips and still it just goes nuts after about 10 minutes. The combination of old age and being moved has probably done it in. The 7800 still works great though! Most of the other computers doom won't be known to me for a while yet. Hoping the SGI isn't in any trouble or that's a trip to ebay for sure. Can't live without that one. While I'm here, I suppose I should post a coupla ideas I had for later: Was thinking about Ooze a bit and reread the comments collected so far. It's not quite a game, though it is fun. One thing that's been getting to me is the use of the joystick for controls. Mostly I did this because the Batari Basic environment limits keep the paddle from being part of the equation. I'm torn between taking the game into assembly land, adding the paddle and polish and just doing something new. Controls are at the heart of this because the lack of them prevent me (or so I think --feel free to chime in) from getting the core game elements where they need to be for a viable game. So, last night while unpacking my Atari stuff, I bumped into my driving controllers. I'm thinking those might be just the trick for Ooze. I want the game to be fast like Kaboom! That's where the trance comes into play and is the core, for me at least, of what makes really great old 8bit games. The joystick just isn't going to cut it because with speed comes the need for really fast player interaction with a far more dynamic and aggressive Ooze. Having not touched the thing for a while, it seems more like a great Bb tech demo than it does a game. (And the solid comments reflect that if taken as a whole.) For those of you out there, starting on the game journey I'm currently on, I highly recommend putting your work aside for a while. When you come back, your perspective is far more objective and valuable. You really get sucked in while working on the project. Core goals can get lost in the shuffle, thus blocking the creative process. At least I've discovered this to be true for me. Take that for what it's worth! Using driving controllers with Bb should be dead simple and they work a lot like paddles, but for the lack of absolute positioning. Maybe that's enough to get the experience where it should be. So I'm going to try that and see where it goes. My gut says it will be a coupla more weeks before things are in order enough to begin hacking on the game again. I'm gonna move everything over to the SGI. This will slow the project at first, but it will be worth it. If you have ever used an SGI, you know about the IRIX environment. It's insanely addictive and very pleasing to work with for long periods of time. On SGI, the emulator scene is good, but getting dated. I think it's time to compile the latest Stella and see if that's viable. If so, Atari game development on the platform will be solid again, which will make me very happy. There is something cool about using a 64Bit platform to develop for old 8bit systems. (That and the excellent screen fonts --easy on the eyes.) I'm not sure how I'm going to do controller interfaces however. Might be keyboard / mouse only for the moment. If push comes to shove and I need to do something else, I'll just use the Linux box for that and display the window on the SGI. Sorry for length, but that brings me to another "Why Unix and the X-Window system kick so much ass it's not even funny" post. I'm not sure the lions share of computer people fully understand just how big of a gift the X-Window system really was in it's time. Heck, that's still true today for those in the know. Basically it comes down to true multi-user computing. Not user switching, or a limited remote desktop environment, terminal server, etc... but true multi-user. That's what Unix has been from the get go. When networked computing became a reality for the masses, Unix and X were there in all their glory ready for what should have been a great time. Instead we got single user win32 boxes. Well, most of us did anyway. Those few who were running Unix in networked environments with the X window system took a different path... X allows any user on any machine to serve graphics to the user on the display they are located at. It's like VNC, but for any number of users and not just for the whole desktop, but for any application. It's possible, for example, to have the machine you are sitting at handle input and display graphics while another runs your window manager and a third machine to run the application. The implications for the desktop are powerful, if not so obvious. For me, this means I can use an SGI (once I get it hooked up again) for my primary desktop, and display Linux programs on it as well, thus having one nice environment. I will typically script the access to resources running on other machines so that my favorites are only a coupla clicks away. Done right with shared network storage and the average user will have no idea they are running stuff across a batch of machines instead of just one local machine. Sounds goofy I know, but it's very cool. Let's say my local machine is a bit slow (which my old SGI is), but a remote machine is much faster. Once I've asked for the program to be displayed on my box, it's pretty much like having a faster machine without the hassle of changing boxes, KVM, VNC, etc... From an IT standpoint this has serious advantages as well. Say you have a group of users who all need a very strong machine 10 percent of the time. Do you buy 10 strong machines, or buy one and let them share it as I've described above? Another example lies with shared applications. In this day and age, many software companies do not let their licenses float, depending on the single user win32 system to force folks to buy lots of copies of their software --even for casual users. With the X window system, this is not necessary at all. Just install one and let people share it to their local desktops as if they actually had the application running on their local box. Finally, there are lots of solid computing choices besides the sometimes problematic client-server approach. Client server is great, but does require some tinkering on both ends to work correctly. The more robust choice of application server can eliminate these problems. Have a difficult or expensive application? Put it on an application server and let all your users run it from there. One copy of the software, one configuration, etc... Or, maybe you want to manage some data. Keep it out of users hands. With the X window system, you can have sensitive data located on a server with the managed application that interacts with it. Users are limited to only those things the application allows when running over X, because they are not running code locally! There is no need for them to even be able to see the data, but through the application itself. Ok, that's enough. Best get connecting or I won't be doing any of this stuff!

I would get a USB adapter and some gaming hardware for them to use. There are a number of joystick / button thingys built for playstation, etc... that should do the trick.

That would be interesting. Very interesting thread. BTW. Use a couple of mirrors to give yourself an alternative view of the world, then try and do something. It's the same problem, IMHO.

I'm wanting to do some coding for paddles. Is this emulation working properly in Stella? I'm on Linux, so a secondary question is that version available for Linux as well?

Very nice! This and KABOOM! are probably my favorite games of all time. Three fireballs is going to be insane! Looking forward to owning this one.

Stumbled on this thread late it seems. I ran into this early on with Ooze. In a nutshell, if one expects reasonably random numbers, don't ask for them quick!

Agreed on this game. Maybe this class needs a cuttle cart / supercharger / thingy to play their games on!

Yeah...I was an early big advocate of BB but kind of let myself fall by the wayside, I think waiting for Batari to have time to plump up the language a bit more. Actually once upon a time I was talking to Al about a bBdb, with snippets and small programs...I'll see what he thinks about that now. I'm still pretty pumped about it. I like the environment --just need to work through some personal issues before continuing on. Thanks for following up on this.

We should start some kind of archive, before too much gets lost.

Yes! I like the two player one death flag. There are some good game play elements in many of these projects, IMHO. I've a short writeup with a few screenies here.

So very cool! Way to go Batari. Any news on the latest bB? I'll be in a spot to work with it soon. (1.5 months or so) Looking forward to the whole experience again. Edit: I shot the prof's a quick note about this thread and the blog post above. Who knows, we might hook a student or two! No matter how that goes, I think they should see others have enjoyed their work. Another Edit: Al, the new forum UI is sweet! Thanks.

That's stiff, but I'm still interested, BTW.

After looking at that guide, you will find there are two sound channels. Each one can make a variety of tones, ranging from a fairly clean squarewave to noise. Stuffing numbers into the registers will get you a constant sound. To get the more interesting game sounds, you are going to have to modulate both the pitch and volume and sometimes the noise register through a series of values. This is something you must do, there is no facility in the 2600 to handle it for you. One good idea is to put your game sounds in your game loops so that the sounds automatically relate to their respective events...

I was thinking 1.0. Regardless, I will get rid of the incorrect "alpha" designation (I don't write software for a living, so I had no idea I was doing this wrong.) I think I will correctly call the next release a "beta" since it will likely have bugs, possibly serious bugs, that will need to be fixed right away, then a week or two later I will fix the bugs and call it 1.0. 989892[/snapback] This is a solid choice, IMHO. bB (Dang, I always want to type Bb) is well past alpha stage with the 0.3* release.

Too late to get on the purchase list for this one?

I just don't think it's a worry and you do, as if something you really want is gonna get shorted. (and it's just not) Maybe that's not what you had in mind, but it's the way it sounds. Honestly, that's as selfish as you clame AtariVOX support to be. (Just offering another point of view, so don't take that personal because I don't mean it that way.) Of course, this is how these things go. The developers of open projects, like Bb, do what feeds their soul because that's often all the repayment they are gonna get. Best to encourage all development, unless you are a contributor to the project, IMHO. (Or you wanna pay for specific things at specific times) Too bad really. I'm going to build then buy when I can. Totally happy for the option too. Greater support for AtariVOX means more oppertunity to obtain one and actually enjoy it. Same goes for other interesting atari stuff. (Supercat's cool RAM cart to name one) Where you see one community, I see two. There are those working with the standard atari stuff. mostly emulation. The other community is more hardware focused. Emulators are free, all you need is your computer. Hardware stuff costs a bit of money as does buying homebrew carts. For those of us who want to spend a little this coming year (and I do) these kinds of developments give us something to spend on. You clearly are not a member of the hardware oriented crowd and that's just fine. However those of us that are, or will soon be, see these things differently. Look at it this way: The atariage community as a whole is large. A few new members really does not matter much. Also most of them are not trying to develop anything, but are collecting, playing, etc... The Bb community is small. A few new members really packs a punch in terms of what we all learn and do. The efforts of those few will bring others into the fold. The hardware community is likely larger than the Bb community, particularly since both communities see overlap in that we are doing more than playing games. A new hardware owner/user/tinkerer is just as important as another Bb programmer. We need other, frankly --if anyone is to have any real fun, which is exactly why I am here! Finally we have the homebrew assembly community, which is probably just a bit larger than the hardware community alone. I'll bet a fair number of them have the AtariVOX as well. If they don't the Stratogems game is gonna change that. All in all, we are talking about a few people in each group, except the largest group of basically non-contributors. When viewed this way, AtariVOX support is fairly significant in that it correctly targets users from all of the groups here that are actually building things. Is this more important than new Kernels or bankswitching in Bb? Probably not, but I think my point is clear that it's just not a waste of time either. Given these observations, when is a good time for AtariVOX then? When everything else is done? That might be years actually. Evolving kernels and interfacing them with Bb is going to be as much of an art as anything else is. By contrast, once AtariVOX support is up and running, it's gonna be done and will likely be something that can be either included or not, so program space is not limited by it's being there. (BTW, 4K of BB is a lot of code. Up to 32K appears to be on the way, meaning the small amount of machine address space necessary for AtariVOX support is going to be a non-issue) Why put off the development of a feature that can likely be completed in one cycle in favor of others that might continue to evolve for a long time yet. Who knows, the greater synergy between folks of different interests here might yield some very interesting projects that might not otherwise happen or become moot if empowered to happen much later in time... My point being it's ok to advocate your interests. Afterall, you are a Bb user and those are few and far between now. Just know you are not alone.

And the Devil's Advocate is gonna say: Without that core group of 50 or so homebrew enthusists, there would be no scene to power this community that brings new tools, games and info each year... Not for those same people mentioned above. Again, without these core people doing what they do, there is a lot less to the community as a whole --even if most others never participate via ownership. Build one like I'm gonna do. Sounds to me like it's four wires, a chip and some other minor bits. One could always ignore developing for it you know. I've no problem with your vote for other features first. Totally valid. However not only are you wanting things you will benefit from first, but are saying the AtariVOX stuff is a waste of time to boot! I just think that's bad form all things considered, that's all.

I disagree. Push it and push it all hard. Those Voxers will test and develop and those without won't. (I am likely just gonna build the speech part and wait until actual units are again for sale. I seriously doubt any other feature will be lacking to a degree that actually matters to anyone if Vox support is intermixed at this time. --and if it does, well help out then, or wait. It's not like plenty can't be done with Bb right now. One can add their own kernels, trigger a Vox and bankswitch right now. This next release just makes that stuff easier. It's Batari's effort and he should be free to do what feeds the soul in that regard. It's not like he is getting paid. (Though I'm gonna donate Ooze royalties to Bb, once I get to a release state.) I didn't think twice about getting one of these until I saw some recent games supporting it and had a request / suggestion for my own game. Thinking about it a bit, I realize the Vox could add a lot of value, and it's fun! If we prioritize according to the hardware for the masses, we then marginalize efforts to extend the fun.

Thanks for the encouragement, I really appreciate it 986746[/snapback] How can I get one? Pushing the edge is what this is all about. Personally, I find new 2600 hardware to be very cool and interesting. --well worth the efforts. I've got some dollars set aside for Supercats RAM cart, and would love to own one of these as well! It is possible to build one easy enough?

All great stuff. The extra address space is going to seem just huge! Funny how that stuff works. Interesting on the text! Looks like I'll be wanting an AtariVOX as well. Always wanted to put speech in a game. I'll bet it can be used for sounds too. Thanks for your hard work. For what it's worth, I have a ton of fun working with the results! Each release has really opened a lot of doors if you think about it. Going from alpha 0.1 to 2 was big. From 2 to 3 fleshed out language features and it seemed that was going to be a plateau. This next version is just as big of a jump. Damn cool, that's all I'm trying to say. Much appreciated. Merry xmas! (don't work too hard!)

The additional space settles it! Even double the 4K space will allow for many of these options to become part of the game. Had I known this, I would not have posted this thread. Thanks Batari for continuing to work on this! I limited the development scope, believing that Bb would not reach this stage as quickly as it appears to be doing. One of the initial goals for this particular project was to push Bb hard, but keep the project Bb, with the exception of tweaks. (AtariVox would be a great example of a tweak I believe would easily done with inline assembly.) Another goal was a great Bb game. Under the currrent Bb constraints, Ooze is there with perhaps some differences in value perception in gameplay vs bells 'n whistles. Bb will evolve quickly enough to meet my time expectations and interest for this project. So, that puts the goal of a great game back on the table. I've been thinking about paddle and driving support off and on. I set these things outside the scope of the project for a number of reasons --space being the primary one. Honestly, I'm glad to see this get pushed. Playing this game in that mode might be a lot of fun and challenge as the ooze can grow very quickly, placing much higher demands on the player. --This will likely be quite ooze like. I was not sure anybody else cared though. I know I would have always wondered about that --probably would have gone back and done it too. Better to get it done first time. Had this been done in assembly, it would have easily fit into 4K of address space with a better feature set. ---it also would have not gotten done either because of where I am at right now timewise. I have some worries of following ever expanding expectations, thus not actually finishing anything... Given the timeframe and overall scope of development suggested, this is not a worry for this cycle of development to come. Is the ooze less ooze like than before? Well, it's faster. However the way it behaves and its drawn has not changed. The initial slowness of the ooze seemed pretty pointless to me. Perhaps it's just me having banged around on the game too much. --thanks for ideas, support and encouragement. I appreciate it. The level question is moot now, given the new project scope, BTW. If anyone spent time on it, put your ideas here now. What I am going to do is make sure this version is complete and as error free as I can make it. That will be 1.0. Links and code will land in my blog, for reference later. Once I see the new Bb environment running, I'll go ahead and make a roadmap for what will become 2.0 and reconsider this thread at that time, once the new elements are running.

I'm wanting to squeeze the best overall gameplay out of this one more time before releasing it on cart. Past efforts only involved a few testers. Hoping to get a few more this time around. Before, the levels were somewhat random, with a couple of real tough ones mixed in. This time around, I've decided to try a cyclic set of similar levels with a better ramp-up to the ending level 10. Additionally, the initial levels in prior versions started out really, really easy. I think that made the game somewhat boring at first, then fairly decent. This set of level parameters starts the game out at the action level, then ramps up from there. I'm hoping this has a better immersive effect than the other combinations did. You tell me! At this point, major gameplay feature changes are off the table, but changes to colors, level parameters and other minor tweaks are going to be considered. Again, lemme know what you think! Here is the binary: ooze0.9.bas.bin New gameplay instructions: Ooze is a single player game, played with a Joystick plugged into the Left Controller slot. You get three chances at completing the game without allowing the ooze, or your own missile, to touch your ship. There are 10 levels to a complete game. Right Difficulty Switch controls the Drip. (b = easy = no drip) Left Difficulty Switch sets player movement speed (a = fast = easy) The reset switch returns the game to the position where it would be after powering the system on. This is the ready for new game position. It can be used at any time to abort a game in progress. Player movement is accomplished by moving the joystick right and left. Press the joystick trigger to launch a missile at the ooze. If your missile hits the ooze, that portion of the ooze will be eliminated and a new missile will be made ready to launch right away. If you hold the trigger, missiles will be launched as they become avaliable (auto fire). However, if you miss the ooze, your missile might bounce back, or be lost for a while, depending on where you are in the game. If your missile is lost, your ship will color cycle while a new missile is found. During this time, you will be unable to launch another missile, leaving you to simply avoid avoid the advancing ooze and it's drops. There is a brief intermission between levels, indicated by a number on-screen. When the ooze hits the bottom of the screen, it will begin to spread, slowly reducing the amount of safe playspace avaliable to you. If the ooze contacts your ship, one ship is subtracted from your total of three and the ooze is knocked back a few lines, giving you a small leg up to finishing the game. Pull the joystick down, to begin a new game.

Thanks, that helps a lot. Perhaps a box is too much, but putting the goodies on a CD is an excellent idea. I could make a nice set and just send 'em to AA for shipment with any carts they happen to sell. Drop one of those in a sleeve and it can go right in with the cart and manual.

Interesting... I always suspected it was possible to write a kernel in bB - it just never occured to me that it would work that well. 981521[/snapback] Very cool! Thanks a bunch for writing that. Still thinking about supercats big memory cart and Bb...

Holy crap! Who are you to say who releases what to whom and when? Did you have trouble sorting through some emulators recently, thus deciding to give orders to the rest of the world so you won't be bothered in the future? Like others said here, people will code what they want and release what they want. It's just not your call. What about the reverse. XP limits you in a number of ways that are just as painful. Portability means the emulator will be avaliable years from now, despite forced changes by the creator of your particular OS. You do realize, XP is controlled by a software activation scheme? There will come a day when you just *can't* run XP legally because authentication has been revoked in favor of the OS flavor of the time. Portable code runs on most anything capable. Wanna build your own creative gaming rig? Portable code combined with Open Source operating systems allows that to happen. You might not be interested in this, but plenty of other people are! Developing for XP only is perhaps the worst thing one can do where emulators are concerned. My personal preference is toward portability, but I'm not about to step up and tell people what to do. Better to simply let them know why it's not a good idea and be done with it. My computer of choice happens to be an SGI workstation. IRIX is a wonderful environment that has many advantages, in terms of usability, compared to XP. It's a good thing that a growing number of people understand what portability means, or I would be stuck with running XP for most things My second choice is Linux because it runs on ordinary PC's of pretty much any vintage. I can literally go take junk from the dumpster and do wonderful things for it --on my terms. Anybody, who has taken the time to learn about these things, can do the same thing. Very powerful and entertaining stuff. Your requests deny those people their fun for no solid reason. Another thing about portability is it's effect on your ability to compute the way you want to. You might be happy with XP today. Plenty of people are, but what about the next edition? Maybe that one pisses you off and you want to go back. Portable code is going to get you there, non-portable code isn't. Portable, and open code in particular, also grants you a degree of computing freedom that is growing scarce where closed operating systems are concerned. Want to make classic game CD's from your old game roms that play on just about any computer with no installation issues? Grab a copy of the open Knoppix operating system, add in your favorite portable emulator and sprinkle with your favorite game ROMS. Let cook for a while and you have a bootable CD that runs your favorite games with no hassles. Perfect for quick sessions or fun times with friends on pretty much any old machine these days. Don't sell yourself short by limiting your worldview to XP. Better, don't encourage others to do things a specific way just to make your life easier. That's seflish and arrogant, particularly if you are not a developer yourself. Did you grow up with the classic games, or just like them today? Back then, the diversity among systems was amazing compared to the giant monoculture we see today where the majority of users are just like you: They run XP and can't see any reason for anyone else to do anything differently. Let me tell you a little secret: That's what makes computing fun! It's easy to go and buy a nice box with XP loaded and ready to go. It's one hell of a lot more fun to build your own computer and load it with a nice Open operating system. A computer built this way can behave just about any way the user wants it to and can be created from an amazing variety of hardware components. Those people that write emulators understand all of this stuff. (Well most of 'em do anyway) We see DOOM ported to cameras, old computers, and other goofy things. These things happen because the people who made them happen actually understand what computing is all about. It's not just learning to use the computer, but understanding what makes it tick. I'm not saying you need to go and totally geek out because that's likely not your thing. But please don't go pissing on those that do choose to do this because a lot of your classic gaming fun comes from the kinds of people that value these things. To do othewise is to cut your noze off to save your face! If you can take some time to learn about classic gaming, you can easily learn to handle a coupla minor issues where portablity is concerned. Cheers and peace.