editor y creador de fpgs (8, 16, 32b) código bennu

[SplinterGU]

yo lo estuve probando, pero tiene unos cuantos bugs... algunos son:

- al usar varias veces una opcion el programa se cierra solo...
- en los casos de seleccion de objetos, (sea el que sea, navegador de fpg, grafico activo, letra font activa, etc) no marca el objeto, nunca sabes con cual estas trabajando.
- hay opciones que no se usan, deberian ser eliminadas o comentadas.
- los ids que no tienen graficos no deberian ser mostrados en el visor del fpg.

y por ahora no me acuerdo mas.

[Prg]

eso de que se cierra solo es nuevo. ok, aquí tendré que ver qué es lo que está sucediendo.

- en los casos de seleccion de objetos, (sea el que sea, navegador de fpg, grafico activo, letra font activa, etc) no marca el objeto, nunca sabes con cual estas trabajando.

Buen punto, tendré que colocar un letreto en cada uno, aunque la verdad no lo había considerado pues al estar trabajando te das cuenta qué es lo que presionaste, y qué es lo que buscas, pero un write sería la solución, o gráficos distintos.

- hay opciones que no se usan, deberian ser eliminadas o comentadas.

ok,. actualmente todo es utilizado, excepto 2 opciones que eliminaré si no logro hacerlas funcionar, a propósito, en mi versión, ya podemos usar 8 bits, pero los textos no se ven por se blancos (al igual que el fondo), veré que puedo hacer ahí.

- los ids que no tienen graficos no deberian ser mostrados en el visor del fpg.

esto es necesario pues al trabajar con zonas sin gráficos, debemos ver qué espacio es el que vamos a utilizar, donde sí no deben verse es en el modo compacto, pero si hago esto el programa me saca, pues necesito información del map que existe, y no se qué tiene, pero me genera un problema en el mod_map, tendré que idearme algo.

En lo que respecta a que los gráficos se hacen más grandes al moverse, aquí también tenemos que corregir el error, pero se sale con error del mod_map, posiblemente unos frames por ahí solucionen el problema.

Bueno, lo que más me sorprende es que se salga usando varias veces una opción, si alguien tiene más información sobre el problema le agradecería que comentara un poco. :) . Creo que ésto es lo más urgente a solucionar.

[SplinterGU]

un recuadro sobre la seleccion bastaria...

me refiero a que si tengo un fpg con un grafico con codigo o id 100, no tengo porque ver los graficos del 1-99 y del 101 al 999, a medida que los voy ingresando, ir viendolos, tal cual el fpgedit... asi deberia ser... incluso asi no hay que scrollear constantemente toda el panel para ver que graficos hay y cuales estan libres... ver los vacios no es practico...

no con todas las opciones pasa, con algunas, si la escoges mas de una vez sale... pero necesitas mas informacion, es obvio...

[Prg]

hola, eh estado meditando todo lo que me han dicho, y planeando un poco todo, y me han surgido algunas cosas:


1. bueno, primero con lo de los procesos sin gráficos ¿qué me recomiendan?, tengo un montón de cosas que se me ocurrieron, pero la verdad no me gustan.

2. El programa se cierra cuando se usa la barra de desplazamiento y se llega casi al extremo, si se soluciona el problema anterior, se solucionaría este. Tambien se cerraba algunas veces al navegar por los directorios, espero que esto ya esté solucionado (coloqué dos frames estratégicamente, esperando sea un respiro para el sistema).

3. Cuando un proceso recibía un gráfico, colocaba el punto de control 0 en el extremo superior izquierdo para posicionarse correctamente, lamentablemente esto hace que se pierda este punto de control tan importante, ¿qué me recomiendan que haga? el problema es que algunos gráficos tienen el punto de control en una esquina, otros en el centro, otros abajo, etc., según el juego y el programador.

gracias...

bueno, esto es un poco de lo que me detiene, si a alguien se le ocurre algo, le agradecería. :)

[SplinterGU]

1. crear solo procesos para los graficos existentes
2. idem
3. se me ocurren 3 formas:
a) cuando editas un grafico, los puntos de control podrian no estar fisicamente en el grafico, sino en una tabla publica/local al proceso o ser procesos independientes hijos del proceso grafico padre, y solo los pondrias fisicamente en el grafico al momento de guardarlo (en el grafico o en otro grafico clonado, en otra lib)
b) calcula las coordenadas x e y del proceso relativas al punto de control 0, la cuestion en esto es que tenes q hacer lo mismo para todas las funciones/procesos donde visualizaras el grafico.
c) podes guardar el punto de control 0 original y cualquier operacion de edicion de este punto, trabajaria sobre esta variable backup... aunque queda un poco desprolijo, es la mas rapida.

