128K/256K RPG

[+Karl G]

I've been long fascinated with the idea of producing a massive game for the 2600, and an Adventure/RPG-style game would be the obvious choice. There have been some pretty good games already in this genre, but I'm imagining a world as big as the original Zelda, including the dungeons, with high-res playfield graphics. RevEng's multikernel framework could make this possible, since graphics data would be spread out between multiple banks, unlike a normal bankswitched game.

 

Anyway, I'm trying to brainstorm what would work best for such a project, so I'm brainstorming "out loud". I'm also interested in hearing others' thoughts, and trying to gauge interest in such a project.

 

Multisprite kernel: This seems like the obvious choice for such a game, since it would allow for multiple opponents, and a high-res playfield in ROM. The fact that the playfield is mirrored/reflected isn't ideal, but I could live with it and still get a good variety of screens, I think. The biggest downside is that I can't do a multicolor player0. I can live with all of the virtual sprites being single-color, but I would want the hero/heroine to look better than that. I messed around with the kernel a bit, but I couldn't figure out a way to shoehorn it in.

 

(Fun fact sidenote: the multisprite kernel defines two bytes that are never used for anything useful, in case one ever needs extra RAM in a project that uses the multisprite kernel: PF1temp2 and PF2temp2)

 

 

Standard kernel: This could allow for a colorful player as well as a high-res asymmetric playfield if I made use of Superchip RAM, but I would be limited to one other sprite for opponents, which wouldn't be ideal for what I am envisioning.

 

 

DPC+ kernel: I would love to use the DPC+ kernel for such a project, since I could have my cake and eat it too with a high-res asymmetric playfield and multi-colored multiple sprites, but the 20K of code, and the 4K of graphics data would make a Zelda-sized huge world impossible.

 

I have wondered though if there would be any way to break up such a game into multiple 32K segments for different parts of the world, and jump between them in some fashion while still preserving some state? Here's where my ignorance is showing, but I wonder if such could be accomplished in the same way a multicart menu selects a game to load?

 

Anyway - as I said, I'm just brainstorming here.

[gauauu]

How tied are you to batari basic? I'm not an expert on the bB kernels, but I'd guess that you'd have to write your own kernel, or do some hackery on the existing batari kernels. Writing your own kernel wouldn't be all that hard, but I think if you want multiple multi-colored sprites, missiles, and an asymmetric playfield, you either want to use DPC+, or be pretty good at writing a tight kernel.

 

That said, if you're willing to put up with a mostly symmetric playfield (which is what I did in Anguna, using the ball and/or some player objects for the asymmetric parts), you could keep your multicolor main character and make a fairly big world. If I had been willing to jump up to some bigger ROM size, I could have packed in higher-res playfields and a much bigger world. I think the trick would be to have multiple kernel banks, each with the kernel repeated, but different graphics data, so different parts of the world would use different kernel banks. I have no idea how that might work with DPC+ or bB, but for a normal assembly game, would be pretty straightforward.

 

Anyway, I'm just rambling/brainstorming also, until somebody smart shows up here

[+Karl G]

I have done a little bit of kernel programming, including a custom routine for Space Game, but I have only done simple stuff so far. I guess rolling my own kernel is an option, too, and a good way for me to learn more. My interest in BB has to do with preferring coding game logic using a high-level language. 6502 assembly isn't difficult to pick up, but it can be a bit tedious because of its simplicity.

 

The multi kernel framework that I mentioned before is doing what you are suggesting: putting a copy of the same kernel or a kernel with the same memory map in each bank, so I was trying to think how to best utilize that.

 

Anyway, thanks for the additional thoughts.

[ZackAttack]

My interest in BB has to do with preferring coding game logic using a high-level language. 6502 assembly isn't difficult to pick up, but it can be a bit tedious because of its simplicity.

Would you be as interested in C/C++? I've been working on new frameworks which make writing the display kernels in C possible.

[+Gemintronic]

Would you be as interested in C/C++? I've been working on new frameworks which make writing the display kernels in C possible.

 

batariBASIC has RevEngs framework that can handle 256k boards from AtariAge. The only other known buy-it-now boards that handle that size come from sources we don't talk about.

 

I might be tempted to switch over to C even before SpiceC if you can handle AtariAge 256k boards though

[gauauu]

. 6502 assembly isn't difficult to pick up, but it can be a bit tedious because of its simplicity.

 

 

I've been playing with writing a new little game using CA65/CC65 instead of dasm for the Atari, and having success with it, using C for the high-level game logic, and assembly for the kernel or loops that need to be tight. There's a few places where the generated C code is terrible, (and you really have to write C thinking like an assembly programmer, not using idiomatic C if you want it to be fast enough), but it's certainly doable.

 

(this new little game is an experiment to take a NES game that I wrote, replace platform-specific bits, but keep the high level game code. So far, the experiment is going quite well)

[+Karl G]

Would you be as interested in C/C++? I've been working on new frameworks which make writing the display kernels in C possible.

 

Definitely! C would be my first choice for development - the idea of being able to write a display kernel in C is intriguing and surprising given the extreme level of optimization that goes into those. I'm looking forward to seeing how that pans out.

[+Karl G]

 

I've been playing with writing a new little game using CA65/CC65 instead of dasm for the Atari, and having success with it, using C for the high-level game logic, and assembly for the kernel or loops that need to be tight. There's a few places where the generated C code is terrible, (and you really have to write C thinking like an assembly programmer, not using idiomatic C if you want it to be fast enough), but it's certainly doable.

 

(this new little game is an experiment to take a NES game that I wrote, replace platform-specific bits, but keep the high level game code. So far, the experiment is going quite well)

 

Interesting. Nearly all of the info that I've seen about 2600 development assumed the use of DASM, or using DASM as a backend in the case of bB. I can imagine that one would have to be careful about RAM usage when using C, using 8-bit integers, not relying on library functions, etc.

[gauauu]

Not only that, but local variables and parameter passing are pretty awful also. Usually I write it in C, read the generated assembly, then replace anything that's too horrible with inline assembly.

 

You could argue at that point that it's not worth the hassle, but the readability of C makes it worth it to me.

[ZackAttack]

 

Definitely! C would be my first choice for development - the idea of being able to write a display kernel in C is intriguing and surprising given the extreme level of optimization that goes into those. I'm looking forward to seeing how that pans out.

 

The basic idea is to run everything on the ARM chip in the cart and feed the VCS with a small subset of its instruction set so it's easy to keep track of the 6507 CPU state. The result is a few C functions that look suspiciously like 6507 instructions. There's just enough room to do some extra work in between function calls so it makes it possible to capture some ARM cycles that were previously lost during active frame rendering. Of course this requires a cart with an ARM chip and is therefore limited to 32K on the harmony carts. The good news is that someone else released an opensource cart which includes a much more powerful MCU. Once I've updated the firmware and ported over the driver it should be possible to make ARM enhanced games as large as 448K.

 

You can see it in action now if you have a harmony cart. I posted a demo back in December which demonstrates a C kernel in action.