Full Color Tile Driver Thread

[Dr_Acula]

Its a bitmap, and uses more than half your memory. But, it gives you the colors.

Sounds fantastic. No problem using half the memory. Indeed, I think one could probably use more - at least up to 20k.

Just a thought. Say you had a 640x480 vga screen. And say you had tiles 32x32. Say you can 20 of these in memory making 20480 bytes.

For arguments sake, tile 1 is black (but it could be any color really) and all the other tiles are icons.

Then you have a tile list. 640x32 is 20, and 480/32 is 15. So you have 300 bytes storing numbers 1 to 20.

Then you print them out eg tile 1,tile 1, tile 10, tile 1, tile 1, tile 1, tile 15 etc

Every 32 bytes on a scan line you need to load in the next tile number and change a pointer to a new location in hub ram. So you do that 20 times on a scan line of 640.

Do you think a vga driver would be fast enough to add this extra code (eg a 2 cog driver)?

[potatohead]

Dr_A, that's very close to the change I mentioned above.

[Kye]

Here's what I've made. I don't plan on working any harder. While two cog VGA solutions give better results I do not wish to make one.

I'll put this driver up in the OBEX.

(Edit - Its now in the OBEX http://obex.parallax.com/objects/686/)

[Dr_Acula]

That looks good Kye. 160x120 will give enough 64x64 icons and more than enough 32x32. Can't wait to get home and try this.

Re potatohead - so you are working on a big full color tile driver? My father in law likes to run his PC with a black background, so with tile driver code and 20 icons, it could look rather similar to a PC home screen, or an ipad. That would be a propeller OS that would be 'familiar'.

Thinking of icons, there are times you want small ones and times you want bigger ones. I'm thinking of taking a 64x64 bitmap with the original 24 bit color and using this to produce a 64x64, 32x32 and a 16x16 in prop colors, both TV and VGA.

[potatohead]

Yes. It will still be a lot of little tiles, but...

If the addressing of the pixels is done correctly, 16x16 bitmaps can be loaded directly into the Propeller, maybe 32x32, whatever size works out in code.

Then, when placing them on the screen, one can choose any origin tile location, within 4 pixels, allowing for placement anywhere within reason.

Because it's tiles, the 320 pixels can be used, as not all the HUB memory will be consumed.

Baggers has 320 on VGA, so I'm hoping those can be matched up for a nice "all-color" solution. However, I'll probably take what Kye did, and see what may be built from there.

On the next pass at this code, I'll post up some detail info on tiles that should clear up how things can work. People have the same general trouble with the Parallax driver, and so that info probably will be of good general use.

It's my intent for the icons to be placed in various places, duplicated on screen, etc... without just having to do a full on bitmap of the entire screen.

[Dr_Acula]

It's my intent for the icons to be placed in various places, duplicated on screen, etc... without just having to do a full on bitmap of the entire screen.

That sounds brilliant.

16,32 and 64 seem to divide well into the screen sizes. I'm thinking in terms of icons at the moment, but one could always take a number of icons and put them next to each other for a bigger picture. So you could click on an icon of a photo, and then bring up a 128x128 picture or maybe even bigger.

Some of that could be built on the fly. Eg click on an icon of a clock, and it shuts down the operating system and runs a new binary that reads the time and displays it on a nice 128x128 clock, that you build up in software. You could even have the clock face as a bitmap and then draw the hands on in software. Then when you shut that down it reloads the operating system binary.

Intriguing possibilities...

[potatohead]

Exactly! That was where my mind went when you first started musing about this idea.

[Dr_Acula]

Testing out Kye's driver. Lots of manual steps with paintshop to get here. Once we have an OS working, one little App that might be useful is to be able to convert a .bmp into a .tv and .vga picture.

Abstract art and cartoons compress to propeller colors a lot better than photos.

I started a new thread for the eye candy.

Meanwhile, Icons.zip goes on the sd card, PotatoDOS gets compiled to the eeprom, and Photo.spin gets turned into a .bin file and goes on the sd card.

There are some bugs - if just one picture or icon file is missing the whole thing crashes. And it is slow to load pictures but I can think of several ways to overcome that.

Kye might have some advice, as this is the Kye SD code talking to the Kye 160x120 video driver code.

[potatohead]

A incremental update.

This archive does WORD addressing for the tile indexes. It's capable of using all the HUB memory for tile displays.

All tiles are 4x8 sequentially addressed, that change to the bitmap friendly tile addresses is next.

Right now the tile addressing is still sequential. If you run the archive, I've defined a few black and white tiles for resolution tests. Nothing special, but useful for looking at how a tile works, and seeing the graphics product on screen.

The next address change will be to arrange tiles in a grid of 16x32, or 32x32, or something that makes sense code wise, so that images may be made that size, and put directly to use by this driver, using "tile sets" of sequentially numbered 4x4 tiles to draw the image anywhere on the screen.

At that point, several images can exist in the HUB, and placed on the screen with very little effort. That's possible now, but requires work to "stack" the 4x8 pieces into the right places on screen.

VGA scan line type, driver coming up next, along with some actual image tile data and a document explaining how things end up in the HUB RAM.

@Dr_A: Very cool to see those on the Prop! Nice conversions.

[jazzed]

So I made a fat, beveled, grey scale "OK button" for a boring old GUI.
With the fat pixels I have to use 6 tiles. Are thin pixels impossible ?

{
'--------------------------------------------
' draw a fat letter OK button

      TEXT.SetTile(0,1,8)   ' upper left
      TEXT.SetTile(1,1,10)  ' upper middle
      TEXT.SetTile(2,1,12)  ' upper right
      TEXT.SetTile(0,2,9)   ' lower left
      TEXT.SetTile(1,2,11)  ' lower middle
      TEXT.SetTile(2,2,13)  ' lower right
'
'--------------------------------------------
}

long  $06060606           '00_08    upper left
long  $06060606
long  $06050505
long  $06050202
long  $06050205
long  $06050205
long  $06050205
long  $06050205

long  $06050205           '00_09    lower left
long  $06050205
long  $06050205
long  $06050205
long  $06050202
long  $06050505
long  $05040404
long  $04040404

long  $06060606           '00_10    upper middle
long  $06060606
long  $05050505
long  $02020502
long  $05020502
long  $05020502
long  $05020502
long  $05020502

long  $05020502           '00_11    lower middle
long  $05020502
long  $05020502
long  $05020502
long  $02020502
long  $05050505
long  $04040404
long  $04040404

long  $06060606           '00_12    upper right
long  $06060604
long  $05050504
long  $05020504
long  $05020504
long  $05020504
long  $02040504
long  $02050504

long  $02050504           '00_13    lower right
long  $04020504
long  $05020504
long  $05020504
long  $05020504
long  $05050504
long  $04040404
long  $04040404

[Baggers]

Jazzed, thin pixels are going to be possible on my VGA driver.
( Potatohead, it's 256 pixels wide, as couldn't get 320 at 5Mhz especially with sync correction oring $03030303 )

64 * 30 * 4x8 chars

will be posting demo of it in a mo.

[jazzed]

Sounds great Baggers! I'll try that on my lovely new VGA module which has megabytes of goodies and other "connected" things

Meanwhile, here's a yellow on blue fat pixel 3D shaded OK button.

{
'--------------------------------------------
' draw a 3D shaded fat letter OK button

      TEXT.SetTile(0,1,14)  ' upper left
      TEXT.SetTile(1,1,16)  ' upper middle
      TEXT.SetTile(2,1,18)  ' upper right
      TEXT.SetTile(0,2,15)  ' lower left
      TEXT.SetTile(1,2,17)  ' lower middle
      TEXT.SetTile(2,2,19)  ' lower right
'
'--------------------------------------------
}

long  $eaeaeaea           '00_14    upper left
long  $eaeaeaea
long  $eaeaeaea
long  $fbfb7e7e
long  $fbfb7efb
long  $fbfb7efb
long  $fcfc7efc
long  $fcfc7efc

long  $fcfc7efc           '00_15    lower left
long  $fbfb7efb
long  $fbfb7efb
long  $fbfb7efb
long  $fbfb7e7e
long  $eaeaeaea
long  $eaeaeaea
long  $eaeaeaea

long  $eaeaeaea           '00_16    upper middle
long  $eaeaeaea
long  $eaeaeaea
long  $7e7efb7e
long  $fb7efb7e
long  $fb7efb7e
long  $fc7efc7e
long  $fc7efc7e

long  $fc7efc7e           '00_17    lower middle
long  $fb7efb7e
long  $fb7efb7e
long  $fb7efb7e
long  $7e7efb7e
long  $eaeaeaea
long  $eaeaeaea
long  $eaeaeaea

long  $eaeaeada           '00_18    upper right
long  $eaeaeada
long  $eaeaeaea
long  $fb7efbfb
long  $fb7efbfb
long  $fb7efbfb
long  $7eeafcfb
long  $7efcfcfc

long  $7efcfcfb           '00_19    lower right
long  $ea7efbfb
long  $fb7efbfb
long  $fb7efbfb
long  $fb7efbfb
long  $eaeaeaea
long  $eaeaeada
long  $eaeaeada

[potatohead]

Jazzed, Just enter the demo program and change the number of pixels from the large size to 160, 256, or 320.

I left it set to 80, because I debug in 80. I like to see the pixels clearly when dealing with the graphics cog. Was out really late at work last night, dealing with a network address change. Lots of little confused devices not talking to one another. I hooked up a prop to kill time while waiting for things to reboot, and archives to get written!

@Baggers, yeah, I toyed with the code already posted, and having to set the pixel clock explicitly adds just one more instruction. Still, 256, is excellent!!

(hard to see 320 on TV's, unless one picks colors very well)

So, they match up nicely pixel wise. I gotta get the next addressing piece done, so I can do bitmaps and have some real tile data!)

Eager to see how Baggers did his tile addressing

[Baggers]

potatohead, can you go on msn for a bit?

[jazzed]

Jazzed, Just enter the demo program and change the number of pixels from the large size to 160, 256, or 320.

Eggscellent Now we're cooking. Guess I'll be using more tiles.
How much HUB buffer memory is used for each of the widths?

[potatohead]

Well, each tile is 4x8, which is just 8 longs. All you need to do is calculate the number of tiles addresses needed to cover the screen:

320/8 = 40*2 = 80 bytes * 25 rows (200 lines / 8 pixels) = 2000 bytes for the tile addresses on screen. That's a sunk cost, unavoidable.

Each tile then is 32 bytes.

To display a blank screen, you just need 2032 bytes!

If you add a tile, it's 32 bytes. Your RAM consumption then depends on the tiles you define, and how much you can leverage shared tiles. There is essentially no cost for populating a tile on the screen, which is why this method of graphics data encoding works well at higher resolutions.

[jazzed]

I can live with that cost. What I have trouble with is not having access to the pre-defined characters in the ROM which are also bit-maps. Too bad we can't use pointers for that.

Thanks.

Here is a nice beveled OK button. Using 4 instead of 5 for button face could be useful. I suppose one could do a byte replacement as needed at run-time.

{
'--------------------------------------------
' Draw an 8 tile beveled OK button.
' Looks good at 120+ width screen

      TEXT.SetTile(0,1,8)
      TEXT.SetTile(1,1,10)
      TEXT.SetTile(2,1,12)
      TEXT.SetTile(3,1,14)
      TEXT.SetTile(0,2,9)
      TEXT.SetTile(1,2,11)
      TEXT.SetTile(2,2,13)
      TEXT.SetTile(3,2,15)
}

long  $06060606           '00_08    upper left
long  $06060606
long  $06050505
long  $06050505
long  $06050503
long  $06050502
long  $06050502
long  $06050502

long  $06050502           '00_09    lower left
long  $06050502
long  $06050502
long  $06050503
long  $06050505
long  $06050505
long  $05040404
long  $04040404

long  $06060606           '00_10    upper mid1
long  $06060606
long  $05050505
long  $02020205
long  $04050403
long  $05050502
long  $05050502
long  $05050502

long  $05050502           '00_11    lower mid1
long  $05050502
long  $05050502
long  $04050403
long  $02020205
long  $05050505
long  $04040404
long  $04040404

long  $06060606           '00_12    upper mid2
long  $06060606
long  $05050505
long  $05020505
long  $05020504
long  $05020502
long  $05020204
long  $05020204

long  $05020402           '00_13    lower mid2
long  $05020402
long  $05020503
long  $05020505
long  $05020505
long  $05050505
long  $04040404
long  $04040404

long  $06060606           '00_14    upper right
long  $06060604
long  $05050504
long  $02050504
long  $02050504
long  $04050504
long  $05050504
long  $05050504

long  $05050504           '00_15    lower right
long  $04050504
long  $03050504
long  $02050504
long  $02050504
long  $05050504
long  $04040404
long  $04040404

{
'--------------------------------------------
}

[potatohead]

Yeah, Jazzed. Can't happen at high color. Too many shifts and adds. Would take several COGs.

Really, you can do that with 4 color tiles. That's what the Parallax driver does. You could also do it in 4 color, with a 2K font, designed that way, with any 4 colors per tile... That driver can be written quickly. May do it, once I'm done with Dr_A, and this VGA / TV graphics bit.

I want to see his icon deal happen IMHO, it's a cool idea.

Re: runtime. YES! If you want to, you can always be building into tiles off screen, encoding that stuff in a smaller way, using SPIN, or PASM to build the tile, then pop it on screen. A whole lot can be done that way. Recommended, IMHO.

If you want to, you can bit-mash the ROM font, into tiles, then display them as needed. When done, recycle the tiles and display something else!

[jazzed]

The "OK Button" is a standard item. This is the first time I've ever seen a nicely shaded OK button on Propeller TV with a driver that allows something else useful with more colors to happen with video memory. The Parallax driver can't do that.

I'm excited by this.

The shades of grey are lacking resolution, but so are the shades of an given color. Dithering shades of color with small pixels offer better opportunities of course.

I'm not trying to distract from anyone's goals here. The full color icons are good and with time they will be really nice.

Good work so far.

[potatohead]

BTW: If you use the older version driver on this thread, only 256 tiles are possible, but... screen cost is half. For your number pad example we discussed earlier, that's possible and likely practical. For something more complex, the word addressing for tile numbers is necessary.

No worries on anything else. It's driver work right now. What happens above that is anybody's call. Not a distraction, IMHO.