Graphics and the Propeller.
SONIC the Hedgehog
Posts: 321
So I've had my propeller for less than a month, but I didn't take me very long to figure out it had the capability for graphics, but have a few questions.
1) Assembly is faster than spin, so I would assume that it would be more efficient for displaying graphics?
2) when moving data to the display buffer to be outputted, should all the data be moved and then the screen refreshed, or should the screen be refreshed every so bytes of data?
1) Assembly is faster than spin, so I would assume that it would be more efficient for displaying graphics?
2) when moving data to the display buffer to be outputted, should all the data be moved and then the screen refreshed, or should the screen be refreshed every so bytes of data?
Comments
On the Prop, there are basically two ways to do graphics. One is standard bitmap graphics. A region of the HUB memory is used as the display buffer, which is scanned and displayed by a COG. One or more additional COGS contain PASM routines for graphics drawing. Line, point, shape, etc... A SPIN program controls the whole thing, essentially issuing commands to the PASM COGS doing the heavy lifting.
Bitmap graphics can be single, partial or double buffered. (triple buffers are possible too, but not realistic on the Prop, due to memory constraints) A single buffer bitmap must either be drawn entirely during the TV / Display blanking time, or flicker will be seen by the user. An alternative is to draw very slowly, or only draw parts of the display, to avoid this.
A partial buffer bitmap display spreads the screen drawing out over a number of video frames, using a smaller buffer. An entire screen is drawn over one or more video frames. The trade-off here is complexity and overall perception of display speed, along with image integrity. (tearing can be seen on some images that are animated and that cross a partial buffer boundary)
Double buffer bitmap graphics are probably the easiest on the Prop, where an entire screen is drawn, then shown all at once while the next draw occurs in an off screen buffer. Memory cost is high for this one, often consuming most of the HUB memory.
Bit-map graphics have been built to do two color, 4 color, 16 color, 8 bit or "full" color.
A variation on the bitmap graphics is "character" type graphics, where the screen tiles are used to build a text screen, or simple graphics representation of things. A small region of HUB memory holds tile or character data, which is drawn to the screen dynamically, based on the tile list, which is a list of all the screen positions and which tile data is to be drawn in that position. The Parallax graphics driver does this to form bitmap displays, by stacking unique tiles to fill the screen. Other drivers, intended for text type displays, allocate less RAM, and only display 256 tiles.
From there, various dynamic drawing schemes are possible.
The basic method is the scan line driver. One COG builds the screen display, one scan line at a time. Those scan lines are built by other COGS in real time, as the display is being made. Sprite data exists in the HUB, and is drawn onto the screen based on a sprite list of positions, data values, image addresses. Using 4-5 COGS, a prop can generate sophisticated screen displays consisting of hundreds of sprites, with tens of sprites per line generally possible. Fewer COGS = fewer sprites per line.
In general, you want to use PASM to setup the graphics engine you choose to use. For a bitmap display, two COGS can do a lot! One draws the screen to the TV, the other provides graphics assist to SPIN by doing things quickly, directed by the SPIN program, which basically runs the game.
For the Sprite display / dynamic display method, it's generally the same, but the PASM requirements rise considerably as those drivers are difficult to write. The good news is we've got lots of them to choose from, most of which can be used for other projects besides the game they were written for.
SPIN runs game logic, collects user input, builds list and can calculate (some) collisions plenty fast enough for games.
Sound is about the same as video. One or more COGS are dedicated to produce sound, with SPIN triggering and defining the sounds.
Graphics are all about time. The TV / VGA beam moves quickly, and needs the display data to be there at all times. The higher resolution the display is, the fewer things a COG can do during that time, meaning the cost for higher resolution, or more sprites or more colors is always more COGS in addition to more RAM.
Sometimes it's good to express data in terms of number of bytes per refresh, though it more normally boils down to memory used and number of objects drawn. The core thing is time, with the rest being determined by the limits of the graphics system you are using.
I'd get a firm grasp on Spin before jumping into Assembly. (Something I'm STILL working on.) You can do this while working with projects you enjoy doing. (Propeller gaming) -- I'd start with some of the links I've already given you. I've opened a discussion around that 1-byte,per pixel driver (mashed_potatoes_TV.spin): http://www.gadgetgangster.com/forums/viewtopic.php?f=4&t=68 It was used recently in: Savage Wheels: http://www.gadgetgangster.com/forums/viewtopic.php?f=4&t=64 -- It's an excellent beginner driver.
OBC
onto the displaying buffer after each significant change to the screen bitmap. The common example is the GRAPHICS demo,
the one with all the moving shapes and a huge counting digit. Its a good starting point.
As Potatohead mentioned it is possible to have scan lines generated in separate cogs, generating video via alternating scanlines. There was a tutorial of that here:
http://forums.parallaxinc.com/forums/default.aspx?f=33&m=288732
To get adequate performance on a multi-cog driver, PASM is almost a requirement, and, as Potatohead mentioned, comes with added complexity.
http://forums.parallax.com/showthread.php?106036-Multi-Cog-Tile-Driver-Tutorial...
When I was trying to learn PASM, I found JonnyMac's SpinZone articles really helpful.
If you are wanting to look at more graphics drivers you might look here. There are some more (and less) complicated than the one previously mentioned. I don't think making a game on the Propeller is any more difficult than any other platform. You might want to try to build something with one of these other drivers first, and then build your own "engine." I have no doubt that you can master PASM though, if you go that route. Definately though look at the Spin Zone article that Duane Degan mentioned. It is a nice introduction to PASM.
At a fundamental level, all of them. Going back to the 4004 and 8080 1970's vintage chips, as there were more transistors per chip, the chips ended up with more instructions. Going from the 8080 to the Z80, there were a huge number of extra instructions, but the interesting thing is that most of them didn't really add much value. There was sort of a backlash with the rise of RISC (reduced instructions) which had the benefit of making chips easier to learn.
I find the propeller has much in common with chips like the 8080 - instructions you use over and over like jump, call, logical and, logical or, bitshifts and input/output and moving data. Learn just those and you are almost there.
For me, the biggest change from the old-skool chips was that there are no registers. Instead of moving data into register A, then some more data into register B, then adding them, then moving the answer back out into memory, in the propeller, every location in memory is also a register. It means you can do things with less instructions.
The two things that get me all the time with PASM i) watch out for leaving out the #, and ii) there is a big difference in the way you handle numbers more than 511.
I love the unbridled enthusiasm - it is infectious!
I actually got a lot out of reading the instruction coding table for the prop. You may too.
@circuitsoft actually that is a great Idea. You sir are indeed quite the genius. But it's time for me to get my spin on, off to the data sheet! Thanks a bunch!
I really appreciate all the help given!