Great Exploitations

Are you...

 

Using the score bit of CTRLPF to make the left side of the PF white and the right side black until half the screen is white, then you turn off the score bit, make the players and the PF white and use the players and the missiles (tripled and as wide as possible) to make the left side white, set the PF back to all blank and then use the PF to fill in the right side?

 

If that makes sense, anyway...

 

...

 

Er, no reason to use the score-bit. Just use the players/missiles to fill the left side, once it's full, leave them there and use the PF to fill the right.

 

 

Or...?

Aha - the shiny object syndrome has claimed another victim Anyway, it looks good - I'm glad that you found the SC skeleton code to be useful. I think that you are doing the progress bar simply by setting the carry and then ROR/ROL-ing the PF registers??

 

Chris

You both may be on the right track, but not right Any other guesses?

Okay, how about this:

 

Score bit again:

 

Background black, left PF white, right PF black.

 

Roll bits into PF registers to fill left side until half of the screen is full.

 

Then set background to white and shift bits out of the PF registers until PF is empty and screen is all white. ??

Okay, how about this:

 

Score bit again:

 

Background black, left PF white, right PF black.

 

Roll bits into PF registers to fill left side until half of the screen is full.

 

Then set background to white and shift bits out of the PF registers until PF is empty and screen is all white.  ??

Yup

 

Cooler than the SC barn door, yet still takes just few scanlines to set the whole thing up. With a few scanlines for a safety margin and a few scanlines for VSYNC, we get >240 scanlines of pure calculation per frame.

Cool.

Since the maze is in RAM, it can be dynamic. You could add the ability to break through the maze under certain circumstances.

 

Maybe try something like that.

Since the maze is in RAM, it can be dynamic. You could add the ability to break through the maze under certain circumstances.

 

Maybe try something like that.

Yes, you can already place walls to help with solving.

 

I've been thinking about how to measure your "score." I think I'm leaning toward making it timed. So far I have solved a few mazes. I have found that it takes me 5-10 minutes to solve one, so breaking through a wall could add 10 minutes to your time.

 

There will be an option to generate a particular maze (there are 65535 possible mazes) or regenerate the current maze in the event that you painted yourself into a corner by placing walls in the wrong places. There will also be an option to create a braided maze.

 

You can also make the 2600 solve the maze for you using a dead-end remembering algorithm, and you can try to beat its time.

 

The solitary maze solving is what makes this different than Maze Craze, as the mazes in the original were too simple to provide any sort of mental challenge, so it had to be made a 2-player game. However, I am not sure what to do to make this a two-player game, or if I even want to try. Two players can just try for the best time on a particular maze,

taking turns or on two different systems (or emus.)

 

I think that a braided maze lends itself to more of a cops and robbers thing (like Supercat said in another thread) so I might add this to braided mazes only. Braided mazes aren't suitable for automatic maze solving *, so this option may not be included.

 

All in all, this seems best suited as a puzzle game rather than an action game.

 

* on the 2600. Braided mazes can be solved easily using the "flood fill" algorithm on a modern computer, as it would require 8k of RAM, and every byte needs to be updated for every move. The only workable way to solve on a 2600 is by dead reckoning, which is pretty lame.

You can also make the 2600 solve the maze for you using a dead-end remembering algorithm, and you can try to beat its time.

 

How about showing the computer solving the maze using another sprite, and the idea is to beat this sprite to the finish?

 

Also, would it be possible to remove the gaps between PF rows, e.g. using self-modifying code in the kernel?

 

Chris

* on the 2600. Braided mazes can be solved easily using the "flood fill" algorithm on a modern computer, as it would require 8k of RAM, and every byte needs to be updated for every move. The only workable way to solve on a 2600 is by dead reckoning, which is pretty lame.

 

The Pledge Algorithm will exit any braided maze whose exit is on the perimeter.

You can also make the 2600 solve the maze for you using a dead-end remembering algorithm, and you can try to beat its time.

 

How about showing the computer solving the maze using another sprite, and the idea is to beat this sprite to the finish?

My original idea was for the computer to place blocks at dead-ends, which wouldn't work well.

 

But I could do this if I can figure out a way to "virtually" lock out dead ends without using a ton of RAM while at the same time not requiring a huge table to search serially, and also not lock the computer out of a player's dead ends.

 

Maybe I could say that in this mode, each player gets a limited number of dead-end markers, and going over the maximum would eliminate old ones on a FIFO basis.

 

Also, would it be possible to remove the gaps between PF rows, e.g. using self-modifying code in the kernel?

 

Chris

Are the gaps really that annoying?

 

Yeah, I know, with a SC, it almost seems that you are required by law to use self-modifying code since it opens up so many possibilities. But I'm not a great kernel programmer and am sort of dreading doing this.

* on the 2600. Braided mazes can be solved easily using the "flood fill" algorithm on a modern computer, as it would require 8k of RAM, and every byte needs to be updated for every move. The only workable way to solve on a 2600 is by dead reckoning, which is pretty lame.

 

The Pledge Algorithm will exit any braided maze whose exit is on the perimeter.

* looks it up

 

Yes, that should work. And it doesn't seem to require placing blocks anywhere, so it might work for a perfect maze too.

 

I'll still need to think of a way to limit the number of blocks that the player can place, or remove this feature when competing with the computer.

Are the gaps really that annoying?

 

It might be nice to offer an option in the bB kernel to allow a uniformly-striped playfield (i.e. blank every other row). Also, for some games, it would be helpful to use something other than zero on the blank playfield rows (e.g. when using the playfield to mask sprites).

Are the gaps really that annoying?

 

It might be nice to offer an option in the bB kernel to allow a uniformly-striped playfield (i.e. blank every other row).

Good idea.

 

Also, I think this will free up enough cycles to read two paddles or stripe players if desired.

Also, for some games, it would be helpful to use something other than zero on the blank playfield rows (e.g. when using the playfield to mask sprites).

Just did this (was painfully easy.)

Are the gaps really that annoying?

Yeah, I know, with a SC, it almost seems that you are required by law to use self-modifying code since it opens up so many possibilities. But I'm not a great kernel programmer and am sort of dreading doing this.

 

I guess the gaps are not too annoying, but it would look better without them. Personally I find kernel programming to be the most interesting (and often frustrating) part of 2600 coding.

 

Chris

Are the gaps really that annoying?

Yeah, I know, with a SC, it almost seems that you are required by law to use self-modifying code since it opens up so many possibilities. But I'm not a great kernel programmer and am sort of dreading doing this.

I guess the gaps are not too annoying, but it would look better without them.

I can't help, but I like those gaps. After a few games written, they might even become a trademark of bB.

 

Personally I find kernel programming to be the most interesting (and often frustrating) part of 2600 coding.

Same here, but probably with less frustration.