We have on and off with the playfield, but what about "no action"

[+Random Terrain]

I know that we can use the following to setup the playfield:

 

   playfield:
  X.X...X..XX..X.XX.X....XX..X.X..
  X.X....XX..X.X..X.X...X..XX..X.X
  X.X....XX..X.X..X.X...X..XX..X.X
  X.X....XX..X.X..X.X...X..XX..X.X
  X.X....XX..X.X..X.X...X..XX..X.X
  X.X....XX..X.X..X.X...X..XX..X.X
  X.X....XX..X.X..X.X...X..XX..X.X
  X.X....XX..X.X..X.X...X..XX..X.X
  X.X....XX..X.X..X.X...X..XX..X.X
end

 

But what if you wanted to make a change to a section of the playfield and leave most of the playfield alone and you can't use pfpixel or pfhline or pfvline? It would be cool if we could use a symbol that means "do nothing" or "no action". I'll just pick the question mark for now since I have seen it used as a placeholder before. So if I wanted to change a part of the playfield and leave the rest alone, I could use something like this:

 

   playfield:
  ????????????????????????????????
  ????????????????????????????????
  ????????????????????????????????
  ????????????????????????????????
  ????????????????????????????????
  ????????????????????????????????
  ????????????????X.X...X........X
  ????????????????X.X...X..X...X.X
  ????????????????X.....X..XX..X.X
end

 

Do you think that could be possible in a future version of bB or would it even be possible to do now with a little hacking of one of the kernels?

 

 

 

Thanks.

Edited April 17, 2008 by Random Terrain

[+batari]

That's a good idea and it should be possible, but it will require writing it into the compiler, so you'll have to wait for me to get around to coding it. Come to think of it, I could have used such a feature a number of times

 

Also, I'm looking into improving the compilation of playfield drawing commands when using all integers as arguments, as they are incredibly slow right now. With integers, they can theoretically be optimized such that we only create a set of direct assembly writes to the playfield based on what has changed, instead of just twiddling bits in a slow loop as is done now. But once this mechanism is in place, the playfield command you mention should be easy to add.

[+Random Terrain]

That's a good idea and it should be possible, but it will require writing it into the compiler, so you'll have to wait for me to get around to coding it. Come to think of it, I could have used such a feature a number of times

 

Also, I'm looking into improving the compilation of playfield drawing commands when using all integers as arguments, as they are incredibly slow right now. With integers, they can theoretically be optimized such that we only create a set of direct assembly writes to the playfield based on what has changed, instead of just twiddling bits in a slow loop as is done now. But once this mechanism is in place, the playfield command you mention should be easy to add.

That would be great. I hope you'll have time to add it.

 

