Bitmap kernel

[SeaGtGruff]

Okay, here's a demo of the bitmap kernel I've been working on for batari Basic. Right now the kernel is coded within the demo program using inline assembly, and the code isn't finalized yet, but the final kernel will be in an include file-- probably named "bitmap_kernel.asm" or something like that, and it will either have a header file to go with it, or the RAM variables will be defined within the kernel.

 

I don't know how useful this is going to be for general purposes, because the data for a bitmap takes up 2.25K of ROM (9 pages, or 2304 bytes), so there's room for only a single bitmap in a 4K ROM, and the kernel isn't designed to take advantage of bankswitching (at least not yet), since the data needs to be in the same bank as the bitmap kernel. I may see if I can load the code for the active lines into zero-page RAM (if they'll fit and still leave enough room for other RAM usage), so that the kernel can display bitmaps stored in other banks-- but no promises about that.

 

I broke the kernel up into different sections, the intention being to allow room for squeezing a little bit of user code into the VSYNC routine, in addition to the usual overscan and vblank regions-- but I'll probably do away with the spare room in the VSYNC routine, since I'm going to set up the pointers in that section of code. (At present, the pointers are being set up outside the kernel, but that isn't very user-friendly!)

 

My original intention was to create a kernel for title screens, but first I decided to do a bitmap kernel. When I eventually do a title screen kernel, it will probably have multiple bitmap areas, like one for a large bitmap (maybe 96x128) for the title graphics, and a smaller area (maybe 48x64) for other text, such as a copyright message, or "press the fire button to begin," things like that. So this bitmap kernel isn't really intended for title screens per se, but it's sort of a step in that direction.

 

This WIP demo displays a drawing of a Celtic seahorse. (Don't ask me why he's biting one of his legs!) I'm including the original image for comparison. I resized it to fit inside a 96x192 area, and then decreased it from a 256-grayscale image to a 2-color image using dithering, which is why a lot of the lines look "dotted" or broken.

 

Michael

bitmap.bas

bitmap.bas.bin

[jbs30000]

First, I stand in awe of your skills.

 

Second, since the bitmap doesn't seem to take up the whole screen, what screen resolution are you using?

[+Random Terrain]

My original intention was to create a kernel for title screens, but first I decided to do a bitmap kernel. When I eventually do a title screen kernel, it will probably have multiple bitmap areas, like one for a large bitmap (maybe 96x128) for the title graphics, and a smaller area (maybe 48x64) for other text, such as a copyright message, or "press the fire button to begin," things like that. So this bitmap kernel isn't really intended for title screens per se, but it's sort of a step in that direction.

This bitmap kernel is great, but I'm especially happy to know that a title screen kernel is on the way. Then batari Basic users will be able to make their own high-quality title screens without begging an asm master to make something for each game. I can't wait to start making my own title screens with the help of your upcoming kernel. I don't know whether to drool or poop myself.

[SeaGtGruff]

First, I stand in awe of your skills.

Actually, it was a pretty straight-forward procedure-- a simple variation of the 6-digit score technique, using the flicker-blinds technique to create what might be called a 12-digit score display. In fact, it was a bit easier than the score routine, because the copies of the players are spaced further apart, so the timing isn't quite as tight as when displaying a 6-digit score, which means you don't need to do the "X-Y-temp shuffle" that the score technique requires. But the timing was slightly tricky because (1) I'm not using VDELPx, (2) the flicker-blinds technique requires alternating between a cycle 73 or 74 HMOVE and a regular HMOVE, and (3) the LDA(),Y instructions can take variable amounts of times since page-crossing will definitely occur. When I revise the kernel for the final version, I may go ahead and use VDELPx after all, since it will make some of the timing a little less tight, and should actually save a couple of cycles on each scan line.

 

Second, since the bitmap doesn't seem to take up the whole screen, what screen resolution are you using?

The bitmap has only one resolution-- 96 pixels across by 192 pixels down. That means each scan line has 32 unused color clocks to the left of the bitmap, and 32 unused color clocks to the right (32 + 96 + 32 = 160). Here's another screenshot that might help you see what I mean:

 

 

In this screenshot, the actual bitmap area is the light blue and purplish area in the center. The red and white stripes show the playfield pixels (the playfield is red, the background is white). There are 8 stripes to the left of the bitmap area, and 8 stripes to the right-- and each stripe is the width of a playfield pixel, or 4 color clocks, so 8 x 4 = 32.

 

I tried to resize the original picture so it would be 96 pixels across, but I was resizing it in Word, because Word's resizing routines preserve more of the details than you get by simply dropping every other pixel or whatever, as most graphics programs do. Somehow the picture ended up having 2 columns of empty pixels on the left, and 2 columns of empty pixels on the right, even though the entire resized image was 96 pixels across (i.e., it's like the actual picture was resized to 92 pixels across).

 

