Bennu Game Development

Hola a todos:

Abro este hilo para mostrar mis avances con Tilemap Editor 2, un editor de mapas tileados que desarrollé hace años, y que finalmente me he puesto a crear casi de cero para arreglar los numerosos bugs y problemas de rendimiento que tenía en su primera versión.

Aquí voy a poner un enlace a la última versión que suba, pero podeis verla en su contexto a lo largo del hilo.
Ultima beta de Tilemap Editor 2 (http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3532)
Versión Linux (http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3533)

A continuación os dejo con... mi yo de hace unos meses, iniciando el hilo. Yo me vuelvo al futuro a seguir desarrollando.

========================================================================================================
Como sabeis, soy el "pesao" del motor de scroll tileado, y es que a día de hoy es el protagonista del 80% de mis creaciones. Cuando no es un plataformas, me sirve para crear objetos en un modo7, o para diseñar niveles. Así que para mi, una buena herramienta para editar mapas de tiles es fundamental.
Hay varios por internet, desde luego, pero usan formatos propietarios, o hacen cosas como comprimir la información o incrustar las imágenes en el fichero, y en formato BMP. También se dijo que había cierto IDE que tendría su propio generador de mapas, con generador de código para la carga y descarga de los ficheros generados, pero no hay nada a día de hoy.

Así que me he puesto a hacer el mío propio. Hace ya muchos años, unos 10 más o menos, creé uno en Fenix que... digamos que o me tiraba meses de debug, o trabajaba con uno de los programas más lentos y exigentes en recursos que recuerdo desde la salida del "Crysis".
Ahora estoy trabajando en BennuGD, con mucha más experiencia encima, habiendo conocido varias librerías y diferentes lenguajes, por lo que el lenguaje está bastante más ordenado.

La idea es la misma de entonces: un editor que me permita editar varios mapas de tiles al mismo tiempo, usando de forma nativa el formato que creé hace ya tanto tiempo, y la última evolución de aquel motor que tan buenos resultados ha dado en varios juegos de Wiz (y si llegase a sacar aquel motor en el que estuve trabajando, un híbrido entre pintado a mapa y scroll de bennuGD, pues probar su mejora de rendimiento).

De momento el programa está en pañales. Apenas es capaz de abrir y guardar mapas, y de crear la interfaz con dos o tres funciones básicas. Las principales diferencias con la primera versión, es que ahora hay una lista con las capas disponibles en el mapa, y que para cambiar los paneles laterales se usan unos botones colocados justo encima de estos (así no hay que andar arrastrando el ratón a todo lo ancho de la pantalla). Internamente usa también un sistema propio para generar el IDE (no, no lo voy a liberar, porque tampoco lo diseñé tan a conciencia). Y también estará disponible en varios idiomas, ya que con la "clase" que diseñé de "listas de strings", crear un idioma nuevo es tan sencillo como cargar un fichero de texto u otro.
Os pongo una captura para que lo veais. No sabía si abrir el hilo, sobre todo porque gafo el proyecto, pero el foro anda tan desangelado, que por darle algo de vidilla...

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3442)

¡Qué cosas pasan! Estoy intentando que se cree un nuevo mapa, y una de las cosas que había dejado para el final era añadir el motor de scroll tileado, para que se muestren los tiles y todo eso (me había centrado en abrir el fichero y cargar el mapa, y las opciones de cerrar y descargar).
Pues resulta que iba a añadirle la opción de zoom, una modificación que hice para el anterior programa, y leyendo el código veo que genero tres variables locales (X2 e Y2, que son las coordenadas dentro del scroll, y un INT ptr_sig, que se suponía que es un puntero al siguiente ID de proceso Tile), y pensando cómo eliminarla se me ha ocurrido un método para aplicar algo que me dijo Splinter hace mucho tiempo: evitar que el proceso de control acceda a las variables locales de los procesos tile (porque decía que según algunas pruebas el acceso a este tipo de variables era el ¿doble? de lento que el de otros tipos.

Total, que estoy reescribiendo el motor de otra manera, a ver si así es más rápido. Concretamente, creo una lista de nodos con los valores de cada tile (posición y gráfico), el ID de un proceso Tile, y a ese tile le paso un puntero directo a ese nodo. Obviamente, los procesos tile son creados y eliminados a la vez que sus propios nodos, por lo que no debería haber conflictos.
También estoy mirando si puedo reducir cálculos en el cambio de tile, que es donde se me cae el rendimiento del motor. Lo mismo cnsigo que vaya el Echo más fluido :P

Vale, pues he hecho lo que me proponía: eliminar la variable local y, de paso, evitar que el proceso de control acceda a variables locales, y estos son los resultados:

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3444)

No sé si es porque ahora tiene que lidiar con una lista enlazada (aunque he intentado evitar los alloc/free en todo lo posible, y recorrer los primeros nodos de la lista varias veces por frame), o que realmente la escritura en variables locales no tiene ningún impacto (al menos, en este caso), pero el nuevo motor de scroll tileado se ha mostrado ligeramente por debajo del anterior motor.
La prueba realizada ha sido hacer que el scroll se mueva solo, con un set_fps(0,0), y usar un fichero .bat para ejecutar ambos DCBs de forma simultánea con la misma versión de BennuGD. Luego intentar sincronizar ambas ventanas de forma visual (al intentar arrastrar una ventana, esta se pausa) y luego esperar a ver qué scroll recorre más distancia con el tiempo (los FPS en pantalla son simplemente orientativos).

O sea, que he perdido el tiempo ^^U
No me hace ninguna gracia tener una variable local que sólo va a usar un único proceso, y no sé si hacer la prueba con una variable pública, pero el rendimiento es importante en este proyecto (no creo que tenga los problemas de la versión 1, pero ya no me fio ni un pelo). Desde luego, este nuevo motor es más elegante algoritmicamente hablando, pero no puedo usarlo en Wiz si voy a perder 1fps.

Aun estoy en caliente, y no tengo las ideas muy claras, así que intentaré decidir mañana, pero estoy abierto a sugerencias.

jaja, bueno, al menos compartiste la informacion con el foro, y todos aprendimos algo

Quote from: Drumpi on March 07, 2016, 08:24:27 PM
Vale, pues he hecho lo que me proponía: eliminar la variable local y, de paso, evitar que el proceso de control acceda a variables locales, y estos son los resultados:

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3444)

No sé si es porque ahora tiene que lidiar con una lista enlazada (aunque he intentado evitar los alloc/free en todo lo posible, y recorrer los primeros nodos de la lista varias veces por frame), o que realmente la escritura en variables locales no tiene ningún impacto (al menos, en este caso), pero el nuevo motor de scroll tileado se ha mostrado ligeramente por debajo del anterior motor.
La prueba realizada ha sido hacer que el scroll se mueva solo, con un set_fps(0,0), y usar un fichero .bat para ejecutar ambos DCBs de forma simultánea con la misma versión de BennuGD. Luego intentar sincronizar ambas ventanas de forma visual (al intentar arrastrar una ventana, esta se pausa) y luego esperar a ver qué scroll recorre más distancia con el tiempo (los FPS en pantalla son simplemente orientativos).

O sea, que he perdido el tiempo ^^U
No me hace ninguna gracia tener una variable local que sólo va a usar un único proceso, y no sé si hacer la prueba con una variable pública, pero el rendimiento es importante en este proyecto (no creo que tenga los problemas de la versión 1, pero ya no me fio ni un pelo). Desde luego, este nuevo motor es más elegante algoritmicamente hablando, pero no puedo usarlo en Wiz si voy a perder 1fps.

Aun estoy en caliente, y no tengo las ideas muy claras, así que intentaré decidir mañana, pero estoy abierto a sugerencias.

si mostraras un diff de los cambios, sin necesidad de compartir el codigo, podriamos tener una idea mas clara de que esta pasando.

No, os puedo subir directamente ambos códigos si quereis, de momento son de libre uso. De hecho, el motor "antiguo" ya se publicó en su día. Dadme unas horas y os pongo un paquete para que lo probeis.

EDIT: Pues ya os he hecho un paquetito. Tiene dos carpetas, una con el motor antiguo (incluye los ficheros del motor, un código de ejemplo, los recursos necesarios, y un .bat para compilarlo y ejecutarlo de forma independiente, el cual debeis modificar la primera línea para que apunte a la carpeta donde tengais guardado los binarios de Bennu), y otra con el nuevo.
Fuera de esas carpetas teneis un .bat para ejecutar ambos ejemplos a la vez (también teneis que cambiar la primera línea). Se me ha pasado añadir un WRITE al código del segundo ejemplo para poder identificar qué ventana es cuál, pero eso sabreis añadírselo ¿no? :D Siento que el código de ejemplo esté tan sucio, pero lo subía ahora o pasado mañana ^^U

Bueno, mientras decidís si lo mirais o no, ya que el código está bien encapsulado, yo sigo avanzando.
He podido añadir el motor a la creación del nuevo mapa, y parece que iba bien. En realidad no lo sé porque no hay procesos tile, no puedo modificar el mapa, ni puedo moverlo, sólo sé que se crea el proceso de control del scroll y ya ^^U
Pero, la creación del scroll se hacía en las funciones que añadían nodos a la lista de mapas, y eso debía hacerse fuera. Me di cuenta al cargar mapa, cuya función pedía el nodo ya creado, así que subí un nivel la llamada a start_tscroll y... segmentation fault, o como le gusta decir a mi Windows: "El programa ha ejecutado una operación no válida y debe cerrarse". A ver si esta tarde consigo no quedarme dormido y veo en qué línea me quedé dormido al escribir el código :D :D :D
Cuando eso funcione, y pruebe la carga de mapas, ya tendré lo más básico del funcionamiento del programa: abrir, cerrar y nuevo. Faltaría guardar, pero vamos paso a paso, porque el cierre también incluye el guardar si ha habido modificaciones al mapa (y al crearse nuevo, se activa el flag de "modificado").
Luego vendría el mover el scroll tileado, y luego no sé si empezar con las herramientas de edición (para poder modificar los tiles y ver que todo funciona correctamente) o con la lista de mapas abiertos, para poder seleccionar el mapa en edición y probar el cierre de mapas de forma individual.

53 ficheros de código llevo ya :D

lo miro y te digo si se me ocurre algo.

primera sugerencia... intenta reducir el uso de funciones en las iteraciones... las funciones son casi tan costosas como los procesos, son basicamente procesos un poco mas livianos... pero se crean como un proceso, se crea una instancia, se crea un area de variables, una pila, etc... intenta usar #define en lugar de funciones donde te sea posible

