KevKelley

Okay. So if I were to also make something like this for Missile1, I would use something like this for Joy1 inputs: m1d= SWCHA^%11111111 And I can use the same data tables as m0d? and thank you so much! This is very helpful!

Ah. I was just playing around with the example program to see what I could do with that. I haven't really used data tables too much but I like it. I guess I had not gotten to the point where I kind of understand some of these things but to determine what purpose they serve sometimes eludes me. I was curious. In the example you posted above, what is the j0f? I did not see it defined.

So I was playing around with SWCHA and I think I understand it much better then a year ago when I first started messing around with it (also with on...goto statements). You are right. Instead of cooked spaghetti my code looks like uncooked spaghetti! temp1 = SWCHA / 16 on temp1 goto P0_STILL P0_STILL P0_STILL P0_STILL P0_STILL P0_GO_DR P0_GO_UR P0_GO_R P0_STILL P0_GO_DL P0_GO_UL P0_GO_L P0_STILL P0_GO_D P0_GO_U P0_STILL DONE_JOY0 I have the various movements off in a different section where I have the speed at which they move. I guess I can then also add in those sections the direction for the missile direction. It will probably get me a little to get comfortable with it and play around but this is definitely much cleaner and looks like it will help in the longrun! Thanks!

So, if I were to use it, I would essentially set 2 temp variables for each controller and then do something like this: on temp2=%01000000 goto... on temp1=%00001100 goto... with it going to which ever directional issue?

I had played around with SWCHA before. I am definitely going to look at that. Some of it confused me when I had first tried to implement it in some programs before. Funny. I would sometimes start with a simple program and then just playing around with things I tend to over complicate stuff. Sometimes I don't think about it much because I figure it is something small and I don't need the space. With this I thought I'd just cut and paste some of my code and go from there.

I had not. I was looking at some of the other programs though in developing this. Originally I had a simpler shooting but then kept expanding on it to be multi-directional. Looking at that program that is a hell of a lot simpler then what my brain was putting together. That would probably make things easier down the road, too.

I was looking over the code and was wondering... Is it possible that because of how I have it written, with there being multiple checks (if joy1up then..., if joy1up && joyleft then...) and because I have the part with the !joy1fire, that the game happens to take my first entry, and then goes with it, essentially locking out some of the other options? If that is the case, the only thing I don't get is why it would work for P) and not P1.

Thanks. It was driving me crazy. It kept throwing me off thinking it was something that related to either the fire or one of the directionals I made or some weird interaction with some of the other code in the program but I would comment sections out to see if it changed and nothing was different. I also was wondering if something was getting lost in the operations but the P0 was throwing me off.yp And I did notice after testing that I would get an occasional shot here or there and every once and a while the shot would freeze. I was hoping to pick it back up tonight and see if I can find the issue.

I was working on a little program and made a section with two sprites that can shoot in seven directions. I had initially gotten the code working for P0. I pretty much copied it for P1 but I couldn't get it working right and I don't know what I screwed up but I've been staring at the screen and my brain is dead. Here is the P0 code that works: if g{1} || f{1} then goto SKIP_FIRE if !joy0fire then goto SKIP_FIRE if joy0left then f{0}=1 if joy0up then f{2}=1 if joy0down then f{3}=1 if joy0up && joy0right then g{2}=1:f{0}=1 if joy0down && joy0right then g{2}=1:f{0}=1 if joy0up && !joy0left then g{3}=1:f{0}=1 if joy0down && !joy0left then g{3}=1:f{0}=1 if f{0} then missile0x=player0x+3:missile0y=player0y-4:f{1}=1 SKIP_FIRE if g{2} then missile0x=missile0x+4 if g{3} then missile0x=missile0x+2 if f{1} then missile0x=missile0x-2:f{0}=0 if f{2} then missile0y=missile0y-1:if g{3} then missile0y=missile0y-1 if f{3} then missile0y=missile0y+1:if g{3} then missile0y=missile0y+1 if collision(missile0,playfield) then f{0}=0:f{1}=0:f{2}=0:f{3}=0:g{2}=0:g{3}=0 if !f{1} then missile0y=200 SKIP_SHOOTING_0 Here is the P1 code: if g{0} || f{5} then goto SKIP_FIRE2 if !joy1fire then goto SKIP_FIRE2 if joy1right then f{4}=1 if joy1up then f{6}=1 if joy1down then f{7}=1 if joy1up && joy1left then g{4}=1:f{4}=1 if joy1down && joy1left then g{4}=1:f{4}=1 if joy1up && !joy1right then g{5}=1:f{4}=1 if joy1down && !joy1right then g{5}=1:f{4}=1 if f{4} then missile1x=player1x+5:missile1y=player1y-4:f{5}=1 SKIP_FIRE2 if g{4} then missile1x=missile1x-4 if g{5} then missile1x=missile1x-2 if f{5} then missile1x=missile1x+2:f{4}=0 if f{6} then missile1y=missile1y-1:if g{5} then missile1y=missile1y-1 if f{7} then missile1y=missile1y+1:if g{5} then missile1y=missile1y+1 if collision(missile1,playfield) then f{4}=0:f{5}=0:f{6}=0:f{7}=0:g{4}=0:g{5}=0 if !f{5} then missile1y=200 It seems to only work firing UP, DOWN, RIGHT, UP LEFT It does not go UP RIGHT, DOWN RIGHT, or DOWN LEFT. Now I did notice that when I deleted this line for the P1 code it kind of worked (except that you wouldn't have to hit the fire button.) if !joy1fire then goto SKIP_FIRE2 Here is the bB file too. Am I blind? CB_12_11_2020.bas

