[Multi] Sprite_gen, el editor de sprites

Darkangelus escribió:Pues queda genial, voy a intentar hacer un monstruo más grande tipo machaca 480x272 X-D


Antes de que hagas nada, deja que te explique mi idea sobre el juego:

La idea es que los enemigos no maten directamente, al atizarte, si no que te roben energia de una barra que luego podras reponer tomando pocimas XD (de ahi que los enemigos tiendan a ser "pesados" por que si fueran de esa forma y con solo rozarte, "piok", iba a tener que sacar el juego con POKE de vida infinitas integrado XD).

La idea es hacer una especie de aventura en un castillo , por lo que habra que diseñar elementos de decoracion tales como armaduras, escudos, armas, banderas que decoren los fondos y luego cofres que se abriran resolviendo algun tipo de puzzle (es decir, el juego mezclara plataformas, aventuras y puzzles del estilo del juego Onimusha 3 de PS2)

La "gentuza" que pulule en el juego, tendra el objetivo de entorpecer la tarea y que el juego no decaiga y todavia no he pensado si Piñaman contará con algun tipo de arma de ataque o simplemente, debe evitar a los bichos mientras resuelve el tema.

¿Pantallas del juego? Las que queramos, pues realmente, el unico limite es que tenemos 100 sprites para decorar hasta 64 pantallas que se relacionen desde el editor de mapas, pero eso no impide que se puedan tener varios sets de sprites/mapas.

De momento, lo interesante es/era el tema de la animacion de los enemigos y como interactuan con los elementos, pero graficamente, las cosas pueden ser un boceto de lo que luego serán (si es que se quiere mejorar algo) y no nos tiene porque preocupar que el juego se vea algo parco en ciertos detalles, si no que todo funcione bien y nos dé un buen abanico de posibilidades ;)
Vamos a ver que te parece esto nuevo, recien sacado del horno.

La armadura me a costado un huevo xD

Adjuntos

Darkangelus escribió:Vamos a ver que te parece esto nuevo, recien sacado del horno.

La armadura me a costado un huevo xD


El cofre te lo he aceptado, pero la armadura no porque es muy pequeña y ya tengo una que he hecho yo.

A partir de ahora, seguiremos el tema en este hilo del foro de PSP:

http://www.elotrolado.net/showthread.php?s=&threadid=755399

Mirate la demo 3 que he colgado, donde se puede ver el juego (52 pantallas) desde una optica muy arcade (me temo que tengo que pensar un poco en el argumento y todavia tengo que diseñar mas cosas, pero es un ejemplo)
Bueno Hermes, eres un tio grande, tienes problemas creando sprites y vas y te creas tu propio programa.
A ver si de mayor puedo ser como tu!! XD XD
hermes a mi me vendria bien un programa como este que se pueda editra por cuadritos o pixel yo que se pero solo le los spf o algo asi me gustaria una version que lea todos los formatos posibles de imagen
Fusion_X escribió:hermes a mi me vendria bien un programa como este que se pueda editra por cuadritos o pixel yo que se pero solo le los spf o algo asi me gustaria una version que lea todos los formatos posibles de imagen


Vamos a ver... el programa soporta sus formatos particulares y formato BMP. Puedes importar un BMP como el primero de los sprites y el adoptará su paleta o tratara de generar una paleta a favor de ese BMP, o puedes importarlo en otra posición, con lo cual se tratará de aproximar colores a la paleta de colores que usa el programa.

Para exportar, incluso es mas facil, porque eliges un nombre y el te creará de forma automatica, una ristra de ficheros BMP con todos los sprites del documento.

Ahora bien, si tu lo que quieres es abrir directamente, un fichero GIF o PNG, pasan dos cosas:

- La primera, es que me pides que me complique la vida añadiendo un código que no me pertenece y con los mismos problemas que al importar los BMP por el tema de la paleta.

- La segunda, es que si tu objetivo es importar graficos de otras aplicaciones para no usar el editor del que dispone el programa, es que no necesitas mi programa. Y si es solo por una importacion ocasional o por usar el efditor de mapas, entonces amigo mio, puedes importar en formato BMP (y todos los programas de dibujo lo soportan)