Mmmm, interesante. De hecho, estaba usando funciones en lugar de procesos porque precisamente se suponía que eran más rápidas de crear.
Me vendría genial para sustituir, de entrada, la función de obtener tile, que se llama tantas veces como tiles caben en pantalla (no sé cómo funcona #define, lo he estado mirando en la wiki, pero no dice si se pueden declarar variables privadas o devolver datos, aunque supongo que se le pueden pasar punteros).

Bueno, pues volviendo a lo de ayer, llevaba 3 horas buscando el fallo, y me había puesto a escribir un tochaco gordo para explicaros mi problema, porque parecía que "mágicamente" los datos del mapa de tiles habían desaparecido al salir de una función, y cuando llevaba 40 líneas y 30 minutos escribiendo, me ha venido la inspiración divina y la he resuelto (había confundido una estructura fija de datos para la interfaz, con un puntero a los datos que se estaban modificando ^^U).
He ahí la importancia de buscar ayuda externa: a veces símplemente escribiéndolo resuleves el problema :D :D :D

o puedes tambien usar funciones locales... recuerdas que hace un tiempo implemente un call a saltos a etiquetas locales? si usas eso ganaras mucha velocidad... pero no vas a tener variables ni argumentos, simplemente comparte las variables del proceso.

aca te dejo un ejemplo


import "mod_say";

global
    int a, i;

begin
    a = 1;
    say(a);

    for (i = 0; i < 10; i++)
        call inc_a;
        say(a);
    end
    return;

inc_a:
    a = a + 1 ;
    return;

end


Vaya, lo he leido antes en el otro hilo ^^U
Sí, eso es bastante interesante, especialmente porque, en el motor antiguo, la búsqueda de tiles en el scroll, usa las mismas variables que la función.

Pero llevaba tiempo intentando escribir en Bennu al estilo C (hasta que me puse con Java, y mezclé un poco de su estilo :P ) por aquello de intentar hacerme menos dramático el salto si me tengo que poner con un lenguaje más "profesional" :D :D :D
Me miraré esto y lo de los #define y haré pruebas, a ver qué me da mejor rendimiento y se adapta más a mi estilo. Ya digo, si puedo reducir a la mitad el tiempo que tarda el motor v3.2 en refrescar la pantalla entera, el Echo iría fluido todo el tiempo y se acabarían las quejas (aunque aun tengo que terminar el anterior intento de scroll tileado, que no sé por qué falla).

EDIT: Vale, con un testeo rápido de las local routines, sustituyendo tscroll_obtener_tile por una de estas, he obtenido resultados no concluyentes. Sí, ha sido rápido, pero he comprobado que con el script que tenía para ejecutar dos programas a la vez, el segundo que ejecuto consigue un rendimiento de 10FPS más que el primero, por lo que no es una prueba muy fiable. Parece (recalco lo de parece) que cuando ejecuto la versión con rutina local la segunda, el rendimiento es ligeramente superior, entre 10 y 20 FPS, pero no puedo hacer una prueba que me de un resultado fiable, o al menos, yo no sé. La diferencia es tan pequeña que si intento ejecutarlos de forma individual, va a ser mi apreciación de las lecturas de la variable FPS la que determine cuál es más rápida, y no es un valor objetivo.
Seguiré probando cuando despeje de pestañas el notepad++ y mi cabeza ^^U

Bueno, una semana después he retomado la programación del editor. No, no he podido hacer más pruebas de rendimiento de los motores de scroll porque no se me ha ocurrido ningún procedimiento que me de valores objetivos.

A pesar de mi bajo estado de forma mental, he "activado" la función de abrir mapas. Tenía previsto dedicarle toda la tarde, pero mira por donde, ¡ha funcionado a la primera! (Drumpi debe haber salido de Semana Santa de forma prematura :D ). He podido cargar el mapa de un proyecto bastante reciente, que no se ha liberado ("proyecto Placton", para más señas) y lo ha leido y mostrado perfectamente, tanto usando un "tamaño de tile" de 32x32, como el formato original de 24x24 (de la primera forma, se mantienen los tiles pero con una separación).
Tengo que seguir haciendo pruebas, a ver si me carga todos los formatos soportados, y los mapas de más de 1 capa.

Pero he aquí la buena noticia: he cargado uno de los mapas del Echo, en concreto, la del segundo nivel, la de "2012: Alien Invasion" (sí, ese nivel que tiene 22x893 tiles, y que con la anterior versión del programa iba a 1 frame cada 5 segundos) ¡Y VA SIN RALENTIZACIONES! ¡¡¡¡WIIIIIIIIIII!!!! Bueno, vale, pega algún tirón, no va 100% suave, pero eso es más por la falta de sincronización entre el intérprete y la pantalla que por falta de potencia (no, no he activado el V_Sync, ni hay planes de ello :P ).
Lo importante es que la cosa promete, y parece seguro que por fin voy a poder editar los nuevos mapas del Echo sin tener que preocuparme de que el programa vaya a paso de tortuga :)

Ahora estoy liado con la lista lateral, que indica los mapas cargados. Tengo que conseguir que se muestren, y que se puedan seleccionar, porque mi siguiente paso es activar el cierre individual de un mapa, y luego poder grabar el mapa. Con eso ya podemos empezar con las herramientas de edición (por fin).

Bueno, pues le sigo dando caña. Ya tengo una lista que muestra los últimos mapas cargados. Aun no se puede desplazar, y seleccionar un mapa no tiene ningún efecto... pero al menos los botones (más bien switches) responden al ratón.

Lo que pasa es que hoy he tenido que solucionar uno de esos bugs que aparecen de pronto sin saber por qué. Me había planteado dejarlo, pero ante la posibilidad de que desaparezca, o de que al aumentar el código hacer un seguimiento del mismo se volviera imposible (y como estoy formateando unos disquetes que han aparecido en un cajón), me he puesto a buscarlo y solucionarlo.
Tras una hora y pico, me he dado cuenta que era una variable sin inicializar. Una estructura creada mediante alloc, que, supuestamente, no era necesario inicializar porque lo primero que se hace con ella es añadirle los valores iniciales (en este caso, del scroll tileado)... pero da la casualidad de que había una variable que no se inicializaba, que era precisamente la lista de procesos tile, y daba una excepción de que el proceso 256 no existía.
Ya está solucionado el tema, y he resuelto un par de pequeños bugs extra que han aparecido por el camino. Ya puedo abrir más de 20 mapas de forma simultánea sin que se me rompa el ordenador :D

Os dejo una capturita:
(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3448)

He tenido un parón con el programa. No me preguntéis qué ha pasado porque ahora mismo ni yo me acuerdo ^^U
No sé si será la pasada Game Jam, seguido de unos días de esquí (uno de los dos periodos anuales en los que hago ejercicio :P ) y quedarme tranquilo en casa con la Feria, pero llevo un par de días que no paro.

He conseguido terminar la lista lateral de mapas abiertos. A lo que ya tenía se le ha sumado que ya se puede hacer scroll por la lista usando los botones, que aparezca el nombre de los mapas abiertos (no sólo la de los mapas nuevos), y que se actualicen si se guardan con otro nombre.
Que esa es otra, creía que ya había hecho las funciones para guardar los mapas, y resulta que no, que lo que tenía hecho eran las pruebas sueltas, sin integrarlo en el programa. Y eso he hecho... parcialmente. El botón Guardar Como... ya funciona y me permite guardar el mapa seleccionado en cualquiera de los tres formatos soportados (TMF, TPR y TMG, siglas de TileMap File, TileMap Project y TileMap Graph), creo... no he probado los TPR ni los TMG, ahora que lo pienso, pero es código reciclado, y no debería fallar, pese a varios bugs que he resuelto.

Bueno, el caso es que poco a poco la cosa avanza. Quiero terminar las funciones de guardado antes de ponerme con las de cerrar, porque si el mapa ha sido modificado, tras la ventana de aviso debería activarse la función de Guardar o Guardar Como según si ya se había guardado anteriormente o no. Con eso, las funciones del menú File (o Archivo, si hablamos en español) estarán terminadas y empezaré con las herramientas básicas del menú Edición, que tendré que conjugar con las de Mapa (añadir y quitar filas, columnas y capas son funciones más prioritarias incluso que la de relleno o selección).

Bueno, he hecho un nuevo avance significativo.
La opción de cerrar un mapa ya es una posibilidad, e incluso te avisa si no se ha guardado previamente (no abre la ventana de guardado, pero quiero mantener las cosas simples, porque aun me queda muchísimo por hacer).
También la ventana de guardar como funciona, con aviso de sobreescritura (y como mejora respecto a la primera versión del programa, es capaz de memorizar la ruta de dónde se guardó la última vez). Y la función de guardar está casi completa, falta por implementar la parte de detectar si el fichero está comprimido o no... aunque tampoco estoy dando la posibilidad de hacerlo ^^U. El guardar, si detecta que nunca se ha guardado el mapa llama a la función guardar como.

Y estos dos últimos días me he puesto con la ventana de selección de tile, necesaria para la mitad de las funciones de edición. Es raro que, con lo grande que es ya el programa, y con lo que me ralentizo buscando nombres de variables y cosas que ya he programado, esta ventana la haya escrito tan rápida y de forma tan sencilla. Me he permitido incluso el lujo de reescalar los tiles para que quepan en 32x32 pixels.

Y ya, de paso, he probado a ver si funcionan los mapas de dos capas con un viejo juego que empecé (siempre uso los mapas de este juego para probarlo casi todo: el scroll tileado, los motores de los nuevos juegos...) y va de miedo. Bueno, si mirais la captura, vereis que hay que hacerle un "retoquito" a la asignación de Zs a los procesos del scroll tileado, pero funcionar funcionan ^^U

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3457)

me gusta.

no me disgusta.

Lo siento, pero esta vez no hay foto.
He estado una semana visitando mis parientes en Cartagena, y el ordenador lo he tocado porque tenía que sacar el cargador del móvil de la maleta :D

A pesar de eso, la ventana de selección de tile, y la ventana de selección de botón del ratón (recordemos que ponemos asignar las herramientas a cualquiera de los tres botones) ya son una realidad. He cambiado la selección de botón añadiendo botones a la ventana, he creido que era más fácil de entender que como se hacía antes, que detectaba qué botón se pulsaba de forma automática.

Con ambas cosas, ya sólo quedaba enviar esa información a la herramienta de edición... pero claro, también había que crear de forma interna una serie de funciones que crearan, almacenaran y borrasen los procesos que hacen las veces de dichas herramientas. Suena complejo, pero no lo es tanto (añade más complejidad al editor, que ya lo es de por sí, pero mantengo las cosas modulares).
Hecho lo cual... ¡YA TENGO HERRAMIENTAS DE EDICIÓN! De momento he hecho las herramientas para poner tile, otra para poner tiles mientras se mantenga el botón pulsado, y la de borrar (que es la misma que la anterior, pero con el tile nº 0 y otro icono). Ya puedo editar mapas y guardarlos, aunque sólo puedo afectar a la primera capa de los mapas (la selección de la capa de edición está aun pendiente).

Mis siguientes pasos son:
- Trabajar con la lista de acceso rápido a los tiles recientes: como en la versión anterior, en la parte de abajo se almacena una lista con los últimos tiles que se han ido seleccionando, para que al pulsar el correspondiente botón numérico de la parte superior del teclado, este se pueda asignar a cualquiera de las herramientas que tenemos asignadas a los botones del ratón, así no hay que abrir y buscar el tile que necesitamos cada poco tiempo. Aun no sé si emplear el mismo algoritmo, de borrar el que más tiempo hace que no se ha usado, o uno nuevo que borre el que menos veces se ha seleccionado (aunque eso significa que debo guardar un valor por cada tile que se use, y por cada mapa abierto :S)
- Actualizar los FPG de los tiles seleccionados: si se cambia de mapa, se cambia de FPG con los tiles que se van a usar. En las herramientas del ratón, la línea inferior tiene un clon del tile que está asignado, por lo que si se cambia de mapa y FPG, los cambios no se reflejan. Tengo que modificarlos "manualmente".
- Terminar con las herramientas disponibles en la versión 1 (mover cámara, rellenar, desplazar mapa...) y añadir las herramientas de modificación de mapa (añadir/quitar fila, columna y capa)
- Deshacer: es una herramienta que se quedó pendiente en la versión 1, y por la que su falta me ha hecho perder unas pocas horas de trabajo, al usar la herramienta de relleno donde no tocaba. Aun le estoy dando vueltas si debo incluirlo en la información de los mapas, o si debo crear una lista aparte. La segunda es la más fácil de implementar, pero es otro módulo que hay que tener en cuenta a la hora crear/cerrar mapas. Tampoco sé sí implementarla en un botón de la interfaz, o si usarla con un acceso rápido de teclado (¿backspace o ctrl+z?).