As for the extra blank space above and below the picture, that's part of the bitmap, but I wanted to preserve the overall aspect raio of the picture, instead of stretching it to fill the entire vertical area, which would have distorted it from the original image.

 

The brown or tan area isn't part of the bitmap-- it's actually part of the playfield, which I turned on to provide a sort of "canvas" for the bitmap.

 

As you can see in the above picture, the bitmap area has an aspect ratio of about 5:6, such that it's a little narrower than it is tall. To get that aspect raio-- which is close to what you'd see on a real TV-- you have to set Stella's video settings to 83 or 84, as shown below:

 

 

If you set it to 100 (as shown below), the bitmap area will be square, but the pixels will be a little bit wider than what they would be on a TV:

 

 

 

Michael

[mos6507]

the timing was slightly tricky because (1) I'm not using VDELPx, (2) the flicker-blinds technique requires alternating between a cycle 73 or 74 HMOVE and a regular HMOVE, and (3) the LDA(),Y instructions can take variable amounts of times since page-crossing will definitely occur. When I revise the kernel for the final version, I may go ahead and use VDELPx after all, since it will make some of the timing a little less tight, and should actually save a couple of cycles on each scan line.

 

Looks like a similar approach that was used on the Chimera title screen (sans queues of course). Stellar Track's main limitation is that every sprite has to have a blank column in it so it only works for text (7-bits each). A full 12-char is harder to do. The timing definitely is critical on that and I had to solicit help to get that to work right.

 

Title support in batari basic is good. Having this mode as a Suicide-mission-like drawing canvas for Harmony similar to what I intended for Chimera would be even better.

[Dan Iacovelli]

I'm for a title screen kernel as well, since it is impossible to do it with multisprite as the playfield is only reflected.

[smartkitten26]

That's cool

[SeaGtGruff]

One more demo picture, then I'll work on finalizing the code. Presenting... Evil Spock!

 

 

 

Michael

bitmap3.bas

bitmap3.bas.bin

[yuppicide]

Thanks, thanks, and thanks. Those screens look amazing!

 

So, basically this doesn't work with bankswitching.. does that mean I can still stick this in the first 4K and then when someone hits fire to start the game it could go to another bank to play the game?

Edited August 13, 2009 by yuppicide

[Jess Ragan]

This is actually really cool! Thanks for sharing!

[potatohead]

This is f-ing sweet!!

 

Any chance it can display RAM?

[SeaGtGruff]

Any chance it can display RAM?

Absolutely! However, a 96x192 image takes 2304 bytes, or 2.25K. I think the only existing bankswitching method that could handle it is 4A50. But the Harmony/Melody cart might be able to handle it, too, although it might require a new bankswitching scheme (unless it can emulate a stripped-down version of 4A50 bankswitching).

 

If you change the bitmap to 96x96 (2 lines per pixel), you'd need only 1152 bytes, or 1.125K, which might be doable with E7 bankswitching, although the kernel would need to be revised a bit.

 

Or you could keep the pixels at 1 line per pixel, and change the width and/or height of the bitmap.

 

1024 bytes (1K) is exactly enough for a 64x128 image-- 8 player columns across, or a little bit wider than a standard 6-digit score display, and 2/3 the height of the screen.

 

1024 bytes is also enough for an 80x102 image-- 10 player columns across.

 

Michael

[jwierer]

For all the Schwarzenegger fans. The Terminator

 

Original image

2600 image

Source & binary

terminator.basterminator.bas.bin

 

-Jeff

[MausGames]

That's awesome, but I think it looks a little better with error diffusion:

 

[jwierer]

That's awesome, but I think it looks a little better with error diffusion:

 

