Pixi.js: Dar una opción para establecer límites fijos en un contenedor

El contenedor no tiene área ni límites fijos, es solo una colección de elementos secundarios, y ese es el comportamiento predeterminado de PIXI. Si desea corregir los límites, amplíe su propio contenedor, anule el método "calculateBounds".

Si no tiene un área y límites fijos y es esencialmente solo una estructura de datos, entonces no debería afectar la representación (similar a cómo si coloca un objeto que es demasiado grande en un iframe, el iframe no se agrandará) . En el ejemplo claramente lo hace, y me resulta difícil culpar a la lógica defectuosa del ejemplo. Quizás no tener una opción de límites fijos no está buscando la raíz del problema, pero el problema definitivamente está ahí.

¿Cómo sugeriría que implemente elementos "fuera de la pantalla"?

¿Por qué necesitas límites de todos modos?

¿Ha mirado el ejemplo? El comportamiento extraño es causado por el hecho de que cada vez que drawDebugLines se ejecuta y dibuja las líneas en el contenedor del "icono", ese contenedor se agranda. Lo que a su vez estropea los puntos de ajuste, ya que dependen de las dimensiones del contenedor (ancho / columnas, alto / filas).

Si mapeo el ajuste al elemento de renderizado, esto presenta 2 problemas: el renderizador depende del tamaño de la pantalla, la orientación, la densidad de píxeles y las dimensiones especificadas por el usuario del elemento de dibujo. Puede contener elementos que sean más grandes que él (p. Ej., Fuera de la pantalla, que se pueden deslizar) y más pequeños (p. Ej., Si hago visibles el escritorio 1 y el escritorio2 al mismo tiempo. En todos esos casos, el ajuste y otras restricciones deben conservarse .

lel.width = wonderfulRectangle.width * 0.8;
lel.height = wonderfulRectangle.height * 0.9;

¿Por qué no lo usas como una constante? ¿Puedes configurar algo global, así:

var globalRect = new PIXI.Rectangle(0, 0, renderr.width/renderer.resolution, renderer.height/renderer.resolution);

actualice ese rect en cada cambio de tamaño y trabaje con eso. ¿Por qué necesita "lel.width" y "lel.height"?

LEL. Ese no tiene nada que ver con nada, es solo un Sprite que se puede mover y estoy configurando el ancho y el alto porque la imagen original es demasiado grande y necesito encajarla en un rectángulo. Si miras el código en el, verás que el contenedor principal para ese "ícono" es desktop1 y es al que estoy tratando de encajar el ícono. Ese pertenece al desktopLayer y el desktopLayer es el que puse en el escenario.

Lo que estoy tratando de emular es el comportamiento de una pantalla de Android Launcher con múltiples vistas deslizables y una cuadrícula de iconos sobre un fondo de escritorio.

return new PIXI.Point(snapPosX.clamp(0, target.parent.width), snapPosY.clamp(0, target.parent.height));

Sigo sin entender lo que quieres. Los límites del contenedor PIXI funcionan exactamente como se supone que deben hacerlo. No eres el primero en cometer este error.

Oh, aliento de creador, ya no puedo hacer esto. ¿Alguien puede simplemente mirar el ejemplo, mover la cara de rabia y decirme por qué está sucediendo esa mierda con las líneas y si es un error / característica faltante en PIXI o si tengo un error en el código?

Pensé que eso se debe a que sus líneas realmente afectan el ancho y la altura del contenedor y, en primer lugar, usa esas propiedades para dibujar líneas.

Además, codepen ya no funciona para mí, de alguna manera. ¿Alguna idea de por qué?

Sí, está roto para mí también porque accidentalmente comenté la llamada de inicio, mi mal, lo siento, arreglado. Sí, tienes razón, eso es lo que hago y no veo ninguna otra forma de dibujar esas líneas para reflejar la cuadrícula visualmente. Entonces, ¿qué me propondrías exactamente para trazar estas líneas? ¿Configurar algún tipo de objeto Rectangle solo meta separado que siempre copie las dimensiones del contenedor renderizado asociado y lo use para derivar los puntos de ajuste y otras posiciones? Eso parece una sobre ingeniería en torno al problema en lugar de resolverlo. ¿Hay alguna razón por la que un contenedor no pueda tener "desbordamiento" como un elemento DOM normal?

Publiqué esto como un problema no porque no haya una solución, sino porque no veo justificación para este comportamiento ilógico. Especialmente porque las líneas en realidad no salen de los límites del contenedor, se dibujan de borde a borde. En el producto que estoy construyendo, se espera que el usuario interactúe mucho con el contenido, me preocupa que si tengo que configurar "rectángulos de referencia" para cada objeto en la escena, el código será extremadamente complicado y difícil de mantener. .

Mencionaste que tenía un "error" en mi código. ¿Cuál es ese error? Busqué muy a fondo pero no puedo encontrar ninguna lógica defectuosa.

Utilice alguna variable global en lugar de "ancho / alto" que están cambiando. Actualice esa variable cuando sea necesario.

var globalRect = new PIXI.Rectangle(0, 0, renderer.width/renderer.resolution, renderer.height/renderer.resolution);

Si quieres límites "locales", hazlos, pero no uses las mismas variables que pixi:

container.myRect = new PIXI.Rectangle(0, 0, renderer.width/renderer.resolution, renderer.height/renderer.resolution);

El error es que no hay diseño en PIXI, en absoluto. "ancho" y "alto" tienen un significado diferente. No puede sujetar las coordenadas secundarias por la altura del ancho principal, porque el niño las afecta.

No hay forma de que PIXI sepa que quieres el ancho / alto de algún rectángulo que dibujaste dentro de los gráficos, y no límites de gráficos completos (¿y si también hay círculos?), Y no límites secundarios. La única lógica razonable para los límites es llevar todo lo que hay dentro de ellos.

Imagina que tenemos un contenedor con dos sprites, cada uno tiene (w = 10, h = 10), uno está en (0,0) el segundo está en (100000, 100000). ¿Qué ancho y alto tiene ese contenedor? Además, incluso si de alguna manera arreglamos los límites, ¿qué afectarán?

¿Y si queremos cambiar el ancho y el alto de alguna manera, cómo afectará ese cambio a los elementos dentro del contenedor?

No estoy bromeando, es realmente difícil para mí imaginar otros diseños de API. Si tiene algunas ideas, puede ser un componente adicional para el diseño, escríbalo aquí. Solo recuerde que estamos tratando con renderizado de escenarios y no con alguna GUI, el rendimiento es un problema real.

Hola @megakoresh , creo que sé qué está causando la confusión aquí. Dado que el objetivo principal de Pixi es renderizar objetos 2D, casi toda la API está orientada a ese fin. Los límites pueden ser particularmente confusos.

En pixi, los límites de un Sprite están definidos por la textura. Es decir, el tamaño del resultado final del objeto renderizado. De manera similar, dado que un Contenedor _no está dibujado_, y por lo tanto, los límites del mismo están definidos por los elementos secundarios que contiene. Particularmente, por los límites de esos niños. Para un objeto Graphics, los límites están definidos por la geometría que dibuja en él. Si dibuja otro rectángulo en un objeto Graphics fuera de los límites actuales, los límites se expanden para incluir la geometría recién dibujada.

Con suerte, eso tiene sentido y te da un concepto rápido de cómo se estructuran los límites en Pixi.

Ahora, específicamente para su ejemplo, creo que su problema proviene del malentendido de cómo funcionan los límites para un objeto Graphics. Creo que le falta que dibujar su cuadrícula está cambiando los límites del objeto Graphics ( desktop1 ) que contiene el rectángulo verde ( wonderfulRectangle ).

Puede ver que después del primer dibujo, su cuadrícula se extiende fuera del tamaño de la ventana gráfica:

Esto amplía los límites del objeto Graphics principal ( desktop1 ) para incluir la geometría fuera de la vista. Esto hace que su ancho sea más grande, lo que desecha su próximo cálculo de la cuadrícula y el ciclo continúa. Recuerde, las líneas tienen grosor y, por lo tanto, toman ancho.

Hay un par de formas de solucionar este problema, la que me viene a la mente es que, dado que su cuadrícula ocupa todo el tamaño de la ventana gráfica, solo use el tamaño de la ventana gráfica en lugar del tamaño de su padre. Esto significa que si / cuando dibuja más geometría fuera de la ventana gráfica, sus cálculos de cuadrícula nunca cambian. Porque la ventana gráfica de renderizado no cambia de tamaño.

Si esa no es una opción, por ejemplo, el área de la cuadrícula no es del tamaño de la ventana gráfica. Puede realizar los cálculos basándose en un "tamaño conocido" del área de la cuadrícula. Creo que eso era lo que Ivan estaba tratando de decir sobre el uso de una instancia Rectangle estática. Básicamente, decida que su cuadrícula es 800x600 y haga cálculos basados ​​en eso en lugar de ejecutar los límites reales renderizados de los objetos en la escena.

Actualicé el codepen para usar el método de ventana gráfica que describí. ¡Avísame si tienes más preguntas!

http://codepen.io/anon/pen/yarVwm?editors=0010

LOL k. Entonces, con sus esfuerzos combinados, creo que entiendo el núcleo del problema: creo que estaba pensando que si la biblioteca a menudo se junta con bibliotecas de lienzo, asumí que es lo mismo, lo que claramente no es así. Supongo que luego cuidar la agrupación de objetos visuales y cosas como el desbordamiento son simples, no están en el alcance (tal vez cuando aprenda más sobre la biblioteca, pueda hacer un complemento para eso) y debo ocuparme de esas cosas yo mismo, mientras que PIXI se encarga de simplemente mostrar cosas en la pantalla. Caso cerrado, gracias.

Este hilo se ha bloqueado automáticamente ya que no ha habido ninguna actividad reciente después de que se cerró. Abra un nuevo problema para errores relacionados.