KevKelley

Definitely check the link provided as it is a big help. Basically you have to define a special variable, so do something like : dim squirrelthing_move = a.b Then you define a and b. So a=0 and b=5 So you can do this: if player1y > player01 then player1y = player1y -squirrelthing_move But if you are really interested in learning, I highly recommend reading the forums and Random Terrain's website. There is a lot of helpful information out there!

How about Cosmic Ark. When you have to shoot the asteroid by pushing a direction, they might have fun.

When I first read about it I thought it was neat and I started to imagine what I could do with it. But then I realized one important detail - I wasn't there yet. I needed to work on a lot of the fundamentals before I even looked at the stack. It took me months before I had even looked at some of the more advanced features. I would practice using different code in different scenarios to see how things work and the best resource are the hundreds of posts on the Atariage forum that may address partsbor all of your questions.

In the DPC+ games I was working on, the only thing I was thinking I could use the stack for is if I wanted to save a value and check the difference later on. I thought it was neat reading about it but since I had no immediate use for it I haven't really experimented with it yet. My recommendation is to make a short little program testing it out. See the basics of how it works. That is what I have been doing since I started. I have found practice helps

That is very interesting. I don't really have a particular use for that. I was just curious if it was a simple swap. That would be an interesting effect if you had the free space for it. But then it might be better to just use the text minikernel at that point.

I thought if you have a=5. Then you push it to part of the stack. When you want that back you pull it I believe you can use that variable anyway you want in between. I have yet to use it so I this is probably a really simplified take.

My noob understanding is that the stack is a part of the the memory where you can store a variable's value and then retrieve it later on.

Yeah. Since I have essentially 3 different code blocks for the generation, elimination, and other pfpixels, that wouldn't work unless I consolidated the code. Another solution I had thought of was to assign a bit and if I pfpixel is picked up it would flip, disable the unnecessary code for a frame, and then reset. Or have a variable so that if the box is picked up at the same time the counter hits a number than to add that variable to the other code. In the end using the playfield variables was much better. Plus I learned something nee. That I can apply to more applications in the future.

In Bag Boy, the closest thing I have to an enemy was the boss at the top of the screen. It starts off with simple right to left movement. But to make them more difficult I have their position determined by the location of the passing cars below so that the move in a somewhat erratic but not too limited way. In Manatee Madness, I have a couple different enemies. Some are simple back and forth movement with maybe a change to the y-axis based on player location. Some move in a set path. Right now the most complicated are the gator and diver. The gator moves towards the player. So does the diver. But if the gator gets too close to the diver he goes towards the diver. If the manatee hides behind the sea grass, the diver tries to surface until the player is visible again. I haven't made any real complex AIs to date, as I am still learning, but so far I have found a mix of randomness and conditional statements give a good degree of simulated intelligence.

Curious. I was playing around with this to swap player1 for a number. Is it possible to perform this in reverse? And have it to where you swap a sprite into the score? As an example, say the game starts. Instead of a score it scrolls "PRESS FIRE!" and when you do it changes the data back to numbers.

Cool. I was looking at bitwise operations on lunch. It is something I haven't really done much with but I see how this can definitely help. When I first started these were probably the more confusing aspects of programming to me. I am slowly getting it. Thanks so very much!

I figured I'd chime in. Graphics for this is amazing. Love the concept. Love the execution. Love the gameplay. I can also see this as a 7800 title. Just saying.

