Cybearg

February 3, 2013

the data statements go where ever you put them and the code

jumps around them.

there's a compiler optimization, noinlinedata, which I believe just

tells the compiler not to generate the jumps so you have to put

the data statements where code won't run in to them.

I meant in the context of memory. The 2600 and its cartridges have very limited space, which is why we only get 26 variables, each of which can hold a single byte. How do we also get as many 256-byte data sets as we want? Where is that information stored? It must go into some area of the RAM that isn't available for normal processes, eh?

February 3, 2013

Maybe it's just me, but this won't compile in bB. I get errors, such as a syntax error on line 35, column 37, three warnings including one for "the," (line 52, column 74) "rainbowdrawscreen," (line 27, column 7) and "asm" (line 38, column 1) and it gets an error while compiling.

I have version 1.0 (build 566) of bBasic and am using the most recent version of dasm.exe that I could find, which is from 4/10/2008 or so.

Also, making it go horizontally is an "exercise" in the same way that winning the Olympics is a "warm-up."

February 3, 2013

it'd help if you posted what you've got now so we

can see where you are.

is it secret?

Ah, no, it's no secret. I just didn't know of a need to spam with a ton of more code, that's all.

this is meant to be a more compact version

of what you posted before

untested etc.

After a bit of tweaking, this worked wonderfully! I changed it to render by pfpixel's color, rather than after each individual pfpixel. Once I get a kernel that will let me update mid-scanline, though, it'll probably be closer to your code.

Still, it saved me another 200 bytes or so! That brings me up to 1438 bytes (and two variables) to spare after implementing your suggestion along with some crazy crap I was doing to make things more efficient.

right

edit as many data statments as you want up to 256 bytes EACH

Where is this being stored, out of curiosity?

February 2, 2013

obviously this is untested but it compiles.

I may well have goofed something up.

I rewrote the collision code you posted to get rid of those

redundant if-then statements (and then stuck a couple of

my own in)
 if playerx1<50 || playerx1 > 117 then goto skip_collision_test
if playery1<9 || playery1 > 94 then goto skip_collision_test

for i = 0 to 14 step 2
if a[i] then collision_test
nexti
next

skip_collision_test
if player1x = 0 || player1y = 0 then goto 750
if player1x=156 || player1y = 140 then goto 750


collision_test
temp1 = playerx1-xtbl[i]&127
if temp1>3 then goto nexti
temp1 = playery1-ytbl[i]&127
if temp1>5 then goto nexti
if a[i]<>ballcolor then goto bad_hit

rem good_hit
a[i]=0

bad_hit


750

data xtbl
81, 00, 114, 00, 130, 00, 114, 00, 82, 00, 50, 00, 34, 00, 50
end

data ytbl
9, 00, 17, 00, 49, 00, 81, 00, 89, 00, 81, 00, 49, 00, 17
end
edit: goofed the datastaments up (now fixed I hope)

should probably interleave the x and y values but

this is just ment as illustration so I didn't bother to

obfuscate

Thanks much for this! It didn't quite work and I ended up varying a fair bit, but if you hadn't made the suggestion, I wouldn't have known to use a data group (or even what they were, really).

Now if only I could simplify my big lists of pfpixel coordinates with a data set. Is that possible? Such as pfpixel [temp1]?

Your suggestion cut my ROM size from about 170 bytes to 734 bytes. I'd love to do THAT again!

By the way, how many data sets am I allowed? Or is it just as many as I like, so long as they don't total over 256 bytes?

Thanks for all the information on the assembly and kernels, folks. I'll check it out, though I'll probably still need a lot of help writing that kernel. Still, things are getting better and better!

EDIT:

And after some more thinking and tweaking, I've cut things yet further, down to 1239 bytes to spare! And with an easier set-up for expansion, to boot, though that size efficiency comes at a bit of a cost of CPU speed. I idle at solid 1024 when on the title screen (which bypasses almost all the code for calculating ball location, colors, etc. until joy0fire wakes it up. When running normally, I can see the numbers going from anywhere between 300 and 1000 in rapid succession. When a ball is in play and I'm rotating the colors, it goes down to anywhere between 300-something and 700-something, sometimes hitting 1000-something here and there.

This is quite the change from a few days ago, when my code only had about 100 bytes to spare but the cycles were regularly at 1300-1700. Still, the game is set up to be more easily expanded now, so all that is really needed still is that kernel stuff.

February 2, 2013

I just realized you have a title screen as well.

No, the "title screen" is just two playfield drawings that alternate. I'm not using bB to do anything special there, at least not in regards to your ability to create "Titlescreens." I don't even really know what those are or how they work.

