Shop OBEX P1 Docs P2 Docs Learn Events
Commented Graphics_Demo.spin — Parallax Forums

Commented Graphics_Demo.spin

potatoheadpotatohead Posts: 10,253
edited 2010-07-07 04:12 in Propeller 1
There have been various calls over time for some simple graphics examples, and a lot of calls to understand the colors and the tiles. While at UPEW, I knocked this out and was asked to post it in the OBEX.

I'll do that, but want to give it a dry run here.

Basically, I've gone through and commented the graphics demo and created a few new methods, and example code that make doing colors, tiles, and graphics screens easy. I've attached a few screenies here to show some of what it looks like.

One of the things in the original demo that gives people trouble is the tile color and addressing code. The way it's written is compact, but not easy for a newbie. Instead of a colors array, I moved that to a DAT section where a person can see the relationship between the palette and the displayed tile, and or only define those palette entries they think they need.

This runs with the Parallax reference video driver, and can replace graphics_demo.spin. The new methods are:

set_tile_color(tilex, tiley, palette)
set_color_palette(palette_num, palette_colors)
set_tile_address(tilex, tiley, HUB_address)
get_tile_address(tilex, tiley)

These methods can be used to define any of the 64 possible color palette sets and assign them to any tile on the screen. Additionally, any tile at on the screen can be pointed to display from any 64 byte aligned HUB memory address.

The program runs through a few basic operations on the graphics demo, showing color and address transforms. Color indirection is shown as well, which can be useful for a lot of displays, so long as the images are tile aligned in a way that makes sense. It's possible to put all the propeller colors on the screen with this driver, and some well chosen palette entries.

Finally, it shows a working example of how gr.setup can be used to draw in a window, either on or off the screen. The graphics cog is actually very useful. It operates with any sequentially addressed tiles, and features variable coordinates.

There are lots of things possible with this driver, and maybe this will help some people explore it better. The idea here is to run the program, which includes some waitcnt statements to slow things down, then read the comments, changing things to verify what has been learned. For all around graphics display, this driver has a lot potential. The only real downside is memory consumption. That can be addressed with the tiles, and repeated use of gr.setup to make the most of HUB memory, if desired.

Any and all comments welcome.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 7/4/2010 9:56:25 PM GMT

