-
Content Count
1,781 -
Joined
-
Last visited
Content Type
Profiles
Member Map
Forums
Blogs
Gallery
Calendar
Store
Everything posted by Kurt_Woloch
-
OK, here's a rather long explanation... The lines on these two games are due to the fact that both games have an asymmetrical playfield. What does this mean? As you may know, the Atari 2600 had very primitive hardware. The display chip called TIA had no means of doing DMA, so all screen changes had to be done by the CPU in each scanline where something should be changed. Without those changes, the TIA would only be able to display vertical bars on its own, and not even do a proper frame refresh. Now there's another problem with the background graphics. The TIA has only got memory for half a line of background graphics, which can either be repeated or mirrored (Examples for repeated playfields would be some sections of Vanguard, while we have a mirrored playfield on River Raid). However, you can get a full line of different graphics by rewriting the background graphics registers on the fly. But the CPU only has a limited amount of time per scanline (74 cycles, as far as I know), and the rewriting of these graphics takes away a lot of this time. Another oddity of the Atari 2600 is that it's only got 2 players (the same as "sprites" in other systems, but with an unlimited height). Now, if you need more than 2 objects on screen, and they should have different vertical positions (which is the case in both games), you have to "reposition" one of the players, which unfortunately also takes rather much time since the CPU has to wait until the electron beam has reached about the correct vertical position and then do a write to a TIA register. This, however, conflicts with the ability to write a full display line. So as far as I know, it's impossible to write a full display line and to reposition a player on the same scanline. That's why many programmers resorted to display their asymmetrical playfield only on some lines and leave other lines blank. As you can see, Super Cobra displays its background only every other line. On Amidar, the problem is even a bit more complicated. Here they use 2 different foreground colors to denote the lines the objects can go and the filled-out areas. But the TIA can only display one foreground and one background color per scanline, so they display those colors on alternating lines. If you look closely, you can see that the lines don't even strictly alternate... there are single blue scanlines followed by one or more red scanlines. I believe this because of the need to reposition players which they wouldn't have if they were constantly changing between red and blue lines. That's why both games display a bunch of lines instead of a solid display for their background.
-
OK. this is my last entry for this week... because... I ROLLED IT!!! Here are 2 screenshots... one taken shortly before the rolling, at 999475, with the game still in progress, the other one at the end of the game, at a score of 1021011, with the score displayed as 021011, but in YELLOW instead of white. Also, there are 2 vertical bars on the title screen which aren't there normally as far as I know. I think I played this for over 6 hours today. Here are some last tips... I now found out that what I said about the unsafety of flying in between a 2-enemy group only applies to certain groups where the two enemies are closer together than the posts normally are. Also I found out how you can make some nice extra points: - When you've passed the last post on the ground, the screen flashes for a few seconds before you enter space. During that time, you are invincible, but you still can fly through posts and hit additional saucers and hoppers. You should also accelerate to full speed while this is happening. - When you've shot the mothership, the game will take a few seconds to add up the 40,000 points you get for it. While that happens, you also should accelerate to full speed, since that will give you a few hundred points more as you still get additional points for flying fast while the bonus gets added up. Also I found out some more bugs... some work in favor of the player, and some don't. First, the counter which counts down the saucers you still have to hit sometimes counts a saucer twice (but you still only get the points for it once). Then you'll maybe notice that if a level gets repeated, you get a bit more time to make it than the first time around. This is because the time line already gets refilled the moment the mothership is hit, and the time it takes to add the 40,000 points is already deducted from the time line. However, if the level gets repeated, the time line starts out full right at the start of it.
-
Another improvement... 811977. At later rounds (from Level 7 or so on) it might be better to fly slower and not make the level every time than to fly faster and make a lot of errors, i.e. lose a lot of ships. If you fly slowly, you'll still be able to make about 30000 points or more for each level that gets repeated, so with a 60% chance, you'll win back the ship you lost by not making the level. You should also try to make as few mistakes as possible in earlier levels where you still have ample time to meet your goal in order to win a lot of extra ships which you can use in later level for a lot of level repetitions and, thus, added points. Another thing I found out is that when two enemies (saucers or hoppers) are beside each other (which happens from Level 9 on), it's not very safe to try to pass through between them. You should better try to eliminate one of the two in order to make enough room, or fly around the whole group.
-
OK. Got a little higher today as well... 741548. Meanwhile I noticed something about the space battles... if you keep your ship close to the middle, you won't get hit from behind by the saucers or the mothership, since they either come out on the left, flying a curve to the right, or vice-versa (they always fly in the same path, by the way... only sometimes from left to right, and sometimes from right to left, so the path is mirrored)
-
OK, here's my best so far... 710203. Actually, the manual here is wrong on many counts: - The time line doesn't FLASH red, it only TURNS red when you have only 1/4 of your energy left. - The rounds of battle are divided differently than described in the manual: You have two goals to meet. The first goal is flying through a certain number of electron posts. While you do this, you first have no enemies to shoot, then saucers, and then hoppers get added. However, this all happens while you're still on your way to your target number. The second target is shooting a certain number of saucers in space. If only one saucer is left, the mothership will come out instead. - They talk about five skill levels in the game. I don't know what they mean by a skill level, though... there are (supposedly) 15 levels with *some* rounds each, but where are the skill levels? - The mother ship is worth 40,000 points, not 20,000 as described in the manual. - Every 50,000 points you do receive an extra ship, but NO full time line. You only receive a full time line after you defeated the mother ship, or if the level gets restarted because you ran out of time. Some of those errors may come from the writers of the manual not taking into account what's different in the 2600 version compared to other versions. In the C-64 version, for instance, there ARE multiple rounds on the ground where you have to meet a target in each round. However, in that version, hitting saucers and hoppers on the ground also counts towards your goal, which is not the case in the 2600 version. The arcade version seems to be another different thing, since it contains some stages not present in any home version. Just played it for a comparison... the arcade version contains 8 "sectors" (which are the "rounds" in the 2600 version) per round (which are "levels" in the 2600 version), some of them play in space, some play on the planet surface, and some play in a sort of tunnel. The timer bar gets refilled at the start of each sector, but when it counts down to zero, the sector simply ends, and you don't lose anything... if, however, you make your target before the time runs out, you get a bonus for the time you left over. I think Sega settled for a simpler round structure for their home versions, which got further simplified on the 2600 version. Sadly, there's a portion of luck involved in this game too. The collision detection doesn't seem to work too well... sometimes, especially in later rounds, you suddenly lose a ship although you didn't touch anything. Contrary to that, you sometimes get hit from behind by oncoming saucers or the mothership. However, sometimes the saucers fly right through you without harming you, but not always. I didn't manage to find out if there's a pattern to this. The farthest I came was Round 10, which actually appears as "ROUND 8C" in the game. I don't know if this is an emulator-related bug (I use Stella again).
-
OK, I managed to improve my high score again by doing an additional trick I didn't mention yet... this trick is giving up rounds that are pretty hopeless instead of hoping to be able to finish them, and by doing so, scoring some more points on the timer bonus. I figured if I only have 1 full bar left and 3000-4000 units on the timer, there's only a slim chance this bar will turn into a bonus bar, so I'll better end the round by shooting the last bar "alive". A similar thing happens if there are many closed bars, but you can reach only few of them, so the others are useless if they turn to bonus bars because you can't shoot them. In the game where this high-score happened, I lost my last two lives consecutively, but scoring an additional 5000-7000 points on each of them through the timer bonus. Thus my new high score of 49560.
-
OK, here's some feedback. Basically, the "eat something and get bigger" game genre is already covered by "Go Fish!" on the Atari 2600. But your game offers some interesting twists on it. Here are some suggestions to make it even better: 1. Introduce more player sizes. Right now, you start out as a 4-pixel ball, which grows to 8 pixels, but after that, you immediately go up to 16, and then to 32 bytes. What if you put the double-size sprite down to the 4-pixel version again, which grows gradually, and the same with the quadruple-size sprite? 2. Right now, the game seems to be "strictly timed", that is, there's no way to extend the time. Here's my suggestion how to improve this: - Make the player consume "energy". The bigger the ball gets, the more energy it consumes. Let's say it consumes 1 energy point per second in its smallest size, and that goes up by one point per second with each growth. The objects you eat give you back energy points, depending on their size, let's say 1 point for the dot, 2 points for the roll (or whatever it is), and 3 points for the square. This way you could play the longer the quicker you make it to gobble up relevant objects.
-
One thing that could be done is to write a compiler/linker that could compile SmartBasic source code, but even that wouldn't work because of the special graphic modes available on the Adam computer (which combine weird pixel displays with 4 lines of text at the bottom of the screen) that are not natively supported by the ColecoVision graphic chip. I don't understand that... if the Adam essentially has the same graphics chip as the Colecovision, how can there be graphics modes on the Adam not supported by the Colecovision? (How do these graphics modes work?)
-
Um... OK. Right now, the triangle does nothing. What it actually should do is to deflect the ball when it's hit by it. But how the deflection works should depend on which side of the triangle gets hit... let's assume that X is the horizontal motion (up / down), and Y is the vertical motion (left / right). Then, when the ball hits the lower side of the triangle: Xnew = -Xold; Ynew = Yold When it hits the upper left side: Xnew = -Yold; Ynew = -Xold When it hits the upper right side: Xnew = Yold; Ynew = Xold I hope that was clear enough... Actually, the square the player controls reminds me of the player sprite in "Centipede". How if you could earn points by hitting the playfield objects with the circle, which would disappear, and new objects would appear at the same time?
-
What have you actually PLAYED? Weekly Top Ten for 2009
Kurt_Woloch replied to cvga's topic in Atari 2600
OK, here are my times for the past week. Sorry if I'm a bit late again... Ram it: 518' (in 4 sessions) Jack and the beanstalk: 36' Mountain king: 15' RollUp: 5' Squared away: 1' Knight rider 2600: 1' Fonzie: 1' All games played on an emulated 2600 in Stella. -
I was always interested in the inner workings of computers. I already programmed the C-64 in assembly language back in 1985, and I drew up mock-up screenshots of different games. For instance, I drew up a mockup screenshot of the non-existing Atari 2600 version of "Penguin Wars" and other games back in the 1980's. Sadly, I didn't know about some of the 2600's limitations back then. For instance, the "Marble Madness" mockup screenshot implied that you could do a non-symmetrical background in 4 colors in a resolution of 40x96 on the Atari 2600. The mockup of "Penguin Wars" looks a bit more doable... Of course, when the Internet came up, and with it accurate information about the Atari 2600's inner workings back in 1998, I absorbed it quickly. And since I already knew 6502 assembly from the C-64, I decided to try something in this direction too.
-
Let the circle jump around the screen (physics similar to how the square moves, or similar to how the bubbles in "Pang" move). The circle should be deflected by your player (similar to "Reactor") and by the triangle. The way it is deflected depends on which side of which object it deflects from (similar to Billard or to "Jinks" on the Amiga). Every time it touches the ground, you lose 2 points... if it touches the ceiling, you lose 1 point. If it touches the side walls, however, you gain 1 point.
-
Yeah, there's a mock-up screenshot from a CES press kit that confirms this. I'd like to see this mock-up screenshot... I wonder how close it comes to the actual Squish'em 2600 (homebrew) version that has been released.
-
Yeah, I think if there was a bit less randomness involved, the game could be definitely more fun. So, I'd... - show the bonus bars in fixed intervals rather than in random ones - do some kind of fixed determination of the growth rate of the bars - such as each second 5 randomly chosen bars will grow by one block each - award extra lives every 10000 points
-
OK, I managed to improve my score now to... 42830. By now I've got a pretty good strategy of playing the game, although it's a bit too much based on luck to my tastes... First, I always try to kill all the bars that haven't grown yet (so they only need 2 shots each), and out of those, I first kill those on one side, and then those on the other one. This decreases the chance that I get caught by a line which grew to full length from both sides, forming a barrier. Then, when a bar is near the middle, I try to get it back somewhat. The highest priority, however, is getting all the bonus bars, since they give additional time. And actually, the higher the timer is, the slower the bars grow! So if I manage to get the timer above 5000, the growing action will slow down considerably, and I have a much bigger chance of shooting back all the growing bars before they hit the middle. Now comes the luck factor... sometimes, on the same round, the bars grow slower, and sometimes they grow faster. Also, sometimes the bonus bars come out very often, and sometimes they don't come out at all. This way, you can lose even the first round if the bars grow very fast, and you get no bonus bars, so you don't manage to clear the round before the timer runs out. I'll usually reset the game if that happens to me in the first round. But generally, with each round, not only the bars grow faster, but also the bonus bars come out more often, even if they don't last for that long, but that's fine if you still can catch most of them. This way, on later rounds, you can actually push up the timer up to 9900, which is impossible on the lower rounds where the bonus bars just don't come up often enough. This also means that if you screw up on a lower round so that a bar has hit the middle, you don't have a high chance of still winning the round, since for still winning the round you'd need every bar that has hit the middle turn to bonus bars one after another (unless the game accidentally turns an already fully grown bar to a not full one, which also happens from time to time). However, the chance for that to happen increases with every round because the bonus bars come out more often, and you also accumulate more time to hit the last bars as bonus bars. But alas, so increases the chance you get into that situation, and also the chance you get into a blockage. So, if the bars start to grow so fast you can't kill them all before they reach the middle, your priority should be to prevent a blockage by holding back those bars whose other side is already fully grown. If you mess up and get shut out of a portion of the screen, you won't be able to shoot the bars in that region even if they turn to bonus bars, because you can't reach them. So far for my tips and experiences...
-
That's actually wrong... your score doesn't increase by doing that, but the TIMER does, so you'll actually get extra time, which turns into points if you don't use it up. Easily... actually the game keeps track of your high score and shows it now and then while in demo mode, as you can see on my screenshot: Of course my entry is the shown high score of 25300.
-
Sorry, I'm a bit late... meant to post my score yesterday evening, but forgot about it. Here's my best... 26875. I also didn't manage to get much into Level 3.
-
OK... here we have an area of 20x34 blocks... and only colored in 1 color, so we only need 680 bits, which would be 85 bytes... looks more doable to me, except for the digits on bottom... I don't think it's possible to put 3 digits next to each other, and another 4 on the same scanline. Maybe if you could use 3-pixel wide digits, it might work. And then there's the question how you're going to do the green line that marks the line the player has just drawn...
-
OK... I, too, think it's a bit pessimistic to call it "the end of everything". At least in the thread about Jack and the beanstalk, I didn't have the impression that people aren't liking your game. I think they seemd to like it very much, at least most of the people on the thread said so. And even though it's unfinished, it already gets a lot of play as you can see in this thread: http://www.atariage.com/forums/index.php?s...=133276&hl= Ultimately, I think, it depends on if it's fun FOR YOU to go on with this project. I know I'm starting several projects only to drop them a short time after since they turn out not to be as much fun as I thought they'd be... or they turn out to be much more time consuming than I thought they'd be. An example for that would be this one: http://www.atariage.com/forums/index.php?s...=113751&hl= ... a project I started back in 1998, then dropped it, then continued to work on it a bit in 2007, then dropped it again. When I started on that project, I just thought it would be cool to do something like that again, but after a while I got tired of constantly debugging and testing code, so I started to do something else. But I never called the project "cancelled"... maybe it will be finished someday, but maybe it won't. Anyway, about that "crappy" quality let me just say I produced many of those "crappy" games back in 1983 on my TI-99 in XBASIC. However, there weren't intended to be released to the public, so many of them just sit there unfinished, which means you can play them for a while, but if you reach a certain level, the program stops with an error message because that level isn't programmed yet. Compared to that, "Jack and the beanstalk" looks "finished" in the respect that the loop is closed... there's no unexpected ending of the game (it ends either if you've finished it or lost all your lives), and as such it's finished in a way that I'd consider each of the last 10 versions you put out "releaseable", meaning they could be released that way if you decide not to go on with the project. Hey, there may be a few bugs in there, but there are also bugs in other commercially released Atari 2600 games. And about you planning to commit suicide... I also planned that about a year ago, but didn't do it in the end. I understand that you probably have got problems in your life which make you think you'd rather be dead. I also understand that many people rather don't want to go into this topic, but if you need someone to talk with about this, I'm here to help. You can write me a PM if you want, and then we can continue talk in MSN Messenger or in a different chat or something like that, or via PM's or mails. With greetings from Austria Kurt
-
Uhm... yes. The problem about this mockup is that to store that kind of playfield, you'd need more RAM than the 2600 can provide, although the resolution is already considerably reduced compared to the arcade version. Let's see... We've got 40 horizontal "blocks" of playfield (each of which is 4 scanlines high in that mockup) and 30 vertical ones. And you have 2 possible colors in which the playfield can be filled plus a third color which denotes the lines laid down by the player. So that's 2 bits per block, which actually corresponds nicely to the 4 bytes of playfield you have to fill in each line. So, you'd need at least 30x40x2 bits, that is 2400 bits or 300 bytes to store the playfield. Unfortunately, the 2600 only has got 128 bytes of RAM, so this mockup isn't possible unless you put at least 256 bytes of additional RAM into the cartridge.
-
What have you actually PLAYED? Weekly Top Ten for 2009
Kurt_Woloch replied to cvga's topic in Atari 2600
Yes, we had that game earlier in the HSC. As far as I remember, the programmer said in an interview that the version out there is the exact version "as finished by him". The problem was that Activision didn't want to release it this way because at that time they wanted to do more complex games (8k) and Kaboober only was a 4k game. The programmer still considered it "finished" and refused to expand it into a more complex 8k game. -
What have you actually PLAYED? Weekly Top Ten for 2009
Kurt_Woloch replied to cvga's topic in Atari 2600
OK, here are my times for the rest of the week... Toyshop Trouble: 157 minutes in 4 sessions Reindeer rescue: 8 minutes Jack and the beanstalk: 79 minutes in 5 sessions (which included testing a version I modified in order to help the atari2600land, the programmer, with the scoring for levels 2 and 4) Total gaming time: 244 minutes (61 minutes per day), all played on an emulated Atari 2600 through Stella. -
2600 idea - Jack and the Beanstalk
Kurt_Woloch replied to atari2600land's topic in Homebrew Discussion
OK, I think I can help you out... I introduced the variable m in level 2, which keeps track of the maximum/minimum screen reached. The initialization code changes as follows: s=0 : v=0 : m=a (m = a has been added, this sets m to the entering screen at the beginning) The lines surrounding the label level_2_screens run as follows (line p=160 comes before level_2_screens, l=160 has been moved here): p=160 level_2_screens if player1y=88 && u=0 && a>m then statusbarlength=244 : m=a : l=160 : p=160 if player1y=8 && u=2 && a<m then statusbarlength=244 : m=a : l=160 : p=160 (The line p=160 after those lines should be removed since it has been moved before level_2_screens) This additionally checks if the player has reached a new screen before refilling the status bar. The scoring lines of level 2 have been changed as follows: if player1y<5 && u=0 && a=m then score=score+p if player1y>88 && u=2 && a=m then score=score+p (note the additional condition a=m here, which compares a to the maximum/minimum screen) This checks if the player has completed the last screen he has reached (if not, he's gone back to a previous one, thus the score shouldn't be added) The lines that lead back to level_2_screens now lack the statement "l=160" which has been moved to the lines immediately following level_2_screens, thus they run: if player1y<5 then player1y=88 : f{0}=0 : player0y=0 : player0x=0 : a=a+1 : goto level_2_screens and: if player1y>88 && a>1 then player1y=8 : a=a-1 : f{0}=0 : player0y=0 : player0x=0 : goto level_2_screens This prevents the status bar from changing if the score doesn't get awarded. These changes cost exactly... 40 bytes (but optimizations are probably possible). -
2600 idea - Jack and the Beanstalk
Kurt_Woloch replied to atari2600land's topic in Homebrew Discussion
OK, I think I found some more bugs: 1. In Level 3, when the gate closes at the beginning which you have to open, it doesn't close completely, but leaves a small gap. 2. In Level 4, there's still a little glitch between, I think the 4th and the 5th screen from the bottom, where the beanstalk reaches a bit more to the right in the upper screen than it does in the lower one, so if you get to the rightmost end of the beanstalk and try to go down, that rapid screen changing thing happens again. 3. If you play variation 2, the 10 screens are not in order, rather it shows the first screen again and again (and I think both the positions of the troll and Jack update multiple times between each showing of it), and also doesn't end the level after the screen has been completed 10 times. That's all for now, though I'm not sure if I found all the bugs... there may be more if you try to really play through varations 2-4, which I didn't do. By the way, I think some scoring mode would be nice. Maybe a good idea would be some "bonus", where, say, you get a time of one minute for each screen, and at the end of each screen, the remaining time gets added as points. Or the time gets increased by, say, 30 seconds for each screen made. This would be the scoring for Level 1 (I'd suggest 10 points per second left over). Then, of course, you'd award a bonus for completing Level 1. Then, at level 2, you'd do something similar, but here you'd have to keep track of the highest / lowest screen that has been completed so that if the player goes back, the timer doesn't reset, but only scores again when the player has reached a new screen it wasn't on before. Then, of course, another bonus for completing level 2. For level 3, I'd put in a general timer, which gets increased by some amount for collecting each of the 2 items you have to collect, and at the end again gets accumulated as points, but I'd give points for the collected items too, and of course, another end-of-level bonus. Level 4 would work the same as Level 2 scoring wise. Just a suggestion... otherwise we'll never have the opportunity of playing Jack and the Beanstalk in the High-Score competition. :-) Here are some examples for the point values: Level 1: Starting time 1:00 for each screen, 10 points for each second left over from that at the end of each screen, Level-End bonus of 1000 points Level 2: Starting time 0:30 for each screen, 10 points for each second left over from that at the end of for each new completed screen, Level-End bonus of 1500 points Level 3: Starting time of 3:00, 500 points and 1:00 increase for the harp, 1000 points and 1:00 time increase for the goose, 10 points for each second left over at the end of the level, Level-End bonus of 2000 points Level 4: Starting time 0:20 (!) for each screen, 20 points for each second left over from that at the end of for each new completed screen, Game completion bonus of 3000 points -
What have you actually PLAYED this week? New Top Ten
Kurt_Woloch replied to cvga's topic in Atari 2600
OK, here are my gaming times for Dec. 29th-31th, 2008: Toyshop Trouble: 135 minutes (in 3 sessions - yeah, again) Reindeer Rescue: 25 (will probably play some more in the next days) Jack and the beanstalk: 23 minutes (in 2 sessions with 2 different versions) Radar Lock: 9 minutes (tried once again, but couldn't make much more sense out of it) All games are Atari 2600 games emulated on Stella.