Como nota aclaratoria y para que en el futuro no se produzcan este tipo de peticiones, esta utilidad ha sido diseñada por mí para cubrir mis necesidades y cubrir un hueco que no me cubren ni el Paint de Windows, ni el Corel PhotoPaint que compre hace años, asi que no me interesa tratar de reemplazar a ninguno de estos, ni trabajar de base con estos programas (o similares) para luego hacer el ultimo paso en sprite_gen.

El formato SPF es un formato muy sencillo de comprender y tal vez alguno de vosotros quiera por ejemplo, usar formato PNG en sus juegos, por el tema de la compresion.

Entonces, es tan sencillo como bajarse la libpng de turno y crear un programita que acepte un archivo SPF de entrada y exporte a PNG.

En ese caso, yo puedo hacer que desde mi programa se invoque una aplicacion externa que trabaje en modo consola y automatizar el proceso (asi no tengo porque añadir codigo que no quiero añadir y se os dota de la posibilidad de invocar aplicaciones externas al programa para trabajar)

Lo que no tiene sentido es que se busquen vias para hacer el trabajo desde otros programas, cuando he creado éste para trabajar desde el: para eso, trabajais desde los otros programas y todos contentos ;)
bien lo he entendido lo tendria qe haber pensado un poco mas = que en el otro post mio que es el de el juego de lucha
Fusion_X escribió:bien lo he entendido lo tendria qe haber pensado un poco mas = que en el otro post mio que es el de el juego de lucha


De todas formas, he estado trabajando hoy en la aplicacion y aparte de arreglar un olvido que tuve, le he añadido la posibiidad de ejecutar una aplicacion externa de nombre plugin.exe que recibe la ruta del documento .spf (con lo cual se podria hacruna exportacion mas personalizada).

Tambien le he añadido otra funcion muy poderosa: el Portapapeles de Windows, lo cual permite exportar/importar bitmaps de forma rapida incluso entre otras aplicaciones ;)

Seguramente, publique esta nueva version entre hoy y mañana :)
Hermes escribió:...


Imagen

Nada mas que añadir. [jaja]
Imagen
¡¡Jaja, soy un copias [oki] [oki] [oki] !!
¡¡Espero con impaciencia la versión nueva!!
ChaoOoOo!
Actualizacion Beta 1.9

Cambios:

En Paleta:

- Introducida una nueva gama de colores, aprovechando una serie de colores que no se utilizan

- Corregido un error cuando se importaban paletas de mas de 64 colores desde un bitmap.

- Al importar un bitmap o desde el portapapeles al primer sprite, ahora se pregunta si se quiere importar la nueva paleta (antes era automatico) o utilizar los colores de la paleta actual para aproximar colores.

A nivel importacion/ exportacion:

- Añadida la posibilidad de importar bitmaps de dos colores

- Añadida la posibilidad de copiar/pegar imagenes al portapapeles de Windows.

General:

- Funcion para rotar sprites desde -360 a 360 grados

- Añadida una funcion de reemplazo de objetos en el editor de mapas.

- Añadido en el menu (en Tools) , una funcion para llamar a una aplicacion externa, de nombre plugin.exe que recibe como parametro la ruta del documento actual, con proposito general (puede utilizarse para convertir el documento .spf a otros formatos graficos)

- Corregidos algunos problemas menores que me he encontrado por el camino.
Hola!

Muy bien como siempre Hermes, una pena que sea con librerias de windows (para hacer port a linux :P)

Funciona bien en linux como ya dije hace tiempo, pero supongo que el tema del plugin no irá, ya que al querer cargar un .exe pues no lo ejecutará.

Entonces yo me pregunto... ¿No seria posible crear un plugin portable, que se pueda compilar en linux y llamarlo plugin.exe?

Segun dices tu programa le pasa el nombre del proyecto y ya pues el plugin lo trata y tal, yo he creado una prueba donde recojo el parametro y lo imprimo, pero el programa tuyo me dice File not found y tengo el plugin.exe en el mismo directorio (un plugin.exe creado por mi claro), supongo que será cosa de wine :PP

Un saludo.
Fox escribió:Hola!

Muy bien como siempre Hermes, una pena que sea con librerias de windows (para hacer port a linux :P)

Funciona bien en linux como ya dije hace tiempo, pero supongo que el tema del plugin no irá, ya que al querer cargar un .exe pues no lo ejecutará.

