Dual Playfields?

cbmeeks

A common feature of 16-bit computers/consoles of the 80's/90's was the ability to display two or more "playfields".
This makes parallax scrolling much easier. On the Amiga, it was dead-simple. The SNES (IIRC) could display up to four layers I believe.

Anyway, has something like this been done with a P1? I'm thinking you would need a dedicated COG to overlay (with masking) an entire line of pixels on top of your rendering buffer just before the renderer plots it to the screen. Basically one giant sprite.

If possible, what are your thoughts on the limitations for various resolutions? NTSC, that is.

Also, I assume 4-color mode would have to be used so that the top layer could be any set of 4 colors (3 plus transparent) on top of the bottom layer's own set of 4 colors.

Thanks.

potatohead

Honestly, bitplanes are not well suited to the Propeller. But, it has a lot of COGS.

If you want "easy" parallax scrolling, it's not hard to render several buffers into a video driver COG and scroll away! Fastest and easiest way to do this is in "full color" one byte per pixel. Loop through the pixels, either writing one or not, depending on the transparent value you've picked. Could be anything. Bright purple was most often used as nobody really likes that color.

That uses up HUB memory quickly though.

It's a bit more compute to do it in 2 or 4 color, but the same overall method applies. COGS read through the pixels, combining and masking as needed to build scanlines that the driver COG renders to the TV. You might need a few COGS to do it, depending on the complexity of the source data. Tiles are memory lean, but take a bit more time. Bitmaps are quicker, but cost HUB RAM.

From there, it's all trade-offs.

Directly emulating the old hardware isn't always the best / fastest way to do these kinds of things on the Prop. It can do them that way, but it can be much faster doing it with simple sprites and such. A few COGS can actually toss up 100 or so sprites per line. Given that many? Doing parallax might just be updating some sprite pointers as much as it can be anything else.

cbmeeks

Wow. I didn't realize that many sprites could be handled per scanline. The NeoGeo works that way. Everything is a sprite. Including the tiles and screen data.

I'm not really trying to create a dual (or more) playfield at the moment but was just wondering if it has been done on the p1.

You also bring up another question...I never fully understood how the bitplanes worked on the Amiga. From everything I've read, they are a pain. And I felt this pain when I used to try and do asm with the Amiga.

But the Amiga designers (Jay) were geniuses. :-D So they must have had a reason. Anyway, I think it helps with memory consumption but perhaps it helps with dual-playfields as well. Especially since you could only do 3 bitplanes per playfield. Or, you could mix them like 2 bitplanes for background and 4 for foreground.

Can the propeller generate such bitplanes?

potatohead

That's an old battle.

There is:

Bitmaps, and bitmaps are either "chunky" or "bitplane". The bitplane people lost out to the chunky people, due to the fact that it was difficult to read and write all the planes for masking, and other operations involving higher color depths. Turns out that is what people want to do most and chunky can be done with a single read, modify, write operation. Bitplane takes multiple reads, masking and combining and then multiple writes to do the same thing.

The sweet spot for bitplanes is low color, overlays, etc... But that just isn't the dominant case.

It all came to a head with VGA 8bpp mode 13h, I think. That one was straight up, 256 color, palette, and it dominated once it was out there.

And there are tiles! Everybody likes tiles, and there is considerable debate over tiles vs linear bitmaps. I prefer tiles in every case, because little bitmaps can be made, or big ones, whatever. Just arrange the tiles and make pointers. Scrolling is a huge win with tiles, and a lot can be done with very few reads and writes to the screen. Memory efficient too.

But, linear bitmaps are super easy. Check out my Nyan Cat toy for a great example of that. The whole thing is drawn in real time with just a dot plotter! It could be an order faster with tiles and such, but a lot harder to write overall. Simple bitmap with pixel plotter made that a doddle.

So there you go.

Sprites vary.

Some systems allow really big sprites. Other systems allow little ones. On systems that are fast, and that have a lot of sprites, you just stack them up and move 'em all together.

Baggers and I have done 5 COG drivers that toss 100+ 4x8 sprites per scanline. If you want, you can move whole groups of them with just spin and a sprite list. A few COGS working together can basically blast stuff onto a screen and move it around no problem. In fact, we've never really used that to it's maximum much at all.

potatohead

...and the HUB access cycles are what limit things on the Prop. Bitplanes can take multiple HUB ops to do what "chunky" or "tile" + "sprites" can do with just a single, or a few reads and writes.

At the driver level, there is only HUB memory and the WAITVID. You stuff the tiles and sprites into scanlines that the WAITVID writes out to the TV.

"sprites" and "tiles" are just COG code setup to pick the pixels up and put them into the scanline. The more COGS you use, the more you can pick up and put into the scanline.

So the trick on the Prop is to think in terms of tiles, sprites and bitmaps, but also think in terms of what is easiest to pick up and stuff into a waitvid. That's where doing it the way the old machines did breaks down. They have different operating constraints.

But the effective result is much the same. Often better on a Prop, because it can do a lot in parallel.