I thought it would turn out better, but now I don't know?

-Jeff

[+atari2600land]

I want to play with this, but I can't seem to figure out what it is yet. Is there a program that converts .bmp files to BASIC programming that hasn't been released yet, or what?

[SeaGtGruff]

I thought it would turn out better, but now I don't know?

It's tricky getting a photo to turn out good. I've been using Microsoft Word to scale a photo down to 96x192, because it seems to give better results than the graphics programs I have-- I guess Word uses an algorithm that tries to combine pixels in some way, rather than just discarding pixels the way a lot of graphics programs do when you reduce the size of an image. Anyway, after I scale the photo to 96x192, I try to convert it to a 2-color palette in Paint Shop Pro, using error-diffusion or dithering. PSP offers three or four types of dithering-- ordered dithering, which tends to look crappy, and three types of error-diffusion dithering. Sometimes I have to adjust the brightness and contrast of the picture before the dithering comes out half decent. It's all a lot of trial and error, so I save the picture at various steps along the way in case I need to backtrack and try again.

 

Michael

[SeaGtGruff]

I want to play with this, but I can't seem to figure out what it is yet. Is there a program that converts .bmp files to BASIC programming that hasn't been released yet, or what?

I found a program called BmpToAscii that I was using at first, but Spiceware wrote a program to do it, and jwierer also wrote a program that I think he might be planning to add into Visual bB.

 

Michael

[jwierer]

I want to play with this, but I can't seem to figure out what it is yet. Is there a program that converts .bmp files to BASIC programming that hasn't been released yet, or what?

There are a couple of methods out there, but I created my own converter over the weekend. I am trying to implement Error Diffusion, as I have greyscale working, but it's like bashing my head into my computer to figure it out... I might just give in and use one of the open source libraries out there.

BashHead.bin

-Jeff

[GroovyBee]

There are a couple of methods out there, but I created my own converter over the weekend. I am trying to implement Error Diffusion, as I have greyscale working, but it's like bashing my head into my computer to figure it out...

Google for "Floyd Steinberg error distribution algorithm" or "ordered dither by J.O Limb". They should give you some leads. If not I can give you the pseudo code for both.

 

I take it that you are using the following formula to convert to greyscale?

 

grey=0.3*R+0.59*G+0.11*B

 

You can use integer maths without much loss (for speed) :-

 

grey=((r<<1)+g+(g<<2)+b)>>3

[+SpiceWare]

I want to play with this, but I can't seem to figure out what it is yet. Is there a program that converts .bmp files to BASIC programming that hasn't been released yet, or what?

I found a program called BmpToAscii that I was using at first, but Spiceware wrote a program to do it, and jwierer also wrote a program that I think he might be planning to add into Visual bB.

 

Michael

The one I wrote is an online program - read about it (and get the link to it in post #10) in this topic. Note: you need to use a GIF, not a BMP.

[jwierer]

There are a couple of methods out there, but I created my own converter over the weekend. I am trying to implement Error Diffusion, as I have greyscale working, but it's like bashing my head into my computer to figure it out...

Google for "Floyd Steinberg error distribution algorithm" or "ordered dither by J.O Limb". They should give you some leads. If not I can give you the pseudo code for both.

 

I take it that you are using the following formula to convert to greyscale?

 

grey=0.3*R+0.59*G+0.11*B

 

You can use integer maths without much loss (for speed) :-

 

grey=((r<<1)+g+(g<<2)+b)>>3

Thanks. I finally did come across some Floyd Steinberg articles that were clear for me to understand and was able to implement my own library. Unfortunately, image Processing is not one of my programming strengths...

 

[EDIT] Arnold does look better with proper dithering.

TheTerminator.basterminator.bas.bin

-Jeff

Edited August 18, 2009 by jwierer

[+Random Terrain]

Who in the heck is this guy?

 

mystery_guy.bin

[Dan Iacovelli]

Who in the heck is this guy?

 

mystery_guy.bin

my first guess was Al,then I saw a pick of rick weis and that would be my guess.

[SeaGtGruff]

Who in the heck is this guy?

 

mystery_guy.bin

my first guess was Al,then I saw a pick of rick weis and that would be my guess.

My money's on Al.

 

Michael