Has anyone got an example object that uses two cogs to generate sprites over a
Baggers
Posts: 3,019
I've read on the forums that you can use another cog to generate more colours etc.
But has anyone got any code that handles more than 4 colours, ie 4 ( or should I say·3 + transparent ) colour sprites over a 4 colour screen?
The reason I'm asking, is I would like to figure out how you can change the colours that another cog is displaying.
So if anyone has an example object file they wouldn't mind sharing or even PM'ing me or whatever.
It would be greatly appreciated.
Chip, I don't suppose you have one lying around or could knock one up for me? if nobody else has?
Cheers in advance,
Baggers.
·
But has anyone got any code that handles more than 4 colours, ie 4 ( or should I say·3 + transparent ) colour sprites over a 4 colour screen?
The reason I'm asking, is I would like to figure out how you can change the colours that another cog is displaying.
So if anyone has an example object file they wouldn't mind sharing or even PM'ing me or whatever.
It would be greatly appreciated.
Chip, I don't suppose you have one lying around or could knock one up for me? if nobody else has?
Cheers in advance,
Baggers.
·
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Perhaps you and I need to trade notes... I'm playing with the 4 color driver right now and also wanting more. I'm about the start looking at the HEL driver myself. I suspect Paul is right, it should do everything that both of us are looking for. Do you have the Hydra book yet?
Oldbit
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." -Albert Einstein
Yeah, sounds like we should trade notes, and no, I don't have the Hydra book, nor do I have a hydra, I just have a prop proto board, which is why I didn't get the hydra book. Prolly should have now, in hindsight, but that's such a wonderful thing, if only it was foresight [noparse]:)[/noparse]
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." -Albert Einstein
As from reading the posts I'm guessing your a protoboard person too [noparse]:D[/noparse]
Ordering book now. [noparse]:([/noparse] Just looked, book $39.99 shipping costs $80+ that's not including the import tax that'll be required. so not ordering it now.
Guys at Parallax, is there any way for me to buy it and download it electronically?
EG could you give me a direct link to a HUGE zip file with CD contents and electronic version of book? once I've paid for it obviously.
I've no objections buying the book, I do however object to paying UPS double the cost of the item.
I don't mind not having the physical book, as long as I have its contents.
The sprite system described in the hydra book uses the same cog as the video driver and (correct me if I'm wrong) does not really function independently of the tile based driver, but rather uses it to draw "sprites" into . this means that the colors that the "sprites" can have are the same colors as the tiles on which they are drawn.
So this sprite functionality seems to me to be like having a software "blitter" that can draw arbitrary shapes in the main bitplane, these sprites do not act like "real" hardware sprites that can function independently, like the sprites in the MSX or commodore 64.
to create "hardware" sprites that function independently from the main video driver they must be able to manipulate the video output "overriding" the output generated by the main (tile based) video driver. For a VGA driver that wouldn't be too hard, just outputting new video data to the RGB pins -just after- the tile based driver outputs it's data would do the trick. A second cog could do that if it could synchronize to the tile based drivers cog accurately enough. The synchronizing could be done by sharing a common timer count and using the waitfor instruction to synchronize on it. However, the problem for PAL/NTSC is that the video driver has to manipulate the color burst generator hardware, and I am not sure how two cog's can manipulate this one hardware resource independent of each other. Perhaps just one cog at a time can do that, I am not sure.
If only one cog can manipulate the color burst hardware then there is a problem.
To overcome the problem the main video cog could be written to accept "sprite video data" from another "sprite video data generating" cog, but the cogs would need a very fast inter communicating system, transferring the necessary color pixel data (six or seven bits per pixel) between the two cog's in real time could turn out to be very hard.
The Propeller could really use a faster inter-cog communication path that does not have to go through the hub. The new Propellor Parallax is working on will use a second I/O port (without pins) that could be used, but the current Propeller does not have such a mechanism a.f.a.i.k.
It has the semaphores, but I don't think they can be used to transfer data in-between cogs.
Mahjongg
Not 100% sure how Cog does TV yet, but gonna work on it, cos I wanna use more than four colours [noparse]:)[/noparse]
And it will be a shared object, so everyone can learn from it, or just use it.
mahjongg,
There's a completely separate video generator attached to each cog. You can have multiple TVs attached to one Propeller, all with different stuff being displayed. With VGA, as you mentioned, it's relatively easy to add more colors by running synchronized cogs and using additional I/O pins, but, with TV, the color information is carried in the subcarrier phase and not easily manipulated. I suspect this could be done using external hardware for the last stage of the video generation like this: www.analog.com/UploadedFiles/Data_Sheets/AD725.pdf
The AD724 (www.analog.com/UploadedFiles/Data_Sheets/AD724.pdf) is similar and includes a PLL and on-chip oscillator so it can use a color burst crystal.
Post Edited (Mike Green) : 4/15/2007 4:14:25 PM GMT
One of the things that disturbs and delights me is the fact that we appear to be on the cutting edge of this technology. All of us are discovering the possibilities of this chip and language, and I suspect that in some ways Chip/Company are surprised and delighted by the ways we have managed to push/twist this chip into so many solutions. The dounside of being on the cutting edge is a lack of avaible documentation.. IIUC, the Hydra book is the only source of information on Propeller outside the command documentation from Parallax. I'm putting together a local father/son group to work with microprocessor technologies starting with cheap picaxe chips (cheap, $3, no tears when blown up) to get the introduction, then moving to the Propeller. I'm starting the process of developing some documentation and projects, (of course I'm only a chapter ahead of everyone)
Parallax, understanding your reasons for not electrophing the book, can you do something with the CD itself?
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." -Albert Einstein
There is a solution to allowing every pixel to be one of the 56 or so colors for the TV driver, and no I didn't come up with this...
You put the video generator into 4-color mode, but you set up the timing in VSCL such that only 4 colors get shifted out instead of the normal 16. The bits nomally used to define the pixels in the WAITVID instruction is always a constant #%%3210, and the palette (4 entries of 8-bits) is what defines those colors.
The problem with this is of course, now a scanline has to be pre-rendered (when doing sprites) because of less calculation time available. There are two ways to do this, one is to bounce between synchronized cogs, alternating between calculating the next scanline and streaming it out. The other is to have one cog dedicated to streaming from a scanline buffer in main RAM, and another cog dedicated to filling that buffer (although I haven't seen code that does the buffered method).
For me, the CD-ROM with commented source code on it was more useful than the Hydra Book, but that was probably the intention.
Personally, I was relieved that it was possible to get per-pixel color without any special hardware (instead of 4 colors per 16 pixels), even if there are only 56 colors available when using the TV.
Does anyone here have a scope and an older computer?
Long ago, on the CoCo 3, I was doing 160x192 with very close to 256 colors through artifacting. Essentially what I think happens is the color burst is triggered at the same time every scan line, so artifacted pixels line up vertically. From there, it was easy to just use the 640x192 4 color mode on that machine to generate the colors. Many older computers did this, but didn't have the higher pixel clock and color depth combination the CoCo did, with the result being less colors, or a coarse looking image. (Look at the Apple ][noparse][[/noparse] for great examples of that.)
The prop does this easily, but for the color burst bit. I've had no luck changing the TV driver to align the color clocks in the same fashion as the older computers. Anyone know, or care to take a look at the signals?
Either the changes I've tried are not actually doing what I think they are, or there is some aspect of the signal I don't understand well enough yet...
I'll give this a shot to see what I can come up with.
I suppose at least without me owning Andre's book, at least when I do end up doing the code I can release the object freely without breaking any copyright, as I'm assuming the contents of the CD will be copyrighted material anyway.
I look forward to this new challenge [noparse]:D[/noparse]
I am well aware of the capabilities of the Propellers video generator, but this thread is interesting in that it tries to find ways to overcome some of the limitations of the current video drivers. The main problem with the current drivers are that they take up much memory and still only can generate four different colors in each 16x16 tile. For games a background where each 16x16 area can only have four different colors, it's no too bad, but if you want to display a multi colored "game character" in front of the background it is a severe restriction. Using a real sprite based system would overcome some of the restrictions, giving more a color-full picture while still limiting memory use.
Yes, external hardware will make this more easy, but I am trying to think of ways to do this for the Hydra, using the existing hardware.
My idea was not to use extra i/O pins to be -tied together- with the existing video I/O pins (wire OR'ing them together) but to "invent" new tricks to do more with the existing hardware of the Hydra.
Let me try to explain the problem.
PAL/NTSC video output is created by the Propeller using two different mechanisms, one for the brightness or "luma", and one for hue or "chroma".
The intensity (luma) of the output signal is created directly as a voltage level, similar to the way the VGA signal is created. The Hydra uses three I/O ports (the fourth I/O port is only used when directly creating a VHF RF signal, not for the standard PAL/NTSC driver), and with that it can create eight different voltage levels on it's TV output.
Of these eight voltage levels the lower few (normally three) are for the sync levels, of which the "top one" (highest voltage) them is used for the "black" level, or "front porch" level. With the then remaining five or so levels the "luma" of brightness levels must be created, except we also need one level above "the whitest white" level to support the color burst signal, which normally adds or subtracts one from the chroma level (this implies also that the "saturation level" of the chroma signal is normally fixed). This leaves us with four different luma levels. Because the color burst generator hardware is only able to give about 16 discrete phase shifts we end up with 64 (4x16) different hues of color. With some software trickery it's possible to create one more luma level, so in theory we can display 80 different hues.
The trick is that there is one, and only one, COG that uses it's counter phase registers to create the color burst signals, other COG's cannot directly write to that same counter phase registers, so they cannot influence the chroma part of the video signal.
Now lets think about what is needed to create a real independent sprite, Whilst the main video driver uses a "WAITVID D,S" instruction to stream video data to the three video I/O pins, it's theoretically possible that another cog runs software that mimics the timing of the main video driver exactly, and is synchronized to the software running the main video driver exactly to the clock tick. If this driver outputs a "different" value to the video I/O pins just after the main video's "WAITVID" instruction, then it would be possible to "overrule" the video signal and output the pixeldata for a sprite. For a VGA display this approach could work, however there is a problem when trying to do this in the PAL/NTSC (composite video) mode! The second cog has no way to synchronize it's color burst generator (using the counter phase registers) so that the phase of the signal that the second COG's "color burst generator" creates exactly matches that of the first COG, at least I don't see how that can be done.
Therefore the "sprite video signal" generating COG cannot change the composite video output signal without corrupting the color base signal.
It is therefore necessary that the same COG that creates the main (background) video signal also creates the sprites video signal, that is very difficult to do.
The COG needs to know -when- to output from the secondary (sprite) video source, and when from the main (tile based) video source, and it needs to fetch the alternative video data from somewhere. Giving the timing restrictions that is a tall order. It would help if this "TILE" COG could be "assisted" by a second "sprite generator" COG, but the problem is how to get sprite pixel data from the SPRITE COG to the TILE cog in time because there is no fast enough mechanism to send data from one cog to another, but perhaps we don't need one. Perhaps it's enough that the SPRITE COG can create a few words of "sprite video data" in "real time" put them in the main memory and that the TILE COG can read this video data and "mix" it with the tile based video data. For example by using a byte of "sprite data" for each pixel, were the upper bit could signal "use this data or ignore it", and the rest of the bits would give the actual color for the pixel when not ignoring it (when displaying a pixel of the sprite).
I hope someone has the time and interest to try to write such a sprite system.
Mahjongg
I wish you well. I'm of the camp that is happy to use a little bit of extra hardware to make something work in a straightforward manner. I remember someone discussing trying to get two different cogs synchronized so that the color burst generators were in phase and found that they couldn't tell whether they would be in-phase or 180 degrees out of phase and Chip had made some suggestions (or something like that). Maybe you could find the thread.
Mahjongg has it summed up perfectly. IMHO, this is why I was exploring the artifacting technique. Having a color burst, that is the same for each scan line, would allow for us to just put pixels where we want them, thus getting the colors we want. If this is done, then it may well be possible to then dynamically draw the sprites instead of merging them with a bitmap. High color depth images then would be possible, given the RAM constraints.
This all assumes a target resolution of ~160 pixels horizontally, NTSC. Given the stable color burst, anything higher than that ends up being sub pixels, which then will be colored according to their placement within the color clock cycle.
As the prop behaves right now, it's excellent! The baseband video output is just great, with scaling, interlace --the works! We are actually needing to degrade it some, for gaming. I find that kind of entertaining actually.
As for using other hardware, I personally just think this kind of tinkering is great fun!
Edit: I spent some time, a year or so ago, programming on the old Atari 2600. It's got video hardware that requires one to dynamically display the screen display. Compared to most everything else, it's a complete pain. However it's also a lot of fun to get your desired display working. And it's capable of a lot of improvement over time. Here we are 30 years later still getting better visuals out of that thing. IMHO, the prop has the same qualities and that's where the fun is.
Also, the tight coupling between display and logic results in rock solid visuals. Movement & such are all perfectly synced to the screen refresh. On the old Atari, it has to be. On the prop, it can be.
The attraction for me personally is the relevance. After many years working with high end computing, scaling down has the appeal of getting back to the bits again, plus some electronics, which is always fun. Much better to be doing this learning and skill building on hardware being produced today, than in 1979!
Post Edited (potatohead) : 4/15/2007 10:56:55 PM GMT
mahjongg
That's the thread. The core hint Chip passed along is a nice technique to make sure the cogs output video in perfect sync. The VGA cursor is done this way. See the attached driver for details.
Attached to this post is a quick example of the artifacting technique. Run it, along with the slightly modified TV driver to see the artifacts and the colors. I normally will put this kind of thing in it's own folder to keep things seperate. The only modification to the TV driver, for this example, is a tweak to the number of scanlines and one other parameter, suggested to me by Chip also.
word 243, 286 'vvis
word 11, 18 'vinv
Some tinkering revealed one can either change the number of scans to be an even number (244 or 242), or change vinv from 10 to 11. I'm sure this example runs either way.
It's running a 640x192x4 color screen. There is not enough RAM for this, so only the 512x192 region is addressable, with the rest displaying some of the prop ROM contents. No biggie for now.
There are several rows of colored blocks. These are artifacted colors, one for each of the three intensities defined in the color map. The bottom three are simple artifacts where one out of every few pixels is plotted to generate a color, based on where it lies along the color cycle. Effective resolution is 160x192, but it's staggerd such that the vertical edges are ragged.
This can be seen in the upper most set of blocks where a slightly different pattern was used.
The two grey blocks should actually generate colors, but don't and that's the rub.
I dug out an older Atari machine to more closely examine what it appears to be doing. I've no scope, so it's a lens and a close look at the TV.
The color clocks are aligned the exact same way on each line, and the effective full color resolution of the machine is 160x192. (This is assuming no overscan.) For each pixel, there are 16, sub pixel locations where a given color value will output a very small sub-pixel and that's where the color comes from. Move the pixel, change the color. The video hardware has 16 grey levels, so it will do 256 colors. This video hardware is also very dumb. No scaling, etc... Just clocks, pixels and RAM.
The prop does a lot more. And this is good stuff actually, in that text displays, etc... will always be rendered in such a way that they are clear and readable. Plotting blue lines, for example, always gives blue lines no matter what the horizontal scale has been set to.
That's it for now. I've no time for it at the moment, but thought I would just post something that illustrates the differences...
Had a play with your aa_color.spin and aa_TV.spin, I assumed aa_graphics.spin was just an unmodified graphics.spin
Really interesting stuff, but would be a nightmare to make a character map + sprite renderer use that layout, especially with having to have gaps.
I also noticed the wonderments of NTSC, whoever named it Never Twice Same Colour wasn't joking [noparse]:D[/noparse]
gr.colorwidth(3, 0)
repeat y from 0 to 191 step 2
gr.plot(y*2 ,y)
gr.plot(y*2+2,y+1)
Doing this gives multiple outcomes, as sometimes it's Red line of dots ( or a line on small PS1 monitor [noparse]:)[/noparse] ) and sometimes it's Green and sometimes it's Blue.
So Using this method isn't really the way to go.
Does anyone at Parallax have a tvout with hardware sprite routine? to make more than 4 colours per cell?
Or am I going to have to buy pay UPS shed loads of cash to get Andre's book, which I would then most likely not be able to share the spin object, since the book source is most likely copyrighted?
As I'm not the only one who would like a TV out with sprites.
Chip, is there a way, ( ie, do you have example code ? ) that has anything like what we're after here? something along the lines of 2 cogs running one generating the sync and colour phase, then outputs one line, where the other cog outputs another line, with more than 4 colours? I don't mind hacking in a line renderer, ie for character map + sprite into a line buffer, while the other cog displays the previous line, then they switch.
I strongly suggest Andre's book. I've worked with much of the code. It all works very well. The included demos are worth the money as lots of solid techniques are shown.
The code and examples are clearly written, and commented. A whole lot is possible with that package.
My main interest in getting the color issues nailed down is being able to obtain that classic computing display look. Also, any hardware sprite emulation will require the colors and such to be synced. High color depths at resolutions below ~160 pixels horizontally will require this too, unless the 56 color scheme is used. I think this is possible, it's just gonna need some more thinking and discovery at this stage. I work on this, from time to time as I can.
I think you can share your spin object(s), just don't include the graphics engine! That way, the effort invested in the book will continue pay off as it should, and everybody is happy.
but again, if I got the book, I couldn't release the object for others to use, if we use anything from the book, that would be unfair to him, and like I've mentioned, probably break a copyright somewhere.
So the best thing would be for us to come up with something that can be used by the masses, to show what the propeller can really do.
Also, Sorry Mike, but yes, it would be easy to add on some extra hardware when needed, but if your gonna do that, you might as well buy a computer, besides, would you be able to get data through another source fast enough? mind you, I guess it's a coder/engineer difference of oppinion, engineers just add on extra hardware, coders like to code.
PS, Chip, for the "Prop2" can you add more bits for TV, and make some way of making it capable of outputting bits to each pixel if need be, or some way to make it so that it can easily handle more colours, like maybe have 4bits for colour, instead of 2.
Now I do realize that a black and white "sprite" is not that interesting (even when superimposed on top of four other colors), but there are some situations where it could help, for example:
- For creating a mouse pointer, (either white inside with a black outline, or black inside with a white outline).
- For creating a score in the game picture, or other black and/or white text on top of the colored game screen.
- For a "cross hair", to aim in a shooting game.
- for a blinking text cursor.
All these processes, (running on a second core) can also help the main program's COG to unload one processor task.For example the mouse pointer generator COG could also do other mouse pointer managing related tasks, such as getting data from a COG that reads the mouse (perhaps even doing that himself), update the mouse position check for borders and mouse (double)clicks, etc.
A COG that displays a score could also keep the score, and format the display text.
So my conclusion is that although at the moment I do not see how a generic sprite could be generated with a second COG (when creating composite video, it seems easy to do when generating a VGA signal), it seems to me it _is_ possible to generate a black and white "sprite", or text, overlaying the video output generated by another COG.
Mahjongg