Sunday 12 July 2015

More work on sprites

Finally got a chance to look at the sprite fixes that I have been working on now that I am next to my FPGA board again.

It is nice to see the sprite colour bug fixed, and see some of the games that are known to work without problem on the MEGA65.

This also means that I have finally been able to take a look at my work on 64-pixel wide, and variable height sprites, as well as a few other fun sprite improvements, some of which are inspired by the Amiga and abuse of sprites on that platform.

First up, I fixed a bug with normal-width sprites that was introduced when I started adding support for 64-pixel wide sprites.  The sprite data fetch logic was fetching one more byte than it needed to. With 24 bit = 3 byte wide sprites, this wasn't a problem, as the 4th byte didn't map anywhere since the byte address was using two bits, and thus has four possibilities. However, the move to 64 pixel = 8 byte sprite fetch meant that the extra byte, now being the ninth byte (byte 8), mapped back onto the first byte (byte 0) in the 3-bit sprite data address register.  This meant that the first byte of each row of a sprite was showing the byte that should be shown in the third position two rows down.  This was fairly easy to find and fix once I thought about it, and indeed fixed the problem.

However, after this I was seeing glitching on the right edge of sprites, which turned out to be an analogous problem, where a 25th (or 65th) column of pixels was being drawn.  Again, easy to find and fix once I thought about what was going on, and could look at a sprite on the screen and fiddle with its data.

There was also a bug where the variable height mode was not working properly, because I had mis-plumbed some registers, rendering it impossible to set the height of sprites to anything other than the normal 21 pixels. I have rolled that fix in to the next build as well.

Just these changes, allowing much bigger sprites, should increase the usefulness of sprites quite a bit.  A tall or wide character now only needs a single sprite, hopefully leaving more sprites free for other things.  Once the rest of the MEGA65 is implemented, I might look at adding more sprites, but for now I am concentrating on making the ones we have more useful and interesting.

Sprite/foreground collision is still not working, so I have also added an "xray mode" to the VIC-IV, where instead of showing the normal display, it shows foreground, background, border and sprites all as a single distinct colour.  This is enabled with a physical switch on the FPGA, to make it easy to debug.  This change is in the build I am currently synthesising now.

I also took the opportunity to add some new extended sprite features, based on my reading about how Amiga sprites work, and also how they were used to create a tiled 16-colour background in some games on the Amiga.  However, I have not copied the Amiga functionality directly, and instead created something that achieves the same results, plus some extra opportunities for abuse.

First up, I added a flag that causes a sprite to be tiled horizontally, instead of being drawn only once.  This is a simple kind of hardware-assisted sprite multiplexing. Combined with 64-pixel wide sprites, it will hopefully be useful.  For example, having a full-width parallax background can now be easily done using a single sprite.  Again, this should leave more sprites free for other things.

Second, I have added a flag that causes a sprite to modify one or two bits in the colour otherwise to be displayed.  That is, each sprite can now be selected to modify one bitplane (or two in multi-colour sprite mode) of the output.  This works for other sprites, providing something effectively the same as sprite-bonding on the Amiga, but allowing the combination of arbitrary numbers of sprites to yield arbitrary colour depths.  It isn't quite the same, because the "master" sprite that is being combined with the bitplane-modifying sprite(s) has its colour selected in the normal way, so a transparent pixel in that sprite will always translate to a transparent pixel when displayed.  So this part of the functionality, while implemented differently to the Amiga, is generally similar.

What I have also done, because it is trivial from a hardware perspective, is to allow sprites in bitplane mode to modify the colour of the non-sprite elements of the screen.  This is something rather different, and offers all sorts of opportunities for abuse.  You could use it to easily draw shadows or highlights on a display, just by carefully setting up the palette and using a sprite in the shape of a shadow.  But you could also use it to provide extra bits of depth to a regular bitmap display, without incurring the memory cost of making the whole display deeper.  For example you could make something that is similar to FLI or one of the other VIC-II bad-line tweaked modes, but with a completely static display.  There is ample opportunity for demo effects here as well, especially since the bitplane modification is an XOR, so you can get a bit creative with the end effect.

All these changes are in the model that I am currently synthesising now. Hopefully they will all work, and I will have a few minutes free some time soon to try them out and post some screen shots of strange looking sprites.



