BenMcLean

This is great! Thanks Random Terrain.

Depth first search isn't really "modern game theory" ... it's just an algorithm and most of the work on it was done in the '70s unless I am greatly mistaken. Anyway, I have come up with a reason why this won't work: there is no fast enough way to check whether or not you've already searched a particular square before in order to avoid going in circles in your search path. You'd have to progress back through the entire stack at each square you search and that would almost certainly be prohibitively expensive. I'll just have to think of something else. Or maybe use a grid with bigger/fewer squares ... hmm. Will keep thinking this over.

Given that you can really only go three gosubs deep, (six bytes reserved / two bytes per gosub = three gosubs) obviously I would want to use goto for the recursion in this case, not gosub, and keep track of how deep in the recursion I am with variables. I do plan to use individual gosub/return pairs within each iteration in order to abstract some parts of the algorithm that are used multiple times. I don't think I'd need to write any actual assembly for this. It seems like it should be doable within Batari Basic.

Random Terrain's web site says, "The DPC+ stack can be used to save and restore your bB variables. There are 256 stack locations available, with the top-most location being #0 and the bottom-most being #255.... Note: The DPC+ stack is a special stack just for you that is 100% dedicated to your push and pull commands. Nothing else uses it. It's all yours." According to this, I should have 256 bytes of stack space that is only for my program, (not used by the kernel) which is used by the push and pull commands. This would be separate from and in addition to the 26 bytes used for variables and the six bytes used for the gosub and return commands. Is that true or not?

I have been thinking about using the stack to do depth first search pathfinding for enemies to get around playfield obstacles when chasing the player. If it ran out of stack space before finding the player then it would throw the search away and revert to some simpler rule set for it's next move. I would try to have it get closer to catching the player within the limits of the Atari 2600's stack by biasing the search in favor of moving towards the player. (always searching in that direction first) This might enable it to get around at least some simple obstacles intelligently. Is this doable? Has it ever been done in an Atari 2600 game? (I haven't actually played all that many) (later edit) Or wait ... the search should be backwards from what I said. It should push the path from the player's position to the enemy's position so that the enemy can pull it's next destination coordinates in the order it needs to follow.

I must have made a typo when I had already tried what you were suggesting before I posted because the method you suggested works now. Thanks. I finally got playfield collision prevention working, albeit with the rule that all horizontal surfaces in my playfield must be at least 2 blocks long to prevent moving through them vertically. (since I'm only pfreading the edges of the player's box facing the direction the player is moving in, and the player's box is wider than a single playfield block) default.bas Now the tricky part is going to be collision prevention and pathfinding for the enemies. ^_^

I get a syntax error when I try to do more than one pfread in an if-then statement. What's going on with that and how can I fix it? default.bas

OK thanks very much.

No, I didn't know that. Thanks for telling me. Random Terrain's site should probably mention that right here.

I've been trying to build something with collision detection and I got the basic idea to store the sprite's current position in temporary variables, move the sprite to the place I want to check, and move it back to where I'd previously stored if there is a playfield obstacle in the way, while leaving the change permanently if it's clear. But for some reason, that basic concept doesn't seem to work. It gets stuck on the first obstacle encountered and cannot move anymore. Any idea why it's doing this? I'm guessing there's something about how sprite positions and/or the Atari's memory work that I'm not getting. A code example that produces this effect (which I've trimmed away most of the other stuff in my program) is attached. The score color changes if collision(player0, playfield) is true default.bas

Not really, but your pointing it out at this juncture suggests that to be on the multisprite kernel, I would say "set kernel multisprite" and I haven't said that in the above program, so I'm not on the multisprite kernel and I can use pfread without a module. Is that right?

What does it really mean to be on the multi-sprite kernel? I have multiple sprites and I've selected kernel options to enable me to use multiple sprites, so does that mean I'm on the multi-sprite kernel? Or do you mean by posting this to say that I'm not actually on the multi-sprite kernel with those kernel options?

I get the error: pfread_msk.asm (1): error: Label mismatch... --> pfread f268 Unrecoverable error(s) in pass, aborting assembly!when I try to add "inline pfread_msk.asm" to the end of my code. Test case: set smartbranching on set kernel_options player1colors playercolors pfcolors main goto main inline pfread_msk.asmAny idea what that's about?

Apparently, all I needed to do was say $11 and it works now. Great! Thanks! I'm gonna message RandomTerrain to suggest that his chart should say $11 instead of $1x Then I've got to figure out that inline command

The chart says $1x, where (x = don't care). But I can try $11, sure.