@Ema, Miqueas : de esa forma si matas un npc con /MATA o borras 1 objeto con /DEST podes hacer reventar todo a la meirda.

maTih.- escribió:@Ema, Miqueas : de esa forma si matas un npc con /MATA o borras 1 objeto con /DEST podes hacer reventar todo a la meirda.

No vas a borrar un arbol, la funte de ulla, un cacho de piedra ,ect

Pudiste solucionarlo al final? Si tienes alguna duda posteala, es algo complejo el quadtree, pero cuando lo entiendes es muy facil y simple.

maTih.- escribió:

Shalvaid escribió:Bueno gracias a todos por sus respuestas. El sistema es tal cual como lo describe Pato, está hardcodeado y se complica entenderlo.
Seguí la idea que me dió Parra, empecé a buscar un poco acerca de los QuadTrees y se me ocurrió hacer algo asi:

[ Imagen ]

Como se puede ver, me quedarían 16 secciones (Hojas), divididas al ancho necesario, pongamos como ejemplo para un fullscreen.
(800 / 32) = 25 Tiles que sería la cantidad que entraría en una "hoja" del "arbol".
(600 / 32 = 19 Tiles, me estarían sobrando un par :p, pero bueno.

Mediante una ecuación, ubicar en que hoja se encuentra el usuario, y darle su ID de hoja. Cada vez que camina se fija si llega a la intersección marcada en líneas verdes, allí cambia la ID y reenvia la informacion del sector.

Como el CheckUpdateNeededUser solo checkea 3 cosas, Usuarios, Npc's y Objetos. Podría hacer algo así

Mostrar Todo el Código | Numero de Linea | Ocultar/Mostrar | Seleccionar todo

1.  
2. Public Type QuadTree
3.          MaxUsers as integer
4.          UserIndeX(1 to 100) as integer
5. ---------------------------------------------
6.          MaxItems as integer
7.          Item(1 to 100) as QTObject (Este tipo tendría el ObjIndex, posicion X y posición Y del mapa)
8. ---------------------------------------------
9.          MaxNpcs as integer
10.          Npcs(1 to 100) as QTNpc (Este tipo tendría el NpcIndex, posición X y posicion Y del mapa)
11. end type

Se crearía una variable de este tipo, para cada "hoja". Y cuando un usuario accede a esa área, le envía solo la información que tiene almacenada previamente por los "MaxUsers", "MaxItems", "MaxNpcs", solo lo justo y necesario y nos ahorramos el loop por todas las coordenadas de esa área buscando a ver que hay.

Lo que si habría que hacer es cada vez que un usuario Tira un objeto, entra al mapa, o un npc se crea o se mueve, actualizarlo a su debido QuadTree.

Bueno, eso es todo, veremos que opinan.
Gracias a todos.

Edit: Pensandolo bien, en un rango de 25 tiles por 25 tiles tengo un total de 625 tiles, tendría que ver como manejar eso, para no tener que andar haciendo Redim Preserve al array cada vez que se agrega un user, un npc, un objeto, etc. -.- . Y 100 es muy poco.

eso mas que un quadtree es una negrada, maneja un array grande para cada tipo (npcs, usuarios, objetos), no uses redim, simplemente para añadir un tipo (npcs , usuarios, objetos) te fijas si entra , si no , mediante una funcion buscas un slot libre para el array y lo metes todo ahí, suponete

Mostrar Todo el Código | Numero de Linea | Ocultar/Mostrar | Seleccionar todo

1. Function buscarNpc(byval NPCindex as integeR) as byte
2.  
3. 'Devuelve la posición para el array de npcs.
4.  
5. dim j as long
6.  
7. for j = 1 to ubound(arrayNPCS())
8.  if arraynpcs(j).npcindex = NPCINDEX then
9.     buscarnpc = j
10.     exit function
11.  end if
12. next j
13.  
14. end function

despues igualas si eso es > 0 entonces esta en el array, y actualizas las posiciones etc etc.

Pero con eso que ganas? Es practicamente lo mismo...

Bueno Parra, realmente los QuadTrees son bastante complejos, estuve leyendo y viendo ejemplos pero no es nada fácil y creo haber visto solo uno hecho en visual basic que era "similar" pero de igual forma complejo. Creo que no es mi tiempo para implementar QuadTrees, aún me falta bastante por aprender y es una técnica utilizada por gente mucho más experimentada que yo en lo que es creacion de engines. No digo que no sea capas, es que dadas las circunstancias actuales, lo veo bastante dificil poder programar dicho sistema y que sea funcional y libre de bugs.
El problema no lo he podido solucionar aún, sigo con las áreas normales que tiene argentum, que por cierto, son incompatibles con una pantalla de 800x600. Estuve descargando otros engines en visual basic, así que voy a ponerme a ver por encima de qué forma trabajan para tener una idea.

Yo por mi parte, agradesco tu ayuda. Siempre estás ahí para ayudar a quien tenga algun problema.
No es un NO definitivo para los QuadTrees, simplemente voy a dejarlos para el futuro cuando tenga algo más de experiencia y práctica en engines y por supuesto en c++.
Te dejo 10 monedas por tu gran ayuda, ultimamente la gente anda escatimándolas no sé por qué.

Ah y suerte en AOC

Te soy sincero, yo todavía no entendí como hacer un quadtree, no me puse a probar tampoco pero por ahora la teoría no la entiendo ! jajaja capaz en la práctica y haciéndolo lo voy comprendiendo pero sí es bastante complicado xd.

Hay maneras mas fáciles de optimizar las áeras, yo que vos no me perocuparía tanto

Shalvaid escribió:Bueno Parra, realmente los QuadTrees son bastante complejos, estuve leyendo y viendo ejemplos pero no es nada fácil y creo haber visto solo uno hecho en visual basic que era "similar" pero de igual forma complejo. Creo que no es mi tiempo para implementar QuadTrees, aún me falta bastante por aprender y es una técnica utilizada por gente mucho más experimentada que yo en lo que es creacion de engines. No digo que no sea capas, es que dadas las circunstancias actuales, lo veo bastante dificil poder programar dicho sistema y que sea funcional y libre de bugs.
El problema no lo he podido solucionar aún, sigo con las áreas normales que tiene argentum, que por cierto, son incompatibles con una pantalla de 800x600. Estuve descargando otros engines en visual basic, así que voy a ponerme a ver por encima de qué forma trabajan para tener una idea.

Yo por mi parte, agradesco tu ayuda. Siempre estás ahí para ayudar a quien tenga algun problema.
No es un NO definitivo para los QuadTrees, simplemente voy a dejarlos para el futuro cuando tenga algo más de experiencia y práctica en engines y por supuesto en c++.
Te dejo 10 monedas por tu gran ayuda, ultimamente la gente anda escatimándolas no sé por qué.

Ah y suerte en AOC

Haciendoles un par de cambios puedes hacer que sean compatibles las áreas con pantalla completa.

El quadtree, la verdad es para rizar el rizo, si mantienes las areas actuales, arreglandolas un poco.. no creo que tengas problemas.

Para que te hagas una idea, y por si te sirve en el futuro.. o a alguien que esté interesado.

En un módulo cualquiera (puedes crear una clase a parte, es lo que haria yo, así le implementas dentro todas las operaciones para trabajar con vectores):


Ahora, creas una clase que se llame QuadTreeNode:


Luego lo demás, crear un módulo que se llame QuadTree e implemente todo para manejarte con todos los nodos.

Para poder entender mejor el quadtree, primero has de entender como funciona la recursión. La recursión es llamar a un método, desde dentro del propio método.. o tener estructuras dentro de estructuras (así es como funciona realmente el quadtree, los hijos apuntan a la misma estructura o en este caso clase, de ese modo, es posible ramificarlo con la profundidad que querramos). Aquí tienes una imágen para que te lo puedas imaginar (lo de un pixel no le hagas caso, eso es relativo):


Si te fijás los nodos en negro se corresponden a las subdivisiones. Por ejemplo, en el segundo nivel, el cuarto nodo está en negro, y como está en la profundidad 2, al dividir todo en cuatro partes, la de abajo a la izquierda, está completamente en negra. En cambio en profundidad 4, el nodo que está en negro (el penultimo de izquierda a derecha), equivale al cuadrado de abajo a la derecha.

Si te fijas, es similar a las áreas, solo que el tamaño de cada area puede ser variable, y éste se ramifica de cuatro en cuatro. Además, si le añades una lista con los entities, puedes unificar tanto áreas como mapdata en una sola estructura. Por eso es muchisimo mejor el quadtree.

Fuera del tema de parra que me parece espectacular pero no logro cazarlo, para mejorar las areas, se me ocurre usar el cliente y su memoria.

No hablo de cargar todo el mapa cuando pasas, ya que si pasas y volves al anterior, mandaste datos sin usarlo.
Pero lo que podes hacer es, si pasas por el centro de ulla y tenes ciertos objetos estaticos, los almacenas. AL pasar la proxima vez, no vas a pedirle los datos de objetos que ya vistes, por lo tanto el paquete va a ser mucho menor.

Lo mejor si queres seria tener un gran array de mapas y posiciones.

type mapa
x as integer
y as integer
grhindex as integer
block as byte
objname as string
end type

public VMapa[1 to maxmapas] as mapa


cuando llegan los datos se los asignas a ese vector, y que el engine dibuje el vector en vez de trabajar con el paquete. El ultimo punto no estoy seguro si se cumple, pero lo demás es la optimizacion que podrías hacerle.

Franeg95 escribió:Fuera del tema de parra que me parece espectacular pero no logro cazarlo, para mejorar las areas, se me ocurre usar el cliente y su memoria.

No hablo de cargar todo el mapa cuando pasas, ya que si pasas y volves al anterior, mandaste datos sin usarlo.
Pero lo que podes hacer es, si pasas por el centro de ulla y tenes ciertos objetos estaticos, los almacenas. AL pasar la proxima vez, no vas a pedirle los datos de objetos que ya vistes, por lo tanto el paquete va a ser mucho menor.

Lo mejor si queres seria tener un gran array de mapas y posiciones.

type mapa
x as integer
y as integer
grhindex as integer
block as byte
objname as string
end type

public VMapa[1 to maxmapas] as mapa


cuando llegan los datos se los asignas a ese vector, y que el engine dibuje el vector en vez de trabajar con el paquete. El ultimo punto no estoy seguro si se cumple, pero lo demás es la optimizacion que podrías hacerle.

Te refieres a usar un caché? Los caches funcionan bien, pero no es la solución. De todos modos, no entiendo como el metodo que has propuesto va a optimizar. Estás guardando una estructura por mapa, como puedes guardar varios objetos por ejemplo de ese modo? Solo podrás guardar uno por mapa..

parra la idea q tire yo no esta tan lejos de la realidad eh y lo q dijo fran tampoco.

yo decia algo como esto (ya q estamos tirando codigos)



despues es simple, para meter un usuario por ejemplo



despues , para enviar los chars del area SOLO recorres el array este.



se entiende lo q qiero decir?

maTih.- escribió:...

Esa, ahora entendí por donde vas. Es una muy buena idea, pero si te fijas, yo tambien la tuve en cuenta (solo que no la expliqué tan a fondo).

Si te fijas, en la estructura del quadtree también hay una lista de entities. En esta lista se guardaria cualquier cosa, por ejemplo, un objeto, un character (npc o usuario), una particula, una luz, o un tile (o un grupo de tiles , y si, yo también consideraria los tiles como un entity y no como algo separado).

La unica diferencia es que estos entities, yo los manejaria desde el quadtree, en vez de por areas. En realidad, llegamos a la misma conclusión ambos. Solo que el quadtree es un poco más elaborado (y eficiente) a la hora de dividir el mapa en rangos