RevEng Posted December 3, 2013 Author Share Posted December 3, 2013 The multi-kernel framework uses its own score_graphics file, so no. The score graphics there would need its own modification to have an extra space character. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 4, 2013 Share Posted December 4, 2013 . . . we now have the ability to reduce the number of DPC+ virtual sprites, so unused vsprite memory can be reclaimed ("set dpcspritemax #", where # is a number from 1-9) So, if I use "set dpcspritemax 4" that means that I can use the following 15 as variables: player5x, player5y, NUSIZ5 player6x, player6y, NUSIZ6 player7x, player7y, NUSIZ7 player8x, player8y, NUSIZ8 player9x, player9y, NUSIZ9 Question #1: Are there any other variables that I'm forgetting? Question #2: Can all of those be used with dim? Update: After RevEng's reply, I now know that using "set dpcspritemax 4" would give us 20 extra variables: player5x, player5y, NUSIZ5, player5height player6x, player6y, NUSIZ6, player6height player7x, player7y, NUSIZ7, player7height player8x, player8y, NUSIZ8, player8height player9x, player9y, NUSIZ9, player9height Using "set dpcspritemax 3" would give us 24 extra variables: player4x, player4y, NUSIZ4, player4height player5x, player5y, NUSIZ5, player5height player6x, player6y, NUSIZ6, player6height player7x, player7y, NUSIZ7, player7height player8x, player8y, NUSIZ8, player8height player9x, player9y, NUSIZ9, player9height Using "set dpcspritemax 2" would give us 28 extra variables: player3x, player3y, NUSIZ3, player3height player4x, player4y, NUSIZ4, player4height player5x, player5y, NUSIZ5, player5height player6x, player6y, NUSIZ6, player6height player7x, player7y, NUSIZ7, player7height player8x, player8y, NUSIZ8, player8height player9x, player9y, NUSIZ9, player9height Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 4, 2013 Author Share Posted December 4, 2013 1. player5height -> player9height 2. yes 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 4, 2013 Share Posted December 4, 2013 1. player5height -> player9height Thanks. My brain must not be working correctly tonight because I don't remember what player#height is or does and I can't find it on the bB page. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 4, 2013 Share Posted December 4, 2013 I think we all recognize your work as a gynourmously huge gift RevEng. I don't expect you to maintain squat. I just really appeciate you, jwierer and CPUWIZ teaming up to make batari BASIC continue to shine. UPDATE: I would mention R.T. for maintaining the batari BASIC command reference but I depend on that so much it's just part of living and can safely be ignored. 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 4, 2013 Author Share Posted December 4, 2013 Thanks. My brain must not be working correctly tonight because I don't remember what player#height is or does and I can't find it on the bB page. Its a variable that automatically gets set to the player's height as part of the player#: command. Its handy to know about, because you can use it to make a player "melt away" (or the reverse) without changing the player#: command, just by decreasing the value. I think we all recognize your work as a gynourmously huge gift RevEng. I don't expect you to maintain squat. I just really appeciate you, jwierer and CPUWIZ teaming up to make batari BASIC continue to shine. Thanks man, that means a lot to me. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 4, 2013 Share Posted December 4, 2013 Its a variable that automatically gets set to the player's height as part of the player#: command. Its handy to know about, because you can use it to make a player "melt away" (or the reverse) without changing the player#: command, just by decreasing the value. Thanks. I don't think that's on the bB page yet. Looks like I need to add it. Does it only work with the DPC+ kernel? Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted December 4, 2013 Share Posted December 4, 2013 In response to the loon's post, I second his appreciation to RevEng for his hard work on bB (and for his help with my personal projects) and to Random Terrain for maintaining bB documentation on his web page. Thanks to both of you for your hard work. I wish I had more time to be active on AA and contribute more often, my work and personal life has prevented it for most of this year. My AtariVox has been calling my name for months, I will get around to making a bB game with voice, hopefully next year. 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 4, 2013 Author Share Posted December 4, 2013 Thanks AM! Thanks. I don't think that's on the bB page yet. Looks like I need to add it. Does it only work with the DPC+ kernel? It works with the standard and multisprite kernels too. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 4, 2013 Share Posted December 4, 2013 It works with the standard and multisprite kernels too. Thanks. Now I see them in the Memory Maps. I didn't know anything about them until now. Seems like a useful thing to know about. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 4, 2013 Share Posted December 4, 2013 I think we all recognize your work as a gynourmously huge gift RevEng. I don't expect you to maintain squat. I just really appreciate you, jwierer and CPUWIZ teaming up to make batari BASIC continue to shine. Yeah, I couldn't do anything without batari's bB, jwierer's VbB, RevEng's bB fixes and tools, code posted by various better programmers than I am, and so on. This latest change by RevEng might give me enough variables to make a DPC+ game that I'd like to play. 20 or 24 or 28 extra variables aren't as good as having 48 extra variables, but it's a lot better than only having 26. We might have enough extra variables now to cure my DPC+ depression. I can live with 5 multicolored single-height sprites or maybe even 4 or 3 if I have to. And I don't need any pats on the back for maintaining the bB page. The page is as much for me as it is for anyone else. The people who should get pats on the back are batari, SeaGtGruff, RevEng, Robert M, and anyone else who provided text and example code for the page. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 14, 2013 Share Posted December 14, 2013 When anyone gets a chance, please take a look at these sections and see if they need to be edited: www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_dpcspritemax www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#playerheight Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 14, 2013 Author Share Posted December 14, 2013 They look good to me. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 14, 2013 Share Posted December 14, 2013 They look good to me. OK, thanks. If you or anyone reading this notices anything I forgot to add to any other section, please let me know. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 30, 2013 Author Share Posted December 30, 2013 Version 28 is in the first post. bug-fix: Previously the "end" for inline assembly had to follow a non-empty line, or else the preparser would format bB commands following it as inline asm, screwing up the rest of the compile. feature: the DPC+ pfscroll command now has 2 optional values to indicate the start and end queue to scroll... pfscroll 1 : rem as before, scrolls the DPC+ playfield one line pfscroll 1 0 1 : rem scrolls the left half of the screen one line pfscroll 1 2 3 : rem scrolls the right half of the screen one line pfscroll 1 0 4 : rem scrolls the playfield and PF colors one line. pfscroll 1 4 4 : rem scrolls the PF colors one line. A note on the last 2 examples. Due to the way the kernel updates PF colors, to keep colors lock-step with the PF graphics you should either set DF4FRACINC to twice the # of DF[0-3]FRACINC fetchers, or scroll the PF queues twice as much as the 4th (color) queue. 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 31, 2013 Author Share Posted December 31, 2013 RT, when you get a chance can you add one note to the DPC+ collision documentation? "The DPC+ collision is pixel perfect, but doesn't take hardware-reflected sprites into account." I don't think there's a lot I can do to change this situation. There isn't enough space to add code to flip the bits of any reflected vsprite prior to testing. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 31, 2013 Author Share Posted December 31, 2013 Version 29 is in the first post. It has fixes for the following bugs... bug: player0y=0 started display on the second scanline, while virtual sprites displayed on the first scanline. This skew also threw off pixel-perfect DPC+ soft collision detection. bug: DPC+ soft collision detection had an off-by-one bug, resulting in some glancing collisions going undetected. Be warned that existing DPC+ bBasic code may need to be adjusted for the new player0y range. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 31, 2013 Share Posted December 31, 2013 RT, when you get a chance can you add one note to the DPC+ collision documentation? "The DPC+ collision is pixel perfect, but doesn't take hardware-reflected sprites into account." I don't think there's a lot I can do to change this situation. There isn't enough space to add code to flip the bits of any reflected vsprite prior to testing. Yep, I'll add that and I'll also see what needs to be changed based on your last two updates (within the next day or two as I let the info sink into my brain). Thanks. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 5, 2014 Share Posted January 5, 2014 Version 28 is in the first post. bug-fix: Previously the "end" for inline assembly had to follow a non-empty line, or else the preparser would format bB commands following it as inline asm, screwing up the rest of the compile. feature: the DPC+ pfscroll command now has 2 optional values to indicate the start and end queue to scroll... pfscroll 1 : rem as before, scrolls the DPC+ playfield one line pfscroll 1 0 1 : rem scrolls the left half of the screen one line pfscroll 1 2 3 : rem scrolls the right half of the screen one line pfscroll 1 0 4 : rem scrolls the playfield and PF colors one line. pfscroll 1 4 4 : rem scrolls the PF colors one line. A note on the last 2 examples. Due to the way the kernel updates PF colors, to keep colors lock-step with the PF graphics you should either set DF4FRACINC to twice the # of DF[0-3]FRACINC fetchers, or scroll the PF queues twice as much as the 4th (color) queue. The last version of this used "pfscroll [value]" or "pfscroll [variable]". Can variables be used for the other two values? If not, can the first be a variable if two numbers follow it? Speaking of the optional values, is what you posted the only values that can be used? If not, is there some way that bB users can know what they can use without needing to type in every number combination they can think of to see what is possible? Thanks. Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 5, 2014 Author Share Posted January 5, 2014 Right now variables won't work for the queue numbers, but you can still use a variable for the scrolling value, even if you add queue values. The 2 numbers after the scroll value represent the start and end DPC+ queue numbers. They match the same DPC+ queue numbers used in the DF#FRACINC resolution settings. i.e. 0=left PF data 1=middle-left PF data 2=middle-right PF data 3=right PF data 4=PF color data So you just pick the things you want to scroll. Remember its a range, so using "0 2" will scroll 0,1 and 2. (3/4 of the playfield) 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 5, 2014 Author Share Posted January 5, 2014 Version 30 is in the first post. DPC+ bug: I had used so much space in the first bank with recent additions, that the extra space used by the kernel option "collision(THING,THING)" could cause bad things to happen. To free up space and get everything working, I've made the blank score digit space mutually exclusive with this kernel option. If you use one, you can't use the other. Special thanks to Atarius Maximus for the bug report! Quote Link to comment Share on other sites More sharing options...
iesposta Posted January 5, 2014 Share Posted January 5, 2014 Version 30 is in the first post.DPC+ bug: I had used so much space in the first bank with recent additions, that the extra space used by the kernel option "collision(THING,THING)" could cause bad things to happen.To free up space and get everything working, I've made the blank score digit space mutually exclusive with this kernel option. If you use one, you can't use the other.Special thanks to Atarius Maximus for the bug report! What does kernel option "collision thing, thing" give you? Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 5, 2014 Author Share Posted January 5, 2014 It gives the Y coordinate of the first such collision. RT has it documented. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 6, 2014 Share Posted January 6, 2014 Right now variables won't work for the queue numbers, but you can still use a variable for the scrolling value, even if you add queue values. The 2 numbers after the scroll value represent the start and end DPC+ queue numbers. They match the same DPC+ queue numbers used in the DF#FRACINC resolution settings. i.e. 0=left PF data 1=middle-left PF data 2=middle-right PF data 3=right PF data 4=PF color data So you just pick the things you want to scroll. Remember its a range, so using "0 2" will scroll 0,1 and 2. (3/4 of the playfield) Thanks. 0 through 3 now make sense to me. I'll post some examples to help make things clearer to myself and to ask a couple of questions. In the examples below, pfcolors: data is outside of the main loop. Hold down the fire button to scroll. pfscroll 1 0 0 dpcpfscroll_1_0_0.bin pfscroll 1 0 1 dpcpfscroll_1_0_1.bin pfscroll 1 0 2 dpcpfscroll_1_0_2.bin I don't need an example for "pfscroll 1 0 3" since it's the same as "pfscroll 1" pfscroll 1 3 3 dpcpfscroll_1_3_3.bin pfscroll 1 2 3 dpcpfscroll_1_2_3.bin pfscroll 1 1 3 dpcpfscroll_1_1_3.bin All examples above scroll the playfield without scrolling the color. This example scrolls the color of the playfield without scrolling the playfield itself: pfscroll 1 4 4 dpcpfscroll_1_4_4.bin After the colors start scrolling off the screen, the colors displayed are yellow, then black, then it's back to the colors below again: pfcolors: $0E $0C $0A $08 $06 $1E $1C $1A $18 $16 $2E $2C $2A $28 $26 $3E $3C $3A $38 $36 $4E $4C $4A $48 $46 $5E $5C $5A $58 $56 $6E $6C $6A $68 $66 $7E $7C $7A $78 $76 $9E $9C $9A $98 $96 $AE $AC $AA $A8 $A6 $BE $BC $BA $B8 $B6 $CE $CC $CA $C8 $C6 $DE $DC $DA $D8 $D6 $EE $EC $EA $E8 $E6 $3E $3C $3A $38 $36 $4E $4C $4A $48 $46 $5E $5C $5A $58 $56 $6E $6C $6A $68 $66 end Seems like you'd need to have a lot more pfcolors: data to get rid of the yellow and black. The example below scrolls pfcolors: data and the playfield: pfscroll 1 0 4 dpcpfscroll_1_0_4.bin When the fire button is held long enough for everything to scroll back on the screen again, we lose a little color at the top of what is scrolling back in (turns black). The yellow at the bottom is just because I wasn't using enough pfcolors: data. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 8, 2014 Share Posted January 8, 2014 When you get a chance, see if this is OK the way it is or if it needs to be edited: randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_pfscroll 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.