Well, low programming skills just means that you haven't learned yet. Nobody's born knowing how to do this.
You don't have to write the tightest code possible, but the way you're structuring things is going to make writing a full game cumbersome to say the least. You have it structured so that every room would have to require a different logic loop. It's not reasonably maintainable.
Do you want help structuring your program better? I'm not sure if you're saying that you plan to keep doing it your way, or if you're saying that you've been doing it your own way because that's all you know and haven't been taught differently.
Do you understand the code I posted? Please ask any questions if you don't. You don't have to do it exactly the same, but please go over it and see if it makes sense to you. Once you start grouping similar logic and using indexed values, you'll be surprised how much smaller and more readable your code can become.
Some more thoughts that I hope will help:
Bookmark this page:
http://www.obelisk.me.uk/6502/instructions.htmlThis is your complete toolset. Everything that you can do is described in detail here. You can see exactly which addressing modes are available to each instruction so that you can figure out how to access the data you want, using what you have available to you.
You've got an accumulator, which holds the data on which you perform general calculations. You have the X register, which will be your primary index. It's faster in some modes. This is what you use to pick which value out of similarly grouped data you want. Do you want to affect object #0, #1, #2, or #3? You put the value in X, and then you can use it to index which byte in memory you're accessing. You start with 0 in this case, because 0 means that the value is offset 0 bytes from the first value. Y works largely the same but has different options. You can use it to track a second object, or keep count of a different value if necessary.
You can also use the X and Y registers to pass data faster than writing and reading it to memory. But you can only do this if you don't need to keep the value in X or Y.
You've also got your flags. These are very important. This is how your program can make "decisions" or go on different logic paths. I'll go over some of the most important stuff.
You've got your zero flag. This simply means that the result of the last computation was zero. This is tested with BEQ (branch if equal zero) or BNE (branch if not equal zero).
Then you've got your carry flag. This one gets a little tricky. It means that the result of the last computation was either more or less than could fit in a byte. The value either went below 0 or above 255. This is how you test if something is higher or lower. The confusing part is that these flags are backwards for subtract. On ADC, it works the way you'd think. adding a total more than 255 results in the carry flag being set. On SBC, subtracting a total less than 0 results in carry flag being cleared. I won't get into why, but some times it works better because it's this way. Sometimes it gets in the way. The point is to remember that it is backwards for SBC.
You've got a positive/negative, flag, and this one is easy to use. Leaving the signed stuff to the side for now, this flag simply means the value of the last computation is greater or equal to $80, or 128. You could also say that the highest bit is set. This is the lowest value that will set the negative flag, and any values greater will also set it: %10000000. BMI will branch if the highest bit is 1. BPL will branch if the highest bit is 0.
Some opcodes affect certain flags and some don't. You can use the link I posted to see exactly which flags are affected by which opcodes.
Everything that you are dealing with is a number. It's not necessarily about being good at math in a general sense because all of the mathematical functions you have are relatively simple, and a lot of them don't translate to math that is applicable outside of binary systems. The point is that it's just about getting good enough at this particular type of math to make the game you want.
When you approach a position where you need to acquire a certain number for one instance and another number for another, look at the opcodes and consider how you can create that result from what's available.
Here's an example:
It's cool that you made the platforms drop faster than they rise. How could you apply this to what I wrote?
Well, I'm currently reversing and adding one, to get the actual negative value.
The value coming in is $FF for moving up one pixel. Se want to get the value 2 out it. Let's write it out in binary:
in = 11111111
out = 00000010
Which bits get flipped and which ones don't?
What binary number do we have to EOR to switch between those two interchangeably?
If you EOR 11111101, $FF becomes 2. If you do it to 2, it becomes $FF.
The same routine now can move all platforms, up and down, with a different falling speed.
The only problem is that since we don't ADC now, we don't get clear the carry again. So we'd have to add a CLC before we loop back to the beginning.