Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #1265 > unrolled thread

SPRITES in DHGR and SHR - discussion

Back to article view | Back to comp.sys.apple2.programmer

Contents

  SPRITES in DHGR and SHR - discussion "Bill Buckels" <bbuckels@mts.net> - 2014-08-06 16:35 -0500
    Re: SPRITES in DHGR and SHR - discussion "Bill Buckels" <bbuckels@mts.net> - 2014-08-06 20:36 -0500

#1265 — SPRITES in DHGR and SHR - discussion

I have been working these last several days with both SHR and DHGR image 
fragments AKA Sprites.

I wrote a DHGR Sprite Converter similar to the one I did for SHR and as I 
write this I am making the same simple cc65 demo for DHGR embedded sprites 
as the SHR demo with the SHR sprite converter.

For the DHGR converter, because the resolution is 140 x 192 I provided a 
scaling feature with 3 variations so the same BMP sprite images can be used 
in SHR and DHGR, and Windows Paint can be used to create and edit the source 
images.

The DHGR scaling feature's variations are:

1. Scale by pixel reduction (throw away every second pixel). This method is 
lossy but preserves discrete colors.

2. Scale by error diffusion. The image is first run through an error 
diffusion routine with two variations, then every second pixel is thrown 
away. Some aliasing occurs with the background color in both the horizontal 
and vertical axis.

3. Scale by merging two pixels into one.

All three methods work fine. Merging gives the best illusion of detail. 
Error diffusion seems brighter than merged and is messier but not bad.

There is only so much you can do with 16 colors unless dithering which would 
need to be implemented only on the pixels and not the transparent background 
or background color. Therefore if I do add dithering, it will need to take 
place after paletting a mask into place, and then using the mask at the end 
to blot the dithers on the background.

The SHR packed pixel is easiest to use in 2 pixel horizontal movements. If 
you go to single pixel movements 2 identical sprites are needed with a 
one-pixel shift.

The DHGR sprite is the hardest to deal with. If you go to single pixel 
horizontal movements 7 identical sprites are needed.

But overall Windows Paint can handle the editing easily and everyone has it.

I'll have this all ready shortly. I may also come-up with the equivalents 
for HGR. The 4 colors that we are limited to due to the nature of sprites on 
demand are really quite restrive compared to DHGR and SHR which has more 
colors but still suffers from only a 16 color screen-wide palette if sprites 
want to be in  all 15 colors with a background color or mask.

Ideally a 4 color sprite would leave room in an SHR palette for background 
variations. My jury is still out on using reserved sprite colors.

The DHGR converter does a fair enough job on non-dithered images, but the 
fixed palette makes it somewhat less robust, but only marginally.

That's pretty much it for me. The color matching is quite good. I have 
restricted input to 24-bit source images in  fixed resolutions. So feel free 
to comment or just wait a day or so and I'll have this ready.

Bill

[toc] | [next] | [standalone]

#1266

"Bill Buckels" <bbuckels@mts.net> wrote:

>I wrote a DHGR Sprite Converter similar to the one I did for SHR and as I 
>write this I am making the same simple cc65 demo for DHGR embedded sprites 
>as the SHR demo with the SHR sprite converter.

This is the cc65 bounce demo for DHGR as much it is finished at this point. 
If you are interested in a preview...

Download it here:

http://www.appleoldies.ca/cc65/programs/dhgr/dhrbounce.zip

Some polishing and documentation to follow after some additional thought...

Bill

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web