I have ideas for games that would create the playfield by letting the game randomly select a piece to fill in each area of the playfield (I'd probably split the playfield up into 6 areas). Each area would probably have 5 to 10 pieces that could be used, so you could have some randomness in how the playfield is created while keeping tight control over exactly what is displayed.

[MausGames]

I've wanted this same feature for the same reasons many times, but I assumed it was impossible. The example you posted has 6 lines of "?"s at the top, I think you would set a playfield pointer instead or that would take up a lot of unnecessary space if you are only altering the bottom half of the playfield.

 

Batari, I think if you define a playfield table that is shorter than the last one drawn, it garbles the remaining playfield rows. So if I only want to change the first 3 rows of playfield, and call a playfield table that's 3 rows tall, it doesn't just write those 3 rows and leave the rest alone, it replaces them with random pixels. It needs to not do this, so that if the above feature is added, single or any combination of playfield rows can be drawn starting at any row without distorting what is above and below.

[+batari]

I've wanted this same feature for the same reasons many times, but I assumed it was impossible. The example you posted has 6 lines of "?"s at the top, I think you would set a playfield pointer instead or that would take up a lot of unnecessary space if you are only altering the bottom half of the playfield.

The compiler might be able to minimize space. The idea I had was to draw the playfield internally within the compiler itself and reverse-engineer what was drawn into a series of simple loads and stores (and possibly AND/OR masking.) If the playfield data plus the routine to copy it to RAM exceeds the space of a number of simple loads and stores, then just use the loads and stores.

 

That was also the basic plan for reducing the cycle cost of pf drawing commands. They are so painfully slow now that they almost can't be used in the main loop of a game.

Batari, I think if you define a playfield table that is shorter than the last one drawn, it garbles the remaining playfield rows. So if I only want to change the first 3 rows of playfield, and call a playfield table that's 3 rows tall, it doesn't just write those 3 rows and leave the rest alone, it replaces them with random pixels. It needs to not do this, so that if the above feature is added, single or any combination of playfield rows can be drawn starting at any row without distorting what is above and below.

You're right, as the playfield drawing command hard-codes in a value equal to the playfield vertical resolution and disregards the number of rows you actually enter. This is easy to fix, as the number of rows are counted already. I guess it never occurred to me that someone would want to define a partial playfield.

[+Random Terrain]

The example you posted has 6 lines of "?"s at the top, I think you would set a playfield pointer instead or that would take up a lot of unnecessary space if you are only altering the bottom half of the playfield.

Yeah, that was just an example. Whether it's pointers or question marks, as long as we'll be able to change any part of the playfield without affecting the rest of the playfield, I'll be happy. Whatever is easier for batari to do.

[SeaGtGruff]

I would leave the full playfield in the bB program, and let the compiler chop out everything it doesn't need. That way the programmer can look back at the program and see "Okay, I was changing just this part of the playfield."

 

Michael

[jbs30000]

Add me into the list of people who would love partial screen change. Right now, the only way I've done it is use pfhline or pfvline to "erase" part of the screen (write over an image), then use pfpixel, pfhline, and/or pfvline to draw the new image.

 

I'm also looking forward to seeing the new and improved bB. Oh oh, I think I'm addicted to writing games for a 25 or 30 year old game system

[lord_mike]

Add me into the list of people who would love partial screen change. Right now, the only way I've done it is use pfhline or pfvline to "erase" part of the screen (write over an image), then use pfpixel, pfhline, and/or pfvline to draw the new image.

 

There's another way to do it, but it's not pretty--directly modify the bits in the playfield variables... You can find them here: http://www.atariage.com/forums/index.php?s...p;hl=memory+map

 

(why isn't that post pinned, or combined with the user guide?... It is really crucial to debugging!)

 

I'm also looking forward to seeing the new and improved bB. Oh oh, I think I'm addicted to writing games for a 25 or 30 year old game system

 

Me too... Any idea when it will be ready, Batari? Thanks for all your work!

[+Random Terrain]

There's another way to do it, but it's not pretty--directly modify the bits in the playfield variables... You can find them here: http://www.atariage.com/forums/index.php?s...p;hl=memory+map

Wow, that's not pretty and it's a pain in the butt, but it does work. I'll see if I can do anything with that until batari gives us a better way.

 

 

 

(why isn't that post pinned, or combined with the user guide?... It is really crucial to debugging!)

If it's OK with CurtisP, I could add it. I don't think he has posted since Jan 1, 2008, so is it possible to ask him anything?

[jbs30000]

This other post by CurtisP from not too long ago should help

http://www.atariage.com/forums/index.php?s...=playfield+var0

Edited April 18, 2008 by jbs30000

[+Random Terrain]

This other post by CurtisP from not too long ago should help

http://www.atariage.com/forums/index.php?s...=playfield+var0

Yeah, that's what lord_mike was talking about. Kind of a pain in the butt, but at least it works. It will be even easier when batari does his magic.

[jbs30000]

Yeah, that's what lord_mike was talking about. Kind of a pain in the butt, but at least it works.

Opps, my mistake.

It will be even easier when batari does his magic.

True. I can't wait to see how it turns out.