Tile Kernel?

[Cybearg]

Essentially, I'd like a kernel for the '2600 that I can adapt for vBb in order to make a game with tiles, such as for a top-down adventure game.

 

I've heard that this has been done by others. Can anyone point me to an available kernel? Are there any special tricks necessary for this in hardware? I'm content using data sets rather than holding the entire tile set in memory, to save space. From what I understand, there's not enough clock-time to address a sprite and place it for drawing as a tile while racing the beam, so there's got to be some other wizardry that is far beyond me going on.

 

Anyone have any leads, please?

[+Gemintronic]

Here is the closest thing I know of:

http://atariage.com/forums/topic/203463-abstract-assembly-development-kit/

 

Mr. SQL intentionally has bB compatibility in mind. I haven't gotten far enough into assembly to try and see how well it plays nice with bB.

 

You might have the skillz now Cybearg! Dive in and give us the scoop

[Mr SQL]

Cybearg,
the ASDK holds the the entire tile set in memory for the large virtual world using extra RAM (either CBS RAM or SuperCharger RAM), it would be awesome to see you build a game with it!

 

The tiles are X,Y addressable like playfield pixels and there are new functions for mapping sprites to tiles on or off the visible screen - I used them to map the non-tile characters in Dodge It Panoramic Adventure.

 

The commented source for the beta of that game is a good example on the ASDK thread; you can see how the gameloop runs every frame with Abstract Assembly code marshalling high level objects like the bB Framework.

 

You can also use the bB compiler to write your game code!

[Cybearg]

Cybearg,

the ASDK holds the the entire tile set in memory for the large virtual world using extra RAM (either CBS RAM or SuperCharger RAM), it would be awesome to see you build a game with it!

Are the tiles all essentially playfield pixels with pixels only every other line? Or can a series of tiles be specified so that different tiles exist within the 8x8 pixels of each tile?

 

I know that ASDK only allows for 2 sprites at a time, which could be fine for what I had in mind (Princess Rescue managed with just 2), but it would largely depend on whether those tiles can look like anything besides blocks and whether colors can vary between them (at least on vertical tile lines) or whether colors affect all of the background/foreground together.

 

I wasn't quite clear on the ASDK page which was the latest, fully-functional version of ASDK. Or has it not been significantly changed since October/November '13?

 

Also, is there a way to read the tile map entirely from ROM, freeing up all that RAM for other things?

Edited January 11, 2014 by Cybearg

[Mr SQL]

Are the tiles all essentially playfield pixels with pixels only every other line? Or can a series of tiles be specified so that different tiles exist within the 8x8 pixels of each tile?

 

I know that ASDK only allows for 2 sprites at a time, which could be fine for what I had in mind (Princess Rescue managed with just 2), but it would largely depend on whether those tiles can look like anything besides blocks and whether colors can vary between them (at least on vertical tile lines) or whether colors affect all of the background/foreground together.

 

I wasn't quite clear on the ASDK page which was the latest, fully-functional version of ASDK. Or has it not been significantly changed since October/November '13?

 

Also, is there a way to read the tile map entirely from ROM, freeing up all that RAM for other things?

Great questions Cybearg!

Both:

The virtual world tiles are just like large playfield pixels that can be x,y addressed (the camera object determines the visible playfield).

Sprites can be moved around the playfield x,y like with the bB Framework, or mapped directly to a virtual world tile, replacing or overlaying it with an 8x8 or missile sprite.

Yes there are only 2 8x8 sprite objects, but flicker is not so bad if you don't push it too much; the game I'm working on right now uses flicker to get 4 8x8 sprites and I think it's hardly noticeable on CRT, particularly with highly luminous colours.

A really cool feature is that sprites that are mapped to virtual world tiles only participate in flicker-timesharing when they are visible in the playfield - the less total fixed and moving sprite objects visible, the less flicker there is.

Your virtual world could have 30 or 40 sprite characters, it doesn't matter - it's what could potentially be visible on the playfield CAM at once:

 

If your game entails displaying from 2 8x8 sprites and 2 missile sprites, up to 8 8x8 sprites and 8 missile sprites, the flicker will vary between none at all and pacman level.

The 8x8 sprites characters are one colour, no multicolour sprites yet.

The virtual world tiles are also all the same colour.

There are two versions of the ASDK, the last two posted are the most recent of each for the CBS RAM chip and the SuperCharger.

It would be easy to modify the ASDK to read the entire map from ROM but you would lose the pfpixel type functionality to change it, though you could still poll the pixels.

By default the ASDK gives you about 50 variables, 30 8-bit and 20 4-bit variables (0-15) which are auto typecast from 8 bit with no bounds checking.

If you want more variables, you might prefer the SuperCharger version - it has the ability to address additional RAM for another 0-255 variables or more but you give up ROM for it. It also allows you to create multiload games, loading more code and new virtual worlds and musical scores from tape