[Prg]

1. crear solo procesos para los graficos existentes

para esta opción, cuando son muchísimos gráficos serían muchísimos procesos en pantalla, y el utilizar varios fpgs, sería dormirlos o cambiar los gráficos y tener los procesos del fpg más grande (con más gráficos), el problema viene con fpgs con 900 gráficos, serían vastantes procesos  :-\ , se me ocurre también probar con un array que almacene los gráficos de cada proceso y se esté actualizando cada que haces un movimiento. Bueno, provaré las 2 opciones, la que funcione mejor :)

3. se me ocurren 3 formas:
a) cuando editas un grafico, los puntos de control podrian no estar fisicamente en el grafico, sino en una tabla publica/local al proceso o ser procesos independientes hijos del proceso grafico padre, y solo los pondrias fisicamente en el grafico al momento de guardarlo (en el grafico o en otro grafico clonado, en otra lib)
b) calcula las coordenadas x e y del proceso relativas al punto de control 0, la cuestion en esto es que tenes q hacer lo mismo para todas las funciones/procesos donde visualizaras el grafico.
c) podes guardar el punto de control 0 original y cualquier operacion de edicion de este punto, trabajaria sobre esta variable backup... aunque queda un poco desprolijo, es la mas rapida.

me gustaron las 3,  :D .
creo que provaré con la b y c.

gracias.

ayer, después de publicar el mensaje, estaba pensando en hacerlos relativos (el b), pero es más fácil el c... o el b.... bueno, provaré con los 2 .

gracias nuevamente.

[SplinterGU]

1. crear solo procesos para los graficos existentes

para esta opción, cuando son muchísimos gráficos serían muchísimos procesos en pantalla, y el utilizar varios fpgs, sería dormirlos o cambiar los gráficos y tener los procesos del fpg más grande (con más gráficos), el problema viene con fpgs con 900 gráficos, serían vastantes procesos  :-\ , se me ocurre también probar con un array que almacene los gráficos de cada proceso y se esté actualizando cada que haces un movimiento. Bueno, provaré las 2 opciones, la que funcione mejor :)

3. se me ocurren 3 formas:
a) cuando editas un grafico, los puntos de control podrian no estar fisicamente en el grafico, sino en una tabla publica/local al proceso o ser procesos independientes hijos del proceso grafico padre, y solo los pondrias fisicamente en el grafico al momento de guardarlo (en el grafico o en otro grafico clonado, en otra lib)
b) calcula las coordenadas x e y del proceso relativas al punto de control 0, la cuestion en esto es que tenes q hacer lo mismo para todas las funciones/procesos donde visualizaras el grafico.
c) podes guardar el punto de control 0 original y cualquier operacion de edicion de este punto, trabajaria sobre esta variable backup... aunque queda un poco desprolijo, es la mas rapida.

me gustaron las 3,  :D .
creo que provaré con la b y c.

gracias.

ayer, después de publicar el mensaje, estaba pensando en hacerlos relativos (el b), pero es más fácil el c... o el b.... bueno, provaré con los 2 .

gracias nuevamente.

no hay mucho problema con la cantidad de procesos, la idea es siempre trabajar con 1 fpg a la vez... pero en el punto 1, no me referia necesariamente a 1 proceso por grafico, sino a los graficos que se ven en pantalla que supongo son 1 proceso cada 1, no mire tu codigo...
igual son todas opciones, de las cuales pueden quedar 1 o ninguna...

[Prg]

Nueva versión, al principio del tema, en el primer post, agrego algunas imágenes que espero sean de ayuda.

he eliminado los las descargas que hacían uso de espacio en el foro, las otras las elimino después (... son bastantes...).

sólamente queda el tema de la fuente que está fea, y necesitamos cambiarla, y algunas cosillas que se me pasaron.

y para lo de las fuentes, una última pregunta:
si fuera problema del editor, se supone que desde el código se verían los carácteres raros  ¿no es así? y las fuentes bdf mostrarían el erro
intenté ya con lo que me decían, pero el error no lo erradiqué, la fuente del sistema y los bdf presentan correctament los textos tal y como aparecen en el editor, pero los fnt no. Bueno, este es mi comentario pregunta.

