Perhaps you have this already, but it shows some tiles used for graphics. The trouble is, there just isn't enough RAM to do much bitmap in 1024x768 mode. You've got to settle for just a few tiles.
hi..Thanks for your suggestion..Yes I already have this project....I need 2 frames with graphics object...and they must containing different shape,number etc...
I need to identify different display_bases and want to fill them different shapes,counters etc..When I tried that all display_bases were same content.
You will need a separate instance of the graphics driver for each graphics frame on your display. Each instance will use a cog the way the graphics driver is currently written. It is possible to change the driver to share one cog among several frames, but it would take some work to go through the code and do that. You might declare:
You could also declare a 4 element array of graphics drivers and it would work the same. Each frame requires a call to start and stop and setup to define the bitmap. You could reduce the number of cogs used if you don't need to constantly update the graphics frames by calling stop for the idle graphics frame and start for the new active one. If there's one frame that's constantly updated, you could leave that cog running. Don't call any graphics method for a frame without an active cog ... the program will hang up waiting for a cog to process the graphics request. Be sure to call finish before calling stop.
Chip Gracey (Parallax) said...
Perhaps you have this already, but it shows some tiles used for graphics. The trouble is, there just isn't enough RAM to do much bitmap in 1024x768 mode. You've got to settle for just a few tiles.
Chip, thank you for posting this.. (Although you've given me another week of sleepless nights to look forward to, to absorb this. This looks like a perfect addition to my 8bit rendering project. (http://www.petscii.com/propeller64)
I'm still working my way through an understanding of the "tiles." Do I understand properly the tiles themselves control colors fore/background colors of the screen? And that the limitation of these is less sections to control?
Then how can I activate cogs for new display bases..Is there any status window to see actived and identified cogs..I tried ur suggestion before...But when I stop the graphics.spin with gr.stop or gr2.stop all the graphics was disable..I understood I have to activate new cog for another graphic processing...Can u help me about setup new cogs identification syntax or code samples..Very very thanx..
Ilker,
There is no status window. You can save the cog numbers returned by the COGNEW calls and display them yourself if you want.
The only reason to stop one of the graphics objects is to reuse the cog involved. If you have enough cogs for all the graphics frames, don't bother.
Also, if you do stop and restart the graphics objects, be sure to use the .finish call before stopping it so the last graphics operation will finish.
The graphics object will handle its own cogs if you call .start during initialization and .stop if you want to stop it.
Set one display base, and map all the tiles into a rectangular area. Draw with one graphics instance where it makes sense. Imagine all of your graphics fit into that rectangle.
Each tile points to an address in memory somewhere. Pointing a tile to the ROM can display a character. Pointing it to a location in RAM can make it display part of the display base. Simply change the addresses for the specific screen tiles to locations in the display base and you are done with one COG and just having to live with drawing in specific coordinates to place images in the right tiles.
See this document for an explanation of the screen array, which is where this addressing is done:
ABCDE
FGHIJ
KLMNO
Each letter is a unique tile, all arranged in the typical rectangular bitmap. This is a structure in RAM, that actually looks like this:
ABCDEFGHIJKLMNO From lower to higher memory, linear.
On the display you do the following:
RRRRRABRRRR
RRRRRCDRRRR
RRRRRRRRRRR
RRRDEFGRRRR
RRRHIJKRRRR
etc...
The 'R's represent a tile pointed to ROM memory to display a character. The lower letters all refer to the RAM mapped tiles that the graphics driver display base point to.
To display your graphics, just calculate where the coordinates would be for each unique tile, assuming they are packed into the rectangle.
You should be able to work with the demo, edit the screen addresses and get different tiles to display different parts of the little bitmap chip put into the demo. Once you have achieved this, the rest will be obvious, I hope!
the graphics.setup command is designed to be called routinely, so that you can point the graphics driver to different bitmaps. Of course, you must call graphics.start to get the driver launched into a cog, but after that, you can call .setup all you want to direct the driver to different bitmaps of varyings sizes.
hi..thanx for all helps...But I m beginner level for Propeller chip yet..I tried to do your suggestions..But I cant say it is ok..I attached my project...Pls examine my project files...I want to do that;
in up frame I want to up arrows, in down frame I want to down arrows..Can anyone· change my code for it....if anyone has done that...I will understood how can use more cogs at the same time...thanx for your helps...
ilker
Posts: 5
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
I need to identify different display_bases and want to fill them different shapes,counters etc..When I tried that all display_bases were same content.
OBJ base1 : "graphics" base2 : "graphics" base3 : "graphics" base4 : "graphics"You could also declare a 4 element array of graphics drivers and it would work the same. Each frame requires a call to start and stop and setup to define the bitmap. You could reduce the number of cogs used if you don't need to constantly update the graphics frames by calling stop for the idle graphics frame and start for the new active one. If there's one frame that's constantly updated, you could leave that cog running. Don't call any graphics method for a frame without an active cog ... the program will hang up waiting for a cog to process the graphics request. Be sure to call finish before calling stop.
Chip, thank you for posting this.. (Although you've given me another week of sleepless nights to look forward to, to absorb this. This looks like a perfect addition to my 8bit rendering project. (http://www.petscii.com/propeller64)
I'm still working my way through an understanding of the "tiles." Do I understand properly the tiles themselves control colors fore/background colors of the screen? And that the limitation of these is less sections to control?
Oldbitcollector
There is no status window. You can save the cog numbers returned by the COGNEW calls and display them yourself if you want.
The only reason to stop one of the graphics objects is to reuse the cog involved. If you have enough cogs for all the graphics frames, don't bother.
Also, if you do stop and restart the graphics objects, be sure to use the .finish call before stopping it so the last graphics operation will finish.
The graphics object will handle its own cogs if you call .start during initialization and .stop if you want to stop it.
Set one display base, and map all the tiles into a rectangular area. Draw with one graphics instance where it makes sense. Imagine all of your graphics fit into that rectangle.
Each tile points to an address in memory somewhere. Pointing a tile to the ROM can display a character. Pointing it to a location in RAM can make it display part of the display base. Simply change the addresses for the specific screen tiles to locations in the display base and you are done with one COG and just having to live with drawing in specific coordinates to place images in the right tiles.
See this document for an explanation of the screen array, which is where this addressing is done:
http://www.parallax.com/dl/docs/prod/prop/Hydra-Ch16Sample-v1.0.pdf
The goods are somewhere around page 333.
EG:
The 'R's represent a tile pointed to ROM memory to display a character. The lower letters all refer to the RAM mapped tiles that the graphics driver display base point to.
To display your graphics, just calculate where the coordinates would be for each unique tile, assuming they are packed into the rectangle.
You should be able to work with the demo, edit the screen addresses and get different tiles to display different parts of the little bitmap chip put into the demo. Once you have achieved this, the rest will be obvious, I hope!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
in up frame I want to up arrows, in down frame I want to down arrows..Can anyone· change my code for it....if anyone has done that...I will understood how can use more cogs at the same time...thanx for your helps...