Sprites and line 216

Page 3/3
1 | 2 |

By DarkSchneider

Paladin (939)

DarkSchneider's picture

25-07-2017, 11:39

Grauw wrote:
DarkSchneider wrote:

The problem of option 3 is that doubles the space used for sprites only for avoiding 1 pixel. Think that for other sprites, those placed in static places (the sprite gfx table) you can't correct them by the vdp command, so a new full table should be used.

I don’t really understand that last bit, what do you mean by a new table should be used? I’m in principle assuming I re-write the full sprite attribute table every frame.

I mean because for option 3 an alternate pattern is needed:

Quote:

3. Use a secondary pattern shifted 1 line up or down when on this line.

This is, not the SAT, the gfx themselves.
Also though that is not enough, because if 1 sprite is at 216 and you change to the alternate gfx table, all the sprites would move 1 line, even worse than only moving the one at 216. The one at 216 would draw correctly but all the others displaced 1 px.

Grauw wrote:
DarkSchneider wrote:

Option 2 is fine, for games at 30 fps.

Hey, why not for 60 fps? Secret of Mana, Chrono Trigger, Phantasy Star IV, all move at 2px / 60fps. Also for platformers it could be a nice fast speed.

Because elements moving at 1px speed. It is fine if you design all to have even speed, but again it is limiting your design. Maybe for future is not the best.
Also, you would end checking for the final position because even with even speed it could ends at 216 due to collisions. In this case you could also condition the collisions to avoid it but, is not too much conditioning? It could affect your freedom to design.

Also, as have been pointed, there are more sprites and characters, so any "trick" you could use, is really hard to apply as you can have many sprites surrounding the 216, which would be a problem.

What would I do (as probably will end doing it): simply check if one sprite ends at 216 and then move the whole character 1 line up or down. The method is fine even for the Yamaha programmer manual. Test it before discarding it.
For implementation, something like this (the idea):

drawcharacter(x, y, satindex)
{
  satindex_orig = satindex;
  for(i=0; i < numsprites; i++) {
    // compute sprite coordinates using x, y as reference and adding values
    if(sprite_y == 216) {
      i = 0; // restart frame draw
      satindex = satindex_orig; // overriding the already written ones
      y = y - 1; // or +1; notice that we modify the LOCAL value, so the character value is not modified
      continue;
    }
    // write SAT values
  }
}

By Manel46

Hero (601)

Manel46's picture

25-07-2017, 16:52

DarkSchneider wrote:

Also, as have been pointed, there are more sprites and characters, so any "trick" you could use, is really hard to apply as you can have many sprites surrounding the 216, which would be a problem.

Sure. I have tried it and it is very complicated, with several sprites around Y216.

By Grauw

Ascended (9377)

Grauw's picture

25-07-2017, 14:59

DarkSchneider wrote:

I mean because for option 3 an alternate pattern is needed:

Quote:

3. Use a secondary pattern shifted 1 line up or down when on this line.

This is, not the SAT, the gfx themselves.
Also though that is not enough, because if 1 sprite is at 216 and you change to the alternate gfx table, all the sprites would move 1 line, even worse than only moving the one at 216. The one at 216 would draw correctly but all the others displaced 1 px.

Yes, I don’t think switching to a second SPT would work. I see two practical subdivisions of option 3:

3a. Keep a shifted copy of all patterns in the SPT and switch the pattern number on line 216. This is quick, the most generic, but halves the total nr of patterns to 32.

3b. Overwrite the pattern itself. This is heavier, requires a 1:1 sprite-pattern mapping, but can be off-loaded to the VDP command engine.

I think initially I’ll use option 2 (2-pixel move) for the main player character, and option 1 (move up) for the remaining sprites (particles, weapon effects, typically 16x16). It’s the easiest to implement.

Later I may opt to use option 3a for the main character sprite. As I will already be writing the pattern for the animations (not enough room in the SPT for all the frames), it will come at near-0 additional cost. For the remaining sprites I may selectively use option 3b; by having a shifted-pattern number, and setting it to the regular pattern or a shifted one, I can choose on a sprite-by-sprite basis.

DarkSchneider wrote:

Because elements moving at 1px speed. It is fine if you design all to have even speed, but again it is limiting your design. Maybe for future is not the best.

For general gameplay, moving at a 2-pixel pace will be nice. I remember some games on PlayStation have a controller button assigned to run. This resulted in me always keeping that button pressed -_-;;. So I think players will thank me if I just use the 2x speed always Smile.

If I need a walking speed for my characters at some point (maybe in a cutscene?), I can implement option 3. But I don’t think I should spend time on it now when I do not know yet whether I will need it.

DarkSchneider wrote:

Also, you would end checking for the final position because even with even speed it could ends at 216 due to collisions. In this case you could also condition the collisions to avoid it but, is not too much conditioning? It could affect your freedom to design.

Why would I need to add conditional checks and special cases? Just put all collisions on 2x2 boundaries as well, this is not a restrictive limitation imo.

DarkSchneider wrote:

What would I do (as probably will end doing it): simply check if one sprite ends at 216 and then move the whole character 1 line up or down. The method is fine even for the Yamaha programmer manual. Test it before discarding it.

I have! I hid the bottom half of the sprite to see how it looked. I didn’t like it Smile. At least not for the main character. Because he is the focus of your attention, and stays static relative to the scrolling screen, the jump is quite visible to the eye (which is sensitive to motion).

By Grauw

Ascended (9377)

Grauw's picture

02-11-2017, 01:32

Another idea (option 5);

If your character animations are synced to the y (and x) position, then if you align your animation frames right, you could make sure the frame which plays when going from line 216 to line 217 is always offset by one line.

E.g. if you look at this animation:

The second and fourth frame have the character’s head move down by one line. So if the transition between frame 1 and 2 (or 3 and 4) happens exactly on line 216 going to line 217 (and vice versa), the sprite display issue could be avoided.

Going from a standstill to a run, one could either jump right into the middle of the animation based on y position, or if you want the animation to always start from the first frame, the character movement could be constrained to occur on a grid of 8x8 or 16x16 (Final Fantasy VI, Pokémon, Lufia, Phantasy Star IV, Star Ocean).

Page 3/3
1 | 2 |