Having followed the many discussions on here and STH regarding sprites and how best to display and update them, I wonder if the experts on here could comment on the following. I'll just make a statement based on my understanding and then you can all tear it apart accordingly....

The TV/Monitor display is only 'repainted' every 20ms and so, to reduce or eliminate flicker, we use an interrupt which occurs at, or somewhere just before, the end of frame to cue our sprite movements. Since we also know that the smoothest movement will be obtained with single pixel increments (or maybe 2 pixels to simplify Mode 2), this then seems to define a finite upper limit for the maximum speed that a sprite can move.

For example, if we consider a simple left-to-right 'base' such as in Space Invaders or similar and slightly compromise with two pixel movement in Mode 2 then there are 80 possible lateral positions for the base (slightly less due to the width of the base). So, with a Left/Right key held down, if we only move it once every 20ms, the minimum time it will take the base to move from one side of the screen to the other is therefore 1.6s.

I presume then that if we need sprites to move around quicker than this, the only option is to increase the number of pixels moved in 20ms. There would be no benefit in keeping the 1 or 2 pixel resolution and decreasing the interval since the maximum visual display update is governed by the 50Hz display.

Basically then, is the above statement correct or have I missed something ?

Martin

That looks pretty much right to me!

Ok, thanks for that Tom. It's just that never having tried this stuff before, I hadn't even thought about the physics so when I changed from 'free run' to Vsync driven, I was surprised to see how slow things suddenly became if the movement resolution was maintained. Makes sense though once you've worked it out (and someone has confirmed it ).

Incidentally Tom, thanks for the 'hardware framework' - it's all working fine and I can see how to improve it by precessing the timer before Vsync. One thing though, I seem to have to manually clear each interrupt from the VIA IFR after servicing - is that expected? There wasn't anything in your notes but there is a reference to this behaviour in the NAUG which mentions the 'independent' interrupt setting.
(My first efforts were permanently servicing the IRQ code but nothing else!)

Moving on (anyone ), Rich has (thankfully!) published tons of priceless info here and on STH about sprite plotting routines but to avoid running before walking, is there a good all round definitive plotter/eraser for Mode 2 with an accompanying screen address calculator? (or is there no simple answer to that..?) I have some generic routines that I plucked from TMU many years ago but I suspect they're not particularly efficient.

Martin

I have an improved Mode 2 sprite plotter compared to one I posted on here some time back. I'm sure it can be improved upon further. If I post the source code then people can inspect and improve it. I have an address calculator too which I'm sure can be improved.

If I add them to the Wiki we can see what ideas and improvements people come back with. Every cycle saved is good I'll post them in next few days.

Cheers Steve, that would be great

As I said earlier, there's tons of informative stuff on here (and STH) from many games gurus (yourself included) but if one hasn't tried games programming before, it's a bit tricky to do the Wheat & Chaff thing and get going with a basic game shell.

Martin

Sorry for no Wiki yet, I haven't forgotten, just been busy. Will try harder !

No worries Steve, I'm sure we're all in the same boat

The way I've designed things means that I can change the sprite and screen routines even after everything else is finished so whenever you can is fine

Martin

I've uploaded a screen address calculator if given X,Y coordinates. It's at;

http://www.retrosoftware.co.uk/wiki/ind ... en_Address

The page includes some code for testing it too.

Cheers for that Steve, I shall duly plumb it in to my project

Martin

Mode 2 masked Sprite Plotter up at

http://www.retrosoftware.co.uk/wiki/ind ... te_Plotter

Extensively commented.

Hi, Having problems getting this to run, its missing a couple of files I think ? (and looking in the wrong place for main) - Might be just me, lol !!

I'll download the copy on the Wiki and give it a go.

Sorry, cock up on my behalf Correct file uploaded. I've re-downloaded and checked it this time...

I'll be adding a sprite erase routine to my next Wiki which will then implement some sprite movement around the screen as well with the sprites crossing over one another to help demo the masked plotting more effectively.

Cool... thanks... will give me something to play with.....

Many thanks Steve - you're practically running a training course now

Martin