Shoot anything that moves .. sprites and joystick example

[GWS]

Hi folks,

I don't think Microprose have much to fear from my gaming attempts    ...

I've been playing with some sprites and the joystick and managed to get this experiment going.  It's far from amazing, but it seems to work.

I found it quite difficult to get sprites to have a good 'transparent' background using Photoshop.  If you use a Black fill, and save as a .jpg file, the compression changes the Black in parts to a 'Near Black'.  Then if the sprite moves over a light background, you can see bits of black floating around.  I found saving as a .bmp was much better.

Then there was the ship sprite.  Parts of the body were Black as well, so displaying the sprite over a light background, it was as if the ship was full of holes and large parts of the body had disappeared.  One way round this was to increase the brightness of the whole image before filling the transparent Black - then reducing the brightness again.  This gave a much better sprite.

Apparently some folk use some 'rarely used' color for the transparency - I tried rgb(255,0,255) - but it looked so horrible, I couldn't work with it ..

I had to use the API routine for the joystick 'cos the DirectInput functions didn't seem to be working at the moment.

Anyway, turn the sound up a bit and see what you think ..

all the best,

Graham

[GWS]

This example raises a number of points ..

- if you create a sprite in a graphics program, of a given size - and display it scaled (magnified) as it approaches along the z-axis, it enlarges until it pixelates .. not good.ÂÃ,  If you draw it at something near the required maximum size, so that is is nearly always reduced in size as it approaches from the far 'z' distance, the .bmp file size is going to be large.ÂÃ,  If you try to get round that using .jpg compression, you run into trouble with the 'transparent' background not being a uniform color - so it shows ..ÂÃ,  I don't know what could be done to get round this problem.

- whatever your sprites look like, as they approach in simulated 3D, their co-ords vary in single pixel jumps.ÂÃ,  This I find, is quite visible and looks like annoying 'jitter'.ÂÃ,  The only way out of this I can think of is to use larger screen resolution to get more pixels to the inch.

- the example uses just one explosion at a time.ÂÃ,  In fact that's the nearest I've got to seeing where OOP might have a role - if each object 'knew' (had a method) of how to explode.ÂÃ,  So if you hit several objects in quick succession, they would explode almost simultaneously.ÂÃ,  There's still a problem though.ÂÃ,  Each explosion needs a big bang - and I believe Windows can only manage one sound at a time.ÂÃ,  For this problem we could do with several bangs playing at the same time ..ÂÃ,  Also sounds ideally should vary in 'loudness' and 'position' depending on distance and direction from the user ..

- there seems to be an 'inefficiency' in the way DX graphics work.ÂÃ,  Putting so much of the re-loading of background, text, and sprites through the GPU, even when nothing much is happening in the scene, seems to be very wasteful.ÂÃ,  Maybe if the scene was 'captured' in a buffer, and only written to the screen when some change occurred .. tricky to do though ..

Don't know if anyone has any views on this .. it seems animated screens are a difficult subject.ÂÃ,  Makes you wonder how they manage to produce such effective games commercially ..

all the best,

Graham

[J B Wood (Zumwalt)]

You need to use DirectSound if you want multiple sounds at one time, not MCI.
Scaling images has its own problems, its best to make the image at the size you desire and use it at that size.
I've only posted a few examlpes here and there of using sprites, going to go for something a little more complicated now, its my illusion of grandure that drive me

[Shannara]

You could also try PNG format, that seems to keep the correct colors for me. JPG does ok with me as well (though photoshop), depending on the compression ratio. Besides, from what I understand, no matter what encoder you use, it ends up a BMP in memory (thus the same size as BMP on disk). However, I guess disk space is to take into account of not using BMPs.

[GWS]

Ah OK ..ÂÃ,  .. thanks for the comments guys .. I'll give those methods a try, and see what improvements I can get.

On the 'jitter' problem, I had a thought - though it might be difficult to do.ÂÃ,  When a sprite is just changing it's co-ord to a new pixel position, and since the GPU is working frantically at high frame rate .. why not let it move to the new pixel position for one frame - then back to the original for the next - and gradually spend more frames on the new position.ÂÃ,  Like a small dither .. that might look smoother at the expense of a bit more computation time ..

best wishes,

Graham