Entonces yo me pregunto... ¿No seria posible crear un plugin portable, que se pueda compilar en linux y llamarlo plugin.exe?

Segun dices tu programa le pasa el nombre del proyecto y ya pues el plugin lo trata y tal, yo he creado una prueba donde recojo el parametro y lo imprimo, pero el programa tuyo me dice File not found y tengo el plugin.exe en el mismo directorio (un plugin.exe creado por mi claro), supongo que será cosa de wine :PP

Un saludo.


Hombre, el programa está construido usando de base las MFC y aunque me he abstraido bastante de ciertos usos al principio (por ejemplo, utilizo muchas funciones externas que no forman parte de ninguna clase y variables de tipo global, aunque la mayor parte de ellas trabajan sobre una clase en concreto que es la que se encarga de generar la visualizacion en la ventana o incluso los botones que dibujo e el area de ventana, que son de fabricacion propia y casi todo se dibuja en pantalla con funciones basicas), existen bastantes piezas de código que probablemente, tengan una portabilidad bastante problematica.

Ademas, uno debe elegir el camino que le resulte mas facil y da la casualidad de que yo sobre Windows, lo tengo mucho mas facil para desarrollar este tipo de programas, pues cuento con un entorno muy bueno, libros en español y documentacion abundante, aparte de experiencia para dicho entorno.

Aparte de eso, se que la aplicacion bajo Windows llega a mas gente que bajo Linux y que bajo Linux, corre utilizando WinE y la perdida de rendimiento, será infima, asi que todos ganamos.

El problema es que yo necesitaba crear una aplicacion rapidamente, que en cierta manera, hay gente que califico de reinventar la rueda, aunque a medida que el programa muestra sus cartas y crece, se va mostrando mas util para hacer ciertos trabajos.

Y es que estas cosas funcionan así: primero creas el armazón basico del programa y puesto que ese programa es tuyo y lo conoces de pe a pa, te resulta tremendamente sencillo potenciarlo, dedicandole un día de trabajo para añadirle nuevas cosas, a tu antojo.

Dentro de un tiempo, veras como hay gente que me pide el codigo fuente del programa, porque quieren añadirle no se que o no se cuanto, pero en este caso, se van a encontrar con un negativa

¿Por que? Pues porque soy "raro" y me molestan algunos pequeños detalles "insignificantes" y a otros detalles que deberian ser mas importantes, no les doy ninguna importancia (por eso no tengo ningun inconveniente en publicar codigo fuente con una licencia mucho mas libre que la GPL (licencia que considero virica, por cierto) tanto para PSP como para NDS y en compartir practicamente, todo lo que hago y hay cosas que están cerradas a cal y canto).

Con respecto a que no te funcione la aplicacion plugin, no se exactamente por que será: necesitaría mas datos, como conocer en que ruta invoca el programa.

Para invocar a plugin.exe, el programa obtiene una cadena de la clase aplicacion donde se especifica la ruta para cargar el fichero .hlp del programa y la recorta para anular el nombre del fichero (con lo cual, obtengo la ruta donde está el ejecutable, sprite_gen.exe, puesto que sprite_gen.hlp debería estar al lado, al igual que plugin.exe) y luego se llama a la funcion system() con la ruta completa del ejecutable plugin.exe y la dell documento .spf de turno

En mi codigo, se utiliza tanto '\' como '/' para detectar los directorios, al menos en mis propias funciones (una vieja costumbre)

El problema podria estar en que Linux le pase un argumento al ejecutable sprite_gen.exe tipo unix (ya sabes tipo /hola/adios/sprite_gen.exe) y la clase aplicacion al tratar de obtener la ruta para el archivo HLP , solo utilice el caracter '\' como separador entre directorios, creando una mala ruta.

Puedo tratar de obtener el parametro de la aplicacion directamente y pasarle un "filtro " propio a ver si lo soluciono y subirte el ejecutable.
Hola!

Hermes escribió:Hombre, el programa está construido usando de base las MFC y aunque me he abstraido bastante de ciertos usos al principio (por ejemplo, utilizo muchas funciones externas que no forman parte de ninguna clase y variables de tipo global, aunque la mayor parte de ellas trabajan sobre una clase en concreto que es la que se encarga de generar la visualizacion en la ventana o incluso los botones que dibujo e el area de ventana, que son de fabricacion propia y casi todo se dibuja en pantalla con funciones basicas), existen bastantes piezas de código que probablemente, tengan una portabilidad bastante problematica.

