Why are my shape tables flickering?

[Heaven/TQA]

Tyrop... your drawing routine takes too much time...that's why on NTSC (60 hz = less time for drawings then in PAL 50 Hz) you see less segments than on PAL machines where the CPU does have more time to finish drawings until the rasterbar is drawing new frame...

 

re: the demo

 

it's not 3d or more heavy stuff running...should be simple adding of some sinus/cosinus tables(values together)

[Shawn Jefferson]

Actually, I just looked at your code Tyrop.. you aren't drawing in the VBI, so it isn't taking too long there. Actually, what appears is happening is that you aren't delaying long enough in your VBI.

 

As far as I can see your code is doing this:

 

Draw the Centipede

Erase the Centipede if the VBI FLAG has been tripped.

 

Your VBI routine is delaying for one VBI and tripping the VB FLAG, so essentially, you code is always drawing the centiped and then erasing it right away. That you don't see the centipede at 60hz but see it at 50hz is a timing issue.

 

Do this in the Atari800Win monitor:

 

a 20a2

lda #$06

<enter>

 

Which just changes your VBI routine to this:

 

VBLANK
;
	 LDA TIMER
	 BNE EXITVB
	 LDA #$6
	 STA TIMER
	 LDA #0
	 STA VBFLAG
EXITVB
	 DEC TIMER
	 JMP XITVBV

 

That slows down the time between drawing and erasing. Of course, your centipede moves really slow too, probably not what you wanted.

 

To overcome this you probably want to move your drawing routine into the VBI, but if you do that you have to be aware that if your drawing routine takes too long, you will have problems as if one VBI isn't over before another one starts... well, that usually isn't good and crashes the computer.

Edited January 30, 2008 by Shawn Jefferson

[Tyrop]

I experimented with different delay values. You can see the whole centipede even with a 2 VBI delay but it results in flicker.

 

I tried your suggestion and placed the draw routine in the VBI (leaving the erase routine out in main code). Interesting result: it draws the whole centipede first but segments become invisible as it progresses down the screen (I have an NTSC Atari). As before, the erase routine waits for the VBI to trip a flag before execution. (Code and executable are attached - executable is the .65o file).

 

It could be that the problem is simply that Antic F is too high for a centipede-like game. In Centipede, I would think that each segment must be separately tracked by the program because, in the game, when the centipede gets hit and segments break off, they become independent of the remaining main body and follow separate paths. Maybe this creates too much overhead. For instance, my draw code checks a variable for each segment to see which direction it is going and then sets up pointers to the appropriate shape table. Directions could be left, right, down, diagonal-right and diagonal-left (for when the segments swivel down the screen). I tried to optimize that part by creating a jump table - sort of like an ON-GOSUB in Basic.

Cent23.zip

[Rybags]

Start the erase procedure at the last line of the display. Simple - it will give you a heap more time.

 

And, yes, it is madness to expect such a game to work in bitmap. Once you get anywhere near the amount of moving objects that Cent/Millipede actually has, the entire thing will break down.

[Shawn Jefferson]

I experimented with different delay values. You can see the whole centipede even with a 2 VBI delay but it results in flicker.

 

Yes, you will get flicker if you are drawing in the "mainline" code, pretty much no matter what you do (this is why some games use a double buffer: it takes them far longer than 1 frame to draw their screens, so cannot do so in the VBI.. they render at less than 60/50 frames a second.) It's possible to get no flicker because of the timing between your mainline code and your VBI, but add some more mainline code or have an interrupt (like a keypress) and you will probably get flickering again!

 

I tried your suggestion and placed the draw routine in the VBI (leaving the erase routine out in main code). Interesting result: it draws the whole centipede first but segments become invisible as it progresses down the screen (I have an NTSC Atari). As before, the erase routine waits for the VBI to trip a flag before execution. (Code and executable are attached - executable is the .65o file).

 

When I said move your drawing routines into VBI, I meant anything that updates the screen... that includes the erase routine as well. Basically, your VBI should look like:

 

