2011-05-26 9 views
5

Estoy creando un nuevo motor de juego para la web con el nombre de Engine1. Actualmente he producido un par de prototipos. Hasta ahora he podido:¿Debo usar un fragmento DOM como dom Shadow en mi motor de juegos Javascript?

  1. Mapa de los píxeles transparentes de los sprites utilizando el lienzo.
  2. Enlace de eventos a los píxeles opacos de los sprites.
  3. Desarrolla un tiempo de ejecución del juego con un conjunto de fps.
  4. Animate sprites con temporización de cuadro variable.
  5. movimiento elemento Animate, tanto del marco
    1. por la fama
    2. y con interpolación de movimiento basado en cuadros

estoy feliz con mi progreso, pero me parece que ser incómodo con el avance más lejos sin consultar a un experto en rendimiento DOM.

Actualmente, cuando se crea un elemento, se agrega a un fragmento DOM que llamo el "DOM sombreado". Cada cuadro de este HTML de "DOM sombra" se copia e inserta en el cuerpo de la página (o el puerto de vista actual).

Lo he configurado de esta manera porque puedo agregar todo a la página en un nuevo flujo del navegador.

Mi preocupación es que el rendimiento obtenido se verá compensado por la necesidad de volver a fluir el contenido del navegador, incluso si solo se cambian partes de la página.

Además, el enlace de eventos se vuelve mucho más complicado.

¿Alguna idea?

¿Debo usar un "DOM sombra"?

¿Hay una mejor manera de representar una gran cantidad de elementos?

¿Hay alguna forma de copiar solo las diferencias del "DOM sombreado" al cuerpo del navegador?

+0

Esta técnica de DOM de Shadow me recuerda el doble almacenamiento en búfer. ¿Es asi? – Spidey

+0

Sí, creo que doble buffering es el término correcto. –

+2

Quizás deberías saber que desde que se hizo la pregunta, el término DOM Shadow se ha convertido en algo real: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html. Los lectores futuros pueden desear que se les avise que esta pregunta no está relacionada con esta especificación. –

Respuesta

0

Reemplazar grandes trozos del DOM puede ser costoso. En general, el DOM es donde ocurren los cuellos de botella. Sería mejor hacer un seguimiento de qué partes del DOM estás modificando y actualizando. Puedes hacer eso en una estructura de datos separada que transformas en DOM al actualizar, o usar un DOM sombreado como dijiste. Si los cambios son individualmente grandes, puede ser una buena idea usar un DOM sombreado. Si son pequeños (como la actualización de valores de texto), entonces tendría más sentido utilizar un tipo de estructura de datos por separado.

En cualquier caso, necesita un tercer objeto para realizar un seguimiento de los cambios.

Escribí Cactus Templates hace mucho tiempo. Lo usas para unir una estructura DOM junto con un objeto de dominio permitiendo que las actualizaciones se propaguen de un lado a otro. Se adjunta automáticamente eventos a las ubicaciones especificadas (rutas de valores clave en el dominio y nombres de clases html en el DOM). Puede o no ser exactamente lo que estás buscando, pero quizás puedas obtener algunas ideas de él.

+0

Útil, consejo. Gracias. Soy mi escenario. Tengo que esperar que los desarrolladores de juegos animen al menos el 80% de los elementos que crean marco a cuadro. Creo que debería seguir el método de "reemplazar todo". –

Cuestiones relacionadas