Besides, if I had to choose between a means of making the game itself work and cutting out a title screen, the title screen would get chucked in a second.

So the BB kernel is still needed. The simplest, probably most non-intrusive way to make your game flicker free is to expanded it to 8k, and leave the new bank empty.

Just like that? I can set the game size to 8k, but how would that do it? Would it just speed up operations to the point that the flicker wouldn't be noticeable anymore?

An assembly kernel could be put in the new bank, and since there is so much room it could all be unwound and the registers that hold your color and and playfield graphics could be directly accessed without using jump to subroutines, or temp registers. The blocks wouldn't have to be hidden by coloring them black. The blocks would be gone because BB would have taken that block out of ram. Once all the graphics are drawn every frame hardware collisions could be used (if desired).

Note that the blocks are not hidden by being colored black. I call pfclear at the top of the main loop and then draw either red, yellow, or blue blocks, depending the value of a variable called flicker, which is either 0, 1, or 2 (and draws a color accordingly).

So you would compile the game with some inline assembly in the other bank. At this point the game would still be using the old BB kernel, and flicker. You then have to manually edit the rom with a hex editor (like HOM3) to get the game to bankswitch instead of running the BB kernel. Once inside the new bank the assembly logic would decide if the title screen is being drawn. If it is then a jump and bank switch would occur to go back to the BB kernel. Otherwise the assembly kernel would draw. Finally after the assembly kernel a jump and bankswitch occurs to go back to the BB side, and hand off control.

Okay... I don't fully understand and I have no clue what to actually write to do this, but I'm glad that there's a possible solution! Also, bB converts the .bas file to .asm before compiling it, so I could always edit the assembly file at that stage, rather than HEX-editing the finalized .bin file, although I do have a HEX editor to do so if necessary.

I know that sounds like a lot, but for an experienced assembly programmer it's not to bad. Since you would be starting out with assembly this might be a little bit too much to ask. You will probably need help to do it, but the plan of attack is there.

I'm just relieved by your optimism! Any suggestions of who I could/should get into contact with for help on doing what I need to do here?

Once the game is finalized (and you compile the assembly in) then there should only have to be a few bytes that need patching if you make changes (I.e. to perform a bankswitch in 1 place, maybe 3 bytes total). Everytime you make a new rom you would have to patch that area, and hopefully that area never changes. The idea and key here is that there is only a small area to patch to get the game working, making the work as little as possible.

Sound simple enough.

With the standard caveat IAFFAE (I am far from an expert)

I don't think it would take all that.

you might be able to do it with the normal bB far call