I always thought they had great concepts for games and had them executed fairly well. They may have missed the mark a bit but they had some original gameplay. I always thought Wabbit was cool. It was a bit hard but I'm sure with some tweaks it could be an amazing game.

Ah. I didn't understand all that. I thought that was part of bB. I was thinking the split option was a bB thing. I guess I'll have to do a work around. Thanks a lot guys! 🙂

My assumptions were that in bB, when using CTRLPF=$23, since it splits the screen colors with those of the players, it also takes the priorities of the players with it.

Here is a picture of the Playfield, Missiles, Ball, P0, and P1. I labeled the players at the top of the picture. As you can see, the one on the left goes behind the Playfield.

I was using standard kernel. I had noticed that if I use a normal background both P0 and P1 are above the playfield. But I noticed when split, P1 is behind the playfield. I'll see if I can post a pic soon.

I had been playing around with some ideas and decided to use CTRLPF=$03. I had Player0 sprite and Player1 sprite on opposite sides of the screens when I noticed that the Player1 sprite goes behind the playfield on the left. I assume that since the playfield is split with the colors of the players, the playfield retains those properties? I noticed if I did something else, like CTRLPG=$00, Player1 would not go behind the playfield. So I guess my question is if it is possible to have both sprites be capable of being above the playfield? Or am I missing something?

Just saw this post and thought it was cool. Nice little exercise. Personally I like the direction the original took but I can see the desire to make a Pac Man clone. I would think it would be neat to combine the two ideas, like Blueprint meets Pac-Man. Maybe some elements of Venture thrown in there.

I am just seeing this post. I had came across this one time late at night on eBay. I think there is usually a copy someone is selling on eBay that might be the same person. It intrigued me because I like using classic sounds in my music or simply for accents and thought this was a cool noise machine. It is even cooler that you made a custom controller for it and it is neat to hear more about it.

I apologize for the lack of updates in the last couple months, as work and home had been crazy! I had been quietly looking at things and did have one little side project to distract me but with a couple vacations before Christmas I was hoping to get some good work done. I loaded up Crossdock to see if there were any issues to fix and had two- For some reason the Missile1 was spawning in the top during the maingame and in the Carts minigame the walls were not appearing during the difficulty progression. The first problem stemmed from me changing the resetting of some variables and coordinates at the beginning of the game. I believe this stemmed from when I attempted to consolidate code in a previous build. I had 2 resets - one moving into the main game and one for all the minigames. I have the minigame reset go to where the main game reset goes but not all things were to be reset the same so I had broken them up but it appears that I made a mistake with that one. As for the Carts issue, after you score a certain amount of points walls will appear to obstruct the path of the player and the cart. I had originally set this to start after 30 points but for some reason when I tested it they did not appear. I changed the value to 2 and it worked so I changed the value to 20 but had not checked it yet to see if it works (my battery is dying). I plan on looking at this a little more closely once I charge my laptop.

Thanks! I have been looking at ways to break up the logic by frame should that be the issue. I had kind of played around with that a while back but haven't had a solid amount of time to delve deeper. I have been mad at my lack of any major developments but I have a couple vacations approaching where I hope at least a couple days to see if I can hammer out the rest of the game and be ready for final play testing. As it is now, it is probably 95% complete as I play looking for bugs, tweak values for balance, and work on that one intermittent over cycle issue. As the issue I have only seems to occur when moving downward, I think I can probably root out the problem by toying with the movement code or possibly consolidating some things or eliminating redundant code if some exists. Since I have been short on time, what I really need to do is print out the code and bring it with me to work so I can mark it up whenever the opportunity arises. It'll bring back memories of middle school. Lol

Awesome to see an update! I loved watching the gameplay of this one.

I have been working intermittently on a special controller that would use inputs that connect using a 1/4" jack. I had considered making a foot pedal similar to what you have. Have you found those "pedals" to be durable after repetitive but use?

Ah. Now I kind of want to try this with a simple little program and 2 Ataris. Just need a second harmony cart.

What is SLI?

I figured there would probably be more needed. I remember back in high school I rigged all my systems together using various splitters and devices. There was a lot of noise to deal with. I look at the add-ons for the system, both new (AtariVox) and old (Supercharger,Compumate) and it always makes me wonder. I suppose there could be a Sega-like add-on for the Atari that could accomplish what I am thinking, maybe run the AV to the add-on in the cartridge port. I guess then there is the question of "What's the point?" I love the debates regarding things like legacy games vs things like DPC+. I like the charm of the Atari graphics and limitations, as it forces more of a focus on gameplay, but at the same time, why not? I like trying to find new ways to do things. That usually leads me down many Rabbit Holes...

I was thinking of the limitations of the system so I was thinking more like this: You have 2 Ataris. Both outputs go to the same television. One controller is plugged into both Ataris using a splitter to keep inputs the same. A program is written on two different cartridges, each containing half of the program. An example would be sprite data for Player 1 containing different information on both carts so that the Sprite would be more complex than what would be possible with one system. Or music data and sound effects on one cart. This may be an extremely simplistic take on what I was thinking and may serve no practical purpose.