Ademas, uno debe elegir el camino que le resulte mas facil y da la casualidad de que yo sobre Windows, lo tengo mucho mas facil para desarrollar este tipo de programas, pues cuento con un entorno muy bueno, libros en español y documentacion abundante, aparte de experiencia para dicho entorno.


Te entiendo perfectamente, yo por ejemplo aunque estoy estudiando C++ (por mi cuenta), cuando mi novia me dice que necesita un programa se lo hago con python que es el camino que me resulta más facil, ya que tengo más experiencia, buena documentación y bueno, me permite programar en linux y hacerlo funcionar en windows :P


Hermes escribió:Aparte de eso, se que la aplicacion bajo Windows llega a mas gente que bajo Linux y que bajo Linux, corre utilizando WinE y la perdida de rendimiento, será infima, asi que todos ganamos.


Sí, excepto fallos visuales, como por ejemplo labels que se salen de los botones (tonteria realmente), todo está perfecto.



Hermes escribió:El problema es que yo necesitaba crear una aplicacion rapidamente, que en cierta manera, hay gente que califico de reinventar la rueda, aunque a medida que el programa muestra sus cartas y crece, se va mostrando mas util para hacer ciertos trabajos.

Y es que estas cosas funcionan así: primero creas el armazón basico del programa y puesto que ese programa es tuyo y lo conoces de pe a pa, te resulta tremendamente sencillo potenciarlo, dedicandole un día de trabajo para añadirle nuevas cosas, a tu antojo.


Esto siempre pasa si, al principio pones lo básico y luego conforme van saliendo ideas pues se va mejorando y ya es algo totalmente distinto al resto de programas, pero claro... no todo se puede hacer en el primer momento :P




Hermes escribió:Dentro de un tiempo, veras como hay gente que me pide el codigo fuente del programa, porque quieren añadirle no se que o no se cuanto, pero en este caso, se van a encontrar con un negativa

¿Por que? Pues porque soy "raro" y me molestan algunos pequeños detalles "insignificantes" y a otros detalles que deberian ser mas importantes, no les doy ninguna importancia (por eso no tengo ningun inconveniente en publicar codigo fuente con una licencia mucho mas libre que la GPL (licencia que considero virica, por cierto) tanto para PSP como para NDS y en compartir practicamente, todo lo que hago y hay cosas que están cerradas a cal y canto).


Bueno, esto ya es al gusto del programador, yo soy partidario de publicar el código, de hecho casi todo lo que tengo es python y al ser interpretado el mismo ejecutable es el código fuente.
Pero vamos, veo normal que cada persona haga lo que quiera con su programa, y nadie deberia de dejar de agradecerte el curro que estás haciendo :)


Hermes escribió:Para invocar a plugin.exe, el programa obtiene una cadena de la clase aplicacion donde se especifica la ruta para cargar el fichero .hlp del programa y la recorta para anular el nombre del fichero (con lo cual, obtengo la ruta donde está el ejecutable, sprite_gen.exe, puesto que sprite_gen.hlp debería estar al lado, al igual que plugin.exe) y luego se llama a la funcion system() con la ruta completa del ejecutable plugin.exe y la dell documento .spf de turno

En mi codigo, se utiliza tanto '\' como '/' para detectar los directorios, al menos en mis propias funciones (una vieja costumbre)

El problema podria estar en que Linux le pase un argumento al ejecutable sprite_gen.exe tipo unix (ya sabes tipo /hola/adios/sprite_gen.exe) y la clase aplicacion al tratar de obtener la ruta para el archivo HLP , solo utilice el caracter '\' como separador entre directorios, creando una mala ruta.

Puedo tratar de obtener el parametro de la aplicacion directamente y pasarle un "filtro " propio a ver si lo soluciono y subirte el ejecutable.


Bueno, esto realmente puede ser un problema mio. No sé la estructura que debería de tener un plugin para tu programa, yo simplemente me puse a probar a ver si hacia algo, así que no te molestes realmente ya que de hecho no he logrado ni hacer funcionar mi """"plugin""""" bajo windows.

hablas de un fichero .hlp, a mi no me viene, sólo viene el exe y el pdf (aparte de la carpeta ejemplos).