Because the COGS are fast, and the drivers are frame locked, due to how the timing works out to communicate everything, a finished driver looks just like a graphics chip would to a much simpler SPIN or PASM program.

BTW: Spin runs about as fast as 6502 assembly on a fast machine does. Gives you a sense of perspective. If you can write it in assembly on, say an Apple or Atari, Spectrum, etc... you can pretty much write it in SPIN on a Propeller, using PASM drivers to get the display done.

cbmeeks

I totally agree with tiles. My favorite games have always been tile based (C64/NES).

You said with 5 COGS you can get 100+ 4x8 sprites per scanline. I am curious....first, why 4 pixels wide and not something more "common" like 8? Also, I'm assuming the height is just arbitrary since you build the sprites as the raster forms the display (like Atari). Is that correct? Would 4x8 sprites render just as fast as 4x128 sprites but just consume more memory in their definitions?

Thanks!

potatohead

4 pixels is nice and simple. One long is one line of the sprite. Pick them up, mask, put in scanline easy, fast. Baggers saw that.

If you make the screen buffer bigger than the display, no masking for sprite edge conditions is needed, making it faster still.

At 80 mhz, 4 or 5 cogs will do more sprites than can even reasonably fit on a scanline. That level plenty of room for them to overlap, etc... priority is just sprite list order. If you want it on top, make it farther down the list.

Doing 8x8 is only a little slower. But it is super easy to manage the list in SPIN too.

Oh, and that high sprite count is with a tile map in the background.

One tile cog and one sprite cog does 30 to 50 sprites on top of the tiles depending on the Prop clock.

Full screen is as many as you want. That never matters. It's only the per line number that is a crunch.

cbmeeks

I've often wondered how I would approach sprites.

The C64 in high-res mode was 320x200 and without any VIC-II tricks, allowed 2 colors per 8x8 char.

So a checkerboard pattern would (in theory) mean 320 color transitions per scanline. Of course, that was with artifacts.

Anyway, within an 8x1 area, you could have a black pixel, then a red pixel. Then, six sprites that are one pixel wide next to each other. So, in a perfect world, you would see 8 different colors. Many tweaked C64 modes did tricks like that to get more colors.

Obviously, you're limited to what NTSC can render but with S-Video and a good monitor, it actually looked very nice.

So on the propeller to produce this, I imagine you would have to set 4 color mode with a waitvid set to 4 pixels. Any pixel, any color. That way, a red sprite could straddle two chars of black/green. Correct?

Sorry....didn't mean to take this into a sprite discussion. lol

potatohead

Yep, you got it. This is why the 4x8 sprite rules on the Prop.

And a modern TV will display 320 pixel, lots of color images well. IMHO, that is a Propeller sweet spot. TV is slow, meaning the COGS get plenty of time to get the pixels done.

VGA is twice as fast, and 320 pixels is the upper limit for full color waitvid like we are discussing.

256 and 320 work on anything.

potatohead

So what you do with your Z80 or 6502 is build up pasm display, pasm sprites and tiles, whatever. Then use SPIN to provide all the easy functions, moving things, grouping them, etc... another bit of PASM interfaces with the retro chip, and it just sets values and does basic things.

cbmeeks

Awesome. Thanks for the info. That's the path I'm taking for my retro computer.

Have you tried any S-Video modes on a modern wide-screen TV?

On a 16x9 TV, seems like there could be a LOT of pixels per scanline. I wonder if the same 63.5µs rule applies?

potatohead

I have. The time per scanline is no different, nor is the color capability.

The artifact problem with composite goes away with Svideo, because the color is on it's own channel.

Monochrome performance on Svideo can be high. Nicer TVS can do 400 to 600 pixels. Color us the same 160 pixels or 320 pixels for interlaced signals. There really isn't the concept of a pixel there, and I'm just citing resolutions where most color combos can be seen reasonably.

When you overdrive composite, color artifacts happen. When you overdrive svideo, pixels get blended together.

Wide screen TV has the same scanline timing, and just stretches the pixels. Say you run a 320 pixel display on a normal TV. That will look stretched on a wide TV. You can run more pixels to compensate. 512 pixels looks a lot like 320 does, for example.

But, all the color limits, etc... still apply. Svideo is not quite good enough to really drive a wide TV, but it is better than composite.

Component video is the next analog step up to what is the best of SDTV and the entry into HDTV.

Nobody has done component for P1.

cbmeeks

I never saw many component devices. I used component on my Wii but that's about it. Seems like everything went to HDMI.

But I'm pretty old-school anyway. :-)

I run my C64 using S-Video on my 1084S monitor and it looks amazing.

potatohead

Indeed it does, and that monitor has insane good color circuits too.

The guys who engineered VIC II just nailed the home TV sweet spot.

cbmeeks

Ah the VIC-II. One of the best graphic chips from the 80's. At least for 8-bitters.

Of course, the NES had a good graphics PPU too. But the C64 beat it hands down in sprites.

I can't believe there isn't a drop-in replacement for the VIC-II. I mean, the single most popular computer in the world. You would think someone would have at least given it the same FPGA/reverse engineered treatment as the ULA has.