potatohead

Not sure where to put this, so I'm going to post it here. I'm running into storage limits. (What's new right?) Anyway, I'm at a point where I need to either giveup some gameplay (on the ooze game), or really start doing some heavy bit lifting to pack everything into the RAM. It looks to me like we are going to run into variable storage limits first, time constraints second and ROM storage space third. Long winded feature request: Can we get 4 bit variables? --Or maybe just the ability to sub-divide the 8bit vars we have into two smaller ones? This sounds like a lot of work, but I think the feature will be worth it based on how the overall system constraints are falling into place. something like: dim al = 5 ah = 3 (For one 5 bit var and one octal one, with both being parts of the 8 bit letter a variable? What do you all think? Too much to ask? Maybe just get better at bit mangling? (Which is what I am about to start doing.)

yep. The problem is that arrays are not allowed in the score right now. I suggest supercat's suggestion in the Solar Plexus thread to get around BCD - it was pretty nifty, I think. Looks like you found another bug - I think score addition only works with a-z. I should change this. 900713[/snapback] I'll give it a look. --Thanks.

Are hex values allowed in the data statements? Just tried this a = some number data scoretab $10,$20,$50,$48,$37 end score = score + scoretab[a] Thought I might get around the whole BCD thing with a lookup table. Didn't add to score. Maybe it's the array index in the score function? Tried running it through a variable data scoretab $10,$20,$50,$48,$37 end temp3 = scoretab[y] score = score + temp3 Got this interesting error message: test.asm (1269): error: Value in 'adc #$683' must be <$100.

Was thinking about some goofy music to play during a title screen. This might be just the trick! Personally, I am looking at all the program listings right now. There are lots of ways to do things! Useful for sure.

You can do it without assembly (technically it is an asm command, but it is also a bB command). Take a look at the NUSIZ command in the bB help file (look under TIA registers). Basically it just mirrors the player. The value I entered for the NUSIZ command in my source is different from what you see in the bB help, but it works the same way (just used to seeing it like that in the asm tutorials I used to look at when I was doing hacks). Cool game btw! Perhaps make your ship slowly melt when you lose? (I know the feeling about not knowing what to do - my game has changed several times. Source just keeps getting uglier ). 900561[/snapback] I just realized the missiles are working now. That's damn cool and opens up some very interesting game options. I really meant you had more than two sprites on screen, not more than two player sprites. Thanks for posting your game listing, I appreciate it.

Nice game! I enjoyed it. I noticed you have three sprites? How did you do that? Nevermind, I see at least one missile is working !?! (Cool!) Man, that changes a lot of stuff where my game is concerned!

Are you reading the paddle, or just using a joystick for now? (Wondering because I'm thinking about a paddle option for my game.)

Just confirmed the bit comparison operators appear to work backward. Or, I need a whack with the clue stick! This line: if s(4) then s(4) = 0 : goto shipslow Should set s(4) to 0, if it is currently a 1. (Toggle) However, it seems to do just the opposite. if !s(4) then s(4) = 0 : goto shipslow Works as I think it should.

Cool. Hope there is a fix in the works. This is a great forum otherwise.

Good comments folks. --Thanks for the game ideas. The creative juices are flowing now. Exactly what I was looking for. Appreciated. The double wide ooze looks good, but introduces a bug involving collisions. Once I get that nailed, I'll start to work on some of the ideas. Lots to work with. Some of what I'm thinking requires another sprite. Anyone think sharing the bullet with that sprite will be a big detraction from the visuals overall. (If it's a bright color?) I played the fighter jet game. How were the multiple players done? Was some assembly required? For those looking for interesting sounds, use your existing game loops and counters to control and shape the sound. --That's what I did.

Ok, I finally got a handle on the various issues with the ooze game, and the alpha 2 compiler issues. If you all would not mind, give this a playtest. I'm looking for bugs like the unshootable pixel present in the last version. There is no score yet... (Sorry) But, there is cool sounds! What I am really after is gameplay suggestions. How to end the game, scoring, etc??? Edit: If you download this, grab the one at the bottom of the thread. Much more playable. ooze_v2.zipooze_v2_src.zip

Have you tried using a different name for the label to see if that works? 900283[/snapback] Take the colon off the label and you should be golden. eg: topofloop a = a + 1 player0x = a if a > 5 then goto topofloop outofloop off and doing something else. The forum nukes the indent, so the rule is a label needs to occupy the first character of a line, with statements indented. (using - for a space) label -statement -statement anothelable -statement -if something then goto label

Ahh, they don't work now. That explains my current trouble.

Ok that tells me what I want to know. I'm doing another redesign because I didn't have much luck storing ooze positions as nibbles in the vars. Either I'm just not groking the bit operations (likely) , or they have some problems. (Somewhat likely) Had some luck with using bits as flags, that will save me enough for now. An inline asm for clearing the playfield works great and that's the route I chose. I no longer need the pfline command and pfpixel can be managed to avoid running out of time. Thanks for the info guys, that tells me enough about the scale of things that I can make good decisions going forward.

Anyone have a rough guess at commands / cycles? Just ran into a timing constraint on the ooze game. To avoid some of the little timing bugs in the last version, I wanted to clear the playfield and draw a fresh set of ooze each frame. This takes too long. Storing ooze lengths two per variable does not help this any. Ahhh... the challenge of the 2600 is beginning to show. FYI, more than a few pfgraphics commands will consume all the time you have. So will a lot of variable shuffling to squeeze more value out of each bit. So, going back to the old approach to see if that can be done with the additional overhead of packing the data into each nibble of the variables.

yes, I know about this bug. It's been fixed in the current build. But for now, a workaround is to change a gosub to inline asm, as: gosub subroutine would become: asm jsr subroutine end 899933[/snapback] This didn't work for me. I'm going to go ahead and use the goto for the time being.

I foud the source of this bug - it's in the 2600basic.asm file. Since it's here, you can patch the file without needing to modify C source or anything... Just change this snippet of code from this: pixeloff lda playfield,y eor #$ff and setbyte,x sta playfield,y rts To this: pixeloff lda setbyte,x eor #$ff and playfield,y sta playfield,y rts Clearly a very subtle yet important difference. Is it "max nested gosubs exceeded"? If so, it's a known bug with a workaround... Check the bug report thread. 899931[/snapback] i'll do the patch. The gosubs are not nested in this case at all. I'll double check that. 899959[/snapback] Well, that didn't quite fix things. Instead of a set of left over bars, I get random pixels now. Tried both horizontal and vertical lines. It seems only the pixel command works as it should. I'm going to use that for now as time does not matter at that point in the game. I'll also try the inline asm function again. Been itching to try that. I want the finished game to be completed with the basic only (just to push the limits). However, I do want to toy with assembler too. So it's all good.

I foud the source of this bug - it's in the 2600basic.asm file. Since it's here, you can patch the file without needing to modify C source or anything... Just change this snippet of code from this: pixeloff lda playfield,y eor #$ff and setbyte,x sta playfield,y rts To this: pixeloff lda setbyte,x eor #$ff and playfield,y sta playfield,y rts Clearly a very subtle yet important difference. Is it "max nested gosubs exceeded"? If so, it's a known bug with a workaround... Check the bug report thread. 899931[/snapback] i'll do the patch. The gosubs are not nested in this case at all. I'll double check that.

Renaming is not quite correct. When you make your own variable name, it points back to the included letter variables. That is what makes it an alias and not a rename, which would eliminate the original variable name from the environment. Of course, it's your help file --do what you want to

Found bugs in the pfhline & vline code. clplay for n = 0 to 32 pfvline n 0 10 on next for n = 0 to 32 pfvline n 0 10 off next return The above should clear the playfield, but leaves stripes behind. I did both of them because I also think turning a pixel off on a line by line basis does not work correctly each time either. Also, I'm having trouble with some gosubs. I know this will be long, but check out this next listing: rem smartbranching on reset gosub title rem Init Game code rem rem x, w, v = ship and bullet position variables rem rem rem COLUP0 = 120 : COLUP1 = 47 x = 50 : w = 60 : v = 60 rem s = 0 rem s = game status flags rem s(0) = bullet launched goto clplay gameloop COLUPF = 43 : COLUP0 = 120 : scorecolor = 10 : COLUP1 = 47 PF0 = 140 player1x = w : player1y = v : player0x = x : player0y = 89 player0: %01000010 %11100111 %11111111 %01111110 %00111100 %00011000 %00011000 %00011000 end player1: %00011000 %00010000 %00001000 %00010000 %00001000 end drawscreen rem GameCode gosub checkswitches gosub moveship gosub moveshot goto gameloop rem Subroutines Live below Here moveship if joy0left then x = x - 1 if joy0right then x = x + 1 if x < 35 then x = 35 if x > 147 then x = 147 return moveshot if !s(0) then goto fire if joy0fire then s(0) = 1 : goto fire w = x : v = 89 - 8 goto shotdone rem bit operators are working backward, change this code when it gets rem fixed. Symptom will be always shooting. fire v = v - 4 if v < 3 then s(0) = 0 : v = 89 - 8 : w = x shotdone return checkswitches if switchreset then goto reset return title COLUPF = 45 : a = 0 : b = 0 titleloop COLUPF = b drawscreen if joy0fire then goto titleexit if switchreset then goto reset gosub drawdot goto titleloop data titlemap 0,0,0,0,1,1,0,0,0,1,1,0,0,1,1,1,1,0,1,1,1,1,0,0,0,0,0,0,0,0,0,0 0,0,0,1,0,0,1,0,1,0,0,1,0,0,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0 0,0,0,1,0,0,1,0,1,0,0,1,0,0,1,0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0 0,0,0,1,0,0,1,0,1,0,0,1,0,1,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0 0,0,0,0,1,1,0,0,0,1,1,0,0,1,1,1,1,0,1,1,1,1,0,1,0,1,0,1,0,0,0,0 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0,0,0,1,1,1,0,1,0,1,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0,0,0,1,1,1,1,0,1,0,1,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0 end drawdot if b > 240 then b = 0 : x = 0 : a = 0 if titlemap[b] = 1 then d = a + 2 : pfpixel x d flip x = x + 1 if x > 32 then a = a + 1 : x = 0 b = b + 1 return titleexit for y = 0 to 9 pfhline 0 y 31 off next return clplay for n = 0 to 32 pfvline n 0 10 on next for n = 0 to 32 pfvline n 0 10 off next goto gameloop If you replace the goto clplay, near the top, with gosub clplay and also change the goto gameloop at the bottom with a return, it won't compile, and it should. Seems to get confused on the labels. Does not matter where you put the code either. I remember this problem with 0.1 too. Happened after I tried to insert a title screen. Thought this time around, I would go ahead and build the screen first, then try and write the game inbetween the two drawscreen calls. Maybe this has nothing to do with it.

Anyone work with the bit operators yet? They don't seem to be working correctly for me. Since we had the math lib issue on UNIXes, maybe it's a platform thing. Actually, they seem to work backward. s(0) = 0 if s(0) then goto itequals1 This actually branches. Using if !s(0) works when it shouldn't.

I think Lex should be assumed to be on the system. Just call out the version you are using and anyone wanting to run this can just do what it takes to get Lex on their particular box. With some things, like gfx and sound libs, this can be a pain in the arse. Lex is pretty standard and tame, IMHO. Lets try it with my box and the SGI for starters to see.

The errors are cryptic in part because the error routine was written to echo the line number, but the line numbers aren't there And the preprocessor/tokenizer is buggy. I've got lex working in the current build now, and the "line" that is reported is now the line in the file, not the linenumber, so I hope these things will go away (and the changes don't create new problems.) 899422[/snapback] That all sounds like good stuff! Don't take my posts the wrong way. I figured it was better to post what I learned for the next guy, that's all. Now that I have an editor configured the right way, things are much better. You don't really notice how and where you put spaces into things for the heck of it. My style happened to be a particularly bad match for the current state of Batari Basic. Just used the data statements for drawing title screen and working on music. ---Very nice implementation. These are going to be handy.

The above appears to mean a line has a space after the last valid character. (goes looking for an editor that will display whitespace) 899413[/snapback] Got one. Kedit (on Linux) allows you to set the background color of a character seperate from the overall editor window background. ---Perfect! I've got it a nice Atari blue on white now.

The above appears to mean a line has a space after the last valid character. (goes looking for an editor that will display whitespace)