Bueno, me voy a comer, que ya es la hora.

Bueno, a pesar del tiempo que pueda parecer que ha pasado, apenas le he dedicado tres tardes más al proyecto. Debería seguir escribiendo código, pero me encuentro en uno de esos puntos en el que debo pasar a una nueva tarea, y esta es gorda, y como no lo tenía planificado, toca parar a pensar antes de seguir (y suele pasar de "pausa" a "hasta mañana o cuando pueda retomarlo" ^^U). ¡La planificación es importante, chicos! :D

Lo bueno es que el tiempo ha cundido. Para empezar he resuelto un bug que tenía con la herramienta de poner tiles, que daba un crash que no se había detectado hasta entonces. Lo que pasaba es que la función de cambiar tile en el mapa de tiles venía de un fichero que estaba reciclando de la versión 1 del programa. Creía que lo había adaptado, pero resulta que no, que seguía en "modo Fenix", y como el editor de tiles actual sólo edita los mapas internamente en tipo de dato WORD, en cuanto cargaba un mapa de tipo BYTE o INT el put escribía en una dirección de memoria no inicializada y ¡catapún! ventanazo de Windows. Total, que he cogido el fichero, lo he re-identado, limpiado y readaptado (casi 500 líneas) y ya funciona bien (y tengo listas para usar las funciones que añaden una fila, columna o capa al final del mapa).

Otra de las cosas que he hecho ha sido lo de actualizar los tiles seleccionados para las herramientas de edición cuando se cambiaba de mapa. No ha sido tan traumático como pensaba, y me ha sido útil para lo siguiente.

El acceso rápido a los tiles seleccionados recientemente ya es un hecho. Sí, los que aparecen en la parte inferior. Además de añadirse los tiles (usando un algoritmo de "sustituye al que más tiempo lleve sin seleccionarse") y actualizarse al cambiar de mapa seleccionado, se pueden modificar manualmente al hacer clic sobre ellos. También se ha hecho que al pulsar los botones numéricos, aparezca una ventana para seleccionar a qué botón del ratón se lo queremos asignar, pero a diferencia de la primera versión, en esta ocasión primero comprueba si hay alguna herramienta seleccionada que use tiles: si no los hay, cancela la operación de forma automática, si sólo hay una, la asigna de forma inmediata, y sólo pregunta si hay más de una herramienta. Podeis verlo en la foto adjunta.

De paso, he hecho la herramienta de desplazamiento de la cámara con ratón. Es un efecto curioso que, cuando la asignas a dos botones y usas ambos a la vez, el scroll va más rápido :D Lo dejo como una feature.
Lo que ya no sé es si el sistema que tengo para asignar estas herramientas es eficiente o no, ya que debe pasar por unas 5 capas antes de poder ser usadas: al hacer clic al botón, se activa el gestor de eventos, este llama a una función que se encarga de recabar datos llamando a diversas ventanas (selección de botón del ratón, selección de tile...), con esos datos se llama a una función de asignación de herramientas a los botones que es la que pone los iconos en la zona inferior derecha de la interfaz, y la que invoca al proceso que es la herramienta en sí, y almacena su ID en la struct del ratón.
Son muchas capas, pero mantiene el gestor de eventos sencillo, separa más o menos la capa de interfaz de la lógica, y mantiene las funciones del ratón aisladas del resto de componentes.

Ahora debo centrarme en la herramienta de relleno, que no sé si usar el mismo algoritmo recursivo de la versión 1 (por cada tile, generar tres procesos que comprueben los tiles adyacentes, salvo desde el que se invocó) o buscar un algoritmo más eficiente. Desde luego, con todo lo lenta que era la v1, el rellenado se efectuaba veloz como el rayo, más que la carga (eso si que era un algoritmo pesado de narices). Y por eso estoy en "pausa".
Aun le estoy dando vueltas a la herramienta de deshacer. Más o menos tengo claro que usaré una nueva lista, que constará de "pasos" y "elementos" (cada paso es un cambio de tile, salvo para la herramienta de relleno, que usa un "paso" con un "elemento" por cada tile que se cambie, así se puede ir deshaciendo paso a paso el "dibujar tiles continuos", pero todo el rellenado de golpe). Lo que no me queda claro es cómo activar la función "deshacer", si mediante un botón en la interfaz, mediante la tecla Z o con la combinación ctrl+Z.

Cualquier sugerencia es bienvenida.

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3463)

PD: Ya queda poco para lanzar una beta, con esas dos cosas, un par de herramientas más, y la asignación de Z a los tiles, estaré en el mismo punto o casi que en el Tilemap Editor v1.

Antes lo digo, antes me estalla en la cara.
He implementado el código más básico de relleno (un algoritmo recursivo que se expande en las 4 direcciones, salvo de la que viene), que era el que usaba en la versión 1 y, al principio ha funcionado bien, lo hace bastante rápido y sin fallos.
Pero en cuanto he intentado rellenar un mapa de 1000x1000 (y luego uno de 400x400) para probar la velocidad, me ha salido la temida ventanita de error de Windows. Gracias a M$, he tenido que estar media hora buscando el código de error, para averiguar lo que ya sabía, y es que he tenido un fallo de desbordamiento de pila. Vamos, que me ha petado por falta de memoria (ahora es cuando teneis que ir al final y leer la frase de mi firma).

O sea, que tengo que prescindir del algoritmo sencillo y buscar otro. Ya estoy viendo cómo funciona el de rellenado por líneas (en cuanto traduzca el código, lo entenderé, porque no hay nadie que lo explique bien :S), y pensando en otros algoritmos alternativos usando un mapa de máscara y comprobaciones a base de barridos diagonales:
repetir mientras haya cambios en el mapa
   por cada fila
      por cada columna
         si el tile está marcado para cambio, comprobar los 4 adyacentes
      end
   end
end

No tengo claro cuántas pasadas serán necesarias, ni si tendría que hacer las pasadas cambiando la dirección cada vez, y lo más importante, si este algoritmo es más o menos eficiente que el de líneas (por número de instrucciones a ejecutar, iteraciones, y no usar una lista dinámica) porque creo que por memoria no será (usaría un mapa con el mismo ancho y alto que el original con datos tipo byte, porque usar tipo bit sería añadir más instrucciones para buscar el bit concreto).
La verdad es que el algoritmo me gusta, quizás lo implemente sólo por diversión y luego trate de probar con otros... aunque me conozco y diré "si funciona, así se queda... y así tiene un toque mío".

En fin, mañana veremos.

Bueno, dicho y hecho. Aunque ha costado bastante más trabajo del deseado (pero menos del que me esperaba), he conseguido implementar el algoritmo con éxito ¿Y sabeis qué? Funciona de miedo.
A ver, que no es el algoritmo más eficiente del mundo, y que hace unas cuantas comprobaciones de más, y cuando hay que rellenar un "pasillo" que va de suroeste a noreste o viceversa es lento, pero he conseguido que rellene un mapa de 1000x1000 tiles, con algunos espacios intercalados, en menos de un cuarto de segundo (es casi inmediato, no podría dar un tiempo ni siquiera aproximado de lo poco que hay).
Pero mira, a pesar de crear casi una copia del mapa (para dicho mapa de tiles, he necesitado 1000x1000 bytes de memoria, es decir 1MB) porque no puedo crear un array de bits sin complicar la lógica, y de que hace algunas comprobaciones de más, en condiciones favorables es más rápido y consume menos espacio en memoria que el relleno por líneas (es decir, en caso de tener pasillos diagonales noroeste-sureste, y pintar más de la mitad del mapa), pero dudo mucho que se den dichas condiciones, y no tengo la cabeza para ponerme a hacer matemáticas estadísticas :D :D :D Podría haber añadido un bucle más para que compruebe las diagonales conflictivas y sería aun más rápido, pero no quiero complicar demasiado el código y no merece la pena.

En fin, que ando en plan loco porque estoy con la cabeza a punto de reventar de tanto cálculo y debug (ha sido una sesión corta pero intensa), así que os subo el algoritmo por si teneis curiosidad. Espero que esté lo suficientemente límpio y explicado como para entenderlo. No, no se puede usar fuera del editor de mapas de tiles (a menos que cambieis obtener_tile y modificar_tile por funciones GET y PUT para mapas), es sólo para que veais el concepto.
Y sí, le he añadido condiciones de uso. Dudo que el algoritmo valga la pena, pero con cosas más tontas la gente ha hecho fortuna, así que lo pongo por si acaso (en resumen, podeis usarlo mientras no hagais dinero con él y me mencioneis en algún lado :P).

¡¡Necesito dormir!!

felicitaciones!

Incomparable la sensación de tildar como hecha una tarea difícil de la lista de pendientes

En cuanto tenga un hueco lo pruebo, que le tengo ganas. Tiene muy buena pinta!!!

Ulthar, espero que te refieras al algoritmo y no al programa, porque al editor aun le falta unos cuantos días de trabajo para sacar una primera beta :D :D :D

Y hablando de días de trabajo, llevo dos jornadas de programación críticas. Se supone que en el foro soy uno de los veteranos y debo daros consejos, bueno, pues aquí van los dos consejos de la semana:
- Planificad vuestro código antes de empezar a escribir.
- Seguid a rajatabla el plan de programación.
¿Y por qué digo esto? pues porque yo no los he seguido y por eso me ha pasado lo que os voy a contar. ¡Vaya veterano estoy hecho! :D

Resuelto el problema de la herramienta de relleno (o al menos, implementada con un mínimo de calidad :P ), he pasado a la siguiente tarea, que era la de implementar los botones de zoom. En realidad, el zoom estaba planificado, y estaba prevista su implementación el primer día que se añadió el scroll tileado al motor, hace ya... pfffffff. ¿Qué pasó? Pues que me apetecía darle caña a otras partes del código más interesantes, como la lista de mapas, las herramientas de fichero o las de edición, y lo fuí dejando...
Hoy me he encontrado con que el zoom debía formar parte de más de una herramienta porque es algo asociado a las variables globales del sistema (o sea, que el zoom es común a todos los mapas, y hay que tenerlo en cuenta a la hora de abrir un mapa, crearlo, o editarlo). Así que hoy me he visto cambiando el motor de scroll tileado para que soporte el zoom, y buscando todas las referencias a la estructura TScroll.

Por fortuna, los cambios no afectan a nada más allá que a lo que hace referencia al ancho o alto de tile, he preferido no cambiar la resolución del movimiento de la cámara para no liarla más (y de paso tener un scroll suave, ya que no va a haber ningún elemento interno dentro del scroll tileado que haga uso de su posición). Vamos, que lo que más problemas ha traido han sido precisamente las herramientas de edición (poner tile, poner tile continuo, borrar tile y la herramienta de relleno), que tenía que reescalar el tile de vista previa y la referencia a la posición en la que se encuentra respecto al scroll.

