How could sprites be implemented?
cbmeeks
Posts: 634
I see a lot of people using the propeller for their homebrew console/computers. And for good reason, not many choices out there for easy NTSC/VGA video.
I am a newbie to propeller and was wondering how/if sprites could be added? Also, I can't seem to find out what the resolution or color depth is to the "default" NTSC display.
Anyway, would it be possible (easy?) to use one cog for the normal display and use another cog for rendering sprites (or a parallax layer) and mix the two for one signal?
If so, then it seems in theory you could have 7 layers with one doing mixing. Unless the mixing would take more than one cog.
Of course, memory is an issue. Can the video be driven from external SRAM?
Thanks for any info.
I am a newbie to propeller and was wondering how/if sprites could be added? Also, I can't seem to find out what the resolution or color depth is to the "default" NTSC display.
Anyway, would it be possible (easy?) to use one cog for the normal display and use another cog for rendering sprites (or a parallax layer) and mix the two for one signal?
If so, then it seems in theory you could have 7 layers with one doing mixing. Unless the mixing would take more than one cog.
Of course, memory is an issue. Can the video be driven from external SRAM?
Thanks for any info.
Comments
With VGA I know it mix it, but only as ORed.
As the Parallax pin out systems is: any output that is high= global high
There is no mask for the sprites to write darker colors.
So a red sprite on a blue back ground will actually be a purple sprite.
A white sprite will be white sprite, so that is why vga cursor is white.
If there was enough internal memory for a large color bitmap, you could software emulate sprites in a Amiga Blitter style way.
Or if you added some external masking circuit as to blank out the image below a sprite.
None if this is easy.
Additionally, mixing on NTSC is tough! It is considerably easier on VGA, but with those limitations in place.
There is no "default" display.
Propellers have a video generator that can do lots of things and the display is a software driven one. The nice thing about this is we've been able to do a ton on TV / VGA displays. The smarter we get about software, the better the display options are! Lots of drivers and approaches have been developed and you have a ton to work from.
The big limit is HUB RAM. There is only 32K, so you need to be clever about how you represent on screen data, sprites, etc... That basic driver can actually do a lot more than most people have even attempted with it. See my signature.
As for sprites and other things, examples abound! Go and get some of the Propeller games and pick through the drivers that drive them. You can do most anything you want with basic sprites and when you use the COGS together, you can do a lot of sprites. Throw up a few hundred (no joke), if you want to.
The basic path is this:
You will have a TV driver. That TV driver outputs the signal and individual scan lines. It offers flags for other SPRITE, TILE and or GRAPHICS COGS to fill the scan line buffers all working together and in sync. Typical flags are VBLANK, HBLANK, SCANLINE (count), and that TV driver writes them to the HUB at specific times. Beginning of vertical blank, end of scan line for the beginning of the horizontal blank, and optionally what scan line is being drawn.
When that driver runs by itself, it only displays what is in the scan line buffer, which results in a blank screen, or stripes.
Optionally, you can have the TV driver offer various resolutions, color depths, etc... and set flags for that. Typical ones would be number of waitvids / scanline, pixels / waitvid, etc...
Most of our best drivers work on a core one like that. There are some template drivers out there too. If you have trouble finding them, message me and I'll go track them down. Eric Ball made some good ones I like, and a particularly good one for color can be found in my Nyan Cat curio animation.
From there, you need to make the other COGS.
A GRAPHICS COG offers functions. Line, circle, text, etc... There is a great example of one in graphics.spin. A more basic, but fast one can be found in Nyan CAT. It's unfinished, with room for expansion. I only did what was needed to animate that crazy Pop Tart cat.
A TILE COG will read tiles from the HUB, and put the pixels for each scan line into the scan line buffer, just prior to it being drawn. Double buffering the scan line buffer is best. More buffers can yield more rendering time, which can be useful if you are also doing sprites.
A SPRITE COG will read sprites from a sprite list, and combine them with data put into a scan line buffer by either a TILE or bitmap type of COG. Doing this requires a read of the scan line buffer, combine with sprite data, write back. HUB throughput is the primary limit on sprites, with the masking of them being a secondary one. If you structure your buffers and data into easy byte / word / long boundaries, and use more than one scan line buffer, a Propeller can draw an awful lot of sprites concurrently.
That is the basics. There are are lots of ways to get these things done too. Some people have combined tasks, like say having the TV COG do tiles and or a bitmap, then just using a SPRITE COG to do the sprites. Others have done it with software sprites. If you don't need a ton of colors, a simple bitmap and GRAPHICS type COG can move a lot of things too, and it does so with basic drawing techniques. Another approach is to make each byte a pixel, which is memory hungry, but if you don't need that many different shapes / tiles, it's super easy to mask, or as I did in the Nyan Cat thing, make a dot plotter and do all the graphics that way.
It's all up to you.
One other thing that limits you is the horizontal sweep rates. TV has the slowest sweep frequency. Because of that, it can pack the most into a frame. VGA, interlaced 640x400 is the next slowest. The faster the sweep rates, the less time you have to assemble and combine graphics per scan line.
Colors for VGA, default to 64 available. There are 80 some colors available for TV. What you get for colors really depends on both the theory of operation used by the driver, and the output circuit used. Most of the drivers are setup for the reference designs found on the Demo Board TV and VGA output circuits.
Because it's software based, there are a lot of options, and I hope this helps you see the lay of the land better.
Perhaps it would help to let you know what I ultimately want to build. Nothing new, but a retro computer based on either the Z80 or 6502 CPU. I imagine an 8-bit CPU that sends simple commands to the video/audio systems (through RAM pokes perhaps) that do awesome things like bounce sprites around, scroll screens or play audio from an SD card.
I have built an SD/VGM player using Arduino but nothing like this.
Anyway, my perfect "version 1" dream computer would have:
1) 256x192 (or perhaps, 320x200 like the C64) resolution on NTSC (not concerned with VGA at the moment)
2) TILED display. Just like the C64 where you can map the system font to custom characters to make tile-based maps.
3) Hardware scrolling display in X/Y directions (like the NES). At least able to have a display that would be 4x the resolution so that tiles can be drawn on the sides while the screen scrolls. This might be impossible. But maybe tiled displays can help with this?
4) 8-16 sprites per scanline with 4 colors per sprite. Each sprite 16 pixels wide. I like the Amiga/Atari way of doing sprites where they are arbitrarily tall up to the maximum vertical resolution. But I would be happy with fixed sized sprites too. As long as there are enough to make good games.
5) Each sprite would have their own 4 colors (3 plus transparent) from their own palette of colors. Similar to how NES does it. So sprites 1-4 could use palette 1, sprites 5-8 could use palette 2, sprite 9 could use palette 3, etc.
6) 16 colors on-screen (minus sprite colors) from a good sized palette. I think you said 80 was average? That would be more than good enough. The NES didn't have that many. Atari had 256 but most of them were the same (16 levels of black) or too close to compare.
7) Audio would implement maybe 4 cogs. Two of them using the amazing SIDCog, one using the AYCog and the last using the SNECog. Which would give 12 voices I believe? And allow tons of pre-made VGM tunes to play (from SD).
8) NES/SNES controller support
9) 64K of RAM for the CPU and maybe 128-512K for the audio/video RAM (as buffers I guess since the grunt work has to be put in the HUB RAM).
10) SD card support for loading programs into CPU RAM and graphics/audio data into other RAM.
I know that is a monumental effort but doesn't sound out of the realm of impossibility with the tools we have today. In fact, I'm thinking of using maybe two or three propellers. They are $8 each and I would have 480 MIPS for $24. LOL (minus CPU, RAM and glue logic)
I also know I would have to deal with bus contention but surely it's possible (I hope)?
I see some pretty amazing things out of the Uzebox and that's one MCU with some very optimized code to run in almost no RAM. Imagine what even one propeller could do even if driven by a 6502. The propeller would by my custom "ASIC" in this design. lol
Now, version two of my dream computer would add the following:
1) 2-4 layers of parallax scrolling.
2) Copper-list type display like in the Amiga (or Atari) that allows custom graphics effects per scanline.
3) Entire propeller devoted to audio (4 cogs for SIDCog, 2 for AYCog, 1 for SNECog and 1 for control).
Of course, that might have to be for the propeller 2. :-D
I'll also plug my composite NTSC sprite driver (follow the link in my sig).
Jeff has pretty much stretched the Propeller to its limits while it does KDB, SD an several modes of Video (yes, sprites) for the Micromite chip. The Micromite provides the programming environment and the MMC provides the I/O. They talk back and forth via I2C. It is a VGA video system but well worth finding an old VGA monitor if you are into retro and want to play.
In itself, it is a very "retro" feeling implementation of some pretty powerful modern day hardware. I believe the link I provided also contains some demo video of the various video modes it supports. There is also a sprite editor and some other tools that run on the systems and provide a pretty complete retro game development system.
When I try to access your "Links to Propeller stuff..." I get an access denied.
Eric contributed a lot...
Ericball, I will certainly check out that driver. I'll read the thread too but how many sprites do you get with 2 cogs? 3 cogs? 5 cogs? Etc.
Thanks!
Danged if I can remember. NTSC line period is 63.5555uS, so at 80MHz that's 5084 cycles / line which means 5084 cycles * (num cogs - 1) for sprite processing. The comments in the file say 287 cycles to draw a sprite, but 27 cycles if the sprite isn't being displayed on that line. For reference, my demo has 142 sprites and uses 5 cogs.
Note: This is a pure sprite engine - no background. It also has a very large color gamut / palette.
NTSC & PAL driver templates -ObEx
Composite NTSC sprite driver - 240x240 Composite NTSC with a palette of 88 colors out of 172 colors; 8x8 sprites (yes, sprites with full X&Y positioning); 2 - 5 cogs (more cogs for more sprites)
NTSC 8bpp bitmap driver & template
NTSC 4x2 - 746x480 2bpp, 220 artifact colors
NTSC 4x - 746x480 1bpp, 15 artifact colors
Greyscale bitmap TV driver - one pin, one cog, 8bpp
more colorful baseband TV - using the auralsub pin to make all 136 colors usable
NTSC video driver in SPIN - 2 giant characters
[url="http://forums.parallax.com/showthread.php?116828-Help-with-a-LOW-res-30-(or-more)-gray-scale-tv-driver]18x18x6bpp greyscale TV driver[/url]
Propeller projects in progress (.plan)
Because video is in software on the Propeller, you will find a variety of ways to generate signals, and those signals have various attributes too. We got into the technical details of TV graphics. Some nice tricks got to play out here. (thanks Eric, for helping me better understand all that)
From there, you will find a variety of ways to build pixel, tile and sprite engines. There are a fair number of those too, and I've put a lot of general discussion about it in my long post above, but...
TV & VGA.spin got broken down into tile drivers. A "native" tile driver is one that uses the WAITVID as intended, and it's generally a two or 4 color per tile driver, with tile sizes ranging from 4 pixels to 32 pixels. 16 and 8 pixels are common. But you can do anything really. Those don't have separate colors for sprites, and so things like color clash happen when sprites cross tiles with different colors.
There was then the "scan line" driver, where a scan line gets made by graphics cogs. Those can be full color, 2 or 4 colors per pixel, or other combinations, like 16 color. Doing this takes processing and multi-color per pixel drivers (above 4) take time and time means resolution...
The scan line type driver is the root for most of the sprite, text, tile engines out there that exceed the basic capability present in the drivers Chip did.
Once you've gotten somewhere you think you want to be, and if you have trouble, it's very highly likely we can dig through the various games and such to pluck out the signal, tile, sprite capabilities you need. From there, it's just some PASM and testing...
If you like video, this chip is a freaking playground like no other!
The next one will be too. Just saying.
Thanks for updating the hyperlinks. I'm sure that took some time. I started doing them, the went to bed.
Truth is, we could probably fill a few pages with driver / video resources.... That's a project for somebody, some day. Man, I think back to the early days, and "Simple NTSC" by CardboardGuru and how that blew the doors open on signals, and scan line type drivers....
Heck, it was a rite of passage to parse Chip's driver and get it to do something new.
Yea, we need yet another Stickie.
Now that I think about it, yes we need another Stickie.
Yeah, there should be an official section devoted to nothing but video. I know the opex has that but something that curates and collects the best of the best for drivers and discussions for newbies like me.
I've officially decided on what type of driver I want to do. It will be based off the TMS9928 driver that was done on here using NTSC. I'm studying that code now and learning how it works.
You bring up a good point on the color clashing. The TMS99x8 could show 4 different sprites per scanline (32 total) and if you're on Graphics Mode 2, you can have 2 colors per 8x1 pixel area. So, technically, you could have 4 "1 pixel" wide sprites of 4 different colors + 2 colors (6 total) in a 8x1 area. So the TMS9928 driver would need to be able to handle at least that (with a 256x192 resolution).
Shouldn't be a problem with the propeller from what I have seen.
I will certainly be leaning on you guys for questions as time goes by. Which I greatly appreciate.
My project is going to be a ColecoVision emulator using a real Z80. Being able to run the ColecoVision games (hopefully, unmodified) would be awesome for phase one.
Phase two would support more VRAM, system RAM and a cog or two for more audio (SIDCog anyone?).
Cool beans.