Jump to content
IGNORED

Modifying the Multisprite Kernel ... its complex for sure


Mike_at_AEI

Recommended Posts

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?!!?

  • Like 2
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

Posted (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 by Mike_at_AEI
Link to comment
Share on other sites

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

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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).

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.
 

image.thumb.png.02d9e12262223b13130a0ddd36e8c3e8.png

 

 

 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...