Pero bueno, parece que la cosa funciona muy bien (salvo un pequeño glitch en el primer frame después del cambio, que se desplaza el mapa y aun no sé por qué). De hecho, podeis ver el efecto de usar el zoom en la imágen que adjunto ¿Recordais que dije que usaba los mapas del Echo y el FenixLand como base para probar todo? Pues ahí teneis una vista global de parte del nivel 3 del Echo, para aquellos avezados que hayan sido capaces de llegar tan lejos.

En mis siguientes pasos, antes de que se me olvide nada más, será:
- Ordenar la z de los mapas... es decir, asignarles una z a cada scroll tileado, porque de momento todos los tiles se dibujan con Z = 0 (salvo las capas traseras, que se dibujan con z = capa * 2). Es un poco molesto depurar con el panel lateral de edición por detrás de los mapas abiertos :D
- Cambiar el icono del puntero que indica qué tile está asignado a la herramienta del botón izquierdo, porque no se actualiza al cambiar de mapa seleccionado.
- Darle funcionalidad a los botones de desplazar el mapa.
- Ir pensando cómo implementar el cambio de Z en los mapas, la función de semitransparencia, y la herramienta del cuentagotas (que no sé si asignarlo como una herramienta más, con un botón en el área de edición, o usando shift + clic, como se hacía en DIV).
- ¡Ah! Que no se olvide, tengo que ir implementando las listas para deshacer cambios, aunque aun no sepa cómo ejecutar deshacer y rehacer.

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3479)

Quote from: Drumpi on May 14, 2016, 06:12:26 PM
Ulthar, espero que te refieras al algoritmo y no al programa, porque al editor aun le falta unos cuantos días de trabajo para sacar una primera beta :D :D :D

Ya, ya me di cuenta :D

Sigo diciendo lo mismo, tiene pintaza espectacular.

Es increible que cosas tan sencillas se acaben complicando tanto, y que cosas realmente complicadas se simplifiquen en poquísimo código.
Quiero decir que, cuando quise implementar algo tan sencillo como "modifica el tile (x,y) por el valor n", tuve que crear una ventana de selección de botón, un sistema de almacenamiento de la función en algún botón del ratón, un sistema para ejecutar, controlar y eliminar el proceso de la función, y añadir un evento al controlador de los mismos (y al botón que lo invoca) para poner en marcha todo un proceso que trabaja en 5 niveles diferentes del editor.
Y hoy, en el segundo día, he conseguido implementar todo un sistema que permite deshacer y rehacer tantos cambios como se quiera en un mapa del tamaño del desierto del Scret of Evermore.

Al final he optado por crear la lista de elementos (ya sabeis, deshacer divide la lista en pasos, que es lo que se modifica en un clic, y en elementos, que son todos los tiles que se modifican a la vez con ese clic) usando nodos enlazados de forma simple, y añadir a los pasos un puntero extra que apunta en todo momento al último elemento de la lista. No es lo más eficiente en memoria, pero sí en velocidad y estabilidad para el sistema, que es lo que más me interesaba.
Lo he estado testeando con algo tan "gordo" como la herramienta de relleno, y he conseguido darle suficiente eficiencia para que sólo almacene los tiles que se cambian (ahora debo trasladarlo a otras herramientas, que no hacen dicha comprobación), y he comprobado que un mapa de 20x20 tarda como un cuarto de segundo en rellenar... porque tengo activadas las lineas de debug que me dicen, mediante "say", lo que se va almacenando en cada momento en la lista de deshacer, y eso ralentiza un montón el programa :D :D :D En cuanto vea que funciona, desactivaré las llamadas, y esto volará a velocidades supersónicas.
Os he hecho una secuencia de imágenes para que os hagais una idea del funcionamiento. No sé crear GIFs animados, así que tendreis que desplazar la página mientras parpadeais :D

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3484)
(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3486)
(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3488)
(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3490)
(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3492)
(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3494)

De momento, para deshacer debe pulsarse la tecla backspace (borrar), y para rehacer shift_izquierdo + backspace. Más adelante implementaré los botones (que no sé dónde ponerlos) y que se pueda usar shift derecho (¿alguien usa shift derecho?).
Y ya, pues me he puesto con la tontería y he implementado las funciones que desplazan todo el mapa hacia arriba y hacia abajo siempre que haya espacio libre. Me faltan a los lados, pero son ya las dos y media de la madrugada y no son horas. Y sí, funcionan al pulsar el botón.

Lo gracioso es que en el último mensaje, todo esto eran cosas "secundarias", que quería dejar para más adelante hasta que le diera una vuelta porque era de lo más complicado de implementar, pero ya están hechas.
Así que sí, debería ponerme con el bug del icono del cursor, y ordenar de una vez las Z de los mapas (e incluso he estado pensando en una función para intercambiar posiciones de los mapas en la lista, y simplificar la asignación de Z por parte del usuario a "más arriba en la lista = más adelante en el editor", en lugar de valores a mano o de andar arrastrando botones de una posición a otra de una lista virtual).
Lo de transparentar los mapas también debería irlo pensando, pero tengo que hacerlo en conjunción con la selección de capas, porque aun no he hecho nada cn ese espacio morado de la parte derecha del editor, y aun quedan las herramientas del panel de mapas (modificar el tamaño de los mapas de tiles).

Este mensaje es para guardar las dos últimas imágenes del mensaje anterior LOL

Bueno, igual que dije ayer, es increible lo que se puede simplificar algo tan complejo.
El bug del cursor, en realidad era que me faltaba refrescarlo cuando se cambiaba de mapa, para eso tenía hecha una función, por lo que, para resolverlo, bastaba con escribir una simple línea al crear, abrir o cerrar un mapa. La cuestión era saber que ya existía dicha función y dónde escribirla, eso me llevó una media hora, y solucionarlo tres minutos.
Así que me puse manos a la obra con la ardua tarea de asignar valores a las Z de los tiles de los mapas... ¡y en eso tardé como media hora más! A la estructura de datos del scroll le añadí dos valores más: z1 y zn, que son la Z de los tiles en la capa 0, y qué incremento de Z tiene cada capa (puede ser de 1, que es lo habitual, 2 si queremos meter sprites entre capas... o negativos si queremos que las siguientes capas estén por encima). Luego bastaba con buscar la parte donde "actualizar_tscroll" creaba los tiles (gracias a include, estaba localizado en un único fichero de pocas líneas) y modificar la linea donde se asignaba la Z por una sencilla fórmula matemática.
Luego creé una función que recorría la lista de mapas y les asignaba esos valores a cada uno de ellos (y refrescaba el scroll) ¡Et violá! en tres líneas ya estaba resuellto.

Hala, voy a ponerme con la función que añade una fila al final del mapa, como ya la tenía hecha de antes de empezar, esto será cosa de otros 30 minut... espera, esta función va bien con mapas de una capa, pero no tiene en cuenta el desplazamiento de memoria que se genera entre capa y capa... y no, no se puede adaptar. Total, que tengo una función que debo reescribir, intentando hacer la menor cantidad de operaciones posibles.
(Ahora es cuando me pongo a pensar en voz alta para aclararme las ideas; podeis saltaros el párrafo) El problema está en que el mapa de tiles no se almacena en un array bidimensional, sino en uno unidimensional (un alloc a un puntero, con tantas casillas como tiles tiene el mapa). Sabiendo el número de filas y columnas que tiene el mapa se puede hacer una conversión sencilla. Es como guardar los datos de un tabla en un fichero, o cómo almacena los datos un ordenador en la RAM: array[(Y *ncolumnas) + X]
Ahora lo que tengo que hacer es:
array[(Y' * ncolumnas) + X'] = array[(Y * ncolumnas) + X]
Lo siento, la notación científica es la mejor forma que tengo de explicarlo. Ahora tengo que buscar la forma de hacer esa operación con todo el mapa, usando la menor cantidad de operaciones posibles, y evitar a toda costa divisiones y módulos (he comprobado que un if y una resta consumen menos tiempo que una división). Todo sin borrar información de una posición que aun no se haya evaluado.

En fin, creo que se me han aclarado algunas ideas, pero mañana necesitaré papel y lápiz para tenerlo todo perfectamente claro (sí, en programación se usa papel y lápiz ¡Qué cosas! ¿no? :D).
Me voy a dormir :D :D :D

Pues nada, aquí va mi consejo de la semana: nunca borreis ninguna de las versiones anteriores de vuestro código, si vais a hacer cambios críticos, salvadlo antes de modificar nada, aunque sepais que ese código está mal.
¿Por qué? Pues porque después de todo lo que estuve soltando en el mensaje anterior, resulta que el código sí que estaba bien, que lo había malinterpretado hasta que me puse a darle vueltas a un nuevo código y terminé con el que ya tenía hecho. Por suerte más o menos me sé el código de memoria (me cuesta localizar las cosas, pero tengo en mente el proceso de ejecución) y no lo borré ni lo sobreescribí.
Hala, después de arreglar un par de bugs y escribir las funciones para eliminar filas, columnas o capas, ya puedo modificar el tamaño del mapa... pero aun no funciona en el editor, porque les tengo que añadir la posibilidad de deshacer.
He empezado por las filas. Añadir fila no supone ningún problema, porque lo mismo que la añades, basta con quitar la fila para haber deshecho el paso. Pero si quieres quitar la línea, eso es harina de otro costal, porque tienes que almacenar todos los datos que había en esa fila (para cada capa) para restaurarlos al deshacer. Hoy me he tirado todo el día intentando que funcionase porque me estaba dando unos segmentation fault de narices.
Al principio creía que era cosa de haber creado un word pointer, que se estaba volviendo loco añadiendo datos tipo int, pero no, estaba haciendo bien la conversión. Era culpa de no asignar bien el espacio necesario. Aun no sé si fue culpa del autocompletar o de que soy estúpido, pero había hecho un "capas*filas*capas" en lugar de "capas*filas*columnas".

Y en eso estaba, hasta que un random bug ha aparecido. He conseguido aislarlo a una función que refresca los gráficos de los tiles seleccionados, que cuando no hay mapas cargados, usa un ID de FPG no válido. Lo he corregido en una parte del código, pero no hay forma de hacerlo en los tiles rápidos: los ID de los mapas creados con NEW_MAP se reutilizan si no están en uso (si hago un NEW_MAP, luego un UNLOAD_MAP y otra vez NEW_MAP, es posible que ambos NEW_MAP devuelvan el mismo valor), y los UNLOAD_MAP son peligrosos porque me pueden descargar un mapa creado en otra parte, y no puedo poner esos valores a 0 porque si no el tile tendrá el gráfico del fondo de la pantalla. Creo que no me ha dejado guardar -1 como valor de FILE, pero lo voy a dejar para mañana que esté más fresco, que hoy el debug me ha dejado rendido.

Odio cuando pasa eso, que estoy centrado en una parte del código, y tengo que dejarlo de lado porque ha aparecido un error, y hay que corregirlo antes de seguir para evitar que sea más difícil de corregir o que desaparezca por arte de magia (variante del Heissenbug :P). Quería haber terminado hoy con la modificación de filas para ponerme mañana con el copy-past... digooo, con la modificación de columnas.

je, lo mismo me pasaba a mi el otro dia, hice el screen_get() para capturar directo del render, y no mostraba el grafico capturado, hice un dump en hexa de la data capturada y tenia datos, pero no se dibujaba en pantalla cuando lo asignaba a un graph de un proceso, mientras los otros graphs no capturados se veian, pense que eran los alphas a 0, volvi de nuevo y reescribi todo el codigo, usando funciones mas pesadas pero asegurandome de convertir los datos... despues de un rato de escribir y tras probar tampoco iba... diablos! agarre hice un for y reemplace todos los 0 por 255, si eran alpha con esto se deberia ver (ya habia probado con b_nocolorkey, y tampoco iba), pero no funciono... ya estaba enloquecido... agarre SDL_SaveBMP, y grabo el surface creado y si tiene la imagen! diablos que paso? revise y revise, y revise, y mientras cambiaba otras cosas, ahi lo vi, eran los cpoints que apuntaban a viejo valor de bennugd que se usaba para indicar "no centro definido"... diablos! lo quite y funciono perfecto! volvi al codigo anterior optimizado (por suerte no lo borre, lo comente) y funciono tambien perfecto!
para esto, perdi unas 2-3 horas con pruebas e intentos...
si van a reescribir no borrar la version anterior por las dudas...

Esos fallos puñeteros, que no hay forma de encontrar. La de veces que me ha psado eso, pero porque las coordenadas del mapa o la Z no eran correctas :D :D :D
Hoy mismo he resuelto uno que al crear un mapa, intentaba seleccionar la capa 1 en lugar de la 0. Usando el buscador de Notepad++ no encontraba la línea que le asignaba ese 1 a ese valor, así que tuve que hacer una traza del programa leyendo el código hasta que encontré la línea en un fichero que no estaba abierto (en serio, tengo que aprender a usar la herramienta de traza del código del debug de BennuGD ^^U).

Y es que tenía que ir cerrando ficheros porque fijaos cómo era mi "entorno de trabajo":

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3503)