Comments

  • wjsteelewjsteele Posts: 697
    edited 2010-07-04 21:52
    Great work, Potatohead!!!

    Bill
  • BaggersBaggers Posts: 3,019
    edited 2010-07-04 21:59
    Excellent potatohead, this should put on the OBEX or stickied [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

    ·
  • HarleyHarley Posts: 997
    edited 2010-07-04 22:35
    Thank you, potatohead, for demystifing some of Chip's graphics demo.

    The comments should help many newbies to better understand this excellent app showing off the Prop's graphics capabilities. And for us 'oldies' too.

    Thanks for your effort yeah.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Harley Shanko
  • potatoheadpotatohead Posts: 10,253
    edited 2010-07-05 01:14
    Just gave it a reread. There are some goofy typos. I'll update that.

    One thing I did not show, and I think I'm going to have to add it somehow is spreading the display out. Say a higher resolution is desired, and there are blank parts of the screen. A small bitmap could be defined, say 8x5 tiles. Those could be sprinkled around the screen as needed, leaving parts of the display with no graphics, or referencing common graphics.

    Say a small bitmap was defined for status bars and such. That could be something modest like 8x5 tiles. One status bar per tile, for a total of 8 of them, with 5 tiles vertical positioning. Those tiles could be put down in strips on the display, yet be seen as one "screen" or "window" to the graphics COG. At higher resolutions, the tiles get nice and small, making this possible. There isn't enough HUB memory to do a full screen, where there might be doing just parts of one. This driver can do that.

    The logical drawing space would just be the 8 (128) x 5(80) bitmap defined and passed to gr.setup. The tile addresses just point back to chunks of that screen as needed. A line drawn from top right to bottom left, for example, might be seen in segments around the screen, depending on what was done with the tile addresses.

    One method would be to setup a working screen, where all the static elements are drawn, or contained in DAT statements. Assign the tile addresses to put all the static graphics on the screen re-using them everywhere possible.

    Then redefine the working screen as discussed here. That's the dynamic graphics screen, which can be much smaller than the actual display would otherwise indicate.

    Really, that is part of what I was getting at with the tile address methods, and simple screen cloning might not convey that.

    Another artifact of doing higher resolutions is the ROM font gets smaller, meaning it could be used in a fashion similar to how it's used in the VGA display. The graphics COG can be used with the higher resolution VGA drivers to accomplish these same things, if a TV graphics isn't desired. As long as the core driver is done in the Parallax reference style, that code can draw graphics for the screen generated.

    Most all the other tile drivers, mine included, use the concept of a table, with values in the screen memory being offsets into that table. The way this driver works is harder to work with, but considerably more flexible, particularly if the graphics primitive cog is being used.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!

    Post Edited (potatohead) : 7/5/2010 1:27:59 AM GMT
  • jazzedjazzed Posts: 11,803
    edited 2010-07-05 13:00
    potatohead said...
    The graphics COG can be used with the higher resolution VGA drivers to accomplish these same things, if a TV graphics isn't desired. As long as the core driver is done in the Parallax reference style, that code can draw graphics for the screen generated.
    Has someone done this? VGA displays are great.

    Here's an area for documentation improvement: I always though the pin assignments for TV/VGA were more difficult than necessary to set in drivers other than TV_Text, etc.... While Chips driver documents are adequate, I have to read them more often than I would like when dealing with video. I wish it was simpler than %010_111 or was it %001_0110 ... dang where are those notes?

    Thanks,
    --Steve

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Pages: Propeller JVM
  • heaterheater Posts: 3,370
    edited 2010-07-05 13:27
    potatohead: I'm going to give this a good read. So far the graphics possibilities of the Prop have totally eluded me.

    Yeah, yeah, I've been lazy and just let those who are seriously into such things do it for me.

    Edit: But now I am facing the abyss as I will need to make a graphics driver or two in C++ for Zog.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.

    Post Edited (heater) : 7/5/2010 1:41:19 PM GMT
  • potatoheadpotatohead Posts: 10,253
    edited 2010-07-05 17:54
    @Jazzed, the only example I know of is in Chips high resolution VGA example. He's got the tiles pointing to the ROM to make text I believe, and a mini graphics screen defined to run the graphics demo code in. I've never run that one, just looked at it.

    Just now got a place where I can use a VGA and the Prop. There is some VGA stuff I've been wanting to run and learn. I'm all about TV graphics right now, because welll.. I like the TV. The real reason is I run a Propeller most often on a battery, connected to a laptop with video capture running in a window for debug, etc...

    Anyway, Jazzed, if the new methods I added to this graphics_demo.spin were used to remap the tile addresses, the type of display I was writing about above would then be a matter of just assigning the tile addresses as desired to sprinkle that graphics screen around the real screen as needed, then planned drawing to generate dynamic elements. A tile pointed to the rom, simply needs to select the right color to make a given character appear. That's because the ROM font is 2 bits per pixel, interleaving two chars in one tile. (that was smart on Chip's part, but unusual, so it's not been used very much at all) The encoding is somewhat convoluted as well, compared to something like an 8x8 driver, where it's largely just values on the screen, and a color map somewhere. Chars need to be converted to addresses, and colors need to link to palettes. Interestingly, on most of the cases I've been thinking of, this driver is more efficient over the others, because they have a font table penalty.

    (I really want a nice 8x8 in the Prop II ROM, done the same way the current one is with the character interleave. One could do a nice, full color 8x8 that way, with a nice, tiny memory foot print. I can see a 80x50 style text display being quite popular on that chip, when we get it. ---> Note to Parallax: I will author this font, if it's an option. Just let me know.)

    I just checked, the TV driver will do 640 pixels x 400 pixels. That's actually 40x25 using the ROM font. Sheesh... didn't really know that was possible. Edit: I recall Baggers doing a 720x480 TV driver to use up the whole display. Gonna have to go and look at that one, as it will use up the whole LCD. (another common newbie question)

    I've always avoided the thing, preferring the 8x8. I still do prefer the 8x8 and the font table concept, but it is possible using the ROM font, to do text without having that font table around in the HUB. That also means being able to do dynamic graphics and reusable common graphics in that 40x25 grid, much like is done with the 8x8 drivers. Maybe something like your GUI could be done? Minimum color text from ROM, using those characters is only 2K, and if one were to overwrite the start code in the HUB, Cluso style, that's pretty lean. Every bitmap display tile consumes 64 bytes over that. The HUB footprint for the graphics cog and the TV cog is about 4K, meaning room for some dynamic graphics on a mostly text display for basically free.

    One of the reasons I ignored this driver is the memory consumption. Bitmaps take a lot. Well, it doesn't have to be bitmaps, and that's kind of new to me, but clearly intended.

    @heater: Fun stuff. Do you have a scope? It helps. If not, break TV drivers down to the core frequency, and cycles of PLLA. You can trace through an existing one, charting out how it built the wave form. Then code from there. For TV, use the template Eric Ball did. It operates at twice the frequency the Parallax one does, and it renders a better signal. For VGA, I don't know which one makes sense for a reference, but a similar thing can be done. One thing I think I would do now is do the math to permit variable clocks. Either put it in #DEFINES or, have a small bit of init code that calculates stuff. Adapting to a given clock is easiest on TV, well that's true for me because I do a lot of it. I think it's a bit harder on VGA.

    Video configuration troubles noted... That's quite a topic actually. The HYDRA book actually does some damage on that. A mini book is required for any real coverage of it. Another Edit: You know, I feel the same way about all the LMM variations... Just was reading the very cool SpinLMM thread. Man, we are making some seriously good progress on some basic stuff. Newbies, who ask about inline assembly code have a sane answer now. [noparse]:)[/noparse] Isn't that cool?

    For now, I think I'm just going to flesh out what can be done with the reference drivers. My initial goal was to cut down on the number of people asking the same questions on these. Generally, those are the first ones that people try. What ended up happening was I found out the thing actually does a lot! Early on, I kind of ignored those, looking for more classic computer type displays and just kind of stayed in that zone.

    The Parallax driver actually uses the Prop video fully, as originally intended. Might as well make that more accessible. For a lot of projects, 4 color tiles at the higher resolutions will get the display they need done, and having the graphics draw cog available makes things just easy. Most other drivers get the display done, perhaps with some text functions, and the rest is then left to the user, done bitmap style.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!

    Post Edited (potatohead) : 7/5/2010 6:13:59 PM GMT
  • jazzedjazzed Posts: 11,803
    edited 2010-07-05 18:18
    potatohead said...
    Anyway, Jazzed, if the new methods I added to this graphics_demo.spin were used to remap the tile addresses, the type of display I was writing about above would then be a matter of just assigning the tile addresses as desired to sprinkle that graphics screen around the real screen as needed, then planned drawing to generate dynamic elements.
    I was wondering about those methods [noparse]:)[/noparse]

    After our little chat about super-hi-res static graphics at UPEW, it occurred to me that one could keep simple yet richly textured building blocks in HUB RAM and draw them many places with a tile-driver. That would beat what we see today and the rich GUI we discussed could be possible. Think of it as cache-tiled graphics. Perhaps your additional methods are a small step in that direction? As I understand it, the PASM rendering would have to change for a larger number of bits/pixel. I suppose that's another thread though.

    I can't seem to find Chips Hi-Res VGA graphics demo. Pointer?

    Thanks,
    --Steve

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Pages: Propeller JVM
  • potatoheadpotatohead Posts: 10,253
    edited 2010-07-05 19:30
    I'll try to track it down. Just did a quick search... no joy. Darn! We need to do better at that somehow.

    Even the normal VGA driver will do nicely. The one that ships with the Prop tool can be operated the same way as I describe.

    Yeah, the problem with higher color depths is on VGA, more bits per pixel are needed, and the waitvid needs to be run with a short frame. That blows the whole tile + colors thing out, and we are back to all the tricks for dynamic display.

    If color depth is set aside, the other stuff you were wanting to do is possible though. On VGA, some dithering could work, particularly at the higher resolutions. Dithers on TV generally come with artifacts. Solid colors, as in text in one color, background in another two colors, could be combined with a matching "end" graphic to form the buttons. IMHO, possible, just not at the depths you want. Time for some pixel art to convey what the gradients would [noparse]:)[/noparse]

    Well, I've got to do some bathroom repair. Sombody slipped and pulled the soap tray tiles out... After that, I'm gonna go work on a model display using the TV driver. When that's done, the VGA stuff should be obvious. We shall see.

    Found it at the last minute!!

    http://forums.parallax.com/forums/default.aspx?f=25&m=156595&p=1&ord=d

    If you search on these, I think there is a 800 pixel one that takes fewer cogs. This one is cool because it incorporates a cursor. It's a tile driver, like is being discussed. That means all the stuff on this thread is possible with that driver, but the methods were never written.

    Note the boxes at the top (look at the bottom of the thread). Those are done with the ROM font, solid background color, then end cap graphics, which may be in the ROM, but if they are not, can easily be stored in a DAT, for re-use on the screen. Because I don't know what my time schedule will be, here's the bits I think are needed:

    Take the text rendering code from TV_Text. It does tiles and colors and uses the text from the ROM. Also take the methods I did for tile addresses and color palettes, and put the palettes in the DAT section, like I've done here. With those three pieces, one could do text, and assign graphics to different parts of the screen.

    From there, the technique used to draw to a smaller graphics screen shown here, could be used with the tile address methods to sprinkle some dynamic graphics on the screen. Who knows? The whole thing might fit in a few K of RAM, if one were frugal.

    For a lower COG cost, one could always use a lower resolution driver, or the one that came with the Prop Tool. I think that one is only one COG, no cursor. But, that means being able to take a second COG to run the graphics cog, and a third to offer text services and probably draw a cursor in SPIN. Heh... The third COG would probably be running a SPIN loop, watching for commands like the graphics COG does, updating the cursor during the blank. Maybe doable, but that's new code. For now, the lower res driver, methods, and graphics cog, gets a person on screen graphics and text with a fairly low COG and RAM cost.

    One last edit: I can't find the 800 pixel one. I'm positive I saw one, and the discussion was about Chip ramping up the VGA resolution. On that one, there was text, and the graphics demo running in a little window on the screen, which actually was the image that sparked this whole affair for me.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!

    Post Edited (potatohead) : 7/5/2010 7:39:04 PM GMT
  • jazzedjazzed Posts: 11,803
    edited 2010-07-05 19:49
    I'm using the 1280x1024 driver to render HTML (W.I.P). I picked it because of the buttons [noparse]:)[/noparse]

    Looks like Rayman has a 1024x768 VGA GraphicsDemo here:
    [url=http://www.rayslogic.com/propeller/Users/VGA_Tile_Driver_Demo_-_Archive__[Date_2006.11.12__Time_03.56].zip]www.rayslogic.com/propeller/Users/VGA_Tile_Driver_Demo_-_Archive__[noparse][[/noparse]Date_2006.11.12__Time_03.56].zip[/url]
    That demo uses about 16KB without the buffer.

    Google search: site:forums.parallax.com/forums/default.aspx f=25 vga graphics demo
    Cheers,
    --Steve
    potatohead said...
    http://forums.parallax.com/forums/default.aspx?f=25&m=156595&p=1&ord=d

    If you search on these, I think there is a 800 pixel one that takes fewer cogs. This one is cool because it incorporates a cursor. It's a tile driver, like is being discussed. That means all the stuff on this thread is possible with that driver, but the methods were never written.

    Note the boxes at the top (look at the bottom of the thread).
    ...
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Pages: Propeller JVM

    Post Edited (jazzed) : 7/5/2010 7:56:53 PM GMT
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-07-05 20:06
    I added a 640x240 1bpp driver to OBEX years ago; based on Chip's 512x384 1bb driver.

    I also have a 320x240 1bpp driver that I need to clean up and add to OBEX some time - uses 9.6KB for the bitmap.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
    My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
    and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
    Las - Large model assembler Largos - upcoming nano operating system
  • potatoheadpotatohead Posts: 10,253
    edited 2010-07-06 05:44
    I'm working on a test display, and the ROM font is 32 pixels high. 640x400 display = 40 x 12 characters with that font...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!
  • potatoheadpotatohead Posts: 10,253
    edited 2010-07-07 01:21
    Ok, after working with this last night, I found out a few things. A coupla of these are silly, but things I did not know, so I'm going to share.

    One is I made a mistake on the text. It's 32 pixels high (jeez louise that's tall), and so the TV will do 40x13 and that's it. Not bad --it's basically TV_Text kind of display.

    I got the graphics driver running with 40x26 tiles last night, that's a 640 pixel x 416 pixel display, 4 colors per tile. Frankly, a modified font to render 16 pixels high would sort of rock. There probably is one, and maybe I'll look. The other part of that is, if one wants to just write bytes instead of bits, that boils down to a nice 160 pixel display, with all the colors available, with the usual tile limit of 4 colors.

    The most interesting thing was after I had gotten done pushing this driver to make an interesting display, I realized I was basically redoing TV_Text, but with a smaller tile / color definition. That was the silly part. Never realized it was the exact same TV cog. Go figure.

    Both use the TV driver, with the difference being a tile size of 32 pixels in the vertical instead of 16. This means, firing up the graphics cog, and inserting the tile address methods into TV_Text, means TV text with graphics! I'm quite sure this was intended at some point, but never really explored. If you were to scroll it, well the graphics will scroll as well, eventually leaving the screen. But, you don't have to scroll to use the text. I think the graphics cog will work just fine, so long as the tile count in the Y is an even number to deal with the 32 pixel tiles. But for the tall text size, that's right in line with what I was musing about earlier.

    Not sure what I'll do at this point. I think it's still worth doing a display with some indicator type graphics, mixed with text, and maybe a little bitmap, or an image from the DAT section. I want to put that out there because a lot of people have asked about that kind of stuff, and the commented code is a start. Adding some ease of use to the powerful Parallax TV driver seems worth it, as everybody basically has it. I don't want it to be too big of a project. Just enough to open the doors on these drivers some, that all.

    Running the driver with 16 pixel tiles means a nice 40x26 display in text, but a font table would be needed due to the ROM font being 32 pixels, but it could be small too, only the characters necessary. That could be mixed with graphics, getting all the prop colors on the screen for maybe 10K or so, for most interesting displays, single buffer.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!

    Post Edited (potatohead) : 7/7/2010 3:15:12 AM GMT
  • jazzedjazzed Posts: 11,803
    edited 2010-07-07 01:52
    potatohead said...
    I got the graphics driver running with 40x26 tiles last night, that's a 640 pixel x 416 pixel display, 4 colors per tile.
    Cool scool.gif

    Things get more interesting with 4 colors per tile.
    Can you have different sets of colors for each tile?
    What are the buffer requirements?
    potatohead said...
    More later ...
    What a teaser [noparse]:)[/noparse]

    Thanks for the update.

    Cheers [noparse]:)[/noparse],
    --Steve

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Pages: Propeller JVM
  • potatoheadpotatohead Posts: 10,253
    edited 2010-07-07 03:08
    Yeah, sounds cool, but the truth is, that is exactly what TV_Text does resolution wise.

    The larger tiles make for the most efficient waitvid loop, and are what allows color and resolution to happen without sprites and or dynamic draw methods.

    Most of the other drivers that have been written have either been special purpose (games and such), or give up some potential to get memory efficiencies. This driver is the best overall balance of color and resolution and RAM, but text is limited in some ways, either in number of characters, or RAM consumption. I'm not really doing anything new or ground breaking, just exploring what the Parallax drivers can really do.

    The nice thing is you get 40x26 tiles in that configuration. Twice the vertical tile resolution of TV_Text. Each of those can have any 4 of the Propeller colors. So that's a really nice color density, and the use of the palettes saves over the color map styles done before, and do not have the limits of per scan line methods. It's not difficult to get all the propeller colors on the screen that way, but detail can be costly, without careful planning on the tile definitions and or text font requirements. One could potentially just use a few blank tiles to indicate something, like big 40x26 pixels too.

    Originally, I was going to just stack them vertically to get text, but honestly that's some work and TV_Text does that already. So, that's off the table really. It isn't hard to add graphics to TV_Text, and the text part is done. The only downside is only 13 tiles vertically, which limits color assignments. But, text is easy cheezy, and efficient as it renders from the data in ROM.

    Buffer requirements can vary significantly. It's 64 bytes per tile. Those are gonna add up quick, though blank areas can consume no RAM at all. Just point them to the blank character in the ROM.

    A full on bitmap is basically 64K, so that gives some idea of the amount of common / blank graphics required to make a display frugal.

    For things like axis indicators, a few tiles that stack together might work well for a graph. Progress bars can stack vertically or horizontally too. Both of those can be built with just a few common tiles, maybe 4 or 6 as a minimum. They can be placed in multiple places, using the color palettes to light them up. Only 64 palettes though. Probably enough, but something to watch out for.

    If one limited the text to 64 chars, that's about 4K to place any character in any tile.

    It's possible to emulate the older gas phosphor display too. Have a few tiles with indicators in them. Those can be placed, and the color palette used to just light one up, or turn it off without drawing. Basically anything involving statically drawn graphics, that are turned on with color selection works single buffer. That's one of the better parts about this driver. Not many of our drivers have color indirection. Three segments, or indicators per tile are possible, because there are three colors, and if used in multiple places, different colors could be used to show the same indicator with a different color. That capability, along with a smaller graphics window hasn't been used much.

    A spartan display might be a few K, a involved one 10. I'm thinking I want to just build one with a bunch of tricks that uses a lot of RAM, but shows stuff. Then people can pick and choose. I'm also thinking I'll just show graphics on the TV_Text driver too. That doesn't have the tile resolution, because of the tall text, but some graphics can be plopped on there easy enough.

    One other thing is possible, and that's just writing bytes to the screen for faster drawing. At the 640 pixels, many TV displays won't render them all. Writing a byte at a time would yield a 160 pixel display that would be fast. Byte values of 01010101, 10101010, and 11111111 would equate to the three tile colors possible. That's kind of an interesting mix between the higher resolution and just getting stuff done.

    That's an interlaced display as well. larger / higher end LCD's will render that nicely. Most of the smaller ones won't, doubling up on the vertical resolution. IMHO, that's not the end of the world though, particularly if one just writes bytes for pixels instead of bits.

    I'm kind of stuck on the big ROM text. That was originally the reason for writing 8x8 drivers. On a VGA, that pixel size kind of rocks. Looks good, and the symbols are excellent. TV doesn't have the vertical resolution needed for useful character densities, though it does rock for smaller displays where fewer, but clear characters make sense.

    For a little bit more savings, one could just overwrite the HUB starter code for the TV driver and the Graphics one, if used. That's almost 4K, enough for lots of little things. Kind of a free 4K too, in that the stuff has got to be loaded anyway, might as well do it, then draw the elements needed with SPIN, right over the top of them.

    So, I've a good picture now of what can be done. Now it's just finding some efficient ways of showing that, and then move on. It's just such a common topic, and the drivers are pretty great overall.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Wondering how to set tile colors in the graphics_demo.spin?
    Safety Tip: Life is as good as YOU think it is!
  • jazzedjazzed Posts: 11,803
    edited 2010-07-07 04:12
    Well gee, I guess I had "Ready, Fire, Aim" enthusiasm.

    I hope whatever you're up to will provide greater per tile color depth than I've seen before.

    Thanks,
    --Steve

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Pages: Propeller JVM
Sign In or Register to comment.