I have a decent amount of tricks for the PCE, some known - some not.
I figure'd maybe I should share some with the community.
Here's one for transparency effect on the PCE. Pretty easy. It's similar to what the Sonic games do on the Genesis. They flash interleaving sprites to had the garbage pixels on that scanline, when they update color ram. The PCE also gets garbage pixels, but they are in the form of short stretched pixel lines going across the screen. There's a way to hide this transition.
The method works as such:
Say you have a water transition line. For the sake of setup, let's say that water below the line is going to be a blue hue-ish color/transparency. The first thing you do, is make sprite color #0 a nice blue color, relative to this under water scheme. Next, you reserve a single row in the tilemap with solid color tiles. These tiles are to make a solid line, and the same color as you did for sprite color #0. Now, for the transition line - you do an hsync interrupt, reposition the tilemap to that solid color area, then disable sprites. That'll make sure that nothing but this line will show.
Now comes the tricky part. There are two ways to update CRAM (vce); one is to use TIA to block copy the new colors. This will delay interrupts of the TIMER interrupt, if you're playing samples. I doubt a delay this short will even be audible, but if you're that picky - you can use the alternate method. You reserve a chunk of ram, and setup a string of code that LDA #$nn, STA port. With an RTS at the end. It's slightly slower (14 cycles to copy a WORD vs 12 cycles of TIA). Ok, so it's not actually that tricky
You can easily fit ~64 color updates (4 subpalettes for sprites) in this time. Right at the end, you re-enable sprites and reposition the tilemap. All of this needs to be done fairly quickly, so do all of your calculations before hand.
What you don't need to do, is update ~any~ colors in the BG subpalettes. The PCE has plenty of those and you can easily make duplicates with the alternate coloring for them. You also don't need two tilemaps either. You just need a redundant copy of the tile row (of the tilemap) that the transition line is on - with the alter water color. Just ~that~ row. Everything below that should have already been changed from the previous vblank call in preparation for this, if needed (i.e. your water line moves up and down on the screen).
The reason why sprite color #0 needs to be the same color as the BG transition line, is that updating color ram (VCE) stretches pixels. Since they are all the same color, you can't see this pixel stretching and all you see the solid color line. The border outside of the BG area (including left/right sides), is filled with sprite color #0. You don't need to update this every frame, unless you're doing color cycling on the transparency (going through hues). And you don't need to do this during hsync; doing so during the previous vblank is good enough. That saves one less color to update for the sprite palette anyway, during the active screen update. I hope that makes sense. Sure, you only have 4 sprite subpalettes for this design (for the main character and any enemies that transition this line). Of course, any objects or enemies that remain above or below this line - don't need to fall into this 4 subpalette group; they can remain fixed in their subpalette. This trick uses two scanlines total. So two solid lines appear as the transition.
Possibly make this a sticky?
Topic: Hardware tips and tricks (Read 477 times)
