Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
  • entries
    430
  • comments
    1,870
  • views
    662,776

One Step forward - Two steps back

Guest

Entry posted by Guest

462 views

 Share

Hi there!

 

Phew... so I hit yet another brickwall.

 

Yesterday I discovered that a single scanline resolution object also requires a single scanline precission for its vertical motion.

 

The problem is with slow moving objects. When an object is moving two scanlines at once every other frame, it's visible on the same position for 2 frames and then makes a 2 scanline jump. The human eye expects this object to move one scanline every frame tough. And so it interpolates an extra *merger* step inbetween the two actual moves. Basically that effect either makes the object just look different, or, what's worse, when the object moves diagonal, it looks like it jitters.

 

Now, why do I move it 2 scanlines at once in the first place?

 

Because I need to update the particles and the crosshair every other scanline. The code for this is not that complex:

 

; Draw CROSSHAIR
   LDA (crossPtr),Y
   STA GRP0

; Draw particles
   CPY particle1
   PHP
   CPY particle2
   PHP
   CPY particle3
   PHP

 

But, it can't happen on a repositioning scanline.

 

So, a reposition can only happen in the line between those updates.

 

Well, I now have plan for a possible solution. I'm not sure if it'd work out though, but it might be worth a last try. (When not succeeding, I'll go back to 2LK sprites. The jitter effect is unacceptable for me.)

 

The plan is like this:

 

- I'll double the resolution of my linecounter.

- I'll position the first visible sprite already before the kernel starts.

-* I'll then wait until the sprite starts.

-* Depending on wether it starts on an odd or even line, the sprite drawing part must either kick in with the line updating the particles or the other.

-* Then it'll draw the sprite until it's done.

-* Then I must skip to the next displayable sprite

-* Then I must complete the current 2 line step

- Use the next two lines to reposition

- Then wait again, until it starts.

 

Ugh... even thinking about trying to get all of that done in the correct order, with the correct timings gives me creeps. In all those lines marked with a * I need to correctly execute the particle/crosshair code every other line, even though individual steps here may *randomly* require a odd or even numbers of lines...

 

Not sure if it's even worth trying... :twisted:

 

Greetings,

Manuel

 Share

4 Comments

Recommended Comments

supercat
But, it can't happen on a repositioning scanline.

 

I'm afraid I don't see the problem. Keep your object repositioning on even (or, if you prefer, odd) scan lines and pad your sprite shapes with a blank row at top and bottom. Depending upon whether the sprite is supposed to appear on an even or odd scan line, the blank row at the top may or may not be displayed.

 

Is there something I'm missing?

Link to comment
Cybergoth

Hi there!

 

I'm afraid I don't see the problem.  Keep your object repositioning on even (or, if you prefer, odd) scan lines and pad your sprite shapes with a blank row at top and bottom.  Depending upon whether the sprite is supposed to appear on an even or odd scan line, the blank row at the top may or may not be displayed.

 

Is there something I'm missing?

 

Hm... dunno if it can be that easy. It sounds like a good idea, but it might be tough to work it in, as it'll require two different vertical resolutions. Also adjusting the pointer inside the kernel might be tricky.

 

Of course, even with extra padding bytes, the sprite will still have an odd or even size. And the padding bytes will sum up and steal valuable space from the GFX page, so I can do fewer frames of animation.

 

Greetings,

Manuel

Link to comment
supercat
Hm... dunno if it can be that easy. It sounds like a good idea, but it might be tough to work it in, as it'll require two different vertical resolutions. Also adjusting the pointer inside the kernel might be tricky.

 

I guess I'm a little confused as to why you'd need to adjust the pointer inside the kernel? If your object is supposed to be six scan lines high, then in one shape table you have: (line4 line2 line0 blank) and in the other you have (blank line5 line3 line1 blank). Bear in mind that the zero-byte following one object can be the same as the zero-byte preceding the next.

 

Your object height should be set to four scan-line pairs. If your object is supposed to appear on an even scan line, set the zero-page pointer used for showing even scan lines so that the bottom even-scan-line data will be line4 and one for odd scan lines so that the bottom odd-scan-line pixel will be line5. If your object is supposed to appear at an odd scan line, set the zero-page pointer used for showing even scan lines so that the bottom even-scan-line data will be the blank before line5 and the bottom odd-scan-line data will be the line4.

 

Alternatively, depending upon what you're doing with the other sprite register, you may be able to just use VDELx.

Link to comment
Cybergoth

Hi there!

 

I guess I'm a little confused as to why you'd need to adjust the pointer inside the kernel?

 

Uhm... didn't you say that I should pad zeros on bottom and top? Depending on wether ypos is odd or even, I'd then either need to set the pointer to shape or shape+1, no? Extra logic requires extra cycles, that's what I meant ;)

 

If your object is supposed to be six scan lines high, then in one shape table you have: (line4 line2 line0 blank) and in the other you have (blank line5 line3 line1 blank).  Bear in mind that the zero-byte following one object can be the same as the zero-byte preceding the next.

 

Ah, ok, that is another technique. Splitting the data like that makes sense if you keep your line counter at 2LK resolution. Well, I've sworn never to go that route again. It sucked already for doing a handful balloon shapes, but I definitely won't arrange a whole page of data like that (2 pages considering color). Also this requires setting 2 extra pointers (one for color), when it's already tight to do 2.

 

I think part of your confusion comes from thinking that the pointers are preset outside the kernel?

 

That is not the case, I'm setting everything on the fly. A solution like you describe would require 2 color and 2 shape pointers. That is 8 bytes. Per sprite. With the engine currently doing 9 objects, we'd be talking 72 bytes here! :)

 

No way to go within the standard specs of 128 bytes RAM ;)

 

And I have yet to see an extra RAM PCB successfully going to mass production, before committing myself to a non-standard b/s scheme.

 

Greetings,

Manuel

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×

  • Recently Browsing   0 members

    • No registered users viewing this page.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...