Shop OBEX P1 Docs P2 Docs Learn Events
Full Color Tile Driver Thread - Page 4 — Parallax Forums

Full Color Tile Driver Thread

124678

Comments

  • jazzedjazzed Posts: 11,803
    edited 2010-11-20 10:45
    Sounds great Baggers! I'll try that on my lovely new VGA module which has megabytes of goodies and other "connected" things :D

    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
    
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-20 11:21
    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 :)
  • BaggersBaggers Posts: 3,019
    edited 2010-11-20 11:51
    potatohead, can you go on msn for a bit?
  • jazzedjazzed Posts: 11,803
    edited 2010-11-20 11:52
    potatohead wrote: »
    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?
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-20 12:20
    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.
  • jazzedjazzed Posts: 11,803
    edited 2010-11-20 12:32
    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
    
    {
    '--------------------------------------------
    }
    
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-20 12:44
    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!
  • jazzedjazzed Posts: 11,803
    edited 2010-11-20 13:20
    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.
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-20 13:40
    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.
  • BaggersBaggers Posts: 3,019
    edited 2010-11-20 13:59
    Hi Guys, here's the VGA driver first release pass anyway :D

    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?
  • ColeyColey Posts: 1,108
    edited 2010-11-20 14:36
    Looking good Baggers, hopefully this will inspire a few more games to be written......

    Amongst other things :smilewinkgrin:

    Regards,

    Coley
  • BaggersBaggers Posts: 3,019
    edited 2010-11-20 14:37
    Yeah, that's the plan! :)
    Cheers Coley!
  • ColeyColey Posts: 1,108
    edited 2010-11-20 14:39
    So I already have a question....

    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
  • ColeyColey Posts: 1,108
    edited 2010-11-20 14:41
    and another question.....
    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???

    Thanks,

    Coley
  • BaggersBaggers Posts: 3,019
    edited 2010-11-20 14:50
    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 :D
    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 :D

    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 :D
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-20 15:31
    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.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-20 15:53
    Wow, this thread works 24/7!

    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.
  • jazzedjazzed Posts: 11,803
    edited 2010-11-20 16:00
    @Baggers, The demo looks good so far. I'll explore more later. Thanks.
  • BaggersBaggers Posts: 3,019
    edited 2010-11-20 16:05
    Glad you like it so far :D
    I'm off to bed now, will catch up again tomorrow!
    It's been great having some prop time again!
  • jazzedjazzed Posts: 11,803
    edited 2010-11-20 18:16
    @potatohead,

    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.
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-20 19:44
    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 use it on smaller displays myself.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-20 19:51
    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.

    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)
    1600 x 1200 - 167K
  • BaggersBaggers Posts: 3,019
    edited 2010-11-21 01:52
    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 :)
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-21 02:10
    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.
    640 x 480 - 42K
    964 x 634 - 86K
  • jazzedjazzed Posts: 11,803
    edited 2010-11-21 08:33
    Nice picture :D
  • BaggersBaggers Posts: 3,019
    edited 2010-11-21 12:17
    Hi again,

    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.
  • ColeyColey Posts: 1,108
    edited 2010-11-21 13:25
    Baggers, I experienced those same issues with the PLL and I turned cogs up to 6 and then back down to 3 and it worked.

    Here's the display....
    648 x 488 - 247K
  • BaggersBaggers Posts: 3,019
    edited 2010-11-21 13:42
    Also, you could try starting the VGA cog after the render cogs, that works also. :D
    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.
  • potatoheadpotatohead Posts: 10,253
    edited 2010-11-21 15:10
    Sweet!!

    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 :)
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-11-21 15:17
    @Baggers, is the source of that conversion program available? I might see if I can merge it with something to create all the fonts.
Sign In or Register to comment.