(what ever it's called in bB) but if not I think you'd just have to

have a few bytes of ASM to replace the normal drawscreen

statement.

What do I need to do to call ASM in bB? Do you know?

GRP0 and GRP1 are the true names of Player0 and Player1 (I think). I'm not intimately familiar with BB, and sometimes the names used in BB throw me off because I'm not sure if they are referring to hardware or a ram location. GRP0 and GRP1 are the hardware registers that hold the graphics for player zero, and the graphics for player one. Hence shortened to GRP0 and GRP1.

Ah, that makes sense, then.

To be a powerful BB programmer you should also learn how the 2600 really works. Andrew Davie's lessons are the best place to start for that.

I've read the first nine of his lessons so far, so I'm fleetingly familiar with how it works and what numbers are involved.

I love that acronym. If you can simply call the assembly kernel instead of the BB one, then yeah that's the way to go. At least everytime you compile it wouldn't be a nightmare!

So how would I do this, then?

February 2, 2013

excellent.

that fixed mine so here it is.

still doesn't look very good to me.

http://pastebin.com/fHQFsUeJ

I also wrote a javascript to write out the pfcolors statements

if anybody has a mind to play with it

http://pastebin.com/QQRFmVc0

It's a neat idea, but keep in mind that the playfield's colors must be retained during left and right rotation and the right color of ball must go to the right color of block (or, in the case of secondary colors, either of the two primary colors that make up that secondary color). I worry that the back and forth animation to make this possible with be almost as sickening to the player as the flicker itself.

February 2, 2013

I don't know enough about BB to say whether or not you can replace most of the kernel with assembly. That would be the ideal solution, where you could insert some assembly inline and compile the whole thing from one source.

An alternative would be to compile the game as is, and patch in the assembly routine where the BB kernel normal lies (since you won't be using it anyhow).

I was thinking that as well--that I could compile the game, then replace what is needed with an alternate kernel. As long as I knew exactly what to replace and what to replace it with, I'm okay with a workflow that involves me doing that.

As to draw it, I believe the routine right now is storing all the PF block bits in ram. You could instead just store the colors for the individual PF (you probably already are), and color the playfield blocks black as they get hit to hide them. Does that make sense?

That's basically what I'm doing, though it's very code-heavy (unless someone has some alternative suggestions for how to do it). The program takes the first 16 variables, a[0] through a[15], and assigns them a number. That number is the color value that will be used for each of the sixteen blocks on-screen, starting at the absolute top one and moving clockwise. The game then does a loop through all the values a[0] through a[15] and, if the color is red, it draws that pfpixel and then sets the playfield to red. If not, the pfpixel is not drawn. Then, it drawscreens and cycles through the main loop again, this time for yellow, then again for blue. So, it takes 3 full cycles of the main loop in order to color every block, and each pfpixels is black for 2/3 frames, which results in significant flicker because each of them is actually black for longer than they are a color.

Also, this is a very labor/code-intensive way to determine the colors and makes adding further colors essentially out of the question because of the bulkiness of that code, plus each additional color increases the time that all the other colors are black, thus increasing the flicker. If I did the whole 8 colors that I would prefer, you'd only get a fleeting glimpse at which color is supposed to be being rendered.

The reason in this case is it would make the assembly portion much easier to do. Essentially the playfield would be set up in reflected mode, and the circular pattern would be drawn each screen with each block its unique color (or black to be hidden).

I believe from your code the collisions are being handled through software, so that should still work.

I don't know what "reflective" mode means, but the circle pattern should not be mirrored, if that's what you're saying. There could be a color standing alone in any location, since it's randomized.

But yes, I'm doing it using pfpixels and yes, the collisions are being handled by a series of if-then statements. I'm going to go back and test the code suggestion on the previous thread page to see if it works/is more efficient, but for the time being, every main loop cycle, the location of the ball is checked against these ranges, and if it falls within a range, the color of the ball is checked against the color of the pfpixel in that location and either it's a good hit or a bad hit.

Actually, I just had the thought that you are probably in asynchronous mode. That is okay, it is easy to deal with too.

Edit:

It would also be nice to know what you are drawing the heart and shot with. Is GRP0 the heart, and GRP1 or M1 the shot?

I've never heard of GRP0 and GRP1. What are those?

The heart is Player0. The ball is Player1. This is because missiles take on the color of the player, which is wrong. The ball needs to take on and retain the color of the central heart as soon as the trigger is hit. The color should not be varying once the ball is in play.

From the last video I dun get why there is flicker and soft collisions.

Can't you use traditional collision(missile0, playfield) when the players shot hits a block?

Also, you don't really need multiple colors per row. Stagger the playfield blocks between rows. This should work except for the topmost row and bottom.

The flicker comes from swapping between rendering the red, then yellow, then blue.

Well, the color of the ball, when spawned, needs to remain the color of the heart at the moment of the ball's spawning.

Maybe I can use traditional collision, but so far as I know, that just checks to see if something collides with something, but doesn't take not or has any feedback indicating WHERE it took place. The game isn't just about hitting a ball to a block--a central gameplay element is hitting the right color of ball to the right color of block. If I can't compare the color of the ball at the time of collision to the color of the specific block that it hit, it won't work.

The reason I don't stagger the blocks, aside from that the symmetry more strongly implies a circular shape, is due to calculating ball trajectory. Since there are too few pixels at play for the ball to move at 1/2 or 1/4 value, I have to handle all that manually. +1 x and +0 y will cause the ball to move up. +1 x and +1 y will cause the ball to move up and to the right at about 45 degrees. +0 x and + 1 y will cause the ball to move straight right. So you can only possibly hit 8 out of the 16 blocks on the playfield.

The point of the other 8 blocks is to see which colors are where and to react faster. When playing, in my opinion, it isn't nearly so evident that half the spots on-screen will never possibly be hit by the ball.

As a result, I only have soft collisions for blocks at every 45 degree increment, since the ball will never hit the every 22.5 degrees.

If the blocks were staggered, it would be difficult to make those numbers work to guarantee a collision path, wouldn't it?

Here is an example of drawing three color blocks on the same row that you can look at:

ThreeColorBlocks.zip

This was just meant as an example to do color changes mid-line. So for your game you would probably make a few more mini-kernels, one for the middle row with the heart, one for the other two block rows, and some code that preps between each mini-kernel.

For the above routine I posted you would also need to add in some code to handle drawing the shot in that area. A "skipdraw" type of code (search for that and you will find it).

I suggest you jump to each mini-kernel as a subroutine. In the prep before that subroutine move the particular color values into a some temporary registers, which you then use in that subroutine. I would help you more with this game, but I'm really pressed for time right now (I got three tests coming up this week). There are plenty of good people here on AA though that I'm sure would be willing to give you a few pointers.

This looks very much like what I need! I'll definitely ask around to see what can be done, but if worst comes to worst, I can always wait a week or so 'til you've got more free time.

I wish there was some mini-kernel magic that could allow for multi-coloured playfields.

I still say he could fake it by alternating playfield rows and even adding some "animation" to the playfield.

Note that I change the COLUPF value every time I cycle the playfield colors. This is because the first row of playfield pixels is incorrectly colored when using pfcolors. A workaround is to set COLUPF as it effects the first row of playfield pixels (for some reason).

I think that you're not quite understanding the way that the game works. Here, let me show a couple videos:

is of the game in its current state. Towards the end of the video, I slow down the footage so that you can see what it's doing.

is the game I designed about a week ago for GlobalGameJam, which this Atari game is crudely based off of. Obviously, I can't do much of what was in the original game, but I'm finding compromises where I can. It should give you a better sense of how the gameplay is supposed to work.

February 1, 2013

May do that, RT. I'd like to hold off unless absolutely necessary.

I managed to fix that silly bug with the duplication between a[0] and a[15], which is a huge relief. I've gone through and optimized the code as much as I can, squeezing out a total of 183 Bytes that have not yet been used. If this kernel thing works to handle the flicker, that can be upped to about 710 bytes, as a good chunk is spent in the flicker code.

I haven't looked into the kernel/etc. stuff yet, but I'm about to. If anyone has a genie-in-the-bottle solution to offer, though, I'm all ears.

It was suggested that some assembly code be used to update the colors mid-scanline. Does anyone have the code for this? Can I insert assembly code into bB so that it runs those things separately?

I can't read Assembly and I don't know what it means, so if it's coming to that, I'm probably going to need some strong advice/help.

February 1, 2013

Have you looked at the example programs here yet:

www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#sound

I make sound effects by hunting down sounds with Tone Toy 2008 and shaping/altering those sounds using VbB's Music and Sound Editor.

Yes, I did. There are a lot of variables at play and I don't see how many of them are absolutely necessary. You have temp variables for all sound values, loops, functions, etc. all over, but is that necessary? What is the absolute minimum code necessary to make a sound work? Because I've only got about 200 bytes and maybe 1 variable to spare.

February 1, 2013

Alright, got that collision detection issue all sorted out. As I figured, I put in the wrong numbers, forgetting that sprites center to their coordinates.

.

There's a bug where block #15 and block #0 always share the same colors. #0 starts at the very top and the numbers go clockwise, so #15 is the one just to the left of it. I'm sure that I made a dumb mistake when writing the rotation routine, but every time I stare at the code for it and try to visualize the problem, my brain goes numb.

If anyone is willing to point out the glaringly obvious oversight, it would be appreciated. I'm sure that I just have to store one of the variables to be placed later or something like that.

rem move all block values to the right
435  for temp1 = 0 to 15
temp2 = temp1 + 1
if temp2 = 16 then temp2 = 0
a[temp1] = a[temp2]
next
offset = 50
goto 500
rem move all blocks to the left
445  for temp1 = 15 to 0 step -1
temp2 = temp1 - 1
if temp2 = 255 then temp2 = 15
a[temp1] = a[temp2]
next
offset = 50
450

Other than that, it mostly just comes down to flicker issues. If I can get the flicker issues fixed through everyone's suggestions and things look to be working well, I'll probably expand this to an 8k ROM and add some further functionality.

Again, if someone can explain how sounds work, that would be a great boon as well.

February 1, 2013

Unfortunately, I do not have an iOS device, but I'll definitely go over that code, thanks! Too bad I don't know anything about Assembly, so I'll probably end up needing assistance.

In the meanwhile, I kept hammering away at the game and I think it's basically done, aside from two things:

1. The flicker problem

2. Collision detection issues

The collision detection code can be seen below:

rem collision detection
700
if a[0] = 0 then goto 701
if player1x > 80 && player1x < 85 && player1y >8 && player1y <17 && ballcolor = a[0] then a[0] = 0: goto good_hit
if player1x > 80 && player1x < 85 && player1y >8 && player1y <17 && ballcolor <> a[0] then goto bad_hit
701
if a[2] = 0 then goto 702
if player1x > 113 && player1x < 118 && player1y >16 && player1y <25 && ballcolor = a[2] then a[2] = 0: goto good_hit
if player1x > 113 && player1x < 118 && player1y >16 && player1y <25  && ballcolor <> a[2] then goto bad_hit
702
if a[4] = 0 then goto 703
if player1x > 129 && player1x < 134 && player1y >48 && player1y <57 && ballcolor = a[4] then a[4] = 0: goto good_hit
if player1x > 129 && player1x < 134 && player1y >48 && player1y <57 && ballcolor <> a[4] then goto bad_hit
703
if a[6] = 0 then goto 704
if player1x > 113 && player1x < 118 && player1y >80 && player1y <89 && ballcolor = a[6] then a[6] = 0: goto good_hit
if player1x > 113 && player1x < 118 && player1y >80 && player1y <89 && ballcolor <> a[6] then goto bad_hit
704
if a[8] = 0 then goto 705
if player1x > 81 && player1x < 86 && player1y >88 && player1y <97 && ballcolor = a[8] then a[8] = 0: goto good_hit
if player1x > 81 && player1x < 86 && player1y >88 && player1y <97 && ballcolor <> a[8] then goto bad_hit
705
if a[10] = 0 then goto 706
if player1x > 49 && player1x < 54 && player1y >80 && player1y <89 && ballcolor = a[10] then a[10] = 0: goto good_hit
if player1x > 49 && player1x < 54 && player1y >80 && player1y <89 && ballcolor <> a[10] then goto bad_hit
706
if a[12] = 0 then goto 707
if player1x > 33 && player1x < 38 && player1y >48 && player1y <57 && ballcolor = a[12] then a[12] = 0: goto good_hit
if player1x > 33 && player1x < 38 && player1y >48 && player1y <57 && ballcolor <> a[12] then goto bad_hit
707
if a[14] = 0 then goto 708
if player1x > 49 && player1x < 54 && player1y >16 && player1y <25 && ballcolor = a[14] then a[14] = 0: goto good_hit
if player1x > 49 && player1x < 54 && player1y >16 && player1y <25 && ballcolor <> a[14] then goto bad_hit
708
if player1x = 0 || player1y = 0 then goto 750
if player1x=156 || player1y = 140 then goto 750

I mapped out the top-left pixel location of all the pfpixels in the playfield seen below:

playfield:
............X...X...X...........
........X...............X.......
................................
......X...................X.....
................................
.....X..........X..........X....
................................
......X...................X.....
................................
........X...............X.......
............X...X...X...........
end

From there, I added a range of 4 width and 8 height to accommodate the full "hit box" of the pfpixel. For some reason, though, only #703 and #707 (the bottom-right corner and top-left corner) work correctly. All the other hitboxes register no detection and the "ball" passes straight through. I would say that it's a problem with the ranges I set, but I used the same sort of range values for all other pfpixels as those two. In all cases, the minimum ranges are derived from the top-left pixel in the pfpixel (determined by checking through spawning player1, with a sprite shaped like a pfpixel, at the location), though now that I say that, I may have an idea as to what is wrong -- I'm probably forgetting that player sprites are spawned in the center of their location, so all my values are incorrectly offset. Oh, well, I'll get 'em fixed!

Somewhat worryingly, I'm down to just 263 bytes left, though it's probable that there is room for optimization and the core of everything is there already. If there is a way for me to resolve this flicker problem as Omega and others have suggested, I may have to upgrade the game to an 8k rom file, because what you see is really a very simplified version of a game that I designed for GameJam. I'd like there to be room to add secondary colors (orange, for instance, can be 'killed' by a red ball or a yellow ball) and white (which can be killed by any ball, but takes to hits to do so) and black (which will hurt if it is hit, so the player will have to take note of the "blank space" relative to the other colors and make sure not to hit it) with levels that progress at more than an entirely random degree (a bit of planned progression to introduce the new blocks as they come, though still governed by randomness).

Also, is there a good, simple tutorial for what is necessary to add sounds? Music is out of the question, both because I am no composer and due to the size limit, but I'd at least like to have audio feedback for a good hit and a bad hit. The demos I've seen seem a bit complicated and don't make it clear how much of all the code is necessary for getting a sound to play.

I'll probably also get someone to playtest to give me some feedback on the controls--whether the balls move too quickly to respond and whether the controls on the block rotation are too fast or too slow.

So, thanks to everyone for the great feedback and help! Any more resources that can teach me more about how to get this flicker problem to go away, or anyone willing to write a kernel that I can just plug 'n play while still programming in bB, that'd be great!

February 1, 2013

Thanks for the info, Spice. I read your presentation as well as about half of the assembly course, though I don't feel much closer to actually being able to do things differently, though it is interesting stuff that makes the meanings of things a bit clearer.

Okay, so we've established that the playfield either has to be a solid color or a solid horizontal line. Now, is there any way to put multiple colors in the background without being limited to a single color per line? There seems to be different colors per line in Pitfall, there. If I could color in specific colors to certain regions of the screen, I could use a mostly-black playfield as a mask to cover up the rest of the background so that the colors only would show through where I wanted them to. If not that, and not any way to do the playfield differently, is there maybe a way of interlacing the image to that each pfpixel is made up of half as many lines, but those lines, each of the appropriate color, could be swapped between fast enough to made the flicker negligible? Even if it results in a less-solid image, that'd be preferable to one that flickers.

If not any of that, is there ANY solution whatsoever, or is it entirely impossible to have multiple colors on screen like I'm trying to do?

January 31, 2013

Well, I've been told that the more advanced stuff, like this, isn't really possible with batariBasic but may be possible with Assembly, although I don't know Assembly. I'll try going through Andrew Davie's course and hopefully that will put me a bit further along.

Meanwhile,

of what the code does so far.

I could try the pflines thing if I space out the blocks differently, but then they certainly wouldn't be circular and it may be very limiting.

Could this be done if I use multisprite, giving each different colors, and moved them around the field instead of pfpixels?

January 31, 2013

Well, I was kind of hesitant to post the full code of what I was working on, but this has so many problems, unless folks have some novel fixes that I wouldn't have considered, it won't be going much further, anyway.

[redacted]

Sorry for the mess in the code.

You can see the basics in place. There are multiple colored squares that are rotated by left/right joystick movements. In the center is a pulsing heart sprite that serves as a life bar as well as an indicator for "ball" color. When the trigger is pressed, a ball of the same color as the heart at the moment of the trigger is created and sent off in a random direction. The object of the game would be to match the color of the ball to the color of the block it hits, scoring points. The wrong ball to the wrong block loses a life.

There are lots of things wrong with the build at the moment. The most glaring is the awful flickering. Second, I can't seem to work out how to get the ball to shoot out in one of 8 set directions at random (every 45 degrees) without being too fast to react to. Third, I have no idea how to perform by-box collision that will allow the hit box's color to be compared to that of the ball to determine whether the hit is good or not. There's also a weird glitch in the first and last box values (the very top and the one just to the left of the top), causing those two to always share the same color for some reason.

And this is just a very simplified version of the game I intended to do. Ideally, the boxes would rotate fluidly, not just swap between a number of pre-determined spots and there would be more possible colors/effects on the boxes, but alas. I'm rather exhausted with the attempt unless someone can suggest novel ways of dealing with the aforementioned problems that I just didn't think of.

January 30, 2013

I very much appreciate the help on the variables and such. Thanks!

Now, there's one major remaining hurdle: I need either multiple colored sprites or multiple colored pfpixels or something else on-screen at once. I've tried going through loops like so:


dim temp = a


for temp1 = 0 to 15

temp2 = rand

if temp2 < 41 then a[temp1] = 64

if temp2 > 40 then a[temp1] = 28

if temp2 > 80 then a[temp1] = 148

if temp2 > 120 then a[temp1] = 46

if temp2 > 160 then a[temp1] = 214

if temp2 > 200 then a[temp1] = 100

if temp2 > 240 then a[temp1] = 14

if temp2 > 247 then a[temp1] = 0

next

rem didn't use a for-loop because it just wouldn't work right

100 temp = 0

125 if temp < 16 goto 150 else goto 175

rem starting at the top, going clockwise, define each pfpixel

150 if temp = 0 then pfclear: pfpixel 16 0: COLUPF = a[temp]: drawscreen

if temp = 1 then pfclear: pfpixel 20 0: COLUPF = a[temp]: drawscreen


if temp = 2 then pfclear: pfpixel 24 1: COLUPF = a[temp]: drawscreen

if temp = 3 then pfclear: pfpixel 27 3: COLUPF = a[temp]: drawscreen

if temp = 4 then pfclear: pfpixel 28 5: COLUPF = a[temp]: drawscreen

if temp = 5 then pfclear: pfpixel 27 7: COLUPF = a[temp]: drawscreen

if temp = 6 then pfclear: pfpixel 24 9: COLUPF = a[temp]: drawscreen

if temp = 7 then pfclear: pfpixel 20 10: COLUPF = a[temp]: drawscreen

if temp = 8 then pfclear: pfpixel 16 10: COLUPF = a[temp]: drawscreen

if temp = 9 then pfclear: pfpixel 12 10: COLUPF = a[temp]: drawscreen

if temp = 10 then pfclear: pfpixel 8 9: COLUPF = a[temp]: drawscreen

if temp = 11 then pfclear: pfpixel 5 7: COLUPF = a[temp]: drawscreen

if temp = 12 then pfclear: pfpixel 4 5: COLUPF = a[temp]: drawscreen

if temp = 13 then pfclear: pfpixel 5 3: COLUPF = a[temp]: drawscreen

if temp = 14 then pfclear: pfpixel 8 1: COLUPF = a[temp]: drawscreen

if temp = 15 then pfclear: pfpixel 12 0: COLUPF = a[temp]: drawscreen

temp = temp + 1

goto 125

175

The problem is that, with the pfpixels arranged in a circle on the playfield, it just creates a very noticeable loop of the colors spinning around, since it's not fast enough to draw them without being noticed.

Is there any way to have multiple (in this case, 16) objects of different colors on-screen at once without it being a flickering mess?

January 30, 2013

Thanks much for the response!

I don't know much about the kernels and such. From what I've just read, they seem to take an awful lot of space. Not sure if that's worth it for bitmaps and the like.

My biggest problem is getting loops, functions, and variables to work correctly, so that's my primary concern. For instance, I know that bit operations work almost like arrays, with a{0} being a binary variable, a{1} being another, on up to a{7}. However, can I somehow reference them using a variable as an index, such as the following:

for temp = 0 to 7
bitop{temp} = 1
next

Which, in theory, should count up through the 8 bits and set each of them to 1, but it returns an error instead.

Secondary is any better way of rendering a series of boxes on-screen with minimal flicker. I know that there may be some answer in this, though I admit that I don't understand the concept there.

The idea I have is fairly simple, I think. The complication is in making those updates without a flickering mess.

January 29, 2013

Prelude:

Hello to all! I've recently had an epiphany of how wonderful game design can be, so I'm doing a little exercise to try to build my programming and artistic skills. Specifically, I'm starting with the Atari 2600 and then trying to work my way up with some other older consoles before settling again on modern engines. It seems like a good, fun exercise in rapid game development, since Atari 2600 games are relatively small. Keep in mind that I'm a novice programmer and this is meant to be a learning exercise to get me used to "thinking like a programmer."

Problems:

I sat down last night to crank out a simplified version of a game that I recently designed for GameJam and it's been going fairly well so far, thanks to visual bB and the manual that came with bataribasic. However, there are a number of problems and questions I have, so I hope that you good folks with all the knowledge can help me out:

1. First of all, I know that there are serious limitations on what can be done, but why are they THIS limiting? Maximum of two sprites? Any more requires significant slow-down and flicker as you teleport them from place to place? What about, for instance,

(which is very similar to the game I'm trying to make)? You've got a ball that does not share the same color as the playfield (and, for that matter, a playfield that is not one solid color) and a series of "blocks" that I assume are sprites, yet there is no noticeable flicker. Or, for another example, Pitfall, which not only seems to have multiple different sprites on screen, but also sprites with multiple colors (the man) and a playfield consisting of much greater pixel quantity/density than is available to me in Visual bB. What gives?

2. It seems like most loops and functions don't really work. For instance, I wrote this:

rem randomize color values
10 for temp = 0 to 15 step 1
temptwo=colorfun(f)
goto storecolors
next

function colorfun
if rand < 81 then return 1
if rand > 80 && rand < 161 then return 2
if rand > 160 && rand < 251 then return 3
if rand > 251 then return 4
rem get and assign numbers for variables - red, yellow, blue, white
end


storecolors
if temp = 0 then one = temptwo
if temp = 1 then two = temptwo
if temp = 2 then three = temptwo
if temp = 3 then four = temptwo
if temp = 4 then five = temptwo
if temp = 5 then six = temptwo
if temp = 6 then seven = temptwo
if temp = 7 then eight = temptwo
if temp = 8 then nine = temptwo
if temp = 9 then ten = temptwo
if temp = 10 then eleven = temptwo
if temp = 11 then twelve = temptwo
if temp = 12 then thirteen = temptwo
if temp = 13 then fourteen = temptwo
if temp = 14 then fifteen = temptwo
if temp = 15 then sixteen = temptwo
return

The intention is for-loop to count from 0 to 15, each time calling the function colorfun[ction] to generate one of four numbers (which will be used to determine the colors of things later on) and saving the value in a temporary variable, then sending it into an appropriate holding variable for later. The problem is, when I don't get a ROM out of space error on this (even though I have ~ 1.2K of ROM left), the screen is simply black, like the program is having trouble crunching the numbers in this fairly simple set-up. It's like batariBASIC can't handle nested functions/loops. Is there some way to get this kind of stuff working? The required workarounds--that is, using goto commands, is very wasteful of preciously scarce programming space.

3. Is there some way to name variables in ways that I can access easily through loops? Taking the above example, I have sixteen variables that hold a number from 1 to 4 denoting the color to be assigned to sixteen pfpixels (I would use sprites, but in my experience so far, the processing requirements to have sixteen sprites on screen at once makes the game such a flickering mess, it's unplayable), with an additional two variables used as bit operations to determine whether a given block should be "on" or "off" (that is, whether it's alive or has been destroyed). I would LOVE to be able to somehow count through the variables with a loop without specifying specifically, one by one, what to do, as if it were an array along the lines of:

array[temp] = temptwo

That would be so much simpler and more efficient. On a similar note, I wish I could do:

for temp = 0 to 7 step 1
bit_op{temp} = 1
next

... Or something along those lines. That is, use variables to denote other variable names so I can quickly and efficiently count through them and determine/set a number of variables without wasting the space with dozens of if-then statements for every possible iteration.

This is especially important for later on, since, after I've established which pfpixels get which colors and whether they are on or off, I'll need to program in collision (or some semblance thereof) so that getting hit by a ball (or missile) kills a pfpixel (a la Breakout). That would be difficult enough, BUT it gets harder:

Basic Game Explanation:

The pfpixels need to rotate their values, since the primary gameplay mechanic is the player moving the blocks to meet the ball, rather than the other way around. I'll need for loops to store the current and next color value of the blocks, swap the new value in while preserving the old, check to see whether that block is on or off, affect the collision appropriately, etc.

Maybe that explanation is confusing, so I'll try to represent it visually. The one-sixteen variables hold a color value from 1 to 4, which will possibly end up being 1 to 7, if I have my way. This is important, because only balls of a certain color can cake out blocks of a certain color, so there will need to be if-then statements comparing the stored value of the color of the ball with the stored value of the color of the brick to see if they are a match or not, then flip the appropriate bit operator. This can be represented with sixteen bit operations (between two variables) and sixteen actual variables (though it could possibly be done with bit operations, though it would be complicated):

1 1 0 1 1 1 1 1 1 0 1 0 1 1 1 1 0 - Bit Operation (on/off = alive/dead)

1 2 3 2 4 3 1 3 4 1 2 3 4 1 3 4 3 - Variables (number = color)

---------------------------------------> - Direction that the values must be shifted for each joystick right

<--------------------------------------- - Direction that the values must be shifted for each joystick left

Meanwhile, balls of three colors are being created on a loop, rather than randomly:


pulse = pulse +1
if pulse = 15 then color = color + 1:pulse = 0:beat = 0
if color = 3 then color = 0
if color = 0 then COLUPF=64
if color = 1 then COLUPF=28
if color = 2 then COLUPF=146

Which, when joystick trigger is hit, creates a ball with a color value based on the color variable and stores it for that ball so that it doesn't change.

When collision happens between a pfpixel and a ball (perhaps manually determined by a range of values that denote the pfpixel's location?), the ball's stored color value is checked in an if-then statement against the values in the brick being collided with:

if ballcolor = [variable containing block color value] then [set block bit operation to 0 to "kill" it and give the player points]
if [variable containing block color value] = 4 then [set block bit operation to 0 to "kill" it and give the player points, since these blocks can be killed regardless of the color of the ball hitting them]
else life = life - 1: goto [somewhere]

If need be, I could try using six variables as bit operations (instead of sixteen) to denote red, yellow, and blue colors and a function to generate the color number when needed , for instance:

for count = 0 to 7 step 1
if red{count} = 1 && yellow{count} = 1 && blue{count} = 1 then color = 4
if red{count} = 1 && yellow{count} = 0 && blue{count} = 0 then color = 1
if red{count} = 0 && yellow{count} = 1 && blue{count} = 0 then color = 2
if red{count} = 0 && yellow{count} = 0 && blue{count} = 1 then color = 3

Though I'd need two versions of it, since there are two bit operation groups at play, since there are sixteen blocks, so I'd have to run it again for the second half.

This would be nice because it's scaleable if I want to expand the number of possible colors:

if red{count} = 1 && yellow{count} = 1 && blue{count} = 0 then color = 5
if red{count} = 0 && yellow{count} = 1 && blue{count} = 1 then color = 6
if red{count} = 1 && yellow{count} = 0 && blue{count} = 1 then color = 7

As is probably apparent, I haven't gotten to these latter parts yet due to the difficulties I'm having getting loops and functions to work correctly.

So, after all that, if anyone can offer me some advice as to what's going wrong or how I can make my dreams come true in an efficient way, it would be very much appreciated!

TL;DR: Help me!

Sign In

Cybearg

Posts

Joined

Last visited

Content Type

Profiles

Forums

Blogs

Gallery

Events

Store

Posts posted by Cybearg

Questions Galore!

bB with custom assembly kernel, example

Questions Galore!

Questions Galore!

Questions Galore!

Questions Galore!

Questions Galore!

Questions Galore!

Questions Galore!

Questions Galore!

Questions Galore!

Questions Galore!

Questions Galore!

Questions Galore!

Questions Galore!

Questions Galore!

Questions Galore!

Apps

My Activity Streams

More