Background/foreground operations; how to utilize them?
Harley
Posts: 997
Made some progress using the 3.5" color touchscreen (from Rayman). But in the process there are some annoying things happening with Chip's Graphics object I don't seem to be able to work around.
First was, not understanding 'graphics' use, trying to write to the display memory addressing it where my CON defines it at $8000 - 9600; a scaling cog was going to use that, but all I got was pretty colorful patterns. (320/32 * 240 = 2400 longs = 9600 bytes) So 'poking' via 'plot' at various smaller values I realized two things; first was the center of the display memory was 0,0 referenced, not the top, left; second, it was in pixels referenced from the center, so having to do + and - values to position plot pixel or line values needs be dealt with.
To help during debug, I wrote to the screen some variable names and values. Large size, not like the 'printStr(string("text"))' size. But that text and its background (blue) seems to only be cleared if everything on screen is erased. How does it appear in front and the graphics always stay behind? Is there an easy way to make that DEBUG information not appear to overlay the graphic image?
it appears only 4 colors are accessible in the graphics mode; 0..3 for black, yellow, orange, and white. Yet, I was surprised to see the yellow text on blue background for the DEBUG text/values; more than 6 colors at one time on the screen. And the graphics never writes over that debug text. Is there a way to make it 'move' behind the graphics of display clear? Is it possible to assign some other set of 4 colors?
Using a sigma-delta A/D and a 4-bit D/A to simulate an example waveform used up all the remaining 6 pins on the PTP board. But the PTP board allows one to begin right in developing code for such a project. Added a 4-AAA cell battery pack which lets one take it anywhere and continue debugging some aspects of one's program. Don't have to be tied down near an a.c. outlet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
First was, not understanding 'graphics' use, trying to write to the display memory addressing it where my CON defines it at $8000 - 9600; a scaling cog was going to use that, but all I got was pretty colorful patterns. (320/32 * 240 = 2400 longs = 9600 bytes) So 'poking' via 'plot' at various smaller values I realized two things; first was the center of the display memory was 0,0 referenced, not the top, left; second, it was in pixels referenced from the center, so having to do + and - values to position plot pixel or line values needs be dealt with.
To help during debug, I wrote to the screen some variable names and values. Large size, not like the 'printStr(string("text"))' size. But that text and its background (blue) seems to only be cleared if everything on screen is erased. How does it appear in front and the graphics always stay behind? Is there an easy way to make that DEBUG information not appear to overlay the graphic image?
it appears only 4 colors are accessible in the graphics mode; 0..3 for black, yellow, orange, and white. Yet, I was surprised to see the yellow text on blue background for the DEBUG text/values; more than 6 colors at one time on the screen. And the graphics never writes over that debug text. Is there a way to make it 'move' behind the graphics of display clear? Is it possible to assign some other set of 4 colors?
Using a sigma-delta A/D and a 4-bit D/A to simulate an example waveform used up all the remaining 6 pins on the PTP board. But the PTP board allows one to begin right in developing code for such a project. Added a 4-AAA cell battery pack which lets one take it anywhere and continue debugging some aspects of one's program. Don't have to be tied down near an a.c. outlet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
640 x 480 - 44K
Comments
The graphics done large size write the entire tile, erasing the graphics. On the other hand, using the gr.text method, writes only the pixels used for the text. The difference is the former being a raster font, just bit patterns and longs, and the latter is a vector font, drawn as lines, which only draws the text, as opposed to the entire tile.
Some modification of the text printing utilities could "or" the text with the graphics, but that's not been done.
There are only 4 colors available in a given tile. Go and use the commented graphics_demo.spin method you will find in my signature to see how to set colors for each of the tiles. The methods in that program can probably be moved to the one you are using, because the same overall driver structure is used. You might have to rename a variable or two, but that's about it.
There are color palettes, each containing 4 colors. Each tile can be assigned one of the palettes. All the colors can actually be on the screen at one time, just only 4 of them per tile.
One way to deal with the graphics and debug text would be to do the text first, then write the graphics. That order of things would improve your display, as would choosing a black background for the text color.
Does your board have serial? If so, you might consider writing debug to that, which does require a secondary machine of some kind.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!
Oh, that explains why at times when something goes wrong, that the screen might fill up with 'interesting' colors and patterns. Where each tile can have one of 4 colors. I did notice sometimes adjacent tiles might have similar color but darker/lighter shades. I know I have a lot to do and to learn to get this program working; a fair amount is already in place. Later will play with doing crazy color generation with some other program.
I don't think Rayman's PTP board has any serial, as all the pins are presently used up. Nor do I recall any '232' type IC on the schematic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
The tiles that are displaying the text from the ROM are simply pointing to the ROM, not by writing the data to the graphics screen. I made a mistake in my post above. Truth is, if the ROM contents were copied to the graphics screen, my post would be true, but that's probably not the case. Chances are your graphics pixels are still there, right under the text!
I've not used Ray's driver.
It's far more likely, those tiles are just displaying data from the ROM. That's done by setting the tile address to the character in the ROM, and choosing one of two color combinations.
If you re-run your init screen code, where it sets up the tile addresses, your graphics should reappear.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/25/2010 6:09:05 AM GMT
Does anyone know how to clear a menu written by gr.text(x,y,@text)?
I imagined by overwriting with n-spaces it would provide the background color, in this case black. If I post some other text at that location it is just OR'ed in the foreground color making for gibberish. HALP!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Noticed I had the menus in the 'repeat' loop, so they always rewrote something that I was wanting to change at one location. My bad on that point.
And trying to over-write text with black spaces on black wouldn't do it for some reason.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Post Edited (Harley) : 7/25/2010 11:51:13 PM GMT