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
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!)
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.
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
{
'--------------------------------------------
}
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!
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.
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.
Hi Guys, here's the VGA driver first release pass anyway
Potatohead and myself are going to match up the drivers, so you can use one or the other, all calls will eventually be the same, and will also be designed to be usable as a binary to load into a cog, and leave, so you can just load it from SD
Anyway, here's the first pass.
1Cog for VGA driver
1Cog for Scanline Render with only a couple of sprites(4x8) more cogs = more sprites.
have a look and a play, and let me know what you think, or if it needs changes anywhere?
Potatohead and myself are going to match up the drivers, so you can use one or the other, all calls will eventually be the same, and will also be designed to be usable as a binary to load into a cog, and leave, so you can just load it from SD
Does this mean it will be usable in PropBASIC and C also???
Yes, Coley, it will only take an extra 32bytes of hubram per tile you add to it, no matter how many times you use it on screen
And yes, my graphics converter, the one I posted AAAAAAAges ago, should convert for it, if you make the BMP 4 pixels wide, and arrange all your tiles down the image, it will do it, I will however make a newer mod to it, so it breaks a bitmap up into 4x8s
And yes, it should be usable in PropBASIC, I'm going to do a demo for PropBASIC next.
and C, I don't see why it shouldn't work in C, as the driver itself is self contained, IE doesn't need spin helpers it should even work with Sphinx
Since there is a converter app, I'm not going down the road of making address change. Let's get that worked out, and I'll strip down the more bulky driver I've built, and sync up!
Thanks a bunch Baggers.
Everyone: This thing renders a LOT of sprites per COG. @Jazzed, a few of these could be made to present as GUI elements, and you could have a mouse, and some common text as sprites. Would take some work at the SPIN layer to have it all come together, but, the sprites offer per pixel positioning, meaning the mouse and some "floating" GUI elements, or text is now possible. IMHO, convert a few buttons to tiles, place them, then render sprites on top of that, done! A lot of the things you wanted to do are possible.
@Dr_A, Jazzed, others: VGA Rocks. Not as many colors, but man! It's sure nice and clean to work with. This particular timing really makes sense too. Pixel clocks are in the range of good resolution for Propellers overall. Got my first real play on a monitor today.
It may be needed to give up 320 on the TV to match up with this, just FYI. Maybe not. Either way, 256 pixels is doable, and appears to be the standard high-color Prop resolution.
Re "will also be designed to be usable as a binary to load into a cog, and leave, so you can just load it from SD "
That would be a huge bonus. Hub ram is precious and, for instance, with the code I posted, 2k is being wasted as the cog space used to load the vga driver, and another 2k for the keyboard and another 2k for the sd card driver.
Not such an issue when the hub ram is fixed at 19k for straight bitmap drivers 160x120, but for tile drivers, every bit of ram can be used for more tiles.
And, binaries for cogs that load from an sd card also will be useful for catalina, zog and the Basic compilers.
I'm already thinking ahead about writing a .bmp to tile converter in spin. Add it as another icon/binary for the operating system.
there is no setting. I'll see about adding that as a fold in the stuff Baggers posted. Those color constants are hard coded into parts of the TV COG, and mixed into the render / graphics COG.
Thanks. The non-interlace mode on this one is kind of special. Happened by mistake, and I liked it. Most non-interlaced drivers either have no color phase change, or if they do, it's alternating back and forth, producing dot crawl, or OBC says, shimmer. This one is alternating static, which results in a crisp picture, with no dot crawl. The trade off is image movement may display ripples in the shape edges, at some specific speeds. The advantage is a nice picture, with nothing moving, unless the programmer wants it that way.
I've just been researching color dithering. With a limited palatte, it could potentially improve the look of pictures.
Can't wait to try out the tile driver.
Thinking about code that you can load into a cog from a binary, a display driver really only needs one variable - either passed to it, or passed back from it, and that is the hub ram location where the data is stored. That ought to make such code easier to write?
Playing around with fonts at the moment. Thinking of ways of automatically creating a library of fonts for use in text boxes.
@Baggers - I changed the last few lines so they are in binary and display all the colors. On my monitor they are just starting to bleed into each other, so I think this is finding the limits of vga.
Dr_Acula, If your still having trouble with the bleeding, make sure the colours are legal values, ie ( OR'd with $03 per byte or $03030303 per long to set the HVbits ) then you could go into the VGA_JB_001 driver and remove the "or pixels,coloror", which should give it the extra speed?
Btw, it's 256x240, not 320x240
I suspect the color bleeding is actually my eyes. <goes and puts on glasses>
Yes, 64x4 is 256.
So, to clarify, you have 64x30 tiles. I presume there is a list somewhere of those? How does the list work - does the list contain each x,y position, or is the list in order of x then y and the list contains the tile number?
Say I want to add to your code. I want to put a tile at position x,y and somewhere I presume I define what data is contained in that file.
So are the steps:
1) Build the data in the tile (either in a data array, but more usefully, loading from sd card)
2) Add the tile?
3) Tell the display code to display this tile?
See attached picture - this 256x240 in Prop colors (gray scale in this example). You need to zoom in to see the gray scale on the edge of the font - it is starting to look smooth.
So - do we need to first scale this somehow from 1.066 to 1.333? Do this while in higher res?
Then, with this example, run it through some code (I'm thinking vb6 as vb.net can't do pictureboxes so well) and search for 4x8 blocks that are solid. It will find lots of white and also some black ones. Make a list of those. Then make a list of all the leftover ones. Store x,y and the data as sprites.
Then create some sort of build list, maybe as a header file, so this can be loaded from the sd card?
Testing fonts on the screen - these seem to work.
Writing a program in vb6 to try to automate capture of a font to turn it into files we can read. See this vb6 program - we can create a font of any size/color and print it to a picture box. If we use the underscore character as a reference, and maybe the top of the [ character, it ought to be possible to capture the bottom, top, left and right of fonts that are variable width - eg Arial and Times Roman. If the process can be automated, it should be possible to build up libraries of data files at a wide range of sizes. Draw a text box of the right size, then fill it with the bitmaps of the appropriate text.
Here's the graphic converter, with a new project, which has the converted data files in, displaying an image + sprites.
To convert the (8bit) bmp image to .chr and .map files just type
bmptolite filename -vga4x8
don't add the .bmp to filename, as it appends the .bmp automatically, and uses that filename to add the .chr and .map extension for the output files.
Cheers,
Baggers.
EDIT: I'm noticing sometimes the PLL messes up and you get blocky columns, so I remember seeing something a while ago, that linus found about the stabilising of the PLL, hopefully that should fix it
but for now, to fix, set the NUM_COGS to 6, then back to what you had it on, or a turn off and on, can fix it too.
Also, you could try starting the VGA cog after the render cogs, that works also.
I tried the Linus thing, which didn't seem to alter anything, I think that was probably more to do with sync'ing 2 or more cogs.
I'm currently working on getting the TV COG to work with Baggers render COG. (bloody brilliant, I might add) My buffer scheme is a careful race between TV and render COG. This scheme is much better, fails gracefully too. So, I'm kind of digging in right now, tracing through, learning what was just done for us.
Got sidetracked with a plumbing problem. Don't you guys hate those?
Anyway, I thought I would say, if somebody wants the higher resolution, just add the OR operation to all the tiles, prior to launching the video COGs. Call it when needed to deal with tile data, and life is pretty good.
...just a thought, so we can have 320 (maybe, if that makes it quick enough) on both drivers. I'm gonna do it as a SPIN method at some point, just because it's a shame to not have all the pixels possible. Funny that way
Comments
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 $eaeaeadaI 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
How much HUB buffer memory is used for each of the widths?
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.
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 { '-------------------------------------------- }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
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!
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.
No worries on anything else. It's driver work right now. What happens above that is anybody's call. Not a distraction, IMHO.
Potatohead and myself are going to match up the drivers, so you can use one or the other, all calls will eventually be the same, and will also be designed to be usable as a binary to load into a cog, and leave, so you can just load it from SD
Anyway, here's the first pass.
1Cog for VGA driver
1Cog for Scanline Render with only a couple of sprites(4x8) more cogs = more sprites.
have a look and a play, and let me know what you think, or if it needs changes anywhere?
Amongst other things :smilewinkgrin:
Regards,
Coley
Cheers Coley!
I guess for every tile I make the driver takes another 32 bytes of hubram no matter how many times I use it on screen?
I bet you already have some little app for converting a bitmap into tiles don't you???
Regards,
Coley
Does this mean it will be usable in PropBASIC and C also???
Thanks,
Coley
And yes, my graphics converter, the one I posted AAAAAAAges ago, should convert for it, if you make the BMP 4 pixels wide, and arrange all your tiles down the image, it will do it, I will however make a newer mod to it, so it breaks a bitmap up into 4x8s
And yes, it should be usable in PropBASIC, I'm going to do a demo for PropBASIC next.
and C, I don't see why it shouldn't work in C, as the driver itself is self contained, IE doesn't need spin helpers it should even work with Sphinx
Thanks a bunch Baggers.
Everyone: This thing renders a LOT of sprites per COG. @Jazzed, a few of these could be made to present as GUI elements, and you could have a mouse, and some common text as sprites. Would take some work at the SPIN layer to have it all come together, but, the sprites offer per pixel positioning, meaning the mouse and some "floating" GUI elements, or text is now possible. IMHO, convert a few buttons to tiles, place them, then render sprites on top of that, done! A lot of the things you wanted to do are possible.
@Dr_A, Jazzed, others: VGA Rocks. Not as many colors, but man! It's sure nice and clean to work with. This particular timing really makes sense too. Pixel clocks are in the range of good resolution for Propellers overall. Got my first real play on a monitor today.
It may be needed to give up 320 on the TV to match up with this, just FYI. Maybe not. Either way, 256 pixels is doable, and appears to be the standard high-color Prop resolution.
Re "will also be designed to be usable as a binary to load into a cog, and leave, so you can just load it from SD "
That would be a huge bonus. Hub ram is precious and, for instance, with the code I posted, 2k is being wasted as the cog space used to load the vga driver, and another 2k for the keyboard and another 2k for the sd card driver.
Not such an issue when the hub ram is fixed at 19k for straight bitmap drivers 160x120, but for tile drivers, every bit of ram can be used for more tiles.
And, binaries for cogs that load from an sd card also will be useful for catalina, zog and the Basic compilers.
I'm already thinking ahead about writing a .bmp to tile converter in spin. Add it as another icon/binary for the operating system.
I'm off to bed now, will catch up again tomorrow!
It's been great having some prop time again!
How can I set the border color? I've seen this done in other drivers.
BTW, non-interlace mode is very crisp here on my dinky DVD LCD TV.
Thanks.
Thanks. The non-interlace mode on this one is kind of special. Happened by mistake, and I liked it. Most non-interlaced drivers either have no color phase change, or if they do, it's alternating back and forth, producing dot crawl, or OBC says, shimmer. This one is alternating static, which results in a crisp picture, with no dot crawl. The trade off is image movement may display ripples in the shape edges, at some specific speeds. The advantage is a nice picture, with nothing moving, unless the programmer wants it that way.
I use it on smaller displays myself.
Can't wait to try out the tile driver.
Thinking about code that you can load into a cog from a binary, a display driver really only needs one variable - either passed to it, or passed back from it, and that is the hub ram location where the data is stored. That ought to make such code easier to write?
Playing around with fonts at the moment. Thinking of ways of automatically creating a library of fonts for use in text boxes.
@Baggers - I changed the last few lines so they are in binary and display all the colors. On my monitor they are just starting to bleed into each other, so I think this is finding the limits of vga.
Quite amazing resolution!
chars byte %00000000,%00000100,%00001000,%00001100 byte %00010000,%00010100,%00011000,%00011100 byte %00100000,%00100100,%00101000,%00101100 byte %00110000,%00110100,%00111000,%00111100 byte %01000000,%01000100,%01001000,%01001100 byte %01010000,%01010100,%01011000,%01011100 byte %01100000,%01100100,%01101000,%01101100 byte %01110000,%01110100,%01111000,%01111100 sprchrs byte %10000000,%10000100,%10001000,%10001100 byte %10010000,%10010100,%10011000,%10011100 byte %10100000,%10100100,%10101000,%10101100 byte %10110000,%10110100,%10111000,%10111100 byte %11000000,%11000100,%11001000,%11001100 byte %11010000,%11010100,%11011000,%11011100 byte %11100000,%11100100,%11101000,%11101100 byte %11110000,%11110100,%11111000,%11111100(Picture below is 160x120. Baggers seems to have pushed this out to 320x240)
Btw, it's 256x240, not 320x240
Yes, 64x4 is 256.
So, to clarify, you have 64x30 tiles. I presume there is a list somewhere of those? How does the list work - does the list contain each x,y position, or is the list in order of x then y and the list contains the tile number?
Say I want to add to your code. I want to put a tile at position x,y and somewhere I presume I define what data is contained in that file.
So are the steps:
1) Build the data in the tile (either in a data array, but more usefully, loading from sd card)
2) Add the tile?
3) Tell the display code to display this tile?
See attached picture - this 256x240 in Prop colors (gray scale in this example). You need to zoom in to see the gray scale on the edge of the font - it is starting to look smooth.
So - do we need to first scale this somehow from 1.066 to 1.333? Do this while in higher res?
Then, with this example, run it through some code (I'm thinking vb6 as vb.net can't do pictureboxes so well) and search for 4x8 blocks that are solid. It will find lots of white and also some black ones. Make a list of those. Then make a list of all the leftover ones. Store x,y and the data as sprites.
Then create some sort of build list, maybe as a header file, so this can be loaded from the sd card?
Testing fonts on the screen - these seem to work.
Writing a program in vb6 to try to automate capture of a font to turn it into files we can read. See this vb6 program - we can create a font of any size/color and print it to a picture box. If we use the underscore character as a reference, and maybe the top of the [ character, it ought to be possible to capture the bottom, top, left and right of fonts that are variable width - eg Arial and Times Roman. If the process can be automated, it should be possible to build up libraries of data files at a wide range of sizes. Draw a text box of the right size, then fill it with the bitmaps of the appropriate text.
Here's the graphic converter, with a new project, which has the converted data files in, displaying an image + sprites.
To convert the (8bit) bmp image to .chr and .map files just type
bmptolite filename -vga4x8
don't add the .bmp to filename, as it appends the .bmp automatically, and uses that filename to add the .chr and .map extension for the output files.
Cheers,
Baggers.
EDIT: I'm noticing sometimes the PLL messes up and you get blocky columns, so I remember seeing something a while ago, that linus found about the stabilising of the PLL, hopefully that should fix it
but for now, to fix, set the NUM_COGS to 6, then back to what you had it on, or a turn off and on, can fix it too.
Here's the display....
I tried the Linus thing, which didn't seem to alter anything, I think that was probably more to do with sync'ing 2 or more cogs.
I'm currently working on getting the TV COG to work with Baggers render COG. (bloody brilliant, I might add) My buffer scheme is a careful race between TV and render COG. This scheme is much better, fails gracefully too. So, I'm kind of digging in right now, tracing through, learning what was just done for us.
Got sidetracked with a plumbing problem. Don't you guys hate those?
Anyway, I thought I would say, if somebody wants the higher resolution, just add the OR operation to all the tiles, prior to launching the video COGs. Call it when needed to deal with tile data, and life is pretty good.
...just a thought, so we can have 320 (maybe, if that makes it quick enough) on both drivers. I'm gonna do it as a SPIN method at some point, just because it's a shame to not have all the pixels possible. Funny that way