R. Jones

so i downloaded the batari program, and am a couple of minutes into it. i am trying to add a sprite for my player. i want to do "shark! shark!". is it ok to pull one from the internet in terms of copywrites and such? also, do you know of a good sprite site? and can i use an intellivision sprite for vcs? thanks! In the US? No. http://www.copyright.gov/title17/ http://www.templetons.com/brad/copymyths.html

Just remember that Solar Plexus was made when batari Basic had fewer features. I think that's the thing though. It certainly doesn't offend me that Solar Plexus was made. I'm sure it was an interesting experience. (Knowing that it was made so early, kinda makes me curious about the early builds of bB.) On the other hand, I don't have any desire to really go back and play the game. (or of course buy it) I feel like if the creator (Jess? the author of the game, not batari) had to write the engine, he wouldn't have been able to settle with the game being as simple as it is. Indeed. Here's to shooting for the stars, landing on the moon, and trying to find a way to appreciate our limited, but impressive, cleverness.

Jerry Lawson is a very interesting guy. Long interview with him: http://www.vintagecomputing.com/index.php/archives/545 I'd be interested to read any articles about Videosoft. Why so many projects and no releases? Who was a part of it? How'd start or end? Maybe when they release the ROMs some more info? Maybe?

Yes. I have a theory on this. I think bB has made possible the worst Atari games. Before I traveled with the carnival, I experimented with making games on the 2600. Now that I'm living in a more stable place, my sweet gf likes to have tv. I've been using the Atari to run simple apps for EMDR, meditation, and some imagination experiments. The Atari 2600 is a very raw, primal, abstract, larval, difficult, simple, game system. Before you can start playing around with anything, you have write the display. Each instruction is written in assembly; they are physical locations, actual spaces for electrons to flow. There isn't that abstraction where you work with ideas like "triangles" and "values". Assembler programmers on the 2600 are forced to acquire a certain amount of respect for the machine. Home-brewers are programming for the love of it. No one is going to spend weeks writing the display, and the physics engine, and the levels, and the sound and testing it, and then finish up their loose ends with an afternoon of loveless work. That's exactly what a lot of bB games are tho. Batari (Fred Quimby) has created several excellent kernels, and put a lot cleverness, love, knowledge, and hardwork into the engines that drive bB. The games that he makes with it show all that (try Gingerbread Man if you're doubting bB). Some programmers scratch out a few hours of uninformed, unpassionate, carless, and boring code on top of batari's engines, and call that their game. I'm not knocking bB. I'm not knocking all bB games; jrock, Atarius Maximus, RT, and others have made interesting software with it. I'm hesitant to criticize the people that are just exploring; i like exploration. NERDS I'm quite willing to criticize. Solar Plexus, . . . meh.

Neat beginning. Looking forward to seeing more. Changing the player color midline to create the submersion immersion looks quite nice. I think having crooked water is a somewhat minor tradeoff, if the levels are clever. (The playfield has to be using up a bit of your of your time.

Yeah. I did the free trial and decided to cancel. They didn't actually get my account canceled, and I had Panzer Dragoon Orta on my queue; so three months went by, until I noticed that I was still being billed. Their customer service folks helpfully offered to cancel my membership but had to transfer me to someone to get a refund who had to transfer me to someone who had to . . . And when my next statement came in, I had only been refunded for 2 of the 3 months and had to go through the process all over. I don't know how much it's changed, but that kinda turned me off to it.

Hi, You're going to get a lot of suggestions for languages and platforms with a thread like this, so I won't add another. Some things I wish people would have told me starting out: 1. There are not "bad" languages, especially to start with. Java, C, C++, Basic, Lisp, Python, Assembler, Forth, whatever. You'll hear people really dig one language or really hate one language, but if you've never programmed before, there are universal things that you'll be able to learn from any language. I believe Random Terrain suggested some kind editor, language, compiler, and platform rolled into one. This is far from anything I'd be interested in (I prefer everything separated and very little abstraction), but even being the complete opposite of what I think is a good environment to write in, you will learn things with it that will help you even if you go on to C, Assembler, Lisp, Python, etc. 2. Read books. Asking questions is good (ask many questions), but you won't find the kind of resources in conversation you would get from a book. Check at libraries if you pick an older platform/language (6502/assembler.) The libraries around here all have books for 6502 computers (commodore 64, apple II, atari 400) from 1980. If you decide on a language and platform that doesn't have books, print out whatever resources you can get for it online; put them in a binder. 3. Use simple mechanics for your first projects. If you like to make music, writings, and drawings try to pick a type of game that maximizes that. If you try something that involves a lot physics, ai, etc., you're going to be frustrated. Adventure games (you can be creative with the mechanics, I'm just using something common; everyone's played Zelda) have a litte AI, some collisions detection, inventory management, but it's mostly the pixel art, the music, the level design. Good luck, -Robert Jones

I am looking at it now - the code you posted above helped - (thanks!) I was looking for ENAMx - what the kernel is doing there is pointing the stack to the location of the ball and missile registers and enabling them that way. Quite welcome. Glad to see it helped. Yeah, under the label RepoKernel. It uses the same line checking routines for the dots. I think the routine is four scanlines long and it runs every time a Player graphic is repositioned. The second routine is set up so that calls to HMOVE are executed at the edge of the screen. If they go off at a different time, you'll get an Activision comb on the left side of the screen.

Hi, I haven't. I downloaded the source to try, but most of it was over my head and uncommented (or strange comments), so I thought it wouldn't be much fun. I have advice though (the doing it part seemed like it may be unfun to me.) Stella's debugger says that you're already using 75 cycles per line. You need to cut something out or optimize something in the MS Kernel to have room to change the playfield colour. There are several places in the code that look like they're for deciding which dot (missile1,missile2, or ball) to draw for a particular line. I don't see any references to ENAM, so all the dots are drawn with the ball or a player in the MS Kernel? (That kind of makes sense for why all dots are only a line high.) They take about 18 cycles each time and you can cut them out since you're not using the dots. (You could also cut out where the dots are drawn, but I didn't look long enough to see) cpy bally php ;+6 39 VDEL ball cpy missile1y php ;+6 71 cpy missile0y php ;+6 1 The easiest way to do a coloured playfield would be to make a big table (192 bytes long) and just read a value from it into COLUPF every line. ;Get a value from a table and store as the playfield colour. lda NameofYourTable, y ;+4, The y register is the scanline counter is MS Kernel. sta COLUPF ;+3, Store the value in COLUPF. Don't know if any of that helped. If you know anything about assembler you'll probably be able to figure the code out better than me. - Robert

Thank you, Mike. I kind of understood what I was doing wrong, but the ways I set about fixing it kept breaking things. You have no idea how much that helped. I'm going to look more at your other suggestions, too. My attention is just focused on the display loop(s) at the moment. Here's the replacement loop with your advice: ScanLoop STA WSYNC CenterHoleDraw ; This draws a hole in the center line. Must be drawn early, so not to tear. tya ;scanline to accumulator, 2 sbc CenterHoleYPos ;the elevation of the center hole, 3 adc #30 ;the height of the center hole, 2 bcs .DrawCenterHole ; draw it?,2(3) lda #%10000000 ;The center line is draw, 5 sta PF2 ; 3 sec ; 2 bcs .DontCenterDrawHole ;And the hole rountine is skipped, 3 .DrawCenterHole ; Draw the center hole lda #000000 ; 5 sta PF2 ; 3 nop;2 nop;2 .DontCenterDrawHole EnemyDraw ;The antagonist is drawn from GRP1. tya ; 2 sbc EnemyYPos ; 3 adc #EnemyHeight ; 2 tax bcs .DrawEnemy ; 2(3) nop ; 2 nop ; 2 sec ; 2 bcs .DontDrawEnemy ; 3 .DrawEnemy lda BigHeadGraphic,x ; 5 sta GRP1 ; 3 .DontDrawEnemy PrizeDraw sec ; 2, The prize is drawn from GRP0. tya ; 2 sbc PrizeYPos ; 3 adc #PrizeHeight ; 2 tax bcs .DrawPrize ; 2(3) nop ; 2 nop ; 2 sec ; 2 bcs .DontDrawPrize ; 3 .DrawPrize lda GraphicPlaceHolder,x ; 5 sta GRP0 ; 3 lda ColourPlaceholder,x;5, The prize is multicolour. sta COLUP0; 3 .DontDrawPrize DEY BNE ScanLoop Thanks again, - Robert

I'm trying to use the sprite positioning routine from this thread: http://www.atariage.com/forums/index.php?showtopic=38020 I attached an example program that shows the problem. Whenever I begin pulling data from the table where the sprite data is kept, the table is treated like it extends full screen. I'm pretty sure that I'm misusing tables, so if there's some place that has good documentation on how to use them correctly that would help also. example.bin example.txt

I'd like to buy a Supercharger for the Atari 2600. I want to use it for homebrew software, so it doesn't matter what version or if it comes with games.

Espire, I really dig those techniques for drawing eyes. It gives your sprites a lot of life that's absent from most vcs pixel art.

Nah. Game data and graphics are stored in a similar way, so the game ran the routine for Zot display and the code (by accident) directed the atari to some random part of the game. EDIT: Nevermind, CPU already got it. Dang.

Nice progress, 2600land. I have a few suggestions: - It feels awkward to me, to use the difficulty switches to turn the timer on and off. I think it'd be more natural to have predefined modes that you could scroll through with the select switch like in the earlier games (gunfight, video olympics, combat.) - You said you were having trouble with an all black level. Have you tried a plain spiral? I think it a geometric level like that would work well without visual feedback. - Have you decided against multiplayer support? If so, was is it artistic choice, bB limitation, etc.?

Red, Blue, Green Red+Green=yellow It is complimentary? I'll add a demo to the original post. I can't attach it to this.

Since Adam Tierney's posts are full of dead images, there aren't many examples of good "game idea" threads. So I was thinking about trying to make sort of a prototypical game proposal thread. The idea is based off of a project I was considering doing, but realized that I don't enjoy the source material enough to go through with the entire game. So here's my rough draft. I thought I'd post this in a blog first, to get feedback on it. The thread will start with one post explaining what the thread is: Then I will post this second message into the thread, right behind the first: EDIT: I've added a demo that I made in bB, that demonstrates the idea.

I'm looking for a supercharger, so I can test games on real hardware. My 7800 will fry a supercharger, so I also need an Atari 2600 (and the power supply for it.)

I bought some paddles and a few games from them in December. They sent me an email saying they didn't have any loose copies of one game in my order (super football) in stock, but if I wanted they could add a boxed copy of it to my order before it shipped for an extra five dollars. My stuff came in about a week. All of it was in good condition. I think the paddles were probably cleaned by 4jays, because I didn't notice any jitter. That really surprised me; I had printed some stuff about cleaning paddles out already, expecting a lot of trouble. Two of my game were new, boxed. One of them was fine. The other had one corner somewhat smashed. The smash was pretty small though. I also got a couple of loose games which looked really nice. The loose games and the smashed game were Christmas gifts, but if you want I can post some pics of the other stuff. Also: Blue Sky Rangers (intellivision) reccomends them.

No, the very top of the "hidden" row of playfield pixels is visible just above the score, and Chris is counting on it being there to make some of the mazes work. This is a result of the "no_blank_lines" kernel option. But I suspect there are other places where he can optimize his use of variables. I'll take a look at the code tonight after work and see what can be optimized. Michael Shoot, you're right. If you are going to fix the ram, you should check and see if Chris has a commented source or a planning file or something. From the source file I looked at, it wasn't really clear what some of the RAM was being used for. The two obvious things when I looked at the code, though were the color variables and the movement byte. The sub control is currently handled with: 810 if joy0left then d=1 811 if joy0right then d=2 812 if joy0up then d=3 813 if joy0down then d=4 818 if joy0up && joy0right then d=9 819 if joy0down && joy0right then d=10 820 if joy0up && joy0left then d=11 821 if joy0down && joy0left then d=12 You could save half the "d" byte with something like if joy0left then d{0}=1 : d{1} = 0 if joy0right then d{1}=1 : d{0} = 0 if joy0up then d{2}=1 : d{3} = 0 if joy0down then d{3}=1 : d{2} = 0 The other thing I noticed was the b/w switch. Currently it's being handled like this: 44 if switchbw then c{0}=0 if !switchbw then c{0}=1 [ . . . ] 48 if c{0} then COLUP0=0 : e=128 : scorecolor=30 timer=timer+1 if timer=3 then timer=0 : g=g+2 if g=254 then g=2 49 if !c{0} then u=4 : e=8 : g=14 : scorecolor=0 It doesn't make sense to use variables for the colours here. The only color that really needs a variable is the title screen. Since that graphic isn't used in the rest of the game, the variable could be used for the title screen graphics and something else in game. Those two changes alone would free up four bytes. S is already open, so that's five completely open bytes of RAM for the main game. I'm sure there's more. You'll probably be able to come with better solutions than me. You seem to have a really good handle on bB and atari programming in general.

Nice. Yar. I took a look at your source. Your comments at the beginning say you only have one variable left right now. You'll probably have to optimize a lot to fit anything in after this octopus. One thing I noticed is you don't seem to be using the row 11 flags. Since your not scrolling, anything that could be done with flags (b&w switch, sub direction, etc.) could be done with single bit flags rather than whole variables and handled with the hidden row of pf pixels.

*bump* I just found this game. I love this. Everyone, please try this game. Demo was an understatement. It's like saying the sun is visible. Somebody (Al, Jarret) needs to round up all of the programmer's who have taken projects to the point of being interesting, and abandoned them, and make some sort of "demo" multicart. (I think Randy did this back in the day.) Stuff like Plops and John Harvery's PG2 shouldn't just be forgotten.

Warning: I'm about to post some long-winded rambles where I explain ideas I came up with while daydreaming on a defensive possession in basketball. Then I'm going to suggest that (other) people do significant amounts of work based on these 24 second thoughts. Read at your own risk. Bouncing objects demo: demoforsubexper.bin I made this demo of how to bounce a prize around the screen using hardware collision detection (it bounces off the actual graphics the atari is displaying, not some preprogrammed invisible maze coordinates.) It was mainly to see how feasible a suggestion I made for this game was. The idea is some prize determined by using bB's built in random number generator and the current level would pop out of the treasure chest and float around the maze. Higher the level: more likely to get a good prize. Getting the prize in timed mode, would add seconds to your score. (small prizes=a few seconds, big prizes=like ten seconds) At the end of the game, all of your left over seconds would be added up, and your deaths subtracted to get your final score. The demo uses a cherry graphic, from something else. The treasure could be stuff like: Evil sub: I made half of a demo to prove (to myself) that this idea worked. But I got halfway through and was satisified (I didn't set out to make half of a demo.) The idea is that on the untimed mode, horrible things would happen (no prizes) such as current, sea snakes, and most importantly an evil sub. The doppleganger sub would pop out of the treasure chest (I know. That doesn't make sense. I thought it would be more fun like that, though. Because you'd be forced to deal with the sub. He's like the minotaur.) He shoots a harmless sonar ping in whatever direction he's traveling: The ping travels twice as fast as the sub. Whenever it hits something (your sub or a wall) it bounces back to the evil sub. All the while a timer runs in the background. The game will check the timer to see if whatever it hit was close or far away. It will then put the info in the sub's memory. The sub's memory looks something like this: Wall | Subs 0000 | 0000 these will be one if the sub found a player ^>v< | ^>v< or wall in that direction, and zero if it's open Up: 00000000 these are the x and y coordinates Down: 00000000 where the subs sonar was used. Left: 00000000 the game will compare them to the sub's Right: 00000000 current x and y values to see if there X Value: 00000000 is still a wall in that direction. if Y Value: 00000000 it turns out that the sub has moved the game will change the direction to zero The evil sub randomly choose an open lane until his ping reveals the player sub. (also, he should probably go about half as fast the player's sub.) When the evil sub finds the protagonist, he will go in whatever direction the protagonist is, and his speed will quadruple for a short period of time. Current: current.bas.bin This is totally not my original thought. (I'm ripping other people off.) But among the horrible things that happen to players for refusing to play timed mode is current. One is added to x or y every other (or if that's too hard, [which it probably is] every three frames, every four frames, etc.) frame. So hypothetically if the current runs left then: > go right slowly < go left fast v go down slowly drifting left ^ go up slowly drifting left Mike Rideout Octupus: I really like the idea of an octupus that blanks the screen out. Maybe instead of killing you the octupus just slows you down, but as long as the sub is in contact with the octofoe then the screen will be blank. Killing your sub for hitting the octupus seems sort of weird and artificial. It should be pretty easy to code too. if collision(submarine,octopus) then COLUBK=0 : COLUETC=0 Also, the octupus could be less random. Right now he feels completely random. Maybe something like whenever he changes directions, half of his changes will be one hundred percent random, and half will go straight at the sub. Darker colors: This is another idea i really like. At the start of the game, the walls/coral can be light green, yellow, orange. And progressively work their way to dark green and brown walls. The background could start out lighter too. As the game goes on, getting a deeper and deeper blue. Selling it in AA's store: Premature, I know, but it would be a shame to not have a blue cart version of this available. If AA doesn't have any blue carts when this is released, I'd be willing to front the money for like 50 cart shells for first fifty copies of the game. (If vgwiz is still making them. Their storefront is down right now. ????) (And if that doesn't make it prohibitively expensive. Forgot it was 8K. Nice Label, Manual, 8K, Blue Case, = $15, $18, $25, $28) EDIT: just saw the build where the octupus can go through walls. Nice. It still feels a little random, but he (the octupus) seems a lot more fierce and threatening (I had to use the pronoun he, because he's so fierce there was no doubt in my mind, that this octupus is anything other than manly man-octupus.)

I understand. Do what you can with what you've got. Thanks for the reply. That sounds cool. The reason I suggested alternating multiplayer is there could be about eight people playing. I'm not sure if you meant one go was harsh for my first multiplayer idea or my second. In the first suggestion for alternating multiplayer, even if a player didn't finish a maze, they'd still be playing in the next round. Each player would get one go at each maze. Then the scores would be shown for each player. That doesn't seem to harsh, so I think you were talking about the idea of a "race" mode. If you have eight people playing to elimination, I don't think it would really be that bad. It would go pretty quick, but it's like when you play basketball in the summer and you set the score low, because it's so hot. If it did go by too fast, you move it up to two or three lives for just a byt or two of RAM. Hmm . . . Brown enemies sound fine. I'm sort of confused about why its ping would have to be black. I was under the impression that your were using Player0: sub Player1: unused Missile0: unused (noblanklines takes away the option of missile0 right?) Missile1: Treasure Ball: unused I thought that meant you would have to use the ball for a ping. I didn't think that you would be able to have missiles and an enemy ping on screen at once. (because they would both need the ball) When I made the suggestion, I was thinking that the enemy sub would take you out the same way the walls do whenever you come into contact with it. You wouldn't have anyway to kill it, but since it's "vision" is so limited the player could outsmart or even trick the enemy sub to get around it. That's also why I said not to time it. A timer and an unkillable enemy would just be frustrating. Good luck, Robert Jones EDIT: nevermind

double post