Bitmap Minikernel

[Lillapojkenpåön]

I would really like this in a dpc+ game! Would it be to much to ask for a dpc+ comptible version?

And looks like this kernel needs some minor update maintenance to look like in the pictures again?

[+Gemintronic]

It's always worth asking. That being said, my strategy would be to consider moving to 7800bas and/or checking out how other people using DPC+ made their title screens.

 

Alas, all I could find for DPC+ examples with large title screen graphics is this:

http://atariage.com/forums/topic/233403-mappy-tia-music-demo-enjoy/

[iesposta]

See DK Arcade 2600 in my signature.

I think I’m the only one so far to use the “Titlescreen Kernel” in game (DPC+ Kernel) as the “how high” screen. The title screen is all batari Basic.

 

That said, the “Titlescreen Kernel” is limited in that it can be called from the game and return to the game, but it is stacking which display routines (96- 42-pixel, Score, 2 Sprites in their own vertical space, etc.), and spaces you choose.

 

I can pass to it the Level so the bottom part “100m” changes and also the number of times to draw the ape: 4 apes, 3 apes, 2 apes, 1 ape (just reusing the 1 ape data over and over).

Unique data for a bitmap the size of 4 apes high in the 48-pixel routine would use a lot of ROM - It’s recommended you use an entire 4K bank for just the Titlescreen Kernel (but you don’t have to use all 4K if you know what the TS Kernel is doing).

 

In my my game the beginning of Bank 6 is the TS Kernel, then I fill the rest of the bank with data and the Basic title screen bB code.

[RevEng]

I would really like this in a dpc+ game! Would it be to much to ask for a dpc+ comptible version?

And looks like this kernel needs some minor update maintenance to look like in the pictures again?

 

A DPC+ version of the bitmap minikernel probably won't happen any time soon, as it would be a complete rewrite. I borrow the 12 or so bytes of ram I need for the bitmap from the standard/multisprite kernel score routine, and restore those variables after usage. I can't do the same for DPC+ score, because it doesn't have 12 bytes of temp ram for it's display code.

 

I'm able to work around that with the titlescreen kernel bitmaps, because I can steal from object position variables instead, and just clear them after the titlescreen is displayed. (it's up to the game to sensibly set object positions after a titlescreen display)

[+Karl G]

If the user were willing to supply the 12 variables, then would this be feasible? E.g.

   dim BitmapKernelStart=o

This would tie up variables o-z leaving a-n, var0-var8, and any freed by dpcspritemax.

 

The other issue would be that the minikernel wouldn't fit into bank 1. One could presumably do a bankswitch, and then execute the minikernel code.

 

I suppose for most users, this would be too big of a price to pay, but if it's not for the OP, I could try my hand at making a custom version.

[Lillapojkenpåön]

I was only planning to use it during my pause and game over loops where I have variables to re-use and time to spare for a bankswitch, probably don't have 12 consecutive vars tho so

dim BitmapKernelVar1=o

dim BitmapKernelVar2=k

etc. would save me alot of trouble.

 

And would be ideal if it could be included anywhere like the titlescreen kernel and only runs when you jump to it or fall into it instead of all the time once included

That would be the fuel I need to justify spending more time on finishing my game!

[+Karl G]

Running the minikernel conditionally might make it a bit more complicated than I am up to tackling at the moment. :-) Are you just wanting to use the bitmap kernel to write text to say "game over" or "paused" or the like instead of using the playfield?

[Lillapojkenpåön]

No that I could live without But when you pause my game the first 3 digits of the score shows how many lives you have left and last 3 how many megablast you have collected and I would really like to be able to show that to the player without having to read a manual, since keeping track of that will be key in the gameplay, so maybe a short pause text followed by LIFE , MEGA and possibly a nice little copyright logo on gameover or a megablast text when executing a megablast, I would do the most out of it! My basic garbage junk would turn into a GAME!!!!!!!!!

[iesposta]

Why can't you just use the assembly routine that Visual bB _Titlescreen Kernel Editor_ makes?

Sure it has its own score, but a Titlescreen with lots of Blank, then the 48-pixel or 96-pixel routine above the Titlescreen Kernel Score isn't that large.

Edited August 2, 2018 by iesposta

[Lillapojkenpåön]

Well I was hoping someone with a little bit more assembly knowledge would cut it out and turn it into a standalone, with the features I suggested, and also had no Idea you could do that? Are you saying the blank space will be transparent and show my playfield and everything else if I do that? And as RevEng said it uses object position variables, but maybe that's easy to change?

[iesposta]

Lillapojkenpåön, on 02 Aug 2018 - 8:02 PM, said:

 

Well I was hoping someone with a little bit more assembly knowledge would cut it out and turn it into a standalone, with the features I suggested, and also had no Idea you could do that? Are you saying the blank space will be transparent and show my playfield and everything else if I do that? And as RevEng said it uses object position variables, but maybe that's easy to change?

No, the TS Kernel draws its own screen, so you are leaving your “batari Basic” game, but you can pass your game score data and display that under a “bitmap Player graphics” in 48- or 96-pixels wide in a Pause Screen, or a Between Levels Screen.

 

Sorry I can’t teach very well.

 

The other point is the less graphic data you create, the smaller this “replacement drawscreen” ROM will be used.

 

Example: this is a Titlescreen I use to display the monkey (same data 1, 2, 3, or 4 times), a bitmap graphic for 59m 100m etc.