Al final he escondido las pestañas y he activado el "doc switcher" para tener una referencia del orden de los ficheros abiertos (suelo estar editando el último, y así es más fácil de encontrarlo que con el "sherlo explorer"), y ahora si tengo espacio para leer más código de golpe. No es que vaya a conseguir mucha más velocidad, pero algo hace, sobre todo para buscar fallos:

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3505)

Bien, respecto al desarrollo en sí, he podido solucionar lo del random bug. Efectivamente era que al descargar un mapa, ese identificador pasaba a estar libre, y al crear un nuevo map, se usaba ese valor y la vista previa del tile lo mostraba como si fuera un tile. Intenté asignarle valores de file = -1, o de graph = 0, pero no sé si porque mi código estaba mal, o porque me identificaba el (file = 0, graph = 0) como un mapa válido y me descargaba un mapa aleatorio, me empezaban a desaparecer gráficos a medida que cerraba y abría nevos mapas. No, no me puse a hacer pruebas porque estaba ya muy cansado, y tiré por la calle de en medio: si no hay mapa cargado, se genera un gráfico de 1x1 transparente, de esta forma siempre que se llama a la función de actualizar, hay un graph en esa posición que descargar. No es una solución muy elegante, pero el código se ha simplificado tanto que ocupa la mitad de lineas.

Resuelto el bug, volví a la modificación del tamaño de los mapas de tiles, y ya se puede cambiar el tamaño y deshacer/rehacer los cambios... Y sí, eso incluye recuperar la información "perdida" al eliminar una fila o columna. Un momento ¿y las capas? Pues en su momento no lo pude probar (y lo cierto es que aun no lo he hecho ^^U) porque no podía editar en ninguna otra capa que no fuera la 0.
Así que ya tocaba trabajar con esa parte morada de la parte derecha del editor: la lista de capas. ¡Vaya follón! entre el número de capas disponibles, el número de elementos que se pueden mostrar a la vez, la primera posición mostrada, la posición seleccionada y la capa seleccionada, la función de refrescar me ha llevado todo un día arreglarla para que funcione bien. Creo que lo he conseguido, pero no descarto que al hacer algún "movimiento raro" no aparezca la lista en la posición 47 o se seleccione más de un elemento :D :D ^^U Nah, básicamente que he hecho varias pruebas, pero han sido tantos intentos que ya no sé si en el último he llegado a realizar todas las pruebas que había hecho en los anteriores.
Lo bueno es eso, que ya se puede ver la lista de las capas del mapa seleccionado, seleccionar una, ¡Y EDITARLA! Por fin se pueden generar mapas de dos o más capas sin tener que crear cada una en un mapa diferente, y unirlas posteriormente por código (aunque tengo previsto añadir dicha funcionalidad como herramienta en el editor en un futuro).

Os dejo una fotico para demostrar lo que vale ya el editor:

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3507)

Aun no puedo subir una beta, porque para empezar aun no he creado una carpeta con los ficheros necesarios para compartir. Además, tengo que quitar unas cuantas llamadas a SAY o a funciones de debug.
También quiero añadir que las capas que están encima de la que se está editando se transparenten, y eso va a suponer un problema. El valor de la capa en edición y quien decide qué capas deben tranparentarse y cuales no son cosas del sistema; sin embargo, quien lleva el control total y absoluto de los tiles es el motor de scroll tileado, y no fue diseñado (porque no era su cometido) para que las capas tuvieran un comportamiento diferente unas de otras. Así que si el sistema hace transparente a algunos tiles (porque puede acceder a cualquier parte de esos datos), el motor automáticamente los volverá a poner opacos. Así que ahí estoy ahora, intentado ver en qué parte del código va esa modificación, o cómo poder implementarlo en el sistema sin alterar el scroll tileado.
Lo cierto es que veo que es posible que al final modifique el motor de scroll sólo para el editor, porque hace tiempo pensé que sería interesante tener capas que manejasen FPGs diferentes, por ejemplo, para crear una capa que no se verá en el juego, pero que incluye información de esa posición (por ejemplo, el valor de la energía de un enemigo situado en esa (X,Y), o la dureza o un flag de propiedades como en los mapas de Sonic de MD).
Y también me gustaría añadir una herramienta para ordenar los mapas cargados y, por tanto, alterar su Z (por ejemplo, para poner el segundo mapa que hayamos cargado sobre el primero, o para alternar entre ambos sin que el otro nos tape). Había pensado en poner un par de flechas al lado del nombre de cada mapa en la lista de mapas, pero es que tendría que poner las dos flechas, un botón para activar/desactivar el mapa (quitarlo, pero sin cerrarlo), y otro para hacer que se transparente.

Cualquier idea es bienvenida (y si es con boceto, mejor).

PD: que no se me olvide: la herramienta de cuentagotas. Aun no sé si asignarlo como un botón más o usar shift+clic

Es gracioso cómo un bug puede hacer que algo que funciona en una parte, falle en otra, haciendo teóricamente lo mismo.
Y lo digo porque hoy me he puesto a implementar el cambio de orden de los mapas de tiles, en la lista interna del sistema. Que esa es otra: el código para intercambiar de posición dos nodos de la lista, con todo lo complejo que es, por estar manejando punteros y una lista simplemente enlazada, funciona a las mil maravillas (leido por consola de debug), pero sin embargo, refrescar la lista de mapas de la parte derecha de la interfaz falla, aunque se pone bien si se desplaza la lista o se crea un nuevo mapa.
Y esa es la cosa, una función que, supuestamente, "elimina" los datos de la lista (sólo en la interfaz) y la vuelve a recuperar con los datos cargados en ese momento, y que ha funcionado bien al crear, cargar, cerrar, renombrar, etc, ahora no funciona cuando cambio el orden de dos mapas... que en teoría debería hacer lo mismo que al crear el mapa, pero bueno. Dadme tiempo para depurarlo.

Y es que al final he decidido que, de momento, sólo voy a poner un botón al lado de cada elemento de la lista de mapas para subirlo una posición. Es un peñazo tener que mover el nuevo mapa una posición tras otra para que quede por encima de las demás, pero ¿Cuántos mapas se van a tener abiertos a la vez? :D Yo nunca he tenido más de dos o tres. Echadle un vistazo a cómo está quedando:

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3513)

A la izquierda de esos botones quiero poner otros para "activar" y "desactivar" cada uno de los mapas. Es fácil crear una función que elimine todos los procesos tile del scroll tileado, y el proceso de control, y aun así, mantenga los datos actualizados, y después devolverlo a la vida. Bueno, eliminar el proceso de control puede ser un poco "heavy", lo mismo se puede congelar o algo, aun no lo he comprobado en el código (lo he hecho de memoria) pero es sencillo.
Lo que no es tan sencillo es decirle que lo ponga transparente, ya sea a parte o a todas las capas. Es lo que comenté en el anterior mensaje: no es algo que le corresponda al motor de scroll tileado, sino al sistema de edición, pero es el único que tiene acceso al comportamiento de los procesos tile.

En fin, como bonus a los que estais siguiendo el culebrón, os subo una beta del programa hasta cómo estaba anteayer... pero sólo para Linux :D :D :D
He cogido el BennuGD "portable" de Pixel, que encontré en un hilo perdido, porque he intentado por enésima vez instalar Bennu desde la versión oficial (he analizado el instalador, y no es invasivo, está todo bien localizado, bien hecho, Splinter :D ) y por enésima-1 vez tengo problemas. Instalarse se ha instalado, pero me sale el famoso error de la libcrypto1.0.0. Tenerla la tengo, igual que la libssl, y he probado a poner en la misma carpeta las que vienen en la versión portable de Pixel, pero le da exactamente igual.
Bueno, que no me enrollo más. Aquí teneis el binario para probarlo. El que lo quiera para Windows, que se lo porte él mismo :D Y no, no hay código fuente. Cuando lo termine es posible que lo ponga, pero en un paquete aparte y bajo pedido. Cualquier sugerencia, bug reproducible, alabanzas y jamones serán bienvenidos :)

PD: He tenido que eliminar una carpeta .svn que no sé de dónde ha salido, del fichero comprimido porque se pasaba del tamaño máximo de adjunto, espero no haber quitado nada importante :P

muy bien drumpi!

Es curioso cómo dos simples líneas entre más de 10000 (por decir un número) puede ocasionar tantos dolores de cabeza, y bugs "mu raros".
Todo el problema que tenía se debía a que en un copy-paste, uno de los punteros quedó sin renombrar, y al señalar a un null me sacaba de un bucle y se quedaba casi toda la lista sin comprobar.
Eso, sumado a que el proceso de refresco estaba empeñado en leer el final de la lista (que no estaba mal, es como se diseñó... hasta que empezaron a funcionar los botones de desplazamiento por la lista :D ), me tenía loco.

Para echar más leña al fuego, esta mañana me estaba fallando el código que modificaba la posición de los mapas en la lista. Tras detectar el fallo, empecé a poner says para leer los datos de cada variable y... empezó a funcionar sólo. Ya no estoy seguro si era porque arreglé lo del puntero o qué fue, pero, básicamente, se arregló solo (y no "mágicamente" como dicen los estudiantes de informática, no, sólo, sin tocar el código salvo para poner says). No sé, me duele la cabeza ya de pensar en ello.

