potatohead
-
Content Count
4,794 -
Joined
-
Last visited
-
Days Won
16
Posts posted by potatohead
-
-
Just checked in...
This is REALLY COOL. Keep up the good work!
-
A single index is definitely needed. That's on my todo list for the summer.Back to the spacebar/joystick thing, I think it's a valid point you raise, even if I do explain and show them the hardware. I've tried to get a number of the students to change their control systems to better reflect the physical joystick, but that doesn't always happen. I think getting a cart writer of some kind will solve this problem, but I haven't had a chance to figure that out. Any recommendations?
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.
-
If I put on some video goggles connected to a pole-mounted camera connected to a backpack I'm wearing so that I'm seeing slightly above and behind my body, I'd no longer have a first person view. I could move and touch things in the same way I always could, but my view would be 3rd person.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!
-
One funny thing is, these young punks...they think of their game as being played by spacebar, keyboard etc, and skip that its emulation of rather different hardware entirely-- to them it's all just a primitive programming language.
Agreed on this game.
Maybe this class needs a cuttle cart / supercharger / thingy to play their games on!
-
We should start some kind of archive, before too much gets lost.
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.
-
Wow, that's very cool! Are any of the games fun?
..Al
Yes! I like the two player one death flag. There are some good game play elements in many of these projects, IMHO.
-
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.
-
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.
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?
-
The AtariVOX users aren't wanting what will benefit them first? Everyone can benefit from just about any other feature you can dream up. Only AtariVOX users benefit from AtariVOX support at this time. It seems more selfish to me.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)
To be clear, you do know that I'm not saying that the AtariVOX itself is a waste of time, right? I'm just saying it seems like a waste of time to include support for it in bB at this time if hardly no one, including most bB users, are ever going to hear the result. The only way I'm going to use an AtariVOX is if someone gives me one or it is emulated.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.
-
Yeah, well that kind of proves our point. If you can't even sell more than a handful of homebrew games that have become semi-famous by being included in various collections, how will the AVox sell any better?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...
If it's not built into a new Atari, it's a waste of time and a waste of the already limited space we have for our programs to support something that an insignificant number of people will ever own.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.
If no emulator emulates the AVox, how could we test it?Build one like I'm gonna do. Sounds to me like it's four wires, a chip and some other minor bits.
We have to constantly bother people who own one?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.
-
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?
-
The WIP version on my hard drive supports bankswitching and it works. I'm working on optimizations still. I've relocated the graphics and can align them in preparation for the multisprite kernel (I hope to get it working tonight or tomorrow.) Definitely there will be bugfixes and minor features.All great stuff. The extra address space is going to seem just huge! Funny how that stuff works.
I *hope* but don't promise to get a text kernel (you will get a 12x12 screen that you can print to using PRINT statements), a few alternative kernels based on the main kernel (color striping, paddles, playfield in ROM: all with something else taken out, of course), PAL support, and hopefully, basic AtariVOX voice support.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!)
-
"Bankswitching has been added to bB, which can generate up to 32k binaries now, so space shouldn't be an issue. Also, there should be a paddle kernel or two. This will be in the next release, probably in 2-3 weeks."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.
-
Well, in my case, I just designed an instruction manual with OpenOffice and created a cartridge label along with illustrator Nathan Strum. I sent everything to AtariAge editor Albert Yarusso, and he did the rest. It was a breeze, and it took less than a week for the game to be released after the cartridge art and manual were completed. It didn't cost me a penny out of pocket; all the publishing expenses were handled by AtariAge.If you're going to package the game in a box, with a CD-ROM, it'll take a little more work. I don't know who makes 2600 boxes... Atari Age might, but you'll need to talk to Albert to verify this. If you want to include the source code with the package, I'd suggest copying the data to some miniature CDs; something that would easily fit in the box along with the cartridge and instructions. You'd have to foot the bill for this, but if you're intent on including the source code with the game, this is probably the best way to do it.
JR
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.
-
Of course, you don't need to use the "canned" kernel. If you have very specific wants and needs (e.g., you won't be using the ball or missiles, just player0 and player1, and you aren't going to need an asymmetrical playfield), and if timing isn't a super-critical issue on each scan line, then you might be able to write your own game-specific kernel using all bB commands (i.e., for...next, if...then...else, goto, gosub, let). And if timing is an issue, you can always write your own kernel using inline assembly code.For example, the attached program is an all-bB custom kernel that I wrote last night to display the 2600's 128-color palette using only the background. Clearly, that kernel won't do you any good for multi-player graphics, but at least it shows that you can write all-bB custom kernels instead of calling drawscreen.
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.
Very cool!
Thanks a bunch for writing that.
Still thinking about supercats big memory cart and Bb...
-
It is one thing to emulate a NES, it is something far, far different thing to emulate a Saturn. The Atari 2600 is probably easier to start with than the NES, and the Colecovision easier than either because it does not use any custom hardware (outside the BIOS.) While working on the older systems is a good way to begin writing an emulator, it is the sort of thing that you keep to yourself or a select few, not something you release to the public.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.
As for portability, I am as big a fan as any so long as you can do the same things in Linux as you can on Windows XP without adding an additional level of complexity.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.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
first atari 2600 game you played
in Atari 2600
Posted
Breakout