Can I just blast out a bunch of stupid question? Because I'm about to drop some serious ignorance on you. 
Is there merit to OldMan's idea about switching background color mid scanline? Could simple, perhaps static, procedural patterns like checkerboards be done this way? While I don't think a static far layer looks that bad, what about dynamic? Could you feasibly scroll horizontally with such a pattern?
Not really, and it's mainly because of one reason; whenever the cpu read/writes/accesses *any* VCE register (color port or otherwise), the VCE will stop reading from the VDCs pixel bus, and will continue to output the last color (well, value) that was on the pixel bus. For instance, you have a store instruction STA. It's 5 cycles long, of those five cycle - it will hold the VCE bus for probably 3 or 4 of those cycles (this is in cpu cycles, not pixel cycles). So if you did manage to time your code (and you would have to somehow re-sync the cpu inside the interrupt routine to the VCE or anything, because of interrupt jitter. Even 1 cycle makes it jitter. This is why the registers on the VDC are buffered and only accessed once per scanline - allowing code to update the regs through out the line without timing issues), you'll be stretching pixels for the position you want to change this. You can see the effect very clearly here:
In my case, I wanted that effect because I wanted to do screen distortion in specific areas. A series of read or writes, causes gaps were no pixels are stretched, allowing new pixels to be showed as stretched. On the plus side, if you wanted a very 'long' stretched pixel - you would use one of the Txx instructions since it holds the VCE bus active the whole time until it's finished - no gaps. But yea, see the checker board pattern on the left side? That gets changed mid scanline (well, more to the left because I positioned it there). Also, that video shows the 16x8 sprite mode I was talking about (like I said, nothing impressive to look at other than proof of concept).
This (and probably all ideas I'm spouting) probably takes more CPU than you can realistically use, but what about multiple layers of background colors? How many gradients can I have moving about? Could I, say, have a pipe gradient that scrolls faster than a sky/ground gradient? You'd have two or more offsets to track, but it seems like this isn't completely impossible.
It's very easy to do and very lite on cpu resource (excluding the h-int routine). Say you have a display that is 224 pixels tall (because of overscan issues) and say that there is a reserved part for status bar - 32 pixels. That leaves 192 pixels of 'game screen'. So you have two arrays; 192 bytes for the LSB color, and 192 bytes for the MSB color. To draw gradient background on the screen, you simply update Y only positions. That equivalent to manually writing 192 pixels (sequentially at that!). That's dead easy to do and doesn't take much time at all. So, you draw you gradient colors, then you draw your 'pipes'. The pipes are only y+offset and the number of pixel tall. That's it. Do as many as you want. You could have lots of layers of scrolling pipes and a gradient scrolling layer as well. And don't forget - any 'line' can use any of the 512 colors of the master palette.
You touched on this in your ninja spirit post (and perhaps your above post which will take a long time to digest), but what about palette rotation? Everyone thinks "blinking lights" and "waterfalls" when palette rotation is talked about, but in an 8x8 tile with 15ish colors available, you can assign a unique color to every horizontal or vertical strip. For something like a brick wall, set most to red and one line to white for the grout. Change which color is white in the palette as the screen scrolls for something similar to dynamic tiles, but without the overhead of 8 different tiles for one-axis of scrolling. Hell, could you combine that with dynamic tiles to get multidirectional scrolling with only 8 tiles?
That's right! There's a huge amount of subpalettes and you could easily reserve 'colors' in a subpalette or whole subpalettes to animate things (including simulating individual moving layers). Edit: I guess I'll give that as my second hint for the last part in this post.
The sprite distortion you mention, there's a PCE game that I want to say is Sol Moonarge, but have reason to believe it might not be that might be doing this. I saw a video clip of a character walking being a jar of some fluid and becoming distorted while behind it. At the time I thought it was related to the DW Duck magnifying effect, but I *really* don't understand how that works.
Looks like more of a brute force method - kinda. The edge of the jars are the transition to remove the old sprite and switch do a new sprite. The new sprite is probably pre-stretched or stretched at runtime (the start of the level) and cached as frames to access later. But yeah, not the same thing. that I was mentioning.
Finally, and this is massively off topic, but how exactly are people doing line drawing with tile-based hardware? A set of precomputed tiles is the best I can think of but there has to be a better way.
Usually brute force, but I had a trick for rasterizing multiple points in an array to a screen (in horizontal strips). Not so great for random pixel access, but very fast for solid runs of pixels (like for polygons). It also didn't use a pixel buffer, so you saved on not having to clear it (which can be expensive), and you don't need to upload it (which can also be expensive). I got the idea from watching an Amiga demo (spheres that overlapped and did transparency in the overlapping parts). Saving that for a demo.
EDIT: Dumbest question yet: Copper bars? Can be vertical? What's this all about?
It can be tricky if you're not using sprites. I have a demo that does them at unlimited 128 colors, but at half res (128 pixels for 256 pixel display). They have the same limitation as horizontal copper bars and also appear behind the BG layer, and has the same setup as the vertical method talked about (a single array of 'column' pixels) - except no H-int is needed. It's tricky to setup - I don't use sprites or BG tiles to do it
I don't want to give out my secret for it yet, because I was saving it for a PCE demo. But yeah, it's do able. If you really sit down and think about it - you'll probably figure it out (there's only one way to do it AFAIK without sprites; that's your hint).
Topic: request: PCE development 101? (Read 742 times)