En fin, arreglado eso, me he puesto con los botones para activar y desactivar los mapas. Ha sido bastante sencillo de implementar porque las herramientas estaban hechas, y el comportamiento era una mezcla entre los botones de mover mapas y los switches de selección de mapa (los nombres de los mapas en la lista). No puedo darlo por cerrado porque apenas he hecho unas pruebas de funcionalidad básicas, tengo que darle caña a ver si puedo romperlo, pero bueno, aquí os dejo una imágen del mapa 1 seleccionado, pero inactivo, y luego otros dos mapas activos. decidme qué os parece, pero me da a mi que tengo que cambiarle el color a los LEDs esos (y quizás la forma, admito sugerencias).

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3516)

Pues nada, a darle caña a ver si saco errores. Se me ha ocurrido que, para el tema de las capas, tener un array de datos en la estructura general del mapa (la que contiene al tilemap y al scroll tileado) con la información de cada una de ellas (de momento, el alpha) en lugar de almacenarla en los tilemap en sí, y hacer que todas las llamadas de refresco del scroll tileado pasen a través del sistema.
Me explico. Actualmente, el motor scroll tileado tiene una función que actualiza todos los tiles de pantalla. Se usa cuando la cámara cambia de un tile a otro (en caso contrario, se usa una función de desplazamiento que es muchísimo más rápida), pero también se puede usar para forzar un refresco en cualquier momento.
Hasta ahora estaba dando permiso al sistema a usar esa función para cuando se hicieran diversos tipos de modificaciones (zoom, gráficos, tamaño de mapa...), pero creo que es buena idea dotar al sistema de su propia función de refresco del scroll tileado. Su función sería, al principio, llamar a la función de refresco del motor de scroll tileado, y después llevar a cabo las modificaciones necesarias a los procesos tile correspondientes (modificar su alpha en función de su posición z o... básicamente es el único cambio que voy a hacer de momento ^^U).
La pega es que el proceso de control del scroll tileado también hace uso de dicha función, y ahora tendría que hacer la llamada a la función de refresco del sistema, rompiendo la modularidad (aquí vendría bien algo para capturar la llamada a dicha función desde cualquier punto del programa, y ejecutar una serie de acciones después, como con las interrupciones ^^U).
Y aun así, me parece la solución menos invasiva y más elegante. A no ser que a alguien se le encienda una bombilla, que la mía está con la carga muy baja :D :D :D

esos cuelgues que se solucionan con say, son normalmente algun pise de memoria, el tema es saber si es pise es de bennugd o del manejo de listas que estas haciendo.

Quería descartarlo, y quité los SAY. No sólo los comenté, los eliminé del código, y seguía yendo bien. Intenté más o menos reproducir el error pero me fue imposible. Ya digo que me faltan hacer pruebas exhaustivas, pero es muy probable que el error fuese mio por dicho puntero que no renombré al copiar. Analicé el código y vi que tenía sentido el fallo, pero está demostrado que eso nunca es prueba de garantía: que no veas el error, no significa que no exista :D

Alguna vez me ha pasado eso, que los say eliminasen un error, y salvo Fenix v0.84, siempre he comprendido que era un puntero con valores mal asignados (he visto en mi cabeza cómo el say modificaba las posiciones y los datos de la zona de memoria del código, y cómo los punteros se escapaban de la zona de espacio reservado para memoria dinámica, por deformación profesional ^^U).

Ahora me interesa que los 6 o 12 que van viendo este "log" me digan qué les parece el color de los leds de la última imágen :D Estoy convencido en un 80% de que mañana debería cambiarlos por leds verdes, aunque aun no sé si de forma rectangular, con el brillo dándole menos altura, o qué.

por mi se ven muy bien

Bueno, al final los he cambiado por leds verdes, a juego con la zona de la lista de mapas, y los he hecho menos redondeados. Por desgracia no he traido imágen que enseñar :(

También le he añadido a la estructura de mapas del sistema una nueva lista enlazada (y ya van... pfffff) para que almacene los datos específicos de cada capa. Eso implica la creación de las funciones de añadir nodo, borrar, contar, escribir, etc... Y luego usarlas en el sistema cada vez que se modifica el tamaño del mapa en el número de capas. Por suerte no ha sido complicado, ya que modificar las capas no es algo que se use habitualmente, ya que por lo general este tipo de mapas se usan en juegos 2D (algún día, Tomb Raider/Mario 3D Land, algún día).

Y ahora tengo una pega, y aquí sí que necesito consejo: habeis visto las imágenes del editor, la lista de capas es la parte morada. Tengo ese espacio para añadir lo siguiente:
- Un botón para activar la capa.
- Un botón para desactivar la capa.
- Un botón para hacer la capa transparente (y si se puede definir la opacidad, mejor).
- Un botón para poner todas las capas en cualquiera de los tres estados mencionados antes.
- Un botón para poner sólo las capas por encima de la seleccionada en transparencia o invisibles.

Para los tres primeros casos, me planteaba usar un slider 0%-100% al lado de cada capa, pero me interesa que se puedan seleccionar fácilmente los valores 0%, 50% y 100%.
Los dos últimos ni idea, el espacio es reducido. Pensaba colocar una barra de texto por encima de todas las capas (puedo bajar la lista unos 12 pixels o poco más), a la derecha, donde se pudiera indicar un valor entre 0% y 100% (quien dice texto, puede decir slider o algo original), y a su lado dos botones: "set all" y "above selection", pero los textos no caben en tan reducido espacio, y encima el editor puede cambiar de idioma (en la beta que subí se pueden ver los ficheros .lang, pero no hay selector de idioma, de momento). Puedo poner imágenes, pero no sé cómo hacerlas para que se entiendan (mucha gente me ha mirado raro porque no entendía los botones de edición :S).
Pero si se os ocurre otra forma, aunque sea en combinación con la lista de mapas, estoy abierto a ideas. Más adelante habrá menús desplegables y botones que se puedan colocar en la barra de botones (la azul claro que ahora está vacía) para acceder a todo tipo de funcionalidades que aun no se han implementado, o para incrementar las que ya existen (como añadir columnas intermedias, acceso rápido a bloques predefinidos de tiles, o la configuración de una herramienta de "pintado inteligente" (que aun no sé exactamente qué significa eso ^^U).

Ya casi está lista la versión usable del programa, queda eso, unos detalles que tengo apuntados, y a partir de ahí es cuestión de ir añadiendo funcionalidades que no estaban en la v1 (tengo que repasar las notas de aquella versión, a ver qué me he dejado).

Pues nada, viendo que a nadie se le ocurre una buena idea, para que el proyecto no entre en la temida fase "pausa hasta que se me ocurra algo, pero se queda de forma indefinida hasta que tenga ganas de retomarlo", pues he decidido implementar la última forma que se me ha ocurrido. Ya cuando la haga os contaré.
De momento he estado implementando los botones que van a establecer la transparencia de forma individual a cada una de las capas que se ven en la lista, es decir, los que van a la izquierda de cada posición de la lista de capas. Estos botones no son botones normales, son un nuevo elemento que he creado para la ocasión, que he bautizado (a falta del nombre original) "botón-slider":
- Con una pulsación simple se comportan como un botón normal y corriente, con la diferencia de que incrementan el valor que contienen en un 50%, o vuelven a 0 si estaban ya al 100% (están programados para que dicho salto sea de 50%, 25%, 12%... en función de los "pasos" que se le indique al "botón-slider", y para darles cualquier valor máximo y mínimo que se quiera).
- Pero si se mantiene pulsado, se comporta como un slider, decrementando el valor que contiene si se desplaza el ratón a la izquierda, e incrementándolo si se desplaza a la derecha.

De momento no he podido hacer gran cosa, porque anoche estuve hasta las 5 de la mañana escribiendo el guión de mi próximo video (o lo soltaba de mi cabeza o me iba a pasar dos o tres noches en vela). Por ahora están puestos en el interfaz, funcionan bien con cualquier valor de paso, valor máximo y valor mínimo, y se congelan/despiertan en función de si hay alguna capa a su derecha, pero aun no modifican el valor de la capa ni se actualizan al desplazar la lista arriba y abajo. Eso ya me tocará mañana.

En fin, os dejo aquí la imágen para que lo veais. Hace algo extraño con la barra de relleno cuando está casi vacía (un valor de size_x muy bajo, no nulo), no sé por qué.
Por cierto ¿cuál es el valor máximo de la variable local predefinida alpha? ¿255 o 256? Es que la he buscado en la wiki, pero no está.

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3519)

Hoy seré breve:
Ya se puede seleccionar el alpha de las capas de forma independiente, y se mantiene aunque cambies de mapa (pero no si lo cierras, eso es sólo información para la edición, no para el mapa de tiles. Los botones-sliders funcionan bien, y tienen valores automáticos a 0, 127 y 255. Y sí, se actualizan bien al cambiar de mapa y al desplazar la lista de capas.

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3522)

También he preparado un pequeño montaje en paint de lo qe tengo previsto a continuación, y necesito opiniones, por favor:
(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3524)

Como veis, he añadido tres botones más. Quiero saber si tal como lo he puesto se entiende o no.
Tampoco tengo claro si los botones van a ser botones o interruptores, o botones que se quedan activos si se dejan pulsados más tiempo de la cuenta (como el botón mayúsculas en el teclado de Android).

Si no se entiende voy a explicarlo, pero intentad entenderlo antes de segir leyendo...
Esos tres botones, junto al boton-slider que lo acompañan, sirven para modificar todas las capas del actual mapa en grupos: el botón central sólo afecta a la capa seleccionada, el izquierdo a todas las que hay sobre ella, y el derecho a las que hay debajo. Se supone que si el botón queda activo, asignará ese valor de alpha automáticamente al conjunto, es decir, que si marcamos un alpha de 127 para todas las capas superiores a la seleccionada, si cambiamos de la capa 1 a la 3, automáticamente la capa 1 y 2 se pondrán transparentes al 50%.

...Aunque pensándolo bien, debería darle otra vuelta, porque ¿y si cambio de la capa 3 a la 1? ¿Se quedarían la capa 1 y 2 semitransparentes? ¿Debería añadir un botón-slider a cada grupo, y un switch al lado para mantenerlo automático (al cada grupo o a todos)? Pero entonces ¿esos símblos se entenderían? es que no tengo demasiado sitio para poner nada. Puedo eliminar una línea más de la lista de capas, pero eso sólo me daría espacio en vertical. Mmmm.

Ya casi está, ya casi tengo lo suficiente para abandonar la v1 definitivamente. Lo sé porque se me están quitando las ganas de seguir con el programa :D :D :D
Aun quedan muchas cosas en el tintero, pero en cuanto arregle un par de cosillas, voy a aparcarlo para centrarme (por fin) en acabar los niveles 4 y 2 del Echo.

Mirad que monada :)
(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3526)

Al final lo que he hecho ha sido añadir 3 switches y 3 botones-sliders. Los switches activan o desactivan el cambio automático de alphas de las capas superiores, de la seleccionada o de las inferiores, según si se hace clic en el izquierdo, en el central o en el derecho respectivamente. Los botones-sliders sirven para seleccionar el alpha de esas capas.
Por ejemplo, si ponemos (0,255,0) sólo veremos la capa que estemos editando, da igual que cambiemos de capa, y da igual el mapa seleccionado (ojo, seguiremos viendo los dos mapas a la vez si los tenemos activados, la funcionalidad de ordenar los mapas y de verlos no se ha modificado). O por ejemplo, podemos poner (126,255,0) para ver en transparencia las capas superiores, totalmente opaca la capa que estemos editando, y que no se vean las capas de atrás para no liarnos.
Pero vamos, que si se desactivan podemos seguir usando los botones-sliders de cada capa como hasta ahora, incluyendo la memorización de las alphas de cada capa en cada mapa de forma individual.

