Mike_at_AEI Posted March 7 Share Posted March 7 Looking to add a few features to the bB Multisprite Kernel. Why bothers when there is DP+? Well, not all players, carts and emulators can play DPC+ games...and they feel a bit like cheating TBH. + Add the use of PF0 (adds 8 more columns to the playfield and allows full screen use like Adventure) I have that working, sort off as it takes too many cycles and throws off the player positions + Add multi color sprites...maybe with some limits, like only 3 colors per sprite or maybe only player0 + Add Playfield and background colors.. with limits. I have been going through the standard Multisprite code for days and cleaning things up, adding comments (there are almost none) and trying to figure it out. The structure is complex (jumps around a lot) and the cycle count comments do not appear correct. Is there anyone out there that would have some background on this code that I could chat with? Any documentation on its design? I'm almost to the place of feeling like it would be easier to start from scratch..and I don't want to do that. Help?!!? 2 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/ Share on other sites More sharing options...
LatchKeyKid Posted March 7 Share Posted March 7 Sounds like a great project! While I can't help given that I'm still muddling my way through learning just the basics (pun intended) of programming again, I completely agree with you that the multisprite kernel is a valuable tool and alternative to DPC+ for the reasons you mentioned. Your project improvements are basically the reasons I haven't looked at it much myself despite loving the idea of having access to more sprites with automated flicker management. In my case(s), the loss of color both in sprites as well as the playfield and background pretty much shut down any potential for me personally using them. 1 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5424644 Share on other sites More sharing options...
+splendidnut Posted March 7 Share Posted March 7 When I modified the multisprite kernel for 1942 (added multi-colored sprites), I went thru and added some comments and put in the cycle counts which might be helpful. I think adding PF0 support to the one in 1942 might be doable, but it's more a matter of finding the best place to do it. I had to jostle around quite a bit of code just to get the multi-colored sprite support in there. https://github.com/Al-Nafuur/1942-bB/blob/main/src/multisprite_kernel.asm If you have any questions, feel free to ask me. 3 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5424800 Share on other sites More sharing options...
LatchKeyKid Posted March 7 Share Posted March 7 What kind, if any, tradeoff did you have to make to add multicolored sprites to the kernel? Or was it just using CPU cycles that were otherwise not being used to program it in? Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5424819 Share on other sites More sharing options...
+splendidnut Posted March 7 Share Posted March 7 The main thing I did was remove the playfield caching code, which was used to protect against extra cycles during the kernel when the playfield is not page-aligned and helped with playfield updates during the repositioning kernel. I also removed the conditional code used to handle different screen height settings, since that's unnecessary for a one-off project. Outside of that, I had to constrain the multi-color support I added to using a single color table accessed with an index as opposed to allowing color arrays to be freely defined by the user/programmer. This was mostly because the reposition kernel is very tight on timing. There's probably other little details I'm forgetting (it was two years ago)... but the majority of work was in trying not to break the kernel timing. The only re-syncing (WSYNC) is done during the reposition kernel (when the next sprite is loaded), which makes it very difficult to make any changes to the kernel. My goal was to release an updated version that was a bit more flexible with sample code so that others could use it. I do have an updated version, but I'm not sure what state it's in, since I haven't touched it since I last talked about it (last year, maybe?) Looking at it real quick, it appears that I was trying to fix the color-offset issue and that I did end up freeing up a few more cycles in the main kernel... or at least I moved around some free cycles. 2 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5424865 Share on other sites More sharing options...
Mike_at_AEI Posted March 7 Author Share Posted March 7 15 minutes ago, splendidnut said: The main thing I did was remove the playfield caching code, which was used to protect against extra cycles during the kernel when the playfield is not page-aligned and helped with playfield updates during the repositioning kernel. I also removed the conditional code used to handle different screen height settings, since that's unnecessary for a one-off project. Outside of that, I had to constrain the multi-color support I added to using a single color table accessed with an index as opposed to allowing color arrays to be freely defined by the user/programmer. This was mostly because the reposition kernel is very tight on timing. There's probably other little details I'm forgetting (it was two years ago)... but the majority of work was in trying not to break the kernel timing. The only re-syncing (WSYNC) is done during the reposition kernel (when the next sprite is loaded), which makes it very difficult to make any changes to the kernel. My goal was to release an updated version that was a bit more flexible with sample code so that others could use it. I do have an updated version, but I'm not sure what state it's in, since I haven't touched it since I last talked about it (last year, maybe?) Looking at it real quick, it appears that I was trying to fix the color-offset issue and that I did end up freeing up a few more cycles in the main kernel... or at least I moved around some free cycles. Wow. Thanks for this. I have found much the same (very fragile timing due to critical cycle timing and few WSYNC). I too have started with a fixed playfield row height (22 rows, which seem like a decent number (nice squares) and was looking to use a color index table as you have. We are thinking alike (although my thoughts are noob in comparison, I suspect ) I will download your 1942 Multi_sprite kernel and hope that I can transfer what I have found so far. Basically, the PF0 data is added to the top of the Playfield: construct in bB (so there are 44 rows of data (those X's and .'s), 22 for PF0 and 22 for PF1 and PF22, a bit wasteful right now). The index is bumped to look at that address of data when writing to PF0 at start of each new row. 1 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5424874 Share on other sites More sharing options...
Mike_at_AEI Posted March 9 Author Share Posted March 9 (edited) On 3/7/2024 at 9:54 AM, splendidnut said: The main thing I did was remove the playfield caching code, which was used to protect against extra cycles during the kernel when the playfield is not page-aligned and helped with playfield updates during the repositioning kernel. I also removed the conditional code used to handle different screen height settings, since that's unnecessary for a one-off project. Outside of that, I had to constrain the multi-color support I added to using a single color table accessed with an index as opposed to allowing color arrays to be freely defined by the user/programmer. This was mostly because the reposition kernel is very tight on timing. There's probably other little details I'm forgetting (it was two years ago)... but the majority of work was in trying not to break the kernel timing. The only re-syncing (WSYNC) is done during the reposition kernel (when the next sprite is loaded), which makes it very difficult to make any changes to the kernel. My goal was to release an updated version that was a bit more flexible with sample code so that others could use it. I do have an updated version, but I'm not sure what state it's in, since I haven't touched it since I last talked about it (last year, maybe?) Looking at it real quick, it appears that I was trying to fix the color-offset issue and that I did end up freeing up a few more cycles in the main kernel... or at least I moved around some free cycles. I have been looking to find a place in the original Multisprite kernel to fit the PF0 load and really found the best place was the same area you thought for you multi-color tables....so After 3 days of trying to modify the original multisprite kernel, I turned to yours. But, when I use your Multisprite kernel in a basic test game, Sella is telling me it is running at 270+ scanlines! and of course the screen is very jittery. Could this be an older code where the cycle count was not quite on? I was hoping to take out you color tables, the superchip RAM and insert my much simpler PF0 load code. But I need to get your kernel stable first. Thank you for any help or insights. Edited March 9 by Mike_at_AEI Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5426243 Share on other sites More sharing options...
+splendidnut Posted March 9 Share Posted March 9 Alright. Here's a copy of my local version that is a bit more optimized from the one in 1942. It works without Superchip RAM, but seems to still require at least an 8k ROM size to work. Please let me know if you have any questions or if you find any bugs in it. Also, it comes with a little test program. bb-multisprite-with-multicolorsprites_20240309.zip 3 1 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5426256 Share on other sites More sharing options...
+splendidnut Posted March 9 Share Posted March 9 It would be nice if you were able to keep the color table functionality while also including your changes. It might be possible... I see some hints that I was potentially thinking about moving the P1 drawing code to a different/better place. Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5426269 Share on other sites More sharing options...
Mike_at_AEI Posted March 10 Author Share Posted March 10 3 hours ago, splendidnut said: It would be nice if you were able to keep the color table functionality while also including your changes. It might be possible... I see some hints that I was potentially thinking about moving the P1 drawing code to a different/better place. Thank you! I am floored by your gracious help. I will certainly do whatever I can to keep as much functionality as possible while adding PF0 support. Your 1942 game pushed the boundaries of the 2600 and very well received. I will keep you up to date on anything I learn. Mike 1 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5426375 Share on other sites More sharing options...
+splendidnut Posted March 10 Share Posted March 10 Awesome and you're welcome. It's nice to see someone wanting to push batariBasic in new ways. Hopefully you won't have too much difficulty adding PF0 support. Most of the credit for 1942 should go to @homerhomer , @Al_Nafuur , and @Pat Brady . My only contribution was adding the multi-color support to the kernel. ------------ Anyways, I've uploaded my WIP code for the multi-color multi-sprite kernel to GitHub for those who are curious: https://github.com/splendidnut/bB-multicolorsprite-kernel Just a heads up that the cycle count comments are currently a bit off. Also, there may be a few bugs lurking. 3 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5426549 Share on other sites More sharing options...
+splendidnut Posted March 10 Share Posted March 10 I just pushed some updates to the Github repo. I rearranged the GRP1 updates in the kernel and now the color changes happen on the same scanline as the graphics changes. I also fixed the cycle count comments, and they *should* all be correct now. This update provides a bit of room for adding another TIA update near the playfield updates during the main kernel.... the only caveat is that there's probably no cycles available in the repositioning kernel to be able to do the same during mid-screen repositioning. 2 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5426727 Share on other sites More sharing options...
+Al_Nafuur Posted March 10 Share Posted March 10 2 hours ago, splendidnut said: I just pushed some updates to the Github repo. I rearranged the GRP1 updates in the kernel and now the color changes happen on the same scanline as the graphics changes. I also fixed the cycle count comments, and they *should* all be correct now. This update provides a bit of room for adding another TIA update near the playfield updates during the main kernel.... the only caveat is that there's probably no cycles available in the repositioning kernel to be able to do the same during mid-screen repositioning. Will this new kernel work for 1942 bB too? Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5426820 Share on other sites More sharing options...
+splendidnut Posted March 10 Share Posted March 10 10 minutes ago, Al_Nafuur said: Will this new kernel work for 1942 bB too? Potentially. There might need to be some tweaking done as I did jostle around some things and do a bit of remapping of the bB variables (defined in multisprite.h). 1 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5426833 Share on other sites More sharing options...
+splendidnut Posted March 10 Share Posted March 10 I just did a quick test. 1942 currently does not run with the new kernel. I'll have to take a closer look at things. Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5426851 Share on other sites More sharing options...
+Gemintronic Posted March 10 Share Posted March 10 This isn't a bug so I never bugged batari or RevEng. But, if someone could mitigate the virtual sprite flickering when some go off screen. Meaning, when any vitual sprite crosses the screen boundaries vertically there's a chance all virtual sprites will momentarily flicker. I haven't found a way to work around it and have dropped some game projects like a scrolling pinball game. Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5426868 Share on other sites More sharing options...
+splendidnut Posted March 11 Share Posted March 11 I just did some limited testing (with my kernel, if that makes a difference) with the virtual sprites. There is currently no 'clipping' done with virtual sprites; once a virtual sprite starts to cross the screen edge, it disappears completely. There also seems to be an issue with the player1 virtual sprite that will cause a nearby sprite to disappear completely when player1 starts to move off screen. Those both seem like bugs to me... that could potentially be fixed. Also, I did get this kernel working with 1942 to a certain degree. The code I added to support scrolling the playfield using playfieldpos interferes with 1942, because 1942 sets the playfield pointers manually. This experiment also revealed that there are still a few bugs lurking. 1 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5427233 Share on other sites More sharing options...
+Lewis2907 Posted March 13 Share Posted March 13 splendidnut, I tried using your zip file and when I use Bb I get the below error. Not sure of the fix maybe an issue on my end. Compiling D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas [3/12/2024 5:19:15 PM] bblint found the following errors in exMultiSpriteColorKernel.bas warning(98): missing matching end to " asm" warning(): Found 17 commands that use end, and 16 "end" commands. Precompilation failed, aborted at 3/12/2024 5:19:35 PM Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5428060 Share on other sites More sharing options...
+splendidnut Posted March 13 Share Posted March 13 While I'm not familiar with bblint, I think that's a false positive. It's complaining about a missing 'end' statement that's not missing at all. The 'asm' is on line 98... and the 'end' statement for it is on line 108. It should compile using bBasic v1.7. That's the version Atari Dev Studio is using on my system. Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5428139 Share on other sites More sharing options...
+Lewis2907 Posted March 13 Share Posted March 13 Thanks. I started to play with Dev Studio some. I did notice the bottom of the errors when I tried to compile it and play around. I think it's the C Header files that are used with Dev Studio, but I could be wrong. Hopefully someone can assist me with your template as I would like to experiment with more in Bb. [3/12/2024 10:33:33 PM] bblint found the following errors in exMultiSpriteColorKernel.bas warning(87): missing matching end to " asm" warning(): Found 17 commands that use end, and 16 "end" commands. char = '{' 123 (-1: 0) char = '}' 125 (-1: 50) char = '{' 123 (-1: 114) char = '}' 125 (-1: 49) char = '{' 123 (-1: 114) char = '}' 125 (-1: 49) not within a macro D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (251): error: Unknown Mnemonic 'macro'. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (252): error: Not enough args passed to Macro. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (253): error: Illegal character '{2}'. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (253): error: Illegal character '}'. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (254): error: Not enough args passed to Macro. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (255): error: Illegal character '{1}'. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (255): error: Illegal character '}'. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (255): error: Syntax Error 'player{1}'. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (256): error: Not enough args passed to Macro. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (257): error: Illegal character '{1}'. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (257): error: Illegal character '}'. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (257): error: Syntax Error 'player{1}'. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (294): error: Unknown Mnemonic 'setSpriteGraphics'. D:\13. Batari Basic\4. My Files\bb-multisprite-with-multicolorsprites_20240309\exMultiSpriteColorKernel.bas.asm (2212): error: Unknown Mnemonic 'endifstart'. Unrecoverable error(s) in pass, aborting assembly! Complete. Errors were encountered during assembly. Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5428168 Share on other sites More sharing options...
+splendidnut Posted March 13 Share Posted March 13 You could always try removing that macro: ;--- remove the macro for setSpriteGraphics Start player0x = 76 player0y = 25 ;-- add/uncomment these lines: player0pointerlo = _Player0_Plane_up_low player0pointerhi = _Player0_Plane_up_high ;-- remove the following: asm setSpriteGraphics 0, _Player0_Plane_up end It was an experiment to try and make it easier to set the player graphics pointers. 1 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5428244 Share on other sites More sharing options...
+Lewis2907 Posted March 13 Share Posted March 13 Thanks. I tried and still get the same error. A little above what I'm able to do as far as programming. Thanks again for trying to help me with the code. Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5428401 Share on other sites More sharing options...
+splendidnut Posted March 13 Share Posted March 13 My only other suggestion is to try compiling without bblint. Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5428438 Share on other sites More sharing options...
LatchKeyKid Posted June 1 Share Posted June 1 On 3/7/2024 at 9:54 AM, splendidnut said: The main thing I did was remove the playfield caching code, which was used to protect against extra cycles during the kernel when the playfield is not page-aligned and helped with playfield updates during the repositioning kernel. I also removed the conditional code used to handle different screen height settings, since that's unnecessary for a one-off project. Outside of that, I had to constrain the multi-color support I added to using a single color table accessed with an index as opposed to allowing color arrays to be freely defined by the user/programmer. This was mostly because the reposition kernel is very tight on timing. There's probably other little details I'm forgetting (it was two years ago)... but the majority of work was in trying not to break the kernel timing. The only re-syncing (WSYNC) is done during the reposition kernel (when the next sprite is loaded), which makes it very difficult to make any changes to the kernel. My goal was to release an updated version that was a bit more flexible with sample code so that others could use it. I do have an updated version, but I'm not sure what state it's in, since I haven't touched it since I last talked about it (last year, maybe?) Looking at it real quick, it appears that I was trying to fix the color-offset issue and that I did end up freeing up a few more cycles in the main kernel... or at least I moved around some free cycles. I finally started looking at the multisprite kernel and remembered your work posted here and had a few questions now that I've tinkered around a bit with it (albeit in a very beginner fashion). Regarding the single color table, is there a limit to how many colors are on it or a limit to how to how many times a sprite can change colors from line to line? Is it difficult (for a n00b) to set up the table and do you define the colors similar to player1colors over in the standard kernel? And, to push my luck as its unrelated to your kernel mod but rather a general question, do virtual sprites all have to have the same player1height in the multisprite kernel? Thanks in advance for any info you can share regarding these questions. Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5478022 Share on other sites More sharing options...
+splendidnut Posted June 1 Share Posted June 1 For the multisprite kernel, each virtual sprite has it's own height variable: player1height .. player5height. ---- For my multi-color multi-sprite kernel, the single color table has to be page-aligned and is typically limited to a max of 168 bytes (256 - screen height of 88). All sprites change color line-by-line. The COLUPx variables are used to index into the color table and no longer directly change the sprite's color register. I've added a 'Basic Setup and Usage' section to the README.md on Github: https://github.com/splendidnut/bB-multicolorsprite-kernel/blob/main/README.md 2 Quote Link to comment https://forums.atariage.com/topic/362717-modifying-the-multisprite-kernel-its-complex-for-sure/#findComment-5478159 Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.