Plans for new kernals?

[CurtisP]

It turns out that rows of six sprites is much easier to do. I could do up to eight rows pretty easily, but six rows looks best. For now I'm going with loose spacing, but putting them right next to each other might also be possible.

Would it also be possible to do a similar thing with multicolored sprites?

 

Here's another thing I wish could be possible in a new kernel. It has to do with the score. Would it be possible for the score to only show the digits used so far? If the score is 10, only 10 would be shown instead of 000010. If the score is 8,000, only 8,000 would be shown instead of 008000. And added to that, could a comma be added once the score hits the thousands? For example, instead of 100742 we would see 100,742.

 

The way six players on a line is done is by setting NUSIZ0 and NUSIZ1 so that you have three copies of each player, with either wide or close spacing, then setting the X positions so that each copy of Player 1 closely follows Player 2, so you have either

1 2 1 2 1 2

or

121212

 

Then, during each line, three different values are written into GRP0 and GRP1 each. Thus resulting in the appearance of six different players.

 

Unfortunately, the limited number of cycles available during each scanline, means that the there isn't enough time to set each of the six "virtual" players their own color. The best that can be done is to give the copies of Player 1 one color and Player 2 another color.

 

Now it should be possible to change these colors every scan line, but this would mean that three of the virtual players would share the same multicolors. I was going to allocate 12 memory locations for player colors so you that the odds and evens could have different colors for each row of sprites, something like this:

R Y R Y R Y

Y R Y R Y R

R Y R Y R Y

G B G B G B

O W O W O W

W O W O W O

 

For the score, there is no way to add a space in the middle, so it would not be possible to add in a comma.

 

It is possible to have score_graphics.asm have spaces. I think I can do a quick hack that runs in vblank which would clear all the leading zeros and would not require changes to the kernal or score_graphics.asm. I will put this on my to-do list.

[+Random Terrain]

It is possible to have score_graphics.asm have spaces. I think I can do a quick hack that runs in vblank which would clear all the leading zeros and would not require changes to the kernal or score_graphics.asm. I will put this on my to-do list.

Thanks. I'd love to get rid of those leading zeros.

[jrok]

It turns out that rows of six sprites is much easier to do. I could do up to eight rows pretty easily, but six rows looks best. For now I'm going with loose spacing, but putting them right next to each other might also be possible.

Would it also be possible to do a similar thing with multicolored sprites?

 

Here's another thing I wish could be possible in a new kernel. It has to do with the score. Would it be possible for the score to only show the digits used so far? If the score is 10, only 10 would be shown instead of 000010. If the score is 8,000, only 8,000 would be shown instead of 008000. And added to that, could a comma be added once the score hits the thousands? For example, instead of 100742 we would see 100,742.

 

The way six players on a line is done is by setting NUSIZ0 and NUSIZ1 so that you have three copies of each player, with either wide or close spacing, then setting the X positions so that each copy of Player 1 closely follows Player 2, so you have either

1 2 1 2 1 2

or

121212

 

Then, during each line, three different values are written into GRP0 and GRP1 each. Thus resulting in the appearance of six different players.

 

Unfortunately, the limited number of cycles available during each scanline, means that the there isn't enough time to set each of the six "virtual" players their own color. The best that can be done is to give the copies of Player 1 one color and Player 2 another color.

 

Now it should be possible to change these colors every scan line, but this would mean that three of the virtual players would share the same multicolors. I was going to allocate 12 memory locations for player colors so you that the odds and evens could have different colors for each row of sprites, something like this:

R Y R Y R Y

Y R Y R Y R

R Y R Y R Y

G B G B G B

O W O W O W

W O W O W O

 

For the score, there is no way to add a space in the middle, so it would not be possible to add in a comma.

 

It is possible to have score_graphics.asm have spaces. I think I can do a quick hack that runs in vblank which would clear all the leading zeros and would not require changes to the kernal or score_graphics.asm. I will put this on my to-do list.

 

This actually reminds me of a possible alternate kernal I've been thinking about. In the current multisprite kernal, all of the 5 virtual sprites are drawn by GRP1. I was curious how difficult it would be to create a kernal that draws three virtual sprites with GRP1 and three with GRP0. I guess the advantage to this that I was envisioning was that you could have multiple instances of two flicker-free sprites on a given scanline, rather than just one (GRP0 with any of the virtual GRP1 sprites). I think this might be good for games where all of the GRP0 and GRP1 sprites are limited in their vertical range, and no more than one P0 and one P1 will appear on any given line.

 

Cheers,

Jarod.

Edited July 31, 2009 by jrok

[Jess Ragan]

What's been added to Batari BASIC in the four years since I stopped using the compiler? I don't think I ever got a straight answer to this question.

[+Random Terrain]

What's been added to Batari BASIC in the four years since I stopped using the compiler? I don't think I ever got a straight answer to this question.

An older variation of my version of the bB page used to have this on it:

 

 

 

Overview

 

Below is an unofficial overview of some of the most important changes:

• The old 4K limitation is gone. We now can have up to 32K of ROM! See Bank Switching. You'll also want to check out return otherbank and return thisbank.
  
  • 128 additional bytes of RAM are now available, but it requires special treatment (rubber gloves, a gas mask and a Geiger counter ). See Superchip RAM.
    

  _

  [*]There are major changes using the set command, one of which can give us multicolored sprites! Now you can make the Imagic/Activision type of sprites you've always dreamed of! See Compiler Directives.

  • smartbranching
    
  • tv: ntsc, pal
    
  • romsize
    
  • optimization: inlinerand, noinlinedata, size, speed
    
  • kernel
    
  • kernel_options: background, no_blank_lines, pfcolors, pfheights, player1colors, playercolors, readpaddle
    
  • debug: cycles, cyclescore
    
  • legacy
    

   

   

  [*]We have been given more control over the playfield than ever before. Change the height and color of each row! We can also change the vertical resolution from 3 to 11 using pfres. See Compiler Directives and Playfield.

  _

  [*]We can have a "life counter" that will show up to six icons to represent player lives and a "status bar" that can indicate health, time, power, speed, and so on. We can also turn off the score using noscore. See Minikernels/HUDs and pfscore bars.

  _

  [*]We no longer have a two sprite limit. We can now have six, one sprite that is pretty much normal and five 'virtual' sprites, but there are limitations and quirks. See Multisprite Kernel. The multisprite kernel also allows us to adjust the height of the screen using screenheight.

  _

  [*]If you ever wanted to cancel a return, like turning a gosub into a goto, now you can with pop.

  _

  [*]Check out the new data related commands sdata and sread under Sequential Data.

  _

  [*]There is a new command called vblank that is closely related to drawscreen.

  _

  [*]If your game doesn't need to remember anything such as a high score, you'll love reboot. It will clear everything.

  _

  [*]Those familiar with include may be interested in the new command called inline.

  _

  [*]There is a new section called Ephemeral Variables & Registers that everyone should read.

[RevEng]

Here's what I'd love to see - a multisprite kernel with asymmetric playfield.

 

Yes, I know the cycles aren't there to do it straight. But what if you only updated the playfield every other line, and left the other ones blank? On the next frame, the playfield line drawn could dropped down a line.

 

Or if if there aren't enough cycles still, then just every fourth line, and in the second frame the playfield line could be dropped 2 lines.

 

Such a kernel would be *very* useful for a variety of games, and I think the missing playfield lines is an acceptable trade-off.