También he resuelto un par de bugs que no había visto, he añadido a la ventana de selección de archivo la posibilidad de hacer scroll en la lista de ficheros usando la rueda del ratón, y que al iniciar el programa se tengan preseleccionadas las herramientas más habituales (poner tile 1, mover cámara y borrar).

Lo que tengo que pulir es que, para empezar, las barra de los boton-sliders no se actualiza si se cambia el valor que contiene de forma externa, que no se puede seleccionar idioma desde el fichero de configuración, y que los ficheros no se ordenan alfabéticamente en la ventana de selección. Tengo un par de cosillas más, y seguro que hay que corregir algún bug, pero de momento, vamos a por eso.

Bueno, no sé si seguiré con el editor o no, dependerá de las ganas que tenga mañana o pasado, porque hoy estoy ya sin ganas ^^U

Le he hecho unos cuantos retoques al programa, empezando por darle utilidad a la rueda del ratón, para hacer scroll en la lista de ficheros en las ventanas de selección de fichero, parecía una minucia pero resulta mucho más cómodo navegar ahora. Debería plantearme añadir algún botón de "atrás"...
También he completado la función que actualiza las barras de porcentaje de los boton-sliders con la ayuda de Splinter y Pixel. Ahora ya se refrescan en todas las ocasiones... o al menos en las que he probado.
He añadido botones invisibles en la interfaz en la zona del ratón, para poder cambiar directamente el tile a la herramienta que haga uso de ellos. Otra tontería que ahorra tiempo.
Y he añadido al fichero de configuración una línea para definir el fichero de idioma que queremos que se cargue. Por defecto he puesto el fichero en inglés (eng.lng) pero se puede poner tranquilamente el fichero en español (esp.lng) o cualquiera que se haga (estoy abierto a aportaciones en este sentido).

Lo bueno de haber terminado lo gordo es que cualquier cosa ahora se implementa en pocos minutos, sólo basta con saber dónde meterlo y las funciones que se pueden invocar... aunque a veces eso lleva bastantes minutos, porque hay cientos de funciones y hay que respetar las convenciones sobre a quién se puede llamar en cada capa :S

Lo que no he conseguido es ordenar la lista de ficheros (eso requiere muchísimo debug, porque no es una función precisamente sencilla), y faltaría cambiarle el texto a los botones de guardar y salir (es lo que tiene el añadir texto a una imágen) y quizás una función para modificar los valores del fichero de configuración, es decir, seleccionar un tamaño de ventana (que ahora mismo requeriría reiniciar el programa :S), seleccionar el fichero de idioma, y personalizar la barra de iconos, que ahora está vacía, y que se supone que se puede rellenar con cualquier función disponible en los paneles laterales. Quizás debería también desplazar la cámara al modificar el zoom.
Y sí, hay muchas funciones que me dejo en el tintero, como almacenar bloques de tiles, fusión de mapas, añadir/quitar filas y columnas en la parte interior del mapa, cargar mapas de Tiled (aunque necesito que alguien me explique algunas cosas del formato)... pero es lo dejo para más adelante que no esté tan cansado del proyecto :P

Si mañana no añado nada más, subiré la beta para que quien quiera pueda probarlo. Por mi parte, el Echo será el primer beneficiario del editor, a ver si por fin le puedo añadir banderas de mitad de nivel al juego, arreglo un par de cosillas, y empiezo con la tercera parte del cuarto nivel, que ya tengo unos cuantos tiles hechos desde hace la tira ¿Alguien sabe de algún programa sencillo que me permita crear imágenes BMP de 24bits con función de roll pallete? ^^U

a veces es bueno dejar un proyecto aparcado un tiempito y cambiar a otro, para retomarlo luego con mas ganas.

Si, pero yo soy yo y no aprendo ^^U
Esta mañana se me ha ocurrido una manera interesante de meter las funciones de añadir/quitar para las filas, columnas y capas, y me he puesto a implementarlas. Añadir los botones al IDE ha sido pan comido, y que el sistema actúe ante los eventos también. La pega es implementar las funciones, porque para no repetir 3 y 3 funciones similares (3 de añadir y 3 de quitar, para filas, columnas y capas), tengo que crear una función que mueva un bloque de tiles a una nueva posición, borrando las posiciones antiguas. La pega es que, dependiendo hacia dónde se mueva el bloque, tengo que recorrerlo de arriba a abajo o al revés, o de derecha a izquierda o viceversa. Y todo eso añadiendo los cambios de tile a la lista de deshacer.
Pero una vez implementado, añadir o quitar algo básicamente es añadir una fila al final y desplazar el bloque, o desplazar el bloque y eliminar la última fila, son un par de líneas (más las necesarias para deshacer/rehacer la operación).

Resumiendo, que me quedan dos jornadas más de trabajo, más lo que se retrase por problemas técnicos o las cosas que no tengo previstas (y que van aumentando minuto a minuto en mi cabeza, acabo de darme cuenta de que el bloque se debería poder desplazar también entre capas).

Venga, que esto no decaiga.
Pues lo esperado, problemas por todas partes. Ayer tuve que dejar por casi imposible la función de mover el bloque de tiles, la cabeza me iba a estallar, así que me fui a dar un paseo. Esta mañana me he hecho coleguita de la consola de debug de Bennu (un poco confusa, porque te dice la siguiente linea a la que se ha ejecutado, y es difícil seguir la traza en cuanto empieza a meterse en sub-procesos :S) y entre una cosa y otra conseguí arreglarlo todo.
Luego me puse con "el par de líneas", que era algo más complejo que eso, gracias a la lista de deshacer y las múltiples capas de código (que sí, que son buenas costumbres, que aclaran el código, que ayudan a la compartimentación... pero entre capas y "plugins"... :S).
Total, que hoy por fin he conseguido añadir y quitar filas en un mapa de varias capas, y aquí teneis el resultado inicial:

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3528)

Aun me queda trabajo por hacer, empezando por copiapegar estas dos funciones y usarlas para las columnas (con el peligro que eso conlleva), y crear funciones para añadir capas, que a todos los problemas tenidos hasta ahora, se suman la lista lateral de capas y la lista de datos de capas (¡esto no se acaba nunca!).
Así que mañana no sé si ponerme el casco de espartano y darle caña hasta que uno de los dos caiga, o ponerme las zapatillas de andar e ir resolviendo problemas uno a uno hasta que el ordenador diga que ya son suficientes.

Y aun me queda ordenar la lista de ficheros ¡AGHHHHHHH!

Puf, parece que el culebrón está llegando a su final.
¡POR FIN! Ya tengo las funciones para incluir filas, columnas y capas en cualquier parte del mapa. Como esperaba, la parte de las capas me ha costado un montón, y no sólo por la parte de llevar la lista lateral de capas y la información de las mismas. Por suerte, la lista de capas funciona a la perfección y me ha ahorrado muchísimos quebraderos de cabeza a la hora de depurar, porque ha sido mi "chivato" todo el rato para decirme si la cosa iba bien o mal. De hecho, me ha revelado varios bugs serios que iba a pasar por alto.
La fortuna ha querido que todos los fallos que he ido cometiendo estuvieran concentrados en la función de añadir o quitar capas, ya fuera al llamarla desde uno de los botones o desde las funciones de deshacer/rehacer. Y sí, es la segunda vez que hago alusión a la suerte, algo que no debería estar permitido en la programación, porque se supone que todo está calculado y medido, pero cuando has dormido pocas horas, es muy fácil cometer fallos, y nunca sabes cuando, y es un factor muy aleatorio, y aunque ha sido así, parte de la "suerte" se ha debido a que el resto del programa está muy bien construido, sobre unos cimientos sólidos y robustos... Lo siento, ya he dicho que he dormido poco y la hora no ayuda, se me va la cabeza :P

Lo cierto es que han sido dos jornadas a medio camino entre una sesión normal de trabajo y la intensidad de una Game Jam, con partes de codificación intensa, con parones para pensar el siguiente paso. Y cuando estaba cansado, atascado en un bug, buscaba cualquier valor tonto que quería ver por consola, para luego buscar el siguiente, y cuando llegase al quinto, encontrar el bug (aunque a veces me quedaba a dos pasos de encontrarlo cuando me venía una "inspiración divina" que me lo señalaba con carteles de neón).

Voy a ir cortando antes de que se me vaya la cabeza del todo. Lo dicho, las funciones para añadir filas, columnas y capas en mitad del mapa funcionan, así que me he puesto a trastear con el fichero de configuración para añadir la lista de números que indican los botones que queremos tener en la barra de herramientas. Eso significa que me puse a escribir unas 100 líneas extra para inicializar, crear, destruir y actualizar la lista de botones que van en dicha barra. Sí, otra lista enlazada, aunque por suerte en esta ocasión han sido 4 arrays dinámicos dentro de una struct global (nota: la struct es global porque no tenemos clases donde encapsular el acceso a la misma LOL). Con los botones puestos, ya sólo quedaba crear el proceso de control que ejecutase todas y cada una de las funciones de los posibles botones que van a ir ahí... y no son pocas.

La buena noticia es que gracias al gestor de eventos, parte principal del sistema, cada botón sólo necesita de una línea para dar comienzo a la ristra de órdenes que lleva asociada, y todas son iguales, salvo por una constante y un valor. Hasta ahora he implementado casi todas las funciones de fichero (abrir, nuevo, guardar...) y la mayoría de las de edición; me quedan 4 de las de mapa que tienen el icono ya hecho, pero tengo que hacer unas cuantas más que no tienen icono porque no eran funciones de por sí, como mover todos los tiles, cambiar el zoom, o modificar el tamaño del mapa (he contado unas 10).
Después de eso, espero no ponerme a ordenar ficheros. Quedaría modificar la cámara al cambiar el zoom, los textos de los botones de acciones de fichero y... tenía otra tontería por ahí apuntada, no sé ¿Mostrar las coordenadas del ratón? ¿Dónde?

Lo mismo no toco mucho más y lanzo de una vez la beta. ¿Qué número de versión debería ponerle? Si le pongo la 1.1.3, que es la que le toca parecerá una revisión del primer editor, si le pongo la 2.1.3 parecerá que ya hay una v2 finalizada, y si le pongo la 0.1.3 que es la que tengo como nombre de la carpeta (porque es un proyecto nuevo casi de cero) ni siquiera parecería que hubiera una versión previa :S

¡Una cama, por favor!

Ya lo tenía, estaba a punto de publicar la beta cuando Drumpi me ha hecho una de sus jugarretas y me ha tenido toda la tarde dándole vueltas al mismo fallo.
La verdad es que no puedo culparlo de algo que en realidad es error mío (pero molaba como intro del mensaje :D ). Ya había añadido los botones a la barra, con otros dos extra de zoom (voy a dejar algunas funciones sin poner como botón, porque si no ¿para qué los paneles laterales?), modificado en tiempo de ejecución los textos de los botones de guardar y salir, e incluso me había permitido el lujo de añadir un pequeño cuadro junto a los tiles de acceso rápido para mostrar la posición del ratón y el tile que había bajo él (siempre en la capa seleccionada). Aquí podeis verlo.

