basic graphics help needed

justin weber

I'm just beginning trying to write some form of game on the prop. I've had little to no success in doing graphics. I don't understand how this code works:

CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

x_tiles = 16
y_tiles = 12

paramcount = 14
VAR

long tv_status '0/1/2 = off/visible/invisible read-only
long tv_enable '0/? = off/on write-only
long tv_pins '%ppmmm = pins write-only
long tv_mode '%ccinp = chroma,interlace,ntsc/pal,swap write-only
long tv_screen 'pointer to screen (words) write-only
long tv_colors 'pointer to colors (longs) write-only
long tv_hc 'horizontal cells write-only
long tv_vc 'vertical cells write-only
long tv_hx 'horizontal cell expansion write-only
long tv_vx 'vertical cell expansion write-only
long tv_ho 'horizontal offset write-only
long tv_vo 'vertical offset write-only
long tv_broadcast 'broadcast frequency (Hz) write-only
long tv_auralcog 'aural fm cog write-only

word screen[noparse][[/noparse]x_tiles * y_tiles]
long colors[noparse][[/noparse]64]
long bitmap[noparse][[/noparse]$C01]
OBJ

tv : "tv"
gr : "graphics"

PUB start | i, j, k, kk, dx, dy, pp, pq, rr, numx, numchr

'start tv
longmove(@tv_status, @tvparams, paramcount)
tv_screen := @screen
tv_colors := @colors
tv.start(@tv_status)

'init colors
repeat i from 0 to 63
colors := $00001010 * (i+4) & $F + $2B060C02

'init tile screen
repeat dx from 0 to tv_hc - 1
repeat dy from 0 to tv_vc - 1
screen[noparse][[/noparse]dy * tv_hc + dx] := (@bitmap) >> 6 + dy + dx * tv_vc + ((dy & $3F) << 10)

screen[noparse][[/noparse]14] := %11

'start and setup graphics
gr.start
gr.setup(16, 12, 0, 0, @bitmap)

'clear bitmap
gr.clear


DAT

tvparams long 0 'status
long 1 'enable
long %001_0101 'pins
long %0000 'mode
long 0 'screen
long 0 'colors
long x_tiles 'hc
long y_tiles 'vc
long 10 'hx
long 1 'vx
long 0 'ho
long 0 'vo
long 0 'broadcast
long 0 'auralcog
This code was borrowed and edited to a point that outputs anything to the TV. right now all I get is a blotch of some random pattern to whatever index I choose for this statement: screen[noparse][[/noparse]14] := %11. What I expected was a solid color of whatever $03 represents. Even when I do screen := colors[noparse][[/noparse]32]. I don't get a solid color. Can anybody give me any insight into how the graphics.spin works. Even looking at games like spinpong seems like gibberish to me. The code above was taken from Dgraphics windows manager.

stevenmess2004

Okay,

The screen array is an array of pointers. Each pointer points to one of the tiles and the colour to be used for that tile. Now you may ask who this works given that a pointer needs to be a word. This page has the details www.rayslogic.com/propeller/Programming/GraphicsDemo.htm

One reason you are getting the different colours is because you are modifying these pointers and making them point to the wrong thing. The other reason is because this demo is setup with the colours changing. A better place to start would probably be the XOR version that I am working on at the moment. That has a standard background colour so should be a little easier to use.

justin weber

alright, I may be starting to grasp this concept. I had to commend out the _stack = $100 ree line in the CON directive in order to call simple_serial. I outputted the screen array contents for the graphics_pallet array to hyper terminal and did a capture. This is the result when x = 0
Screen Array
X Y Value
0 0 1100000101000000
0 1 0000000101000001
0 2 1100000101000010
0 3 1000000101000011
0 4 1000000101000100
0 5 0100000101000101
0 6 0100000101000110
0 7 0000000101000111
0 8 0000000101001000
0 9 0000000101001001
0 10 0000000101001010
0 11 0000000101001011

What i'm still having problems with is finding out what these binary numbers(longs,words) in the value field are for. I now understand that the screen is an array of pointers to words. (192 longs for a 16x12 tile screen). In reference to the graphics_pallet code and not the code in my first post, exactly how is the screen array used. the line:
gr.setup(16, 12, 0, 0, bitmap_base)
uses bitmap_base as a pointer(presumably to address's starting at $2000)
exactly how does this work. Is the screen array somehow aligned to take up address's starting at $2000. And also in the the var section, the lines:
long tv_screen 'pointer to screen (words) write-only
long tv_colors 'pointer to colors (longs) write-only
are both 0 in the dat section under tv_params. I'm having a problem in fiquring out how screen is even used at all. Any help appreciated.

stevenmess2004

Okay, for the graphics driver we have several things. They are
1. The screen array. (A list of pointers to tiles)
2. The bitmap. (All the tiles, what the screen array points to)
3. Sometimes a buffer for the bitmap.
4. A colours array. (Lists the actual colour values that will be used)

The way the tv driver works is that expects a series of tiles. These tiles can be either 16x16 (used in graphics.spin) or 16x32 (used for tv_text) pixels and are four colours (2 bits). The screen array is simply a list that tells the tv driver where to get these tiles from and what colour to make them. When we arrange these tiles correctly in memory (the way that the graphics driver expects them) the graphics driver can use them simply by knowing where they start. So, once you have set up the screen array initially you don't need to change it ever (well this is not quite true, you may have a good reason to change it). Normally you will just change things in bitmap and leave the screen array alone.

The bitmap is not declared anywhere because it needs to be 64 byte aligned. The easiest way to do this is to just put it at the end of the RAM. The easiest way to change things in it is to just use the graphics driver.

It isn't a good idea to comment out the _stack line. That is used to make sure that the stack doesn't get too big and start to make gibberish on you display (or muck up your stack).

Have you got a copy of Andrea's Hydra book? It explains a lot of this stuff really well.

Hope this helps.

justin weber

parallax has been out of stock for about a week now, I decided I would probably NEED that book eventually and went to buy it and it was out of stock. For a couple days now I keep checking back and still can't get it. I figured it wasn't proper to comment out the _stack directive, but I don't know enough about micros yet and that was the most logical solution to get simple_serial to work so I could see the screen array being generated. I went line by line through the graphics_pallet demo trying to figure it out and got very confused when screen was initialize but never really used anywhere. Anyway I did manage to set some text in the middle of the screen to show me the x and y coordinates of the mouse, but still have very little clue about how color is choosen for background and text. I messed with this for a couple hours and the x and y coord values would jump randomly all over. This is where I blindly used gr.finish after each line. After this the coords on the screen were smooth and progressive. I am learning pretty much just by messing around with stuff, but I'd like to know why it works, not just hack demos into a project of my own.

Ken Gracey

Justin,

We have them in stock and you can order them even though the web site says "none in stock". It's a long story why the web says this, but I'll make it short. We don't actually have physical inventory of the Hydra Book PLUS the CD in a single bag. Instead, these are assembled at the time of order by our shippers. They physically grab a book and CD and it becomes the Hydra Book and CD. The inventory level is always zero for this reason, and that's the value of "Quantity on Hand" in our business software.

We've got a few other situations like this one that we're sorting out that cause things to look not the way they are. Once we address a short list of issues like the one you identified, on-line orders will stream into our business software and our treasured sales staff will no longer have to type them in one by one as they have done for many years.

Ken Gracey
Parallax, Inc.

justin weber

i put in my order. Thank you very much.