Quote: Mode 5 is more 'native' to c64 graphic storage (just using 4 colours), but mode 2 is more 'true to c64' to give more colours which is what I desire... but snatches vital memory....  .... BUT mode 5 is more cpu intensive if I want to plot fine positions horizontally (less than 4 pixels), Mode 2 allows 2 pixel plots more easily, and more colours too...
I haven't really been following this thread so closely, but just thought I'd add a little something.
As always on the Beeb, you're forever trying to balance memory requirements versus frame rate versus resolution/colour - it's pretty tough! I guess you need to determine which of these is most important, and then make the decision on the screen mode based on that.
If you really need the colour, then Mode 2 is your only option. This also allows you to quickly move sprites by 2 pixel amounts horizontally, and you can also get relatively cheap (speed- and memory-wise) masking by nominating logical colour 0 as your 'transparent' colour, and using a simple lookup table to do the appropriate ANDing. Here the compromise is with the memory requirements - a full unshrunk screen is 20k, and a 16x32 sprite is 256 bytes! This, in turn, will take longer to render, and so your frame rate also potentially suffers! On the Beeb, it's possible to define screens of custom sizes, so you can at least reduce your memory requirements for the screen.
If it's more important to be able to blat around a lot of sprites, whilst maintaining a reasonable frame rate, you might have to go with Mode 5. Here the sprites will require half the memory, and therefore render twice as quickly  If you're prepared to sacrifice logical colour 0 as a transparent colour (leaving 3 colours for the actual sprite, which I think is the same as a C64 anyway), then you needn't store a separate mask, and can use a table-based solution, as with Mode 2. If you require smooth horizontal movement, then one option is to store two copies of the sprite, one offset two pixels horizontally from the other. This will give you the same freedom of movement as Mode 2 (with identical memory requirements for storing the sprite), but will render very quickly. Don't try to do on-the-fly bit shifting of sprite data for pixel-by-pixel horizontal movement, it's just too horrible to think about. The only problem then is that you only have 4 colours, but if they're chosen carefully, you can 'make' new colours by dithering, and you can also use interrupts to change the palette midway through the screen raster to allow a few more simultaneous colours.
Finally, Mode 1 - only recommended if you need the high resolution. Otherwise it suffers the same problems as Mode 2 with the same drawbacks of Mode 5! Also, movement by 4 pixels horizontally might not really be acceptable.
So, in summary then:
Mode 2 - low resolution, colourful, memory intensive, slow to render
Mode 5 - low resolution, not so colourful, half the memory requirements of Mode 2, twice as fast to render.
Mode 1 - high resolution, memory intensive, meh.
|
