Why Tiles?

awesomeduck

I am about half way through the Hydra book now, and enjoying it. I was playing with several of the demos and realized that at about page 330 in the book I think I got my thinking off into the weeds. I follow the mappings of how the tiles and colors and all work...but what I don't understand is why use tiles at all?
When I look at the graphics demo routines it seems they just don't really need to care about tile boundaries. Why not just lay the screen out as one big map of x by y pixels? What am I missing here?

potatohead

It's all about the function of the waitvid instruction and how it shifts pixels and colors out to the display.

Basically, the largest unit of data that moves from HUB to COG, and from COG to video generator is the long. A long can either be 32 pixels, at one bit per pixel, on or off, or 16 pixels, 2 bits per pixel, four color, or 4 pixels, 8 bits per pixel. The waitvids generate the video signal sequentially from the beginning of the frame to the end of the frame.

0000111122223333444455556666....

This is where the tiles come from. Depending on how you want to use your display, the screen memory mapping might be linear as in just one grid of pixels x and y, or it might be some multiple of the default pixel sizes. 8 pixels, or 32, or 16. Whatever.

Additionally, the Propeller ROM has a 2 bit per pixel character set where each character is 16 pixels wide. If you break the screen into tiles, each tile can either be pointed to the ROM for it's pixel data, or the RAM, for graphics data.

The Parallax drivers work this way to maximize system RAM availability at higher graphics resolutions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

Spork Frog

@awesomeduck: Most modern systems that still use 2d graphics normally use a bitmapped mode, you're right. Problem is we're a little bit RAM-constrained on the Hydra. A 320x240 bitmap at 8bpp (actually larger than the Hydra pallette; for practical purposes, the Hydra pallette is only about 86 colors.) would take almost 77k of RAM. A 4-color bitmap of the same size (2bpp pallette) would only take about 20k, but still doesn't leave much headroom for any other user code or other assets.

On the other hand, a smaller number of medium-sized tiles can be created to be much more colorful without much RAM usage. This way, you get much better looking graphics with less RAM usage.

soshimo

I'm still waiting on my book so I don't know the details, but could you also do tricks like the old says of palette cycling to get animation? That, of course, depends on the graphics object having a palette. Again, I don't have the book yet (Friday can't come sooner) so I may be way off base.

awesomeduck

I'm happy to say I've made it to page 600 or so and everything is becoming clear. Great book, lots of fun, learning a lot.

Baggers

awesomeduck, there's nothing ( other than ram of course ) using a bitmap, you just have to use either lower resolutions or lower bits per pixel, like for example, my spectrum driver is 2 colours per 8x8 pixels, but the screen is 1 bit per pixel bitmap in a linear format.

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

·