If DRAWNOW flag not set then goto DO_OTHER_STUFF;

Erase the centipede from the old location.

Draw the centipede in the new location.

 

DO_OTHER_STUFF:

Do other stuff that you might want to do in the VBI, like music, etc..

 

The reason you do screen updates in the VBI is that the VBI happens when the raster beam is "off screen". This ensures (provided your VBI code doesn't run too long) that on-screen objects are updated when the Atari isn't actively trying to display them. Rybags suggestion to put your erase routine at the last line of the screen (triggered via a DLI) would work as well, and give you more time for your code to work before the Atari will start displaying objects on the screen again. However, I'd just get the VBI/mainline code sorted out in your mind first, and then worry about optimizations like this later.

 

It could be that the problem is simply that Antic F is too high for a centipede-like game.

 

It could be, as you progress, but that's not your issue at the moment. Your problem is your drawing logic is causing the flickering (as far as I can see anyway.)

[Tyrop]

I will try triggering the erase routine via a DLI on the last line. Heaps more time is what I need.

 

And, yes, it is madness to expect such a game to work in bitmap. Once you get anywhere near the amount of moving objects that Cent/Millipede actually has, the entire thing will break down.

 

Is there any other way to do it in Antic F beside bitmapping?

[Rybags]

Character mode, with pre-shifted segment definitions.

 

But, then you'd also need adjacent segment characters, and possibly also cater for the "head" segment and it's adjacent combinations if it uses a different looking character.

 

A bit of work, but end result would be a lot faster.

[Tyrop]

Character mode, with pre-shifted segment definitions.

 

But, then you'd also need adjacent segment characters, and possibly also cater for the "head" segment and it's adjacent combinations if it uses a different looking character.

 

A bit of work, but end result would be a lot faster.

But then you would need characters pre-shifted in all directions, no? In other words, for an 8x8 character, I would need pre-shifted characters for each of the 8 character positions that surround the character so that the "B" for example, can shift over to any of the "A" positions:

 

AAA

ABA

AAA

 

Is that how you would do it?

[Rybags]

Why do you want pixel perfect vertical movement?

 

And what is this all for anyway - game or demo?

[Heaven/TQA]

no... as you are not moving diagonal you would need only

 

AB for left/right moving

 

and

 

C

D

 

as the segments are always falling/walking down on byte positions...

[Heaven/TQA]

no... as you are not moving diagonal you would need only

 

AB for left/right moving

 

and

 

C

D

 

as the segments are always falling/walking down on byte positions...

[Tyrop]

Why do you want pixel perfect vertical movement?

 

And what is this all for anyway - game or demo?

Its for nothing other than my own curiosity.... to see if it can be done, to see if centipede can be written in Atari's highest res mode.

[Tyrop]

I guess I'm not following, Heaven. There will be times when a centipede segment will have to move between 2, 3 or 4 characters. Rough illustration of a segment moving through the center of 4 characters:

OOOOOOOO OOOOOOOO

OOOOOOOO OOOOOOOO

OOOOOOOO OOOOOOOO

OOOOOOOO OOOOOOOO

OOOOOOOO OOOOOOOO

OOOOOOXX XXOOOOOO

OOOXXXXX XXXOOOOO

OOOOXXXX XXXOOOOO

 

OOOOXXXX XXXOOOOO

OOOOXXXX XXXOOOOO

OOOOXXXX XXXXOOOO

OOOOOXXX XXOOOOOO

OOOOOOOX XOOOOOOO

OOOOOOOO OOOOOOOO

OOOOOOOO OOOOOOOO

OOOOOOOO OOOOOOOO

OOOOOOOO OOOOOOOO

Edited February 2, 2008 by Tyrop

[Rybags]

Well, diagonal movement like that means character mode just got a lot harder.

 

You could assign a range of characters for the common possibilities like horizontal graduations and moving down vertically on a character boundary.

 

Then, you'd have to reserve another range and dynamically put the graphcis data into them to cater for stuff like diagonals.