Scoped cross mode

[nkh]

Crossing overlay is a global setting. It's applied on the projection of the elements not on the elements itself. Although visually pleasant it ignores that Asciio deals with objects.

Connection crossing

The images below show an example where scoped crossing overlay would make Asciio's output better but we want the crossing overlay to be limited to the lines connected to the same object.

Grouped elements

A visually appealing group of component, created with crossing overlays, becomes less appealing if unrelated crossing is added.

[qindapao]

@nkh I haven't replied yet because I haven't thought of a good idea. But this is a new cross mode. It's the linker cross mode you mentioned before.

It is necessary to judge the type of the current cross element.

Let's finish processing the buffer first and then deal with this

[nkh]

Agreed, the advantage of separating the cross mode from the 2D map generation is that Asciio can provide multiple maps to the cross module.

the groups, also note #134, can be passed to Cross separately and the rendering of the group can be cached, then the rest of the elements (as a Zbuffer) can be passed to the cross Cross module.

There will probably be other types of grouping we want to handle differently; the code to handle those should not be in the cross module, it should probably be in separate modules which specialize in those special case, like hooks/canonize_connections.pl for example.

Maybe the first change you should look into is to replace Cross.pm map generation with the Zbuffer implementation.

[qindapao]

@nkh

https://github.com/qindapao/P5-App-Asciio/tree/cross_zbuffer

cross_mode_and_connector_cross_mode.zip

I moved our previous intersection calculation algorithm to the new zbuffer architecture and added connector cross mode.It may not be completely rigorous yet, but it's basically usable.

[qindapao]

The use Term::Size::Any qw(chars) ; module is not installed in my environment, so I commented it out temporarily. I don't see you using it either.

[nkh]

@qindapao if you mean:

lib/App/Asciio/Actions/ZBuffer.pm
15:use Term::Size::Any qw(chars) ;

it looks like something that's been left there from my refactoring, Term::Size is use in tasciio.

[nkh]

@qindapao

I can't accept the patch you made as this is not how I intend the Zbuffer to be used. Cross data is again spread all over the code base. The whole Idea of using a Zbuffer is to stop mixing the different classes.

I understand that you have tried to fix this issue and issue #108 at the same time but I believe this is not the right approach.

First fix #108 using exactly the Zbuffer implementation I wrote (please discuss architectural changes with me in issues first in the future)

• do not change ZBuffer
• do not add arguments to it
• do not put any code from Cross.pm , or anywhere else, in it.

If you believe it's not possible, discuss it with me in #108.

• do not create any class derived from the ZBuffer, it's supposed to be "dumb" for a reason, we can discuss this issue after the above is fixed.

• use get_neighbors instead for accessing the $zbuffer->{coordinates} directly as it wastes memory because of auto vivification.

furthermore, the code below is probably broken as $zbuffer->{coordinates}{x;y} contains a character not an array reference.

while( my($coordinate, $elements) = each $zbuffer->{intersecting_elements}->%*)
	{
	my ($Y, $X) = split ';', $coordinate ;

	my ($up, $down,  $left,  $right) = 
	   (
           $zbuffer->{coordinates}{($Y-1) . ';' . $X},
           $zbuffer->{coordinates}{($Y+1) . ';' . $X},
           $zbuffer->{coordinates}{$Y . ';' . ($X-1)},
           $zbuffer->{coordinates}{$Y . ';' . ($X+1)}
           ) ;

	my $normal_key = ((defined $up) ? join('o', @{$up}) : $undef_char) . '_' 
			. ((defined $down) ? join('o', @{$down}) : $undef_char) . '_' 

if necessary you can add this function to ZBuffer.pm

sub get_cardinal_neighbors
{
my ($self, $coordinate) = @_ ;
my ($x, $y)             = split ';', $coordinate ;

return 
	{
	map 
		{
		exists $self->{coordinates}{$_} 
			? ( $self->{coordinates}{$_} ne ' ' ? ($_ => $self->{coordinates}{$_}) : undef) 
			: undef
		}
		$x .';'. ($y-1), 
		$x .';'. ($y+1),
		($x+1) .';'. $y,
		($x-1) .';'. $y,
		($x+1) .';'. ($y-1), 
		($x+1) .';'. ($y+1),
		($x-1) .';'. ($y+1),
		($x-1) .';'. ($y-1) ;
	}
}

which allows you to write

my ($up, $down, $left, $right, $char_45, $char_135, $char_225, $char_315) =  $zbuffer->get_cardinal_neighbors($coordinates) ;

my $normal_key = $up // $undef_char  . '_' . down // $undef_char ; 

• explain what 1 and 2 in USE_CROSS_MODE are and do not use MAGIC numbers

[qindapao]

@nkh Sorry, This time I made some changes to the code that deviated from your design direction without discussing it with you.I'll remember it, and we'll discuss it clearly next time and then I'll take action again until we reach an agreement.

Most of you are right, but I will discuss some small details with you. I'm going to make a language description, and I'll discuss it in the issue you mentioned when I have time.

It seems that you need to do more things with zbuffer than just cross? That is, it will be used for other purposes besides various cross models.

Because I can only use my mobile phone for the time being, I can only reply briefly. I will prepare the detailed language in another issue.

[nkh]

@qindapao the largest change you made is at the right place

plans for ZBuffer include:

• make knowledge of Asciio internals Zero in the Cross module
• make knowledge of Cross internals Zero in the other modules
• use it as the rendering engine for Text Asciio
• implement scoped cross mode, this issue, with it