Now I do wonder, I see the playfield variables are formatted something like var31=%00000000. Is it possible to turn on a single bit from that, like var31{4}=1? Would that essentially work like a pfpixel on/off command? (I don't have my computer with me otherwise I would run a simple test on my own )

I plan on looking through the assembly to kind of learn more. I bought the Atari programming book but haven't delved into it too much but I've been looking at all the forum topics to try and get familiar with how it looks and works for when I eventually play around with it. In my program, when I mentioned "weird" values, what I meant was that when I first ran into overcycling issues I changed some values. I generally have a pfpixel drawn when counter reaches 100. Player0 can also pick up pfpixels. Originally I had the values on the counter at an even set of intervals and it seemed that when it drew and erased too many pfpixels at once it would over cycle. My original attempt at troubleshooting was to just change the values to avoid everything happening all at once until I could figure out a better way. For the most part it worked but it really seemed to just kick the can down the road. When I read about playfield variables it got me thinking.

I guess I never really worry about time until it is too late. I know I tend to try to code and then tweak things after to see how I can improve, comparing my original code to see what I can do differently in the future. I still got lots to learn and am very thankful for your explanations.

I understand it makes sense. I know my code is probably bloated with unnecessary statements. As I have been coming up with things I plug it in and see what works. I had one question. What do you mean by the table the kernel uses? Looking at your code I assume that each playfield variable is set up using a table so instead of making a new data table for the variable you just alter the existing one?

Thanks! I just swapped the code and this uses 40 less bytes. I started to play around with my my pfhlines to see if this would also help. For a short pfhline of about 5 pixels I was able to save about 50 bytes BUT I found that if my line extended across a couple playfield variables it may not be worth using it because then I would have to write up some checks to make sure the right pixels turn on or off. This may be helpful later on. I had experienced an issue earlier on where I was trying to turn off a long pfhline and ran into some overcycling so I solved it by having it turn off shorter segments on a timer. This might help free up some more space and cycles.

Ah. I have been slow to use data statements but I understand the principles. I suppose in this instance it would work well because it is a sequence versus a one-off. I will definitely have to check this out later. I was planning on trying to play around with these variables to see how far I can push it.

The game I'm working on would draw pfpixels on a timer and as you can see from the code I posted, I also had it turn on and off pfpixels in a row. I experienced overcycling so I shifted when these were drawn, hence the weird counter numbers like 43 or 87. That kind of worked but I didn't consider other factors like if a pfpixel is removed or potential collision detection with a missile. I do see how pfpixel could work better than a playfield variable but I can see how this could be very beneficial. I wanna learn more about what goes on under the hood and why this uses less. In Bag Boy and Manatee Madness I essentially redraw the entire (or parts) of the playfield and it never had overcycle problems versus a couple pixels being turned on simultaneously. I guess this gets me closer to learning assembly...

Seeing how this worked, I am going to play around with it and see what is possible. It did surprise me how much was saved. It also makes me wonder how this compares to pfhline of pfvline. I might be able to free up even more!

So I swapped my code with using playfield variables versus turning on or off a pfpixel. From what I can tell it seems as though it uses less cycles. I didn't delve entirely into the debugger but I ran the program for a while and under different conditions that the over cycle had occurred with and I did not experience it so I am thinking it may be fixed. Also on a plus side it uses about 300 bytes less. I changed this: if counter = 43 then pfpixel 31 7 on:pfpixel 25 7 off if counter = 51 then pfpixel 30 7 on :pfpixel 31 7 off if counter = 59 then pfpixel 29 7 on :pfpixel 30 7 off if counter = 66 then pfpixel 28 7 on :pfpixel 29 7 off if counter = 73 then pfpixel 27 7 on :pfpixel 28 7 off if counter = 87 then pfpixel 26 7 on :pfpixel 27 7 off if counter = 92 then pfpixel 25 7 on:pfpixel 26 7 off if counter =99 then pfpixel 25 7 off to this: if counter = 43 then var31=%10000000 if counter = 51 then var31=%01000000 if counter = 59 then var31=%00100000 if counter = 66 then var31=%00010000 if counter = 73 then var31=%00001000 if counter = 87 then var31=%00000100 if counter = 92 then var31=%00000010 if counter =99 then var31=%00000000 I understand that my initial method was probably very wasteful and there may be an even better method but I thought this was a good exercise in trying to understand pfpixels and use different ways to change the playfield.

This was standard kernel. I was just trying to slowly understand the workings under the hood. I was gonna play around with using either/or to see if there is a difference. I had came across it in my reading to try and figure out a workable alternative to what I had done and get the same effect. Currently I had pfpixels moving around. I tried to limit their appearance with all else going on and came across that. I will play around with it later on lunch and update on my findings. Thanks!

I had been reading about playfield variables and was curious if there would be any benefit versus using pfpixel to turn on or off playfield pixels? Less cycles? Less bytes? Or if there is no real discernable difference except how it may work with a particular line of code one may fit better?

This looks very impressive! Great job!

This is interesting, as I was just wondering about this when I was reading about the playfield variables and wondered if sprites had something similar.