Compute!'s P/M Graphics Toolkit: help!

[+Philsan]

As you may already know, after finding the listings, I have typed in the P/M toolkit described here:

http://www.atarimagazines.com/compute/issu...ics_Toolkit.php

This ML toolkit seems perfect (for example other ML routines don't move missiles, are only in single or double line resolution, etc.) but there is a problem: the player sometimes flickers!

You can enter and run the file DEMOTANK.LST from the attached disk image to see what happens and read the listing.

 

Can someone tell me why this happens and if there's a solution?

PM_Toolkit.zip

[analmux]

OK, I did just a fast check.

 

You make use of Machine Language routines. They are direct routines though, in the sense that you execute them from basic with the USR statement. The routine executes once and does return to basic afterwards. Basic though can't tell WHEN exactly it is executed.

 

In your listing there are actually two routines: "PAGCLR" and "PMMOVE". The first one isn't involved in this. The second one "PMMOVE" actually consists of 2 steps: (1) clearing the shape totally from PMBASE ...(2) putting the shape at a new y-position in PMBASE.

 

Step one could occur exactly when the videochip processes the PMDATA at (nearly) that scanline, but BEFORE it redraws the shape. There is quite a bit of time wasted in the clearing process, as it wipes out one complete block of 256 bytes:

 

20430 DATA 204,169,0,133,203,168
20440 DATA 145,204,200,208,251,173

 

means:

...
LDA #0
STA 203
TAY
STA (204),Y
INY
BNE 251
...

 

This means that it deletes 256 bytes. This process can easily cost you a few scanlines of CPU time (around 3000 cpu cycles = around 40 scanlines, in display-dma period).

 

When it would keep track of the old y-position it could only erase the part of PMBASE where the old sprite was located.

 

 

How to solve this? Multiple choices:

1) try to reduce number of CPU cycles wasted for the clearing: won't solve it totally though

2) try to add a wait loop: in M.L. you can check VCOUNT register to check & control the timing

3) a totally different thing: try not to use direct routines, but a background process in a Vertical Blank Interrupt. In Compute's 2nd book of atari-graphics there's a nice routine that does this.

...etc.

 

I did a small change, like option 2. Scanline 240 corresponds to a vcount value of 120. This should be outside the screen area.

 

I defined a wait loop that waits until vcount holds that value, and then continues.

 

I deactivated line 20075 and 20370 and I changed lines 20050,20070,20075,20371,20372 and 20373.

 

 

I included a modified version.

You can do ENTER "D:DEMOTAN2.LST"....or just ENTER "D:DEMOTANK.LST" and then ENTER "D:DTCHANGE.LST"

Edited April 29, 2008 by Analogue Multiplexer

[peteym5]

Hey Philsan, were you using a version of this routine I wrote. I admit I made mine memory location static because it uses self modifying code. Instead of Indirect Indexed, (sta ($203),y) it uses absolute,y (sta $ffff,y) addressing which is faster. Also does not clear out the whole page when you move the player, but deletes only the area where the last player was written. It maintains the data from prior writes a few bytes before the missile page. That is the vertical position and height of your sprite. That is an issue with the Compute! magazine version, admit its more flexible, but because it has to do all these extra things, it is much slower, and flickers.

 

The version I created does flicker, but it is much less noticeable unless you make a really tall sprite. Also supports using the missiles together as a fifth player. The limitation is that it only run from a specific memory location because it modifies all the absolute,y addresses before erasing and drawing the sprite. Also is single line because most of the stuff I see people make are at the highest resolution possible. Another advantage is it takes less time to execute from Turbo Basic and will be a speed increase.

pmdemo.zip

[+Philsan]

Analogue Multiplexer, thank you very much for your work and your technical explanations (thanks also to peteym5).

 

With your corrections the routine doesn't flicker anymore!

Yes, it's not the fastest PMG ML routine, but I have discovered that it can be compiled by Turbo-Basic XL.

I have tried many routines but one flickers, one doesn't support missiles and double line resolution (Page 6), one cannot be compiled by TB...

This routine is also very simple to understand.

Do you know a better routine?

 

I attach a new disk image ("PM_Toolkit_3") with all programs corrected and renumbered.

 

EDIT

I have only one problem.

In TB, I can load a picture before starting the routine.

If I load a picture after starting the routine the picture is damaged.

You can test this entering and running the program "TEST.LST" in the image "PM_Toolkit_Test".

You load the picture pressing the button.

PM_Toolkit_3.zip

PM_Toolkit_Test.zip

Edited May 1, 2008 by Philsan

[analmux]

Philsan, no thanks needed. I just did it for the fun. That's why I still didn't throw away all my ataris