Multisprite Kernel - Surplus graphics data on second-to-last bank?

[PixRuss]

Hey guys,

 

Last night while working some more on Night Watch at Wilford's, I ran into an issue where bank 4 in my program (16k btw) kept filling up and getting overloaded.

The game uses relatively high-res playfield graphics (pfheight = 1; stored in ROM) and will likely have a good variety of sprites when it's finished, so the fact that this is happening shouldn't bee all that shocking.

 

I am considering dropping the playfield resolution a tad to save space, but even then I'm not sure if that will totally solve the problem or even sell the effect I'm aiming for with the graphics.

 

Is there any way to let surplus graphics data onto other banks of the program, or to direct the program to store it on a different bank? Any asm code or kernel hacks I can do? (Keep in mind I know nothing about assembly) Any other tips or tricks?

 

Thanks!

[+Gemintronic]

Al_Nafuur uses a technique that makes sprites use normal data statements that aren't forced into the last bank.  This also lets many virtual sprites share said data.  The tradeoff is added complexity.

https://github.com/Al-Nafuur/PlusROM-Hacks/blob/main/bBasic/1942/1942 HSC.bas

 

I haven't figured out how to use Al_Nafuurs technique from code in other banks.  So, the main game engine must be in the same bank as your shared sprite data.

 

The best I've been able to do is put my sprite and playfield loading code in the second to last bank and DON"T touch the last bank except for mini kernels.  I figure whatever overhead labels and setup code has no longer resides with the graphic data in the last bank.  Maybe a small savings?

 

Sometimes if you're clever you can make a generic playfield that uses sprites as part of the screen.  Say, a door or wall.  Why have two separate playfields when you can just block off exits with a sprite to make a different room?

 

Also, you can alter the pfheight during the game to make the static playfield look different.  Maybe a room with a central opening looks like a long hallway if the pfheight is increased.

 

[orange808]

Here's the thread:

 

There's a macro in there you will probably want.

[+Gemintronic]

Should have also posted my simple demo of the technique at work.  oops!

 

[+Karl G]

The reason you can't have image data in other banks is because the display kernel runs in the last bank, and reads it in real time as the screen is being drawn. If the data is in a different bank, the display kernel can't see it, and it doesn't have time to switch banks to read data, and then switch back while the screen is in the middle of being drawn.

[+Gemintronic]

10 minutes ago, Karl G said:

The reason you can't have image data in other banks is because the display kernel runs in the last bank, and reads it in real time as the screen is being drawn. If the data is in a different bank, the display kernel can't see it, and it doesn't have time to switch banks to read data, and then switch back while the screen is in the middle of being drawn.

 

Would it make sense to use the second-to-last bank as the main draw event bank.  Using Al_Nafuur technique for sprite data (2nd to last) AND normal sprite data statements (last bank).  Would that effectively double the graphic data you can use?  Maybe putting game logic in other banks and jumping to the second-to-last bank for screen drawing?

 

[orange808]

Seems like it would be easier to make the rom bigger and "redundantly" place the kernel in more than bank. Each bank of data could be used for different stages or something like that.

 

Could also switch to bB DPC kernel.

Edited April 13, 2022 by orange808

[+Karl G]

7 minutes ago, orange808 said:

Seems like it would be easier to make the rom bigger and "redundantly" place the kernel in more than bank. Each bank of data could be used for different stages or something like that.

That's the idea behind @RevEng's Multikernel Framework, which effectively overcomes the 4K graphics limit if you plan your game to take advantage of it.

[PixRuss]

On 4/12/2022 at 11:08 PM, Karl G said:

That's the idea behind @RevEng's Multikernel Framework, which effectively overcomes the 4K graphics limit if you plan your game to take advantage of it.

Gonna try and rework my code to work with this framework!