blocks overlap at rotate

[GoogleCodeExporter]

Submitted by Egmont Koblinger (egmont):

When a block is falling down, and you press the right/left arrow to move
it, and the block cannot be moved at this moment, but will be movable in
that direction in less than one unit of falling down, then only the shadow
is moved, the block remains in the same coloumn. This is very nice. The
same should happen with rotate, too.

However, when rotating under the same circumstance (i.e. the block isn't
rotatable now, but will be very soon), then not only the shadow, but the
block is rotated now, too. And hence the block overlaps another one for a
short time.

Take a look at the attached .rec file, you'll see it twice :-)

All this is tested with 1.1.8, shadow enabled (I don't think it's needed
anyway), all other settings at their default value.

Original issue reported on code.google.com by pphaneuf on 31 Mar 2008 at 4:05

Attachments:

• quadra-rotate-bug.rec

[GoogleCodeExporter]

I can confirm that this is a valid request but I think it would be insanely 
hard to 
fix relative to the benefit. Looks like the kind of thing that stays 
low-priority 
forever.

Original comment by slaj...@gmail.com on 31 Mar 2008 at 10:20

• Changed state: Accepted
• Added labels: Priority-Low, Component-UI
• Removed labels: Priority-Medium

[GoogleCodeExporter]

If you're going to have smooth falling gravity with collisions detected against 
the
bottom edge, then this is unavoidable. If you're going to have smooth falling 
gravity
with collisions detected against both toe top and bottom edges, then certain 
piece
placements (moving 2 or more cells under an overhang without anything to 
support it
after the first move) become impossible. If you've ever played <i>The New 
Tetris</i>
for N64, then you will possibly have seen this.

Original comment by Shrapnel.City@gmail.com on 31 Mar 2008 at 10:26

[GoogleCodeExporter]

I think you misunderstand Egmont's point. It has everything to do with 
maneuvering a 
block into place and nothing to do with clearing lines or subsequent gravity 
effects.

Another thought occurs: those clever little moves work exactly the same way 
when 
block shadow is disabled. That means an argument could be made that the current 
behaviour is counter-intuitive because we allow block movements without showing 
any 
feedback on the screen. Of course, we can't change anything in the controls 
without 
messing up the 200+ bpm players so that's here to stay.

Original comment by slaj...@gmail.com on 31 Mar 2008 at 11:08

[GoogleCodeExporter]

Hmm... let me look at this again...

My interpretation of the behaviour that is described in the original report, is 
that
the animation of the current piece is sometimes incorrect, and that Egmont is
requesting it to be incorrect at other times. In a falling blocks game, the 
animation
of the currently falling block should always reflect the internal behaviour, and
therefore, the piece should be shown to be overlapping when moving sideways 
under an
overhang as well as when rotating under an overhang. And showing it overlapping 
does
not require changing anything in the controls. At least, it shouldn't...

Original comment by Shrapnel.City@gmail.com on 31 Mar 2008 at 11:29

[GoogleCodeExporter]

I understand what you mean in comment 4 but completely fail to get what that 
has to 
do with gravity in comment 2. Anyway, there is special code to prevent showing 
an 
overlap while a block is sliding underneath an overhang because it was deemed 
too 
ugly. If any change is made, I think it should be to make rotated blocks behave 
like 
that as well (as originally suggested). People who play without shadow might 
think 
it looked funny but so be it (it's a very subtle move anyway, it matters very 
little 
how we display it).

Original comment by slaj...@gmail.com on 1 Apr 2008 at 12:11

[GoogleCodeExporter]

In another falling blocks game that I play, the option to show the active piece
moving down smoothly instead of 1 cell at a time is called "smooth gravity".

Original comment by Shrapnel.City@gmail.com on 1 Apr 2008 at 12:28