8 comments:

  1. Interesting news. It always nice to read about the abilities to provide decent features using the same notions somehow still, as with the VIC-II, just with some "tricks" dropped in though. Till recently I thought that C64DTV can be / could be the platform which is some kind of "modern C64 with many extra abilities and good degree - but not 100% - compatibility" stuff. However as far as I see "C64DTV scene" is relative silent after the initial keen mood for one or two years. I really hope that C65GS/MEGA65 will be a more static success, and it also have more abilities.

    ReplyDelete
    Replies
    1. Hello,
      I am glad that I seem to be succeeding in preserving the VIC-II feel for you with the enhancements I am providing.

      Regarding the C64DTV scene, I think the severe physical limitations and generally poor compatibility (which is no negative reflection on the engineering of it -- it was simply time and cost constrained), and lack of continuing availability, all contribute to the lack of interest in it. I also feel that the way the extensions were added was not as elegant as it could have been (again I understand this is due to the limited time available and general commercial pressures). Thus I hope that we can provide a more sustained interest in the community, but of course only time will tell. I will say that it has been very exciting to see the compatibility of the MEGA65 improve quite a bit lately as sprite and other issues have been fixed. There is still some way to go, but there are now several dozen games that we have tested and work more or less perfectly. Once I finish implementing 1MHz, 2MHz and 3.5MHz mode, there will be a number of other games that should work okay, instead of running too fast (like Stunt Car Racer).

      Delete
    2. Will there be a way to set the speed of the CPU more freely than a few modes? Some over clocking possibilities?

      Delete
    3. The CPU itself runs at about 48MHz, these modes just insert delays between the instructions. Because the CPU speed and video pixel clock are linked, it will not be possible to de-couple the two and try to push the CPU clock higher without really reworking the whole design to change the clock ratio between these throughout the design. Once it is all finished, I might look at pushing the ratio from 4:1 to 3:1 to give a CPU clock speed of about 64MHz -- but that would not be for some time off. Alternatively, I might be able to do something interesting with linking a pair of FPGA boards together, so that the CPU is in one, and the VIC-IV etc in the other. This would probably allow better timing closure on the CPU, and allow faster speeds. But again, this isn't likely to happen in the near future.

      Delete
    4. The ratio idea sounds interesting :)

      Delete
    5. Well, in a way. But the machine is already almost 50x faster than a stock C64. There isn't really much need for it to go faster, since you can already do in a frame what took a C64 a second, and in a second what a C64 would take a minute to do.

      Delete
    6. What I can't get with the DTV that it was more or less a mass product. So it should be much more common topic :) I don't see the compatibility issues, of course there are some but still much lower than C65 (I mean the original planned). It's not so bad, maybe the lack of SID filters is annoying for me. I am curious where you can see major compatibility problems (of course there are, just not as many I would worry about, but it can be quite subjective viewpoint I have to admit). I am afraid a bit that C65GS/mega65 can't be such popular, even if the desired FPGA board become cheaper it can hardly beat the price of the DTV (well of course with mega65 there are much more features, connectivity whatever!!). It would be so cool to have an ASIC version with much cheaper price, but: I guess it is expensive so mega65 must be a mass product for that, also mega65 should be "ready" for a "fixed" design given by the nature of the ASIC unlike FPGA. However, I also though there can be eg Commodore plus4 compatibility. TED chip of plus4 uses more or less similar modes as C64 (but no sprites) so it shouldn't be that hard. Also as far as I can see, C64 mode of mega65 is some kind of "emulation" on the c65gs own mode if I am right, so there can be something for plus4. Why do I say this? Because having more machines mean that it can be even more popular even among the fans of plus4. Of course there can be even more machines, but I have no idea how hard/easy it can be to do (C128 maybe problematic because of the VDC?). Also, DTV's selling were good because of even the "retro gamers" not so much interested in the hardware, but "the good old games" and because DTV was also very cheap it helped a lot here. That's why I also mentioned some kind of cheaper mega65 release later maybe with ASIC design but it really requires being a "mass product" with enough customers whating to buy ....

      Delete
    7. Hello,
      You are right that a cheap MEGA65 would require an ASIC, and that would require that we finish the design completely first. There is nothing to stop this from being explored in the future.

      Regarding Plus/4 compatibility, the MEGA65 does C64 VIC-II and C65 VIC-III modes natively -- there is no emulation of those modes compared with the MEGA65's own VIC-IV modes. That is, the VIC-IV is backward-compatible with the VIC-II and VIC-III.

      I don't have any objections to having compatibility for additional machines, but I am not going to work on such things until the C64/C65/MEGA65 parts are all done. If there is still FPGA space after that, we can look at such things.

      Paul.

      Delete