(http://forum.bennugd.org/index.php?action=dlattach;topic=4207.0;attach=3530)

Pero al querer modificar la posición del scroll tras hacer zoom, para que la cámara intentase mantenerse más o menos cerca de la zona donde se estaba editando, ha saltado un error que hacía que todo el mapa apareciese desplazado hasta el siguiente refresco del mapa (esa función que se invoca cada vez que la cámara cambia su posición de un tile a otro).
Hace tiempo ya saltó el problema con la propia función de zoom. No le di importancia porque sólo se apreciaba durante un único frame, y lo achacaba a los problemas típicos del orden de ejecución, podía dejarlo para más adelante. Pero al modificar la posición de la cámara, este desplazamiento se mantenía estático hasta el refresco, y con el zoom al mínimo un tile de 16x16 necesitaba desplazar el mapa 128 pixels antes de que eso sucediera.

Me he tirado más de dos horas mirando el código sin tener el más mínimo indicio del fallo. El debuger no ayudaba porque toda la información estaba contenida en punteros, y crear funciones para escribir los datos me iba a llevar un par de días. Al final encontré el hilo del ovillo, y pude comprobar que era cosa de la función de refresco del scroll.
Hasta ahora esta función sólo podía ser llamada por el proceso de control del scroll, y en contadas excepciones, por algún elemento externo (generalmente, por cambiar un tile o el FPG). Ahora que era llamada por una función del sistema, en determinadas ocasiones se produce un efecto no deseado, y es que la cámara no modifique su posición y algunas operaciones se quedan sin realizar.

Aun no he podido determinar el alcance de los "daños". He visto que al coincidir la posición de la cámara con el frame anterior, se llamaba a la función de desplazamiento rápido de tiles con valores inaceptables, llegando a mover el mapa incluso tile y medio. He tenido que pasar los datos de la posición anterior a la estructura del scroll para que la función de refresco pudiera actualizar los valores si se hace desde fuera.
Otro de los efectos no deseados se ha dado con algunos cálculos que hasta ahora eran secundarios. Pensaba que era cosa del cálculo del tile en el que se hallaba la cámara, pero resulta que no, que he aislado el fallo a los cálculos de la posición del tile (0,0), que como digo, era información extra para el usuario... aunque he visto que se usa en algunos cálculos principales.

Tengo que ver cuales son los datos concretos que tengo que actualizar, y lo más importante: por qué. En teoría, toda modificación de la cámara del scroll tileado debería haber estado cubierta por el proceso de control, y este tenía que ser el encargado de refrescar el scroll incluso antes que cualquier llamada externa. Y sin embargo la llamada externa no responde como el proceso de control, y la omisión de esos cálculos han provocado todo el caos de hoy.
Sé que esto os dice poco o nada a vosotros, pero tengo que desahogarme e intentar analizar el problema, y ya sabeis que a veces, escribir sobre él trae la luz a las cabezas.

Como digo al principio del mensaje, el programa está casi terminado en su versión beta, y quiero dejarla lo más estable posible antes de lanzarla, para que no pase como con la primera versión. Y también quiero ir eliminando de la lista la mayor cantidad de "cosillas tontas" que se suelen dejar para el final, y que al acumularse suman varios días de desarrollo. Aun tengo pendiente mover un texto de error crítico de un SAY a una ventana (bueno, hay varios, pero este es el que más importante sería), y añadir la típica ventana de créditos, pero eso supone desarrollar el sistema de menús y submenús de la parte superior, y aunque tengo una ligera idea de por dónde lo quiero llevar, aun tengo muchos detalles que arreglar.

De acuerdo, voy a anotar esto antes de que se me olvide, para tenerlo registrado:

Resulta que esos cálculos que no se actualizaban, todos son necesarios de una forma u otra. Estaba usando la función ts_actualiza_tiles como si fuera la función de refresco de todo el scroll tileado, y no lo es. Sólo es una función que actualiza la posición y la lista de tiles del propio scroll. La actualización de los datos del scroll tileado la hace sólo y exclusivamente el proceso de control, porque en función de unos cálculos hace un refresco completo o un simple desplazamiento de tiles.
¿Qué pasaba? pues que al hacer zoom, efectivamente la cámara se desplazaba, pero al cambiar el tamaño de los tiles, ese desplazamiento mantenía la cámara dentro del mismo tile de antes, que es el requisito indispensable para forzar el refresco completo.

Para no crear una variable que forzase el refresco desde fuera (que podría provocar que no se viera hasta un frame después), ni modificar la función de refresco para que hiciera los cálculos del tscroll dos veces (una por el proceso de control, y otra por la llamada de la función de refresco por parte del sistema desde el propio proceso de control), lo que he hecho ha sido crear una función de refresco que prácticamente hace lo mismo que el proceso de control, incluida la llamada a ts_actualiza_tiles, y en el proceso de refresco del sistema he buscado la fuente de la llamada, y si father.reserved.process_type es el proceso de control, en lugar de llamar a esta nueva función, llama directamente a ts_actualiza_tiles... y ya después aplica toda la lógica extra de modificar el alpha de los tiles y demás.

No sé si es la solución más elegante o no. Le he dado vueltas hasta casi marearme, he empezado el planteamiento cuarenta veces, una por cada vez que se complicaba demasiado el código en mi cabeza. Y de momento las pruebas son prometedoras, ya no hay glitches, el zoom funciona (autodesplazamiento incluido) y no sé si tengo fuerzas para poner el programa al límite con varios mapas abiertos a la vez.

De momento voy a relajarme pensando si le añado un botón de "atrás" a la ventana de selección de ficheros, o selección mediante doble clic o algo sencillo, y si veo que se complica mucho la cosa, esta tarde subo la beta.

Bueno, pues ya está. Ayer salí a que me diera el aire y no pude arreglar nada, pero por la noche le dediqué unos minutos y añadí los botones de deshacer a la barra de botones por defecto, un nuevo valor para que podais escoger el mapa para el scroll de fondo que más os guste (los valores son el número de gráfico del fichero grafs/scroll_bg.fpg, podeis añadir el que querais) y solucioné un bug que metí con la nueva función del sistema de refrescar el mapa. Si quereis personalizar la barra de botones, los valores son los gráficos contenidos en grafs/system_icons.fpg... pero no useis los de los ratones, no sirven para eso... ni la del cuentagotas, si se ha quedado ahí ^^U).

Esta mañana he estado probando la versión antes de subirla creando un nuevo nivel para "El Ballena Azul" ¡y vaya diferencia! Bueno, en realidad la versión 1 no tenía ningún problema en mover esos mapas, y por ahí había poca diferencia, pero el poder editar los dos mapas a la vez, el visible y el de durezas, ha ayudado a poder resolver en cuestión de segundos problemas que antes tardaba minutos, y esos ajustes finales han pasado de necesitar de 5 a 10 minutos, a unos ridículos 20 a 120 segundos. He tenido problemas porque el mapa de durezas usaba tiles de 32x32 y el visible de 64x64, y el zoom afecta a todos los mapas por igual.
Aparte de eso, he aprovechado para añadir la rueda del ratón a la ventana de selección de tile, que no lo había hecho (por eso hay que probar las cosas antes de subirlas.

Así que aquí os dejo la versión 0.2.0 de Tilemap Editor 2. No os preocupeis, voy a poner un enlace al fichero en el primer mensaje del hilo.
No trae instrucciones (lo siento, pero ya estoy KO con el proyecto, podeis preguntarme las dudas que tengais). Y es sólo el ejecutable para windows, pero si teneis la versión de Linux, el port es básicamente cambiar los binarios y el script de ejecución (o al revés, añadir a aquella versión el DCB y cambiar las carpetas de gráficos y textos por las nuevas).
Tampoco trae código fuente, si a alguien le interesa me lo puede pedir y se lo mando por correo (pero voy a poner como condición que esa persona haya hecho algún juego en Bennu y lo haya subido, pertenezca al Fenix, Bennu o PixTudio team, o que sea un asiduo del foro :P )

yo cumplo las condiciones creo  ;D  gracias.

Okis, pues cuando Drumpi encuentre tu correo, intentaré mandártelo ^^U

Mientras, como no tengo sueño, he preparado un binario para Linux.
Ya sólo me falta un Notepad++ para desarrollar el Echo también en Linux :D :D :D

Pues me ha dado por probar el TME y ...

No he sido capaz de cargar un mapa del Echo. (Si es que se puede). Vale que no me he leído el hilo, así que lo mismo es que no se puede. :D

A ver si ponemos al menos un read.me, y un ficherito de ejemplo para cargar, que soy muy vago y no tengo ganas de comerme el tarro.

Por lo demás.... muuuu friki  y al puro estilo Drumpi.

Mi enhorabuena. :)

Sugerencia:

Cuando intento abrir un tmf, ¿por qué no coge automáticamente el tamaño de este? Lo digo porque el mío si lo hace. :D

Es más, yo lo que hago es crearme un tpr (tile map project) donde tengo asociados las durezas, los gráficos y el mapa de tiles.)

Ahora bien, yo no tengo multicapas como el tuyo. :p


Freee, que no lo pongo porque está muuuuuuuu verde. Que te conozco. :D

A ver. Los mapas del Echo sí que los carga, de hecho, los he puesto de prueba en algún screenshot:

Tienes que darle a abrir, que es el icono de la hoja de papel con la flecha azul que sale.
Busca el fichero tmf, por ejemplo, lvl3_city.tmf.
A continuación tienes que indicar el tamaño de los tiles: 16x16 (el formato TMF contiene sólo información del mapa de tiles, no de los tiles en sí, por eso debes especificar su tamaño y los gráficos que vas a usar... pero no el tamaño del mapa).
Luego buscar el FPG, en este caso, grafs/stylish/level3.fpg
Y ya está, debería cargártelo entero.

Obviamente, a la hora de trabajar es más cómodo usar un TPR, que es un fichero Tilemap PRoject, y como es un proyecto, este sí almacena los datos que necesita el programa para funcionar, y eso incluye el tamaño de tile y el fichero de gráficos (ojo, una vez seleccionado un fichero de gráficos, no se puede cambiar, ni se debe mover el FPG de sitio, aun no he añadido esa funcionalidad al editor, está pendiente). Cuando hayas terminado con el proyecto, usas "guardar como..." y ya lo almacenas como TMF.

Y ojo al dato: ahora puedes abrir el mapa visible y el de durezas a la vez. Las flechas al lado de la lista de mapas (lista verde) te sirve para ordenarlos en profundidad (cuanto más arriba, más adelante está). Y los botones de la zona morada te permiten seleccionar la transparencia de las capas si los pulsas y arrastras.

Ya sé que falta un readme, quería terminarlo ya y ponerme con el Echo, pero cualquier cosa del programa está explicada en este hilo, porque lo fui poniendo a medida que lo implementaba :D
Lo sé, no es excusa ^^U

Ojo, que muchos de mis juegos son compatibles con esta herramienta: Screen Break Time, Drajon Lol: devolución, Boulder, Plaaaa...se ha quedado muy buena noche ¿no? :D

Gracias machote.


Y si, hace fresquito esta mañana. :)