Could you list some horizontal flipping techniques?

[ssr86]

Rotate 180 degrees (horizontal+vertical flipping):

rot180_1.asm is using "in-place" method
timings:
draw normal: 5986 nops
flip: 2592 nops
-------------------------------------
rot180_2.asm is using "buffer" method
timings:
draw normal: 5981 nops
flip: 2775 nops
-------------------------------------
rot180_3a.asm is using "during drawing" method with no partial preflipping of sprite data
timings:
draw normal: 5983 nops
draw flipped: 7049 nops
-------------------------------------
rot180_3b.asm is using "during drawing" method with "normal_byte-reversed_byte" partial preflipping of sprite data
timings:
draw normal: 6510 nops
draw flipped: 6510 nops
-------------------------------------
rot180_3c.asm is using "during drawing" method with "normal_line-flipped_line" preflipping of sprite data
(draw_normal uses top-bottom and draw_rotated uses bottom-top drawing)
timings:
draw normal: 6331 nops
draw flipped: 6434 nops
-------------------------------------
rot180_3c_alt.asm is using "during drawing" method with "normal_line-flipped_line" preflipping of sprite data
(draw_normal and draw_rotated use top-bottom drawing)
timings:
draw normal: 6325 nops
draw flipped: 6435 nops
-------------------------------------
rot180_3c-2.asm is using "during drawing" method with "normal_line-flipped_line" preflipping of sprite data
(like hflip3c-2 with hflip3c)
timings:
draw normal: 6500 nops
draw flipped: 6645 nops
------------------------------------
rot180_3d.asm is using "during drawing" method with "half_normal-half_flipped" preflipping of sprite data
not finished so not included

[ssr86]

Horizontal shifting (half-byte):

hshift1.asm is using "in-place" method
timings:
draw normal: 5973 nops
shift right: 3709 nops (need two routines (shift_left and shift_right) so the data can be unshifted)
-------------------------------------
hshift2.asm is using "buffer" method
timings:
draw normal: 5984 nops
shift_right: 4740 nops (need only one shift routine)
-------------------------------------
hshift3a.asm is using "during drawing" method with no partial preshifting of sprite data
timings:
draw normal: 5983 nops
draw shifted: 8919 nops
-------------------------------------
byte-byte partial preshifting doesn't make sense so no hshift3b
-------------------------------------
hshift3c.asm is using "during drawing" method with "normal_line-shifted_line" preshifting of sprite data
timings:
draw normal: 7395 nops
draw shifted: 7395 nops
------------------------------------
hshift3d.asm is using "during drawing" method with "half_normal-half_shifted" preshifting of sprite data
timings:
draw normal: 7594 nops
draw shifted: 7461 nops

(have also done/tried a few shift+flip examples but would need to check which are complete and convert them to the cpc (all examples were written for ep128 in pasmo and only recently started converting them to cpc to compile in winape assembler...))...

[Ast]

I'd look later but i must congratulate you for all this long work. Fantastic!

[ssr86]

I've posted another example on flipping/shifting but for dual playfield mode 0 packed sprites (Dual playfield mode 0 sprites + packing)

I'd look later but i must congratulate you for all this long work. Fantastic!

Thanks, it really took me some time...
...the lack of feedback is really demotivating...

[arnoldemu]

Thanks, it really took me some time...
...the lack of feedback is really demotivating...

I am sorry because I haven't had time to look at it yet.

Don't get demotivated your investigations and work are worth it.

I don't get much feedback for my code postings, but I know
1) I investigated it and it's very useful for myself because I learn things I can use in my own games
2) at some time somebody else will read over them and find them useful (they may not always tell me)
3) The information I post is limited in scope to the programmers.

I haven't done an in-depth investigation into sprite methods so I will read it over soon and enjoy it.

[andycadley]

Yeah, there's a lot to take in there and I rarely get chance to sit and code at the moment, but it's definitely useful stuff to have written out. Will hopefully try and have a look over the weekend.

[ssr86]

Vertical flipping of compiled sprites.

Method used:
each line was made into a separate subroutine and all are then called in normal or reversed order depending on the wanted version.

Example uses the same sprite as before (24x22 mode0 pixels masked)
I'm saving the background outside the drawing routine.

timings:
draw normal: 1501 nops
draw flipped: 1498 nops
save background: 1963 nops
erase sprite: 1918 nops

without dividing into calls, draw time was: 1481 nops

Vertical flip is the only (?) tranformation applicable  to compiled sprites  in "real-time"...
This is the only way I could think of doing it.

[ssr86]

Just thought of another way of doing the vertical flip of a compiled sprite. This time I'm using a "dispatch jump" instruction...
So I'm not dividing the routine into separate lines, but instead modify the next_line macro to include a call to a jump instruction and the address of the jump is set to either scr_next_line (for normal) or scr_prev_line (for flipped).
So takes a little less memory (because no need for the call list like in the previous method). But the setup for flipping takes a little  longer because I have to recalculate the screen address of the last line of the sprite (I'm drawing bottom-up, in the previous example both versions were drawn top-bottom).

I guess this would be the better method of the two - you don't loose much speed compared to the previous one and save about 6*sprite_height bytes (so 132 for the used sprite).

timings:
draw normal: 1499 nops
draw flipped: 1581 nops (more time because I must calculate the address of last line of sprite from which I want to start the drawing...)
rest as in previous post...