Así que bueno, supongo que mi plugin estará mal ya que bueno, seamos sinceros, mi idea de C++ es bastante básica ya que llevo bastante bastante poco con el.

Aqui te dejo lo que hice de prueba (seguro que te ries :P):

#include <iostream>
#include <fstream>
using namespace std;

int main(int argc, char** argv)
{
    ofstream myfile;
    string frase = argv[1];
    myfile.open("prueba.txt");
    myfile << frase;
    myfile.close();

    return 0;
}


Como ves, pensé que el nombre del documento se enviaba como parámetro y lo recogia y escribia el nombre en un txt, pero parece que no funciona o estoy realmente perdido :P


Un saludo!
Tu programa no es el problema: soy yo XD

Veras, cuando habilité la funcion, en vez de llamar a un ejecutable, llamaba un fichero .bat que devolvía el parametro como eco y ponia el sistema en pausa para permitir visualizarlo.

Pues bien, para componer la cadena de la linea de comandos, utilizo una funcion de una clase que trabaja de forma equivalente a sprintf y ahí es donde he cometido el error: al borrar el nombre del fichero bat para sustituirlo por el de plugin.exe, me he cargado la 's' que deberia haber para que la cadena de formato quedara como %splugin.exe y claro, dificilmente va a funcionar así porque al traducir %plugin.exe, lo que hace es visualizar la DIRECCION en hexa de la cadena (%p es puntero) seguido de lugin.exe ([carcajad] que error mas tonto [carcajad] )


Bajate de nuevo la aplicacion que ya está corregida :)
Para mi sigue igual, me sale una ventana de msdos que se cierra instantaneamente tenga o no el plugin.exe.


Un saludo.
Prueba con este que te adjunto. Si sigue sin rular, te subo una nueva version que me proporcione los datos que necesito.

Adjuntos

Nada, abro un proyecto, le doy a call external plugin y se abre la ventana de MSDOS y se cierra corriendo, y no veo que haga nada.

Un saludo.
Bueno, prueba esto que seguramente chute y primero te muestra una ventana con la ruta del ejecutable al completo y el parametro que recibe, con lo cual sabremos si no funciona ahora, la causa probable.

http://mods.elotrolado.net/~hermes/sprite_gen_v1.9B_Beta.rar
Bueno, con tu plugin pues me da la ruta correcta del pluginy la del proyecto, luego se abre la ventana msdos y se cierra instantaneamente, no veo que haga nada.

Un saludo.


EDITO: Qué gracioso, dije de probar en linux, así que nada, pruebo (con mi plugin) y me dice "Z:/home/jesus/psp/sprite_gen/plugin.exe" "Z:/home/jesus/psp/sprite_gen/Untitled.spf" y digo, bah, esto no va a funcionar, pero SI, ha funcionado perfectamente, tengo un fichero llamado prueba.txt que pone lo siguiente:

Z:\home\jesus\psp\sprite_gen\Untitled.spf

y es efectivamente lo que tiene que hacer :)

NOTA: eso de unidad Z será cosa de wine :P

Un saludo.
¿Funciona en Windows98? Lo digo porque me han regalado un PC con Windows98, no está tan mal. ;)
Update 1.9B

Bueno, he subido la actualizacion para llamar a la aplicacion externa desde Wine, sin que te presente la ventana de mensaje (toy algo petado de curro ultimamente y voy ralentizado en temas de programacion XD)
Gracias hermes :)

Buen trabajo como siempre :)


Un saludo.
ei! gracias por el gran trabajo de currarte este programa!!
Desarchivado a petición de Hermes
jiXo escribió:Desarchivado a petición de Hermes


Gracias nen ;)

Bueno, pues he subido una nueva versión, la 2.0 que corrige problemas con la importación de imagenes desalineadas desde el portapapeles y en la importación de bitmap.

Por otro lado, el hilo queda abierto por si teneis algun tipo de problema con la aplicación o alguna duda para exportar los bitmaps o mapas.
Hilo desarchivado a petición de Hermes
Gracias jiXo.

Bueno, he subido la nueva version 2.2 del programa y me he dado cuenta que la antigua aquí era la 2.0B XD

La nueva versión aporta soporte para RGB5A3 que es uno de los formatos de color de Wii (de 16 bits concretamente) en las exportaciones .C
78 respuestas
1, 2