potatohead
-
Content Count
4,794 -
Joined
-
Last visited
-
Days Won
16
Posts posted by potatohead
-
-
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!)
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.
-
As far as the order of things, one example of how that can make a big difference is with collision checking, especially if you want to "bounce" the player off of the wall to keep him from just walking through it. You must check for a collision first, then "bounce" the player back so it isn't overlapping the wall anymore, *before* you read the joystick and change the player's motion appropriately.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'm also going to put this question out - how important is sound in regard to this game? At the moment, I think I can stick a few Adventure type sounds in to indicate things happening as well as other stuff. But it may get to the point that it comes to a choice between audio and extra gameplay options. I would lean towards a silent release if it comes to that. Opinions?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.
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...
-
Okay, here's the first version of my simple adventure game in batari BASIC. It's still very much in the early stages, so there isn't much to it yet.Use joystick 1. The "instructions" (such as they are) are in the zip file, along with the batari BASIC code and the bin file. It's written for batari BASIC 0.2a; I tried to modify it for 0.3a, but it uses a lot of bit operations, and they aren't working yet in 0.3a. Once 0.35a is released, I'll start working on it some more.
Michael Rideout
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'll have to download bB and start playing with it. Seems very promising. Biggest limitation I can see at this point is that games don't get much memory for their own use even when using a custom kernel (though I suppose it should be possible to reclaim the memory for the playfield).Did you see my earlier suggestion (a few weeks ago) about display lists? Did you understand it?
One thing I was just thinking might be an interesting kernel idea would be to do something along the lines of a Stellar Track kernel for people who want to do "hunt the wumpus" and similar games. Because it would be prohibitively expensive to keep an image of the text screen in memory, what Stellar Track does is store the strings in ROM, with a character code 255 to mark newlines and 254 to mark places where something needs to be "inserted" from RAM. The RAM data are then stored consecutively to fill in the inserts. Thus, the starting message is stored in ROM as [something like] "YOUR MISSIONIS TO [email protected]## [email protected] ##@STARDATES" [using # to mark code 255 and @ to mark code 254]. Don't know if such a kernel would be worth the effort, but it might be somewhat cute.
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 don't have time tonight to look into this, but I just d/l'd 0.3 and tried compiling F-4 & Pirate. I knew the bins wouldn't work right, but I thought they would probably compile. But they both return label mismatch errors, which is an odd problem to be having for something that was working.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.
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!
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...
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.
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...
-
Graphically, the bouncy bullet looks great though!
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.
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 kind of like the difficulties they way they are currently balanced. I was able to play beyond level 8 without too much difficulty. I'm not crazy about the bouncing shot. It makes the game too easy IMHO. I liked the stun feature more. Maybe after the VGE is over, you could drop Albert a PM and ask him to feature your game on the front page. It'd direct more people here and hopefully get more beta testers. Right now you have 2 people who like the stun feature and 2 people who like the bounce back feature. That's not enough to get a good consensus, IMO.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!
One thing I can tell you for sure is that when this is done and on a cart, I will be buying a copy as it is a very addictive game.
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.
Hi Potatoheadgreat work;hope to see more nice Batari basic games.
greetings Gambler172
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.
-
I like the missile bouncing back. The levels are good too. kinda reminds me of Turmoil. I got to level three and all of a sudden the game went in slow motion. I am using Z26, and I don't know how to adjust the emulator to speed up the game again (if you can with the emulator). I kept going though and level four got crazy. The oozes' speed returned to almost normal, and my missiles got slower. I know that the speeds were on and the problem was just with the framerate (if that's the right term) running slower. Even in slow motion though I died right away. The only way I can see anyone having a chance of getting to level eight or so is if you utilize the top two lines of the screen to have the ooze start falling from there. One interesting note too is that even when the ooze killed me the game would continue to play and once the next level started the ooze would begin at the top again. The only way I truily died is if the bouncing missiles finished me off.Keep up the good work. I like the direction this game is going!
The speed changes are on purpose. It is totally possible to survive through level 8. (Not really easy though.) I'll be doing some playtuning on that part of things. I was not sure what swings of difficulty made any sense. Was hoping for comments in this area, once folks played it a few times.
The game start bug has to do with you holding the joystick trigger. I'll fix that. Game is supposed to stop & wait for trigger no matter how you end up finishing the game...
-
I don't play the home games much. Suppose I could hook up a trakball and MAME though...
Worked in a pizza place that had a sit down model. I used the warps to see the different levels, but on the game I won, I only warped the first time. After that it was just working hard.
The final level is bizzare. Physics are wrong. --Makes getting all the crystals very tough. I remember thinking I'm never going to make this... one well timed jump to the center combined with an aggressive swoosh of the ball got the last ones done. A few pixels seperated the game character and the three rolling ball enemies...
-
It is cool to finally have the ability to play around with Atari 2600 sounds. I think I found a sound from Star Raiders while playing around:AUDC0 = 8 : AUDF0 = 31
It's either Star Raiders or Starmaster. It's been a while since I have played either.
I thought sounds were harder for the programmers to make back then, but all they had to do was pick a distortion and a frequency for a lot of these cool classic sounds.
For a bunch of the sounds, you are right. Another great source of cool sounds are the game loops, counters and timers in your code. Setting sound values from within these results in nice, complex and repetitive sounds. You can take a frame counter, bullet position, etc... and use it either as is, or after some simple math operation (div by 2, minus or plus some value, for example), and feed it into the frequency and volume registers every loop iteration.
-
I'll second that feature. Would come in handy.
However, I must point out the information you need can be encoded into the data itself too. A bitmask can be used to make use of the unused bits in the pitch values, making the 'end of data byte' unneeded. Takes a bit longer (coupla cycles), but end result is about the same.
Set the high bit for the last note and it lets the playloop know to reset the notepointer...
-
A problem I see here is you need a smartbomb or other hail-mary feature, otherwise it's going to be too difficult in the higher waves.You and I think alike in that regard. For what it's worth, to this day I *will* stop and play a defender machine at any cost, when I see one
The hail mary is coded, just need to decide how to trigger it. I could link this to the target, or have a limited number of them triggered to a joystick down move.... Defender has smart bombs. Tempest has superzappers. Atlantis has the little guy you can hit that clears the screens (which is key in the upper waves).The first two games you mentioned are the most addictive for me. Bought a Jag just for the Tempest 2000.
Without these I can see too often scenarios where the ooze is too far gone and the player is just not going to be able to dig himself out of his problem.I've two options for this. One being the unfinished hail mary feature, the other being the levels. One thing I wanted to do was cultivate that almost dead scenario, then provide some means of relief --if the player can just manage the situtation long enough. If the player runs out of hail-marys, then they can still work really hard to get through anyway. That's done through the levels and game parameters. Either way, there are two paths to completing the game.
How about having the ooze get spawned by something at the top of the screen like a mothership or boss monster that you can pick away at in order to end the wave? If you kill the boss, the ooze dies instantly.Not ready for that yet. Great idea though. It will need a custom kernel. That will happen at some point and I'll keep this in mind. The top of the screen remains unexploited in the current game iterations.
Or maybe within the ooze there is a "brain" or a "heart" that is floating around and if you kill it, it kills the ooze.Having things inside the ooze would give you a good conflict of interest. If you blow up the ooze, whatever of interest inside the ooze goes away with it. If you go inside the ooze then you aren't controlling the ooze which could make matters worse. Competing objectives are key to making a 'zoner' game.
Interesting insight. I've always called this the trance, but I believe it's the same thing. This is why I've stayed with the classics. Very few modern games evoke that special state of mind like the classics so often do. Of all the classic games, Kaboom! manages to do this in seconds.
Or make it so you can float in the ooze for a certain length of time (the ooze being acidic). When you are inside the ooze, you can't shoot, just pick up stuff. The fuel meter becomes a shield meter. Or maybe if you shoot inside the ooze it spits out a Breakout like missile that bounces around and does something interesting.If the shooting scheme evolves more into a Vanguard scheme then it could get more Robotron-like. The ooze acting like columns of enemies surrounding you.
If the ultimate goal is to fly to exit the screen like in Midway Tron or Berzerk, then it would help the gameplay.
Hopefully all this provides some inspiration.
It does, and is appreciated!
Edit: The latest version is on the thread Ooze v0.5 released.
-
I was excited about that too. --never happened. One biggie today is the development tools are much better than they were when Stella was launched.Well, that's true, but I still think it's a combination of emulators (for people to quickly distribute and try out stuff) and burnt carts, rather than say development tools pushing the what's possible envelope, that set the non-supercharger course of this history.
And in some ways I find the group that does everything without ASM more interesting...if you do everything tough in ASM, bB is basically just a big macro to save you from writing conditionals and the other easy stuff in ASM.
Agreed. That was all inclusive in my view. (carts, etc...)
I think I'll end up being a mix of the three. Doubt I'll touch the kernel this time around. (Could happen though.) Having inline bits in the language is very cool. --and powerful. The language will grow to eliminate many of my current uses at least.
Having said that, there is a real charm to how it works right now. It's close to the CPU --and I like that. It's very easy to think in terms of a simple language that runs really fast. As long as language development does not get in the way of that, I'm happy.
-
A historical note:Glenn was one of the "founding fathers" of [stella].
(I think there's some tie-in with the "stella gets a new brain" project too.
Exactly right. I'm one of the ones that bought the original CD. Very cool project. Have got a super charger too. (Isn't there some way we could make more of these?)
But I think it veered from where he originally saw it going: he became fascinated with the idea of the supercharger becoming the de facto way of distributing exciting new atari games. But Packrat/Hozer showed up (as much as I like AA I think they were first) with burning carts, and for nostalgia reasons (hey I'm making what I played in my childhood!) and practical ones (there are only so many superchargers to go around) making carts has been the primary expression of homebrew activity.I was excited about that too. --never happened. One biggie today is the development tools are much better than they were when Stella was launched.
But Glenn is willing to put his money (some kind of bonus from his job) where his heart is, and try to entice people to *finally* do a 2600 game that can *only* be done on supercharger.As for bB...I think he just likes that as well. Honestly I wish the contest was after bB was more stable and mature, but still. Also, if it were my world/contest, I would be more interested in something that used bB *without* a lot of assembly, not just as "glue logic"...and/or maybe a seperate prize for someone who did the most work in kernals that *anyone* could take advantage of in their bB program.
I dunno. My gut says the 2600 is just a bit too limited to allow this to reach a good potential. Of course we have been proven wrong before. I'm open minded on this topic.
-
I'll do something. Can't just take the ship. Just wanted folks to be able to compare both quickly while the idea was fresh.
-
New version of this in the Batari Basic forum. Didn't want to keep duping threads.
Thanks.
-
1. Maybe the missile could bounce back if you miss and cause some kind of negative effect such as taking some points away from the score.
That's done to compare the two ideas.
2. Maybe the ooze could have a sensitive base layer behind the stuff that drips down and if a line is clear to it and you 'miss' the dripping ooze and hit that base layer, the whole ooze would flash (very quick cycle of colors) and then the ooze would speed up a bit because you pissed it off.Like this one, but no room for all of that.
If you go with that, will the ship flash or will there be a special sound?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Alpha 0.2 to 0.3+ code converter
in batari Basic
Posted · Edited by potatohead
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.