olividaba decirles que la bara de desplazamiento ha quedado deshabilitada por ser una gran fuente de errores. :) luego lo corrijo.

[TYCO]

Cuando le das al "+" en estando en "Puntos de control" sube de dos en dos, sin abrir ningún fpg... a parte que no debería dejar entrar sin no está abierto un fpg.

Lo de los Créditos Mola XD pero lo esencial es que funcione esto a la perfección y que muestre un Texto descriptivo de cada Contador que hay por ahí que no se sabe para que son.

Eso de que al entrar te pregunte 8,16 o 32 no sabes ni para que es.... y ese pantalla no debería salir cuando crear un nuevo FPG???

Tiene buena pinta.

[Prg]

Cuando le das al "+" en estando en "Puntos de control" sube de dos en dos, sin abrir ningún fpg... a parte que no debería dejar entrar sin no está abierto un fpg.

ya veo, no le j¡he puesto atención a eso porque pensé que nadie iba a intentar modificar algo que sabe no existe... pero todo eso se arregla.

Lo de los Créditos Mola XD pero lo esencial es que funcione esto a la perfección y que muestre un Texto descriptivo de cada Contador que hay por ahí que no se sabe para que son.

ehmmm... bueno, para eso eran las imágenes que agregué al principio con su descripción. Quizá no son muy claras... je je je.

Eso de que al entrar te pregunte 8,16 o 32 no sabes ni para que es.... y ese pantalla no debería salir cuando crear un nuevo FPG???

eso no puede ser porque el modo de video afecta al programa y a todos los fpgs, por tal motivo sólo se puede elegir al principop del programa.

Gracias.

[SplinterGU]

en que afecta al programa el modo inicial de video?

[Prg]

Supuestamente la forma en que cargará los gráficos, pero creo que en modo 8 bits no se pueden cargar gráficos png de 32, y por supuesto los gráficos del programa.

bueno, faltan algunas pruebas con este tema, pero en configuración inicio deciden si abrirá o no el progarama al iniciar.
El que un fichero sea 8, 16 o 32 bits lo desiden todos sus graficos, y la profundidad de los gráficos (8,16,32) se puede observar en el primer recuardo negro de la pantalla de visualización de gráficos.

A propósito Splinter...
Cuando se modifica el punto de control 0 de un gráfico (centro), y está dibujándose, sucede algo raro con él, parece que es un restore incompleto.

También. me ha emocionado vastante el hecho de que ya podemos reproducir mp3, lástima que se perdió el archivo. pero felicidades por el logro.

[SplinterGU]

ummm, si se pueden cargar en 8 mapas de 32 y de 16... pero solo en 32 bits los png son de 32 bits...

podria ser eso del punto de control, ya lo vere.

bueno, no habia terminado todavia la implementacion estaba en pleno desarrollo, pruebas y correcciones, no habia logrado reproducir nada todavia, pero bueno, tenia mucho escrito, ya no lo hare de nuevo...

con respecto al png, creo que lo mejor es incluir un parametro extra (opcional) que indique la profundidad, y entonces se acaban los problemas... o que lo cargue sin modificacion... ya lo vere tambien...

[Prg]

con respecto al png, creo que lo mejor es incluir un parametro extra (opcional) que indique la profundidad, y entonces se acaban los problemas... o que lo cargue sin modificacion... ya lo vere tambien...

incluir un parametro extra (opcional) que indique la profundidad Esto estaría increíble  :)

ummm, si se pueden cargar en 8 mapas de 32 y de 16... pero solo en 32 bits los png son de 32 bits...

lo que yo observaba es que los gráficos de 32 bits en modo 8 bits no se visualizaban, al menos los gráficos cargados con la función load_png (los del propio programa, incluso me tocó hacer una carpeta con los gráficos a 8 b para poder cargar ese modo de video).

[SplinterGU]

no se visualizan es cierto, pero se cargan en memoria, luego tendrias que convertirlo vos a mano (caso para fpg, claro esta), pero quizas lleve cpu... es importante trabajar con 1 solo fpg a la vez.
Yo como esto es una aplicacion, que no requiere gran rendimiento, sugiero usar 32 bits siempre.