Animan Posted July 3, 2011 Share Posted July 3, 2011 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? Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted July 3, 2011 Share Posted July 3, 2011 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 Quote Link to comment Share on other sites More sharing options...
+batari Posted July 10, 2011 Share Posted July 10, 2011 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. Quote Link to comment Share on other sites More sharing options...
+batari Posted July 10, 2011 Share Posted July 10, 2011 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.) Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted July 11, 2011 Share Posted July 11, 2011 I hope RandomTerrain is adding this information to his batari Basic guide! Michael Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 11, 2011 Share Posted July 11, 2011 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? Quote Link to comment Share on other sites More sharing options...
+batari Posted July 11, 2011 Share Posted July 11, 2011 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 11, 2011 Share Posted July 11, 2011 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 14, 2011 Share Posted July 14, 2011 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 Here's the bB code: pfhalfwidth_test_2011y_07m_14d_0433t.bas Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 15, 2011 Share Posted July 15, 2011 Does anyone know why blank lines are being added? Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 15, 2011 Share Posted July 15, 2011 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 15, 2011 Share Posted July 15, 2011 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. Quote Link to comment Share on other sites More sharing options...
+batari Posted July 15, 2011 Share Posted July 15, 2011 Did a little work on this and I think it's fixed on my end. 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.