Need opinions on multisprite kernel

[+batari]

I'm working at getting the multisprite kernel integrated into bB.

 

So the problem right now is with RAM. There's just not enough. Initially it seemed like there was, but that was before I found that the new kernel stores graphics pointers and sprite heights in ROM, which is bad from a compilation standpoint if you want to allow any sprite to have any graphics and any height. So this needs to be moved to RAM, but this requires 15 bytes that simply aren't there.

 

So I'm needing to make a compromise. I can do one of the above.

 

I'm leaning toward #2, since this kernel uses a playfield that is only 16 pixels wide and symmetrical about the center, so it's not well-suited for plotting individual pixels and lines anyway. You would define the entire playfield in one command. You could change the playfield at will, but you'd have to change the whole thing at once.

 

 

Let me know what you think.

[supercat]

I'm leaning toward #2, since this kernel uses a playfield that is only 16 pixels wide and symmetrical about the center, so it's not well-suited for plotting individual pixels and lines anyway.  You would define the entire playfield in one command.  You could change the playfield at will, but you'd have to change the whole thing at once.

987031[/snapback]

 

Although it's the RAM-based playfield that allows the two-sprite BB to be something other than a Firefly Construction Set, I tend to think its advantages are diminished when using a multi-sprite kernel.

 

On the other hand, it would be good to allow playfield scrolling. If the kernel can allow for the playfield to cross page boundaries without trouble, that might be nice. Even if it cannot, that would not be a showstopper since a game could "piece together" different bits of playfield if they started and ended with ending sections. For example, for a "river raid" game, one could have a number of different areas which all start and end with a medium-width single river. Jumping from one area to another would thus be invisible to the player.

[+batari]

I'm leaning toward #2, since this kernel uses a playfield that is only 16 pixels wide and symmetrical about the center, so it's not well-suited for plotting individual pixels and lines anyway.  You would define the entire playfield in one command.  You could change the playfield at will, but you'd have to change the whole thing at once.

987031[/snapback]

 

Although it's the RAM-based playfield that allows the two-sprite BB to be something other than a Firefly Construction Set, I tend to think its advantages are diminished when using a multi-sprite kernel.

 

On the other hand, it would be good to allow playfield scrolling. If the kernel can allow for the playfield to cross page boundaries without trouble, that might be nice. Even if it cannot, that would not be a showstopper since a game could "piece together" different bits of playfield if they started and ended with ending sections. For example, for a "river raid" game, one could have a number of different areas which all start and end with a medium-width single river. Jumping from one area to another would thus be invisible to the player.

987036[/snapback]

With either option there would be scrolling (only up or down, of course), it would just be handled a little differently with each option.

 

With #2, you would specify the entire scroll area statically. The page boundaries cannot be crossed due to timing restrictions, but this isn't too restricting since one page could have PF1 and one PF2, and you could scroll throughout the entire page. Assuming a 12-pixel-high playfield, you could have a scroll area 21 "screens" high. If you get to the end of the scroll area, you could either start over or begin a new scroll area in another page, but in either case you'd need to have at least one "screen" of overlap to make it seamless.

[SeaGtGruff]

I'm working at getting the multisprite kernel integrated into bB.

 

So the problem right now is with RAM.  There's just not enough.  Initially it seemed like there was, but that was before I found that the new kernel stores graphics pointers and sprite heights in ROM, which is bad from a compilation standpoint if you want to allow any sprite to have any graphics and any height.  So this needs to be moved to RAM, but this requires 15 bytes that simply aren't there.

 

So I'm needing to make a compromise.  I can do one of the above.

 

I'm leaning toward #2, since this kernel uses a playfield that is only 16 pixels wide and symmetrical about the center, so it's not well-suited for plotting individual pixels and lines anyway.  You would define the entire playfield in one command.  You could change the playfield at will, but you'd have to change the whole thing at once.

 

 

Let me know what you think.

987031[/snapback]

 

Could you provide both solutions using alternate kernels? Then the programmer could select which include file to use to get the kernel he or she wanted. Also, is the original kernel going to be retained as an alternate, so that any existing bB programs won't be broken by the new version? I know most everyone is eager to get the multi-sprite capability, but it seems to me that most games tend to have rather specific kernels anyway, as dictated by the needs of the game. I'd rather see a collection of different canned kernels which could be selected from. In fact, it might be nice to have a SET comand for specifying which kernel to compile into the game, like "set kernel=original" or "set kernel=multisprite".

 

Michael Rideout

[djmips]

duh... what are the options again?

[s0c7]

I was about to ask the same thing. Would like to see the old kernel retained even if it isn't the default.

 

Would it be possible to load multiple kernels per game? Say you created a 32k program that used one for one section of a game and then a different one for another section?

Edited December 22, 2005 by s0c7

[supercat]

With #2, you would specify the entire scroll area statically.  The page boundaries cannot be crossed due to timing restrictions, but this isn't too restricting since one page could have PF1 and one PF2, and you could scroll throughout the entire page.  Assuming a 12-pixel-high playfield, you could have a scroll area 21 "screens" high.  If you get to the end of the scroll area, you could either start over or begin a new scroll area in another page, but in either case you'd need to have at least one "screen" of overlap to make it seamless.

987046[/snapback]

 

Is the plan to do playfield stuff on even lines and sprite stuff on odd lines, or what's the intention?

 

If there's a reasonable minimum height for playfield pixels, the code for handling each playfield "row" could be spread over several scan lines. Load the new values into temp. RAM locations and then once all are fetched load them all into PF0-PF2 (or PF1-PF2 if you don't like PF0).

[+Random Terrain]

I vote for whichever one gives us the most freedom. I just don't know which one that is.

 

I'm more interested in the future versions with smaller Playfield Pixels and multicolored sprites.

[supercat]

If there's a reasonable minimum height for playfield pixels, the code for handling each playfield "row" could be spread over several scan lines.  Load the new values into temp. RAM locations and then once all are fetched load them all into PF0-PF2 (or PF1-PF2 if you don't like PF0).

987056[/snapback]

 

Continuing...

 

Depending upon the application, it may be useful to use a pointer-list structure. Each two-byte pointer could contain an address and a number of lines (1-7) to be read from that address. Processing playfield rows under such a structure would take more kernel time than using a single straight bitmap, but it would allow for selcted lines of the playfield to be read from RAM.

 

Oodles of ways to do things, and what's right for one application may not be right for another. BTW, are you planning to multiplex both players or just one?

[+batari]

I'm working at getting the multisprite kernel integrated into bB.

 

So the problem right now is with RAM.  There's just not enough.  Initially it seemed like there was, but that was before I found that the new kernel stores graphics pointers and sprite heights in ROM, which is bad from a compilation standpoint if you want to allow any sprite to have any graphics and any height.  So this needs to be moved to RAM, but this requires 15 bytes that simply aren't there.

 

So I'm needing to make a compromise.  I can do one of the above.

 

I'm leaning toward #2, since this kernel uses a playfield that is only 16 pixels wide and symmetrical about the center, so it's not well-suited for plotting individual pixels and lines anyway.  You would define the entire playfield in one command.  You could change the playfield at will, but you'd have to change the whole thing at once.

 

 

Let me know what you think.

987031[/snapback]

 

Could you provide both solutions using alternate kernels? Then the programmer could select which include file to use to get the kernel he or she wanted. Also, is the original kernel going to be retained as an alternate, so that any existing bB programs won't be broken by the new version? I know most everyone is eager to get the multi-sprite capability, but it seems to me that most games tend to have rather specific kernels anyway, as dictated by the needs of the game. I'd rather see a collection of different canned kernels which could be selected from. In fact, it might be nice to have a SET comand for specifying which kernel to compile into the game, like "set kernel=original" or "set kernel=multisprite".

 

Michael Rideout

987050[/snapback]

This is an alternate kernel. Probably accessible through set kernel=multisprite as you suggested. Doing nothing will invoke the original kernel by default.

 

I just have time for one option right now. Integrating new kernels is a lot more work than I thought it would be. Maybe later I can go wild on alternate kernels.

Edited December 22, 2005 by batari

[+batari]

Would it be possible to load multiple kernels per game?  Say you created a 32k program that used one for one section of a game and then a different one for another section?

987055[/snapback]

It will take quite a bit of fancy coding to allow multiple kernels in one game, so in the next release, no. But eventually, yes.

[+batari]

If there's a reasonable minimum height for playfield pixels, the code for handling each playfield "row" could be spread over several scan lines.  Load the new values into temp. RAM locations and then once all are fetched load them all into PF0-PF2 (or PF1-PF2 if you don't like PF0).

987056[/snapback]

 

Continuing...

 

Depending upon the application, it may be useful to use a pointer-list structure. Each two-byte pointer could contain an address and a number of lines (1-7) to be read from that address. Processing playfield rows under such a structure would take more kernel time than using a single straight bitmap, but it would allow for selcted lines of the playfield to be read from RAM.

Well, it might be an idea for a later kernel. The current kernel is basically done and I probably won't have time for too many alternatives if I want to get a release out around the first week of Jan. Though it should be possible to allow varying the "pixel" height with the kernel and not be fixed at 16 scanlines. I'll have to look into this.

Oodles of ways to do things, and what's right for one application may not be right for another.  BTW, are you planning to multiplex both players or just one?

987066[/snapback]

One sprite is multiplexed and one has free roam of the whole screen. I'm looking into intelligent flicker for the multiplexed sprite, but no promises here (yet.)

[+Random Terrain]

It will take quite a bit of fancy coding to allow multiple kernels in one game, so in the next release, no.  But eventually, yes.

987102[/snapback]

This is an alternate kernel.  Probably accessible through set kernel=multisprite as you suggested.  Doing nothing will invoke the original kernel by default.

987099[/snapback]

That's cool. We could eventually have a nice selection to choose from depending on what we needed. Multiple sprites, multicolored sprites, smaller Playfield Pixels, Multicolored Playfield Pixels, and so on.

[+batari]

It will take quite a bit of fancy coding to allow multiple kernels in one game, so in the next release, no.  But eventually, yes.

987102[/snapback]

This is an alternate kernel.  Probably accessible through set kernel=multisprite as you suggested.  Doing nothing will invoke the original kernel by default.

987099[/snapback]

That's cool. We could eventually have a nice selection to choose from depending on what we needed. Multiple sprites, multicolored sprites, smaller Playfield Pixels, Multicolored Playfield Pixels, and so on.

987107[/snapback]

That's the idea. For the next release, you should get about a half-dozen new kernels, two of which are fundamentally different from the default kernel, and the rest will be minor variations on the default kernel.

[+Random Terrain]

If I knew how to tap dance, I'd be doing it right now. I still don't think I should vote in this thread because I don't understand the benefits of the choices yet.

[SeaGtGruff]

Well crap, I had a long bitchy post written about how we should all start writing our own bB custom kernels and other tricks instead of whining to batari to add stuff for us, and I lost my connection and the post got wiped out! I guess it's just as well.

 

Anyway, I was basically trying to point out that a lot of really cool things can be done in bB right now, without any new commands or features having to be added by batari. For example, we can create custom kernels using only bB code (here's an example, the Atari rainbow); or defining the playfield with binary data sort of the way it's done in Adventure; or putting player data in a strip of ROM data and displaying the desired shape by pointing bB to it; or even creating modifiable player shapes by putting the player data in RAM!

 

For the player example, push up to see a circle, push left to see a square, and push right to see a triangle.

 

For the RAM player example, move the snake around. The positioning is buggy, the snake doesn't turn correctly, but it should work well enough to give an idea of what I was trying to accomplish.

 

Michael Rideout

playfield_example.bas

playfield_example.bas.bin

player_example.bas

player_example.bas.bin

ram_player_example.bas

ram_player_example.bas.bin

reverse_rainbow_2.bas

reverse_rainbow_2.bas.bin

[+Random Terrain]

Thanks for the examples. My sleep got messed up (or fixed), so I have to go to bed now. I'll check those out tomorrow. Can we make our own small playfield pixels or multicolor sprites in the same way or is that a job for batari or other pros?

[SeaGtGruff]

Thanks for the examples. My sleep got messed up (or fixed), so I have to go to bed now. I'll check those out tomorrow. Can we make our own small playfield pixels or multicolor sprites in the same way or is that a job for batari or other pros?

987231[/snapback]

 

To create small playfield pixels, you can write a custom kernel, but it depends on where you want to store the data-- RAM or ROM. The neat thing about the existing bB kernel is that the playfield data is stored in RAM, so it makes it easier for a beginner to create a simple playfield display-- and that's adequate enough for games like Adventure and Superman, which used big blocks (many scan lines tall) for the playfield (castles, city skylines, mazes, etc.). If you want to get the data from a ROM table yourself as you're drawing the playfield, you can create a simple custom kernel in your program.

 

Ditto with multicolor sprites, you can store the shape and color data for each scan line (or pair of scan lines, whatever your vertical resolution is going to be) and move the data into the registers yourself in the kernel.

 

If you use the M-Network bankswitching ability that I made custom includes for a while back, you can store the data in the expanded RAM areas.

 

I didn't mean to sound bitchy or whatever, and my original lengthy post was not so much a rant (well, OK, it was sort of a rant) as an urging for everyone to get creative and try to do things with bB as it is, much the same way you would with assembly-- which, after all, doesn't have multicolor sprite commands and such, you have to write the code yourself. First off, bB's original documentation states that it's intended in part to be a stepping-stone to learning assembly programming. And as I see it, the most spectacular thing about bB isn't how easy it makes it to do certain things (like put a player on the screen), but rather its sheer flexibility and ability to be customized via user-written include files. My point is that we really aren't limited to bB's builtin commands or canned kernel, we can use it as a tool for writing fancy stuff of our own. That is, just because bB has a canned kernel doesn't mean we can't write kernels of our own.

 

Also, creative ideas are fine for coming up with cool solutions, but a big part of programming success (for me, at least, because I'm not a great programmer) is to be too stupid to know your own limits (so you aren't afraid to try something that everybody smarter than you insists is impossible), and to be too stubborn to know when to quit (so you keep trying until you either succeed, or accomplish something different from what you intended, but that's pretty cool in its own right)!

 

I know that bB is a wonderful programming platform in its own right, but a big part of what makes it so incredibly powerful is not any of the canned stuff that it gives us to work with, but rather the ability to build nifty tools (routines) of our own. The only way we'll ever be able to unlock the full potential of bB is to write our own kernels or routines with it, otherwise we're stuck with whatever canned kernels or routines batari is able to add to it.

 

Not that I mind batari's efforts to add new canned features and stuff-- I think he's doing a super spectacular job, and bB is pretty awesome even as it is now.

 

By the way, a while back I was trying to compare bB with BASIC (for my tutorial which I want to do), and my point was that bB isn't really BASIC, because it has only a few of BASIC's commands, it has many of its own commands that aren't in BASIC, some of its operators (logical operators) are more like C than BASIC, etc. (my real point being that since bB isn't BASIC, we can't expect to be able to type in a BASIC program listing and compile it with bB). But the other night I was searching for information on the original BASIC, and I discovered that BASIC originally had only 15 commands-- almost all of which are already available in bB (although a couple of them behave very differently)! So I guess bB really is a dialect of BASIC!

 

BASIC's original 15 commands, and whether or not bB has them:

 

LET yes

READ no

DATA yes (but behaves differently)

PRINT no (not yet, but maybe soon)

GOTO yes

IF-THEN yes

FOR yes

NEXT yes

END yes (but behaves differently)

STOP no

DEF no

GOSUB yes

RETURN yes

DIM yes (but behaves differently)

REM yes

 

Michael Rideout

[Retro Archaeologist]

wow seaatgruff, great examples !, i am looking at them now very cool and gives me a better understanding than i had before thank you.

 

RA

[+Random Terrain]

To create small playfield pixels, you can write a custom kernel, but it depends on where you want to store the data-- RAM or ROM. The neat thing about the existing bB kernel is that the playfield data is stored in RAM, so it makes it easier for a beginner to create a simple playfield display-- and that's adequate enough for games like Adventure and Superman, which used big blocks (many scan lines tall) for the playfield (castles, city skylines, mazes, etc.). If you want to get the data from a ROM table yourself as you're drawing the playfield, you can create a simple custom kernel in your program.

 

Ditto with multicolor sprites, you can store the shape and color data for each scan line (or pair of scan lines, whatever your vertical resolution is going to be) and move the data into the registers yourself in the kernel.

 

If you use the M-Network bankswitching ability that I made custom includes for a while back, you can store the data in the expanded RAM areas.

987248[/snapback]

I don't want to sound bitchy either, but I could also grow wings and fly if I really, really wanted to. That stuff sound great for people who already understand that stuff, but I'd never be able to figure out how to create my own kernels like those. It requires too much knowledge of the guts. If I knew and could understand that much, I wouldn't need batari Basic.

 

 

 

. . .as an urging for everyone to get creative and try to do things with bB as it is, much the same way you would with assembly-- which, after all, doesn't have multicolor sprite commands and such, you have to write the code yourself.

987248[/snapback]

Well, boo-hoo. Assembly doesn't have multicolor sprite commands, so batari Basic shouldn't either? Sounds like the ghost of assembly is getting jealous. Assembly doesn't have some of the other easy to use commands that batari Basic already has, so should we remove those commands too? I don't see why batari Basic users should be punished because assembly is lacking easy to use commands. Assembly is like crawling 5,000 miles on your hands and knees. Things like batari Basic should be like traveling that same distance, not by car, but by jet airplane. You get to the same destination, you just get there much faster with less wear and tear on your body and mind.

 

 

 

First off, bB's original documentation states that it's intended in part to be a stepping-stone to learning assembly programming.

987248[/snapback]

That's a great intention, but only some people will be able to do it. The rest of us will only be ale to handle the most simple of assembly programming jobs. If batari Basic can become a more powerful tool with every update, why not let it? Why fight it? The ghost of assembly might be screaming in your ears, but he can "talk to the hand" if he tries to dump his baggage on me.

 

 

 

My point is that we really aren't limited to bB's builtin commands or canned kernel, we can use it as a tool for writing fancy stuff of our own. That is, just because bB has a canned kernel doesn't mean we can't write kernels of our own.

987248[/snapback]

The thing that will stop many of us from writing our own fancy kernels is the same reason why we use programs such as batari Basic. We just aren't bright enough. I know the human mind is capable of some great things, but all men are not created equal. We cannot all be college professors and rocket scientists.

 

Telling some people to write their own fancy kernels is a little like telling a person stuck in a wheel chair to walk. "Come on, get out of the chair you lazy bastard! You can walk if you want it bad enough. Will those legs to work!" Tools like wheel chairs and crutches help the disabled to keep up. And forgetting about tools for the disabled, people who do not need tools and shortcuts use them every day. Most people don't hunt for their own food and grow their own crops. They don't wash their clothes by hand down by the river. They don't start a fire by rubbing sticks together and cook over the open flame.

 

There is nothing wrong with advanced tools. If you don't want to use an electric sander because you like to do it by hand, that's OK, but don't try to take my tool away. Some of us are limited to bB's built-in commands and canned kernels for the most part. There are plenty of talented people around here who could create hundreds of kernels for the rest of us to use. There will eventually be a canned kernel for just about every type of game you can think of. No one will be forced to use them. Anyone who is able to create their own fancy kernels can do that, but why discourage a library of useful kernels? I don't want to reinvent the wheel every damn time. Even the most talented of people who use assembly use bits of code that someone else created.

 

 

 

Also, creative ideas are fine for coming up with cool solutions, but a big part of programming success (for me, at least, because I'm not a great programmer) is to be too stupid to know your own limits (so you aren't afraid to try something that everybody smarter than you insists is impossible), and to be too stubborn to know when to quit (so you keep trying until you either succeed, or accomplish something different from what you intended, but that's pretty cool in its own right)!

987248[/snapback]

I have done that before on the VIC-20 and the Commodore 64. I found shortcuts. I cut through the accepted crap to make the complicated simple. I was able to make programs that ran faster than was thought possible by the average and not-so-average person. And it was all done using BASIC. A language does not have to hold you back. You can do some cool things with the tools provided.

 

If you can create new kernels and tools to make batari Basic even better, please do so. I don't want batari to burn out and get sick of the whole thing. Anyone who can contribute please do so. Add to the library all you want, but the discouragement of the use of tools is not cool with me. I will use every damn tool I can get my hands on if it will help me make better programs in a shorter time with less frustration.

[+batari]

I put the playfield in ROM.

 

Anyway, I've got the multisprite kernel working with bB (got it working today while relatives are watching football what a waste of time) though there are still some things to do (mostly cleanup.) I spent gobs of time hacking the kernel to fix a few issues. Sprite 0 can go anywhere, but the kernel originally required sprite 1 to be above sprite 2, which be above 3, 4 and 5, so now sprites 1-5 can be in any order. Also, I had to change PF to RAM, which required indirect indexing (and more cycles) which was kind of hard to do, and allow variable heights of PF blocks (though you are limited to 1, 4, 8, or 16.)

 

I've added an "intelligent flicker" engine that allows any two sprites (1-5) to be on the same scanline, while flickering them at 30 Hz. Well, maybe it's not that intelligent as it still has limitations. Bad things may happen if you try to put >2 sprites on a scanline, or two sets of two, or something like that. I'll see if I can make this better.

 

But anyway, here's a demo to whet your appetites. This was made with bB using "set kernel multisprite." You have 6 sprites, numbered 0-5. 0 can be moved anywhere without limitation. 1-5 are subject to limitations above. To select which sprite you are moving, press the fire button. Also, bad things happen when you move off of the visible screen - I'm looking into this.

ms.bas.bin

[Cropsy]

I tried the multisprite demo, looks good! The new kernal should drastically increase the styles of games bB is capable of.

 

Will the missiles and ball still be available in the multisprite kernal?

[+batari]

I tried the multisprite demo, looks good! The new kernal should drastically increase the styles of games bB is capable of.

 

Will the missiles and ball still be available in the multisprite kernal?

991116[/snapback]

Yes, you have both missiles and the ball, but you cannot specify the height - they are fixed at 2 scanlines high.

[jjsonique]

Demo looks good! I like putting the playfield in ROM as the better solution for now, and can't wait for the official release! In other words: .

[mos6507]

I put the playfield in ROM.

 

Anyway, I've got the multisprite kernel working with bB (got it working today while relatives are watching football what a waste of time) though there are still some things to do (mostly cleanup.)  I spent gobs of time hacking the kernel to fix a few issues.  Sprite 0 can go anywhere, but the kernel originally required sprite 1 to be above sprite 2, which be above 3, 4 and 5, so now sprites 1-5 can be in any order.  Also, I had to change PF to RAM, which required indirect indexing (and more cycles) which was kind of hard to do, and allow variable heights of PF blocks (though you are limited to 1, 4, 8, or 16.)

 

I've added an "intelligent flicker" engine that allows any two sprites (1-5) to be on the same scanline, while flickering them at 30 Hz.  Well, maybe it's not that intelligent as it still has limitations.  Bad things may happen if you try to put >2 sprites on a scanline, or two sets of two, or something like that.  I'll see if I can make this better.

 

But anyway, here's a demo to whet your appetites.  This was made with bB using "set kernel multisprite."  You have 6 sprites, numbered 0-5.  0 can be moved anywhere without limitation.  1-5 are subject to limitations above.  To select which sprite you are moving, press the fire button.  Also, bad things happen when you move off of the visible screen - I'm looking into this.

989216[/snapback]

 

 

It's not working 100% under Stella. Depending on where the sprite is, it makes other copies disappear completely rather than flicker.