Estructura de datos muy grande necesaria. En busca de ideas

Question

He estado masticando esto por un tiempo y pensé que abriría una pregunta y trataría de obtener algunas ideas al respecto. Tal vez algo encenderá una bombilla.

Necesito construir una rejilla hexagonal y esa rejilla hexagonal tendrá un mínimo de 10 x 10 y un máximo de 500x500 - y posiblemente más grande. Obviamente, esta es una grilla masiva en el extremo superior y, naturalmente, tendrá que dividirse.

Aquí está la mayor parte del problema.

• 500x500 cuadrícula de hexágonos. aprox.
• No cambian muy a menudo, pero pueden cambiar.
• Descomponerlo en secciones de 50x50 o 100x100 es muy factible; sin embargo, es posible que alguien corra de un extremo del mapa al otro, así que tengo que ser capaz de manejar todo en algún momento, incluso si está en secciones
• Esto obviamente creará una gran pérdida de memoria.

Puedo almacenar los datos (vars compartidos) como simple byteArray o incluso en plainText. La información por hex es muy simple, es la cantidad que hay. No "tengo" que guardar los datos. (Sería una característica)

La estructura básica por hexágono es:

• color hexadecimal (con contorno obviamente) (o una imagen de mapa de bits) blitting cualquiera!
• TextField con un número en él. (Máximo 2 dígitos)

Eso es más o menos toda la información que se necesita.

Si no hubiera la posibilidad de que el hexágono cambie en absoluto, esto sería bastante trivial.

Tengo curiosidad por saber si alguien tiene alguna idea al respecto. (cualquier verdad absoluta no estaría mal;)

Editar: Oh, la información en los hexes viene a través de una corriente tcp. Esto no es un problema, como dije, los datos son simplistas por hex. Y mi analizador es muy rápido, así que no es un problema.

Actualización: La posibilidad de tener que crear y mantener 250,000 objetos (hexágonos) es lo que más me hace hacer esta pregunta. Es por eso que estoy buscando ideas. (250k objetos en flash están bien laf)

Answer 1

La estructura básica por hexágono es:

* hex color (with outline obviously) (or a bitmap picture) blitting anyone! 
* TextField with a number in it. (max 2 digits) 

supongo que no es necesario para almacenar todos 250K campos de texto y mapas de bits, ya que son por qué existir solamente en la pantalla. Empaquee estos datos en un número pequeño de bytes: un máximo de 2 dígitos es de 7 bits, agregue identificadores de color de su paleta (o 24 bits si necesita color verdadero) e identificadores de mapa de bits. Si crea estructuras del mismo tamaño, puede escribirlas en ByteArray. Esto le permitirá deshacerse de las referencias de objetos de 250K y evitar la posible fragmentación de la memoria.
Luego solo necesita crear funciones de paquete/desempaquetar para esos bytes en algunos objetos utilizables (no olvide los grupos de objetos) y haga los aritméticos para obtenerlos de ByteArray a la derecha. Como otros señalaron, las células 250K no son mucho si empaqueta los datos de la celda en un par de int.

Answer 2

¿Quizás podría abordar esto como un ejercicio de desduplicación de datos? Por ejemplo, no hay más de 100 valores de texto distintos que pueden asociarse con sus hexágonos. Suponiendo que realmente solo utiliza una pequeña cantidad de diferentes colores hexadecimales (como, digamos, menos de 20), entonces un conjunto relativamente pequeño de instancias hexadecimales puede representar todas las posibles configuraciones hexadecimales. Lo que podría tener una función de utilidad como (la sintaxis de ActionScript no es válido, lo siento):

Hex getHex(int color, String label)

... que comprueba si un hexágono ya existe con la configuración dada, y sólo crea una nueva instancia Hex si uno no existe ya

Así que todavía tiene 250,000 referencias en su matriz (o cualquier estructura que use para realizar un seguimiento de sus hexágonos), pero solo un número mucho más pequeño de instancias de objetos reales. Parece que debería ser manejable, incluso en Flash.

Tendría que tener mucho cuidado si sus hexágonos son mutables después de haber sido creados.