OType

[Iapetus]

So awesome...

Twilighte we miss you.

[8bit-Dude]

I have just seen the video and am blown away by the sprite animation Twilighte achieved.
Was the code for the OType gfx made available? Or do any other Twilighte game contains the same technique and has code availability?

[ibisum]

I believe the O-type project started off as SWIV, and when Twilighte renamed it, he nevertheless didn't change his repo .. so the code is in the miniserve SVN, under "/users/twilighte/Swiv" ..

[NekoNoNiaow]

For the details, Chema is correct: It is AIC; so the scroll vertically need to be in multiple of two steps, sprites move by 6 pixel laterally, there's no attribute conflicts because it's AIC so all the attributes are on the left side of the play field.

Oki, so the scroll step is two lines because AIC uses one paper/color combination for the even lines and another for the odd ones.
This said, if one is willing to also copy the color attributes at the left side of the play field, then it becomes possible to only scroll by one line.

The inconvenient is obviously that the top line of the screen may stick out like a sore thumb since it will initially appear alone, without being complemented by its "parent" line (which has not yet scrolled into the screen). But I presume it should be relatively simple to alter this first line to use slightly muted colors to simulate a "fade in".

[Dbug]

Oki, so the scroll step is two lines because AIC uses one paper/color combination for the even lines and another for the odd ones.
This said, if one is willing to also copy the color attributes at the left side of the play field, then it becomes possible to only scroll by one line.

The problem is that the scroll is far from 50fps, so there's a large probability that copying the line and attribute will not happen atomically, so you can get bright flashes caused by having some of the graphics displayed with the wrong set of colors.

[NekoNoNiaow]

The problem is that the scroll is far from 50fps, so there's a large probability that copying the line and attribute will not happen atomically, so you can get bright flashes caused by having some of the graphics displayed with the wrong set of colors.

Damn, you are right, I completely forgot about the absence of vsync.

[Chema]

Scrolling the attributes will alter the colours of the ships when they are at a fixed location.

About the syncing it is possible to do it, but what Dbug says is that it takes longer than the blank period to update the scroll. Probably longer than a frame time.

I think I managed to scratch 7000 cycles for updating by using only part of the screen height. What scroll size could you have as a best case (bunch of lda/sta pairs) in that time?

[NekoNoNiaow]

Scrolling the attributes will alter the colours of the ships when they are at a fixed location.

Yes, which is why I suggested to copy the attributes, not just the pixel data. This way the colors are preserved.

About the syncing it is possible to do it, but what Dbug says is that it takes longer than the blank period to update the scroll. Probably longer than a frame time.

I seem to be interpreting what DBug says differently than you do. To me (I may be wrong obviously), it seems that he is saying that since the copy cannot be aligned to vsync, there are bound to be lines where the attributes and pixel data will not be in sync, which will lead to color artifact.
This would probably take the form of a line of colored pixels scrolling up (or down) across the screen at a speed proportional to the VSYNC mismatch.

Moreover, I do not think copying the attributes would increase the copy time unreasonably.
Only two additional bytes to be copied per line need to be copied, one for the ink attribute and one for the paper attribute.

The O-Type scrollable area where graphics are drawn seems to consist at first glance of 18 characters horizontally.
Adding two bytes per line would increase this to 20, that is a 2/18 = 1/9th increase, that is around 10%.
This said, these bytes do not strictly need to be copied since we already know in advance what they must be. A dedicated routine could simply output them directly which would be much faster than a copy since no read would be needed.

So, yup, that would slow down the copy, but this would allow smoother and slower scrolling.
That compromise would not necessarily suit every game obviously.

I think I managed to scratch 7000 cycles for updating by using only part of the screen height. What scroll size could you have as a best case (bunch of lda/sta pairs) in that time?

The O-Type video seems to show that the copy is already not VSYNC aligned: there is ample tearing as the screen scrolls along so copy time is not the issue.
As far as I understand it, the issue is that the ULA could catch up to the copy (or the reverse), this is likely/possible since there is no VSYNC. The consequence would be that it would display a line of old pixel data with the new attributes (or the reverse, depending on when ULA/copy intersect).

I completely agree with you that screen copy time is important and tricky to reduce, I would even wager that this idea would deserve its own thread.

[Chema]

Scrolling the attributes will alter the colours of the ships when they are at a fixed location.

Yes, which is why I suggested to copy the attributes, not just the pixel data. This way the colors are preserved.

I understood. What I mean is that the player's ships (enemies too?) also use AIC, so if they are still at, say, the bottom of the play area and you scroll attributes one row up, their colors will change.

About the vsync thing, I am sorry if I misunderstood. In any case, it is possible to get an interrupt in sync with the vertical retrace, as was proposed here viewtopic.php?f=8&t=78&hilit=vsync&start=15#p15173

[NekoNoNiaow]

I understood. What I mean is that the player's ships (enemies too?) also use AIC, so if they are still at, say, the bottom of the play area and you scroll attributes one row up, their colors will change.

Hum... ok, I now understand what you mean. Nothing better than a good example! Thanks.

In the context of OType this is indeed an issue since enemies and player are moving in increments of two lines, so to avoid having them jiggle up and down one line as scrolling occurs they would have to be copied one line down compared to the scrolling copy, thus inverting their attributes.

I can envision two possible solutions:

• unproven: invert the odd and even lines of sprites every frame.
  Since sprites have an effective color granularity of two lines, swapping the lines should hopefully lead to the same blended color effect.
  This obviously needs to be verified graphically but I am hopeful that this would work, although this could result in annoying flickering if the frame rate is too low.
• guaranteed: have two versions of each sprite, one aligned on even lines, one aligned on odd lines.
  This way, we are guaranteed to have correctly colored sprites for each possible Y position of the sprites on screen.
  The inconvenient is that this requires double the RAM for moving sprites but this might be worth it.

I would not be surprised if there were other methods to work around this issue though.

About the vsync thing, I am sorry if I misunderstood. In any case, it is possible to get an interrupt in sync with the vertical retrace, as was proposed here viewtopic.php?f=8&t=78&hilit=vsync&start=15#p15173

Do not be sorry!
Oh, nice technique. If it really works, this would indeed be great and would solve the vsync flickering issue.