Tile Explanation desired

Erik Friesen · 2008-10-26 18:54

Could someone explain in what format graphics tiles are arranged? The reason for asking is that I am talking to another forum member about using the graphics driver with my 128x64 driver. My driver loads the lcd like this-

row1--byte1, byte2, byte3 and so on--
row2--byte17,byte18,byte19, and so on--
---
row64--last row byte113,byte 114, and so on--

Now if I have it right, the tiles are arranged like this(if you can visualized this)

byte1,byte2
byte3,byte4
byte5,byte6
and so on

So, I would arrange a 4x8 screen size.

But, do the tiles run up and down, and then left to right? or left to right, and then up and down?

Ok now, for example we have word screen[noparse][[/noparse]4*8]
Is screen[noparse][[/noparse]x] a pointer to the memory location of byte 0 that the graphics driver is writing to?

Are these tiles written in an interleaved style like the letters a stored in rom?
Or in what format are these arranged? Where is the color stored?

Mike Green · 2008-10-26 20:03

The format of the tiles depends on the driver. The TV driver for example uses the low order 10 bits of the tile word to point to block of 16 longs (on a 16 long boundary) that make up the tile. The high order 6 bits contain the index into a 64 long color table.

Erik Friesen · 2008-10-26 20:11

That makes sense. So its not the actual memory address until you add the offset.

Mike Green · 2008-10-26 20:22

The 10 bit field contains the upper 10 bits of the 16 bit hub address of the tile. There is no offset. The tiles have to be on a 16 long / 64 byte boundary, so the address is always a multiple of 64.

Erik Friesen · 2008-10-26 20:47

This however, doesn't seem to point to an active part of memory. lcdpointer is byte 0 of the lcd array.

When I add $3000, then I get some action. (One tile displayed from graphics 16x16)

    repeat qwer from 0 to 16 'tile
         word[noparse][[/noparse]lcdpointer+(qwer*16)]:=word[noparse][[/noparse]((screen[noparse][[/noparse]0]&%1111111111)<<6)+(qwer*2)]

hal2000 · 2008-10-27 14:32

<< The reason for asking is that I am talking to another forum member about using the graphics driver with my 128x64 driver. >>
am I!!!

Thanks for the help
It would interesting to have a routine for graphic lcd graphics.
The routine of TV requires lots of memory dedicated to the display.
With lcd 128x64 or 256x128 does not need as much memory.
big memory for program free

·

Baggers · 2008-10-27 15:34

    repeat qwer from 0 to 16 'tile
    word[noparse][[/noparse]lcdpointer+(qwer*16)]:=word[noparse][[/noparse]((screen[noparse][[/noparse]0]&%1111111111)<<6)+(qwer*2)]

Hi Erik, and hal2000,

It's not quite that easy, for two reasons.

    repeat qwer from 0 to 16 'tile

should be 0 to 15 as Spin does the last number too, and would have done 0 to 16 = 17 loops

and the second reason is that the fonts are intermingled, ie 0 is intermingled with 1, and are seperated by the driver, by use of colours, so if you had text on the screen, it won't appear correctly on your display, but if it's for graphics, then it's ok.

if it's graphics, to do a 128x64 pixel do

PUB updatelcdbuffer | x,y,t
    repeat y from 0 to 3
      repeat x from 0 to 7
         repeat t from 0 to 15
            word[noparse][[/noparse]lcdpointer+(y<<8)+(x<<1)+(t<<4)]:=word[noparse][[/noparse]((screen[noparse][[/noparse]y*x_tiles+x]&%1111111111)<<6)+(t<<1)]

if it's graphics, to do a 256x128 pixel do

PUB updatelcdbuffer | x,y,t
    repeat y from 0 to 7
      repeat x from 0 to 15
         repeat t from 0 to 15
            word[noparse][[/noparse]lcdpointer+(y<<9)+(x<<1)+(t<<5)]:=word[noparse][[/noparse]((screen[noparse][[/noparse]y*x_tiles+x]&%1111111111)<<6)+(t<<1)]

PS, I don't have any of the kit, so can you test this, and let me know, as it's written blindly.

You will also, have to have lcdpointer already set to your buffer, and x_tiles as your graphics tv_hc setting ( it's usually set to 16 as 16 * 16PixelTiles = 256 pixels width )

Baggers.

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

·

Erik Friesen · 2008-10-27 18:23

Actually I have it working. It is like this..

    repeat a from 0 to 3     'row
      repeat b from 0 to 8    'across
        repeat c from 0 to 15  'tile row
          tot:=long[noparse][[/noparse]$3000+(c*4)+(b*256)+(a*64)]
          repeat d from 0 to 15
            tot2:=tot2<<1+(tot&1)
            tot>>=2
          tot2><=16
          word[noparse][[/noparse]lcdpointer+(c*16)+(b*2)+(a*256)]:=tot2
          tot2~

It is pretty slow though. It needs to be done in assembly.

hal2000 · 2008-10-27 22:59

····repeat·a·from·0·to·3·····'row
······repeat·b·from·0·to·7····'across
········repeat·c·from·0·to·15··'tile·row
··········tot:=long[noparse][[/noparse]$3000+(c*4)+(b*256)+(a*64)]
··········repeat·d·from·0·to·15
············tot2:=tot2<<1+(tot&1)
············tot>>=2
··········tot2><=16
··········word[noparse][[/noparse]lcdpointer+(c*16)+(b*2)+(a*256)]:=tot2
··········tot2~

·

Baggers · 2008-10-28 09:29

oops yeah, forgot it was longs on the tv end for 16 pixels [noparse]:)[/noparse] well, it was late lol
but you got there in the end [noparse]:)[/noparse]
also change the *4 to <<2 and *256 to <<8 etc, that'll speed it up a little bit. nowhere near as fast as asm though.

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

·

Tile Explanation desired

Comments