I replaced the pf commands with tables, and added a little color.
Very nice! You've got a good eye for color. It looks like there's a LOT of great new features in the upcoming version. I can't wait until it's out!
(As a general rule, I never target an unreleased platform unless I'm intimately familiar with it.)
BTW, it looks like you've updated the code to allow for restart on fire button. Even with a delay, this doesn't work right. What you need is to use a flag that checks for when the fire button *isn't* pressed. Only after it isn't pressed should you accept the continue. There are still some problems with doing that, but it's better than nothing.
I like the scrolling demo you posted, but I can't really see what it has over bB's built in scrolling.
Unless the newer version has significantly updated playfield scrolling and rendering, the key is that it's smooth
scrolling. i.e. A single line of pixels at a time. For something like Lunar Lander, this is really important. At least, it is in my opinion. Using the chunker playfield is perfectly acceptable on the 2600, but if I'm going to bother, I'd rather try for Thrust-type smoothness.
I've just tried it on my 2600 (I love my KrocoCart) and it goes just fine with a regular joystick. I did notice one thing that you don't see on the emulators; the screen does a quick flip/roll when the playfield is being redefined. Since that's just at the beginning and end of the game, it's no big deal.
I had a feeling that might happen. The playfield redef is kind of computationally intensive. I might look at adding a few drawscreens in there to smooth it out. I'm glad to hear that it has a good feel on a joystick. I was hoping I got it right, but the only way to be sure is to test, test, TEST!
One suggestion I would make would be a little countdown between pressing reset and starting gameplay.
That's a great game for just a weekend of effort!
Putting in a custom kernel can be easy or hard depending on how you do things. As inline asm, it's a snap. As .asm modules in an includes file, it's a little harder but still doable. Fully integrated, it's really tough.
From what I can tell in 3.5, there are two ways of doing it. Either I can write my own drawscreen function and call it something different, or I can hack out the old drawscreen/kernal jumps and replace it with my own.
Both seem like they'd be workable, but neither one is very appealing. Some of the APIs will need to change regardless. (Unless I decide to maintain backward compatibility.)
I may write a kernel adaption guide at some point to explain how it's done, with an example of how a real kernel may be adapted.
Actually, I was hoping I might convince you to create a kernal plugin mechanism. From what I see, the kernal you've written is great. It does some general purpose stuff that makes it easy for programmers to write games. But for more specialized games beyond what the default kernal is capable of, we either need to hack bBASIC, or keep bugging you for features. (Which makes your life more difficult as the kernal gets more complex.)
What I'm thinking you should do is extract the kernal-specific functions into their own files, then wrap up the kernal, functions, additional memory map, and intialization routines into a subdirectory. (Or a ZIP file, if you're willing to link against InfoZip
.) Have the bBASIC engine default to a specific kernal, but allow it to be overridden by either a "set" option, or a command line parameter. The bBASIC engine would then look in the specified subdirectory (or ZIP file) for the correct plugin.
The advantages to this are numerous. A few off the top of my head:
- Both the multisprite and the monosprite kernals can co-exist.
- bBASIC users would be encouraged to dive into assembly by writing their own kernals (or hacking a custom version of yours).
- The community could get involved in improving bBASIC.
- A library of kernals could be tracked, allowing programmers to choose the one that best meets their needs.
It's food for thought, anyway.
Anyway, the PACMAN kernel appears to be full-width (40 pixels wide) while bB's is 32, but I suspect that the PACMAN kernel is reflected.
IIRC, I did code it to be reflected. However, at some point it wasn't (for reasons that I can't remember), so I know I can make the code workable both ways. With Pacman, there's not much reason not
to reflect the playfield.
Edited by jbanes, Mon Jun 19, 2006 8:14 PM.