12 replies to this topic

[Animan]

Is it possible to use a mirrored playfield in the standard kernal? Will it allow me to free up the playfield variables on the right side, since those pixels are basically mirrored from the left pixels? Or do I have to use the six sprite kernal to do this?

[SeaGtGruff]

Animan, on Sun Jul 3, 2011 3:28 PM, said:

Is it possible to use a mirrored playfield in the standard kernal? Will it allow me to free up the playfield variables on the right side, since those pixels are basically mirrored from the left pixels? Or do I have to use the six sprite kernal to do this?

You'll have to modify the kernel to do that.

Michael

[batari]

The latest standard kernel does allow for reflected playfields and variables may be freed.

I believe the command needed is "const pfhalfwidth=1"

I don't recall offhand what variables are freed. I'll have to look into that.

[batari]

OK, I think by default the variables freed are var24-var47, but since this is an undocumented feature, it's probably not well tested. If someone wishes to test and report back, feel free.

Alternatively, I think you can also set pfres higher, up to 24, and get double vertical resolution, and this will use up the remaining "var" variables.

Also, another feature is you can create a 16-wide playfield about the center using "const pfhalfwidth=1" and "const pfcenter=1" which was created to allow block puzzle games (of which a couple have been made.)

[SeaGtGruff]

I hope RandomTerrain is adding this information to his batari Basic guide!

Michael

[Random Terrain]

SeaGtGruff, on Sun Jul 10, 2011 6:09 PM, said:

I hope RandomTerrain is adding this information to his batari Basic guide!

So is this only for the new DPC+ beta version of batari Basic or are we talking about the regular version?

[batari]

This is for the standard kernel.

Before it is documented, it probably needs some testing. If anyone wants to try it out, feel free and report back.

[Random Terrain]

batari, on Mon Jul 11, 2011 1:01 AM, said:

This is for the standard kernel.

Before it is documented, it probably needs some testing. If anyone wants to try it out, feel free and report back.

Thanks.

[Random Terrain]

There seems to be blank lines between each row.

This:

   playfield:
   XXXXXXXXXXXXXXXX
   X..............X
   X..............X
   X..............X
   XXXXXXXXXXXXXXXX
end

Ends up looking like this:

   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   X              XX              X

   X              XX              X

   X              XX              X

   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Here's the .bin file to use with an emulator:

 pfhalfwidth_test_2011y_07m_14d_0433t.bin   4K   19 downloads


Here's the bB code:

 pfhalfwidth_test_2011y_07m_14d_0433t.bas   2.21K   19 downloads

[Random Terrain]

Does anyone know why blank lines are being added?

[RevEng]

The playfield command doesn't appear to generate playfield data that's compatible with the new feature - it's still generating 4 bytes of rom data, even though your playfield is 2 bytes wide. From the generated assembly...

PF_data0
 .byte %11111111, %11111111, %00000000, %00000000
 .byte %10000000, %10000000, %00000000, %00000000
 .byte %10000000, %10000000, %00000000, %00000000
 .byte %10000000, %10000000, %00000000, %00000000
 .byte %11111111, %11111111, %00000000, %00000000

...when I remove the right two bytes the data from each line and assemble it, it looks like it should.

[Random Terrain]

RevEng, on Thu Jul 14, 2011 8:17 PM, said:

The playfield command doesn't appear to generate playfield data that's compatible with the new feature - it's still generating 4 bytes of rom data, even though your playfield is 2 bytes wide. From the generated assembly...

Oh, OK. Thanks.

[batari]

Did a little work on this and I think it's fixed on my end.