Baneado
Ya he hecho mi primer pong y mi primer juego de un laberintoa ver si a este ritmo cuando salga wiz tengo algo preparado pero lo dicho poquito a poco.
Por cierto no me ha quedado muy claro si es mejor separar los fpg en enemigos, fondos...y con que programa hacer los graficos porque hasta ahora estoy con mspaint y paint.net...
Un saludo
Akibaranger!
por curiosidad, como usas los fpgs?? en 8 o en 16 bits?
Baneado
Empeze con la opcion de los 16 bits porque el manual que tengo de curso de fenix decia que asi iban a ser sus ejemplos pero creo que para juegos mas grandes estilo rpg y aventuras y demas me gustaria hacerlos en 8 al principio a ver como van de rapidez.
Es que los graficos que puedo conseguir con paint dan penilla...
◄|| SECHS ||►
Lo de dividir en varios FPG va a gustos.
Si el juego es simple mete todo en un FPG. si la cosa se complica, usa varios.
Lo de FPGs distintos viene de put. mad. para hacer enemigos con aspecto distinto; por ejemplo, si quieres hacer un juego en el que haya enemigos con la mísma lógica pero distinto aspecto, sol tienes que programarlos una vez, y dependiendo del fpg que este cargado, tendrán una pinta u otra.
Google stadia es un fracaso, google stadia funciona mal, google admite su fracaso con stadiala latencia es el problema intrinseco de stadia, el público abandona google stadia, stadia mal.
Baneado
Y una pregunta un poco chorra, estoy pensando en cambiarme a linux, este sistema por lo que he leido ya hora mismo que loe stoy probando es mejor para programar, casi todos los programas referentes a fenix soncompatibles, quiero decir fpg edit y demas...
Sega Shinja
Para programar en Fenix te da igual en qué sistema operativo lo hagas.Iniciado por Jonazan2
Ánimo, que ya te queda menos (para publicar tu primer juego!).
Baneado
Joer en poco tiempo estoy intentando hacerlo todo lo mejor posible...ahora solo saber perfeccionar los que tengo e intentar un marcianitos y un breackout...
Por cierto la misma compilacion que tienes en dcb la lee la gp2x o tienes que meterle un interprete para cada tipo de programa
Segata Sanshiro era ironico lo del primer juego jejeje ?
Road to version 1.4!!
Ya llego, ya llego, arf arf. Juer, ni hacer una triple mudanza puede uno
DIV, prodigiosamente programado por Daniel Navarro como PFC, y originalmente llamado Dibujo IV (cuarta version de un editor gráfico llamado Dibujo), fue tomado bajo las manos de Hammer Technologies hasta que quebró, entonces los derechos fueron comprados por Fastrack, que prometieron hacer una version llamada DivWin y le dedicaron un fabuloso equipo dotado de un programador y un PC.Jonazan2, tanto DIV1 como DIV2 son programas que tienen más de 10 años y no funcionan en los ordenadores actuales
Fenix partió de DIV y aún se le parece, pero en estos 10 años ha avanzado mucho y ahora los lenguajes DIV y Fenix son incompatibles. Fenix es ahora mejor en todo, excepto en el entorno de programación que tenía DIV (que no te valdrá para Fenix, y uno de los motivos es que no funciona en los sistemas actuales)
¿Sueno resentido? bueno, si, un poco, despues de ciertas "amenazas" al Fenix Team por "vulnerar patentes" inexistentes hasta ese momento, pues que quereis.
Fastrack siguió el camino de Hammer, y aun en la cuneta, creo que alguien aun tiene la patente.
Fenix no es que sea incompatible con DIV: salvo algunos cambios de sintaxis son iguales... bueno, si, hay más diferencias. Fenix ha mejorado muchísimo, pero aun tiene carencias respecto a DIV, como el modo 8, pero le gana de calle en otros aspectos.
Si aun queréis seguir usando DIV, teneis el proyecto GEMIX, que es 100% compatible con los códigos y formatos de DIV, y añade muchísimas mejoras (por ejemplo, ya tiene 16 y 32 bits de color). No está aun acabado, lo único que hay son algunas betas gratuitas, pero ya tiene casi todo lo de DIV y más. Eso si, aviso: se trata de un proyecto comercial.
Y para los fans de Fenix, Fenix no se ha quedado estancado: BENNUGD es su sucesor parcialmente oficial (lo lleva a cabo uno de sus programadores en plan personal). Tambien tiene muchísimas mejoras de rendimiento, tambien se ha dividido en módulos, para que useis sólo los que necesiteis y ahorreis recursos, o useis el que más os guste (si no os gusta el módulo gráfico por defecto, usad el bennu3D, o cread uno acelerado por openGL o DirectX). Tambien tiene los modos de color de 8, 16 y 32 bits y se están añadiendo cientos de cosas. De momento sólo hay ports para windows y Linux, pero todo se andará.
No es necesario ningun IDE: con tener a mano la documentacion del wiki y un editor de texto, ya vale. Luego os explico un truquito que uso en windows.
Pues ve echando un vistazo al FenixPack de Colombian Developers, lo tienes todo listo, y seguramente no tengas problemas con Vista. Si no, busca, que hace poco han lanzado una nueva version de FlameBirdMX, a ver si así se soluciona.
De todas formas, me parece recordar que en las últimas versiones había un problema por culpa de un fichero con nombre manifest, si mi memoria no me falla, debes borrarlo (haz una copia por si acaso), ejecutar el programa, salir y volver a entrar.
Hay problemas al arrastrar cuando estás programando en varios ficheros distintos, si sólo hay uno no debería darte problemas. Ya te han comentado lo del dcb, así que nada más que añadir.
El fichero es STDOUT.TXT, si ha habido errores tambien está el STDERROR.txt. Estos ficheros son muy útiles, ya que usando la funcion SAY puedes escribir lo que quieras en el stdout.txt en tiempo real (se escribe aunque haya un error en la siguiente instruccion). Yo la uso para ver los valores de las variables y seguir el flujo del programa, porque la consola de comandos es inutil si no hay un frame o si se te cierra la aplicación.Eso no sé si sigue pasando, desde cierta versión dejan de salir errores por la consola y los escribe a unos ficheros sdlout.txt o algo así. Así que hay que irse a donde está el fxc.exe y ver el fichero que ha creado. Pero si ha salido el dcb es que todo va bien
Los gráficos puedes hacerlos con el programa que te de la gana. Luego, con el FPGEdit los arrastras y listo. Un consejo: si no quereis tener serios problemas con las transparencias (a veces, un negro "ligeramente claro" lo toma como transparente al redondear valores, o viceversa) haced los gráficos en PNG con transparencias, y usad sólo el valor máximo y mínimo de transparencia.Ya he hecho mi primer pong y mi primer juego de un laberinto
Por cierto no me ha quedado muy claro si es mejor separar los fpg en enemigos, fondos...y con que programa hacer los graficos porque hasta ahora estoy con mspaint y paint.net...
Un saludo
Lo recomendable es separar los gráficos en varios FPG, más que nada, para ahorrar espacio en memoria: no es sensato tener cargados gráficos que no vas a usar.
No, ninguno son compatibles. Por desgracia es el gran lastre de sistemas no windows. Tienes el fpg.exe y el map.exe en version linux, pero nada como FPGEdit o FNTEdit ni similares.
Tampoco es muy dificil hacerse un programa multiplataforma para estos menesteres usando Fenix: save_fpg (o save_fgc en 092a, lo comentado del problema de patentes, aunque es posible que tambien esté save_fpg, no recuerdo) y save_map (o su equivalente "libre" save_fbm) forman parte del código.
Incluso yo mismo cree una herramienta para intercambio de colores en múltiples ficheros gráficos, si buscas en el foro de Fenix por cambia_color seguro que te sale. Como está hecha en Fenix es multiplataforma, y puede servir de "parche" para crear FPGs, siempre que consigas la IMAGE.DLL compilada para Linux (tiene que haberla, si no, el código fuente viene en la descarga oficial) que es la que uso para cargar gráficos que no sean tipo MAP o BMP.
PD: bueno, creo que es este.
Las dos cosas: el dcb es un archivo compilado que te sirve para cualquier SO o plataforma, pero claro, necesitas el FXI de esa plataforma para ejecutarlo.
Un truco que tengo yo para compilar es usar un IDE básico para escribir código (a mi me gusta el FEdit, que funciona hasta la 084). Cuando tengo el código, copio el FXC, el FXI y las dll a la carpeta donde tengo el código. Luego creo un archivo de texto y escribo estas lineas:
Modo debug
Modo compilacion finalCódigo:fxc -g mi_codigo.prg stdout.txt
Y lo guardo con el nombre compilar.bat (ojo, debes cambiar la extension, y debes poder verla para cambiarla). Así, cada vez que quiero comprobar si funciona la cosa, hago doble clic en compilar.bat, y se me abre el notepad con todos los errores, y si no los hay, arrastro el dcb al fxi y pruebo el juego.Código:fxc mi_codigo.prg
Este truco tambien vale en Linux, y supongo que en MAC. Ahorra mucho tiempo y te olvidas de la consola de comandos.
Creo recordar que hay ficheros para el resaltado de texto para GEdit en el foro de Fenix, incluso hay uno para BennuGD para Notepad++, así como varios más para editores como ultraedit, etc (en el foro de bennuGD están a vuestra disposición).
Buf, me voy a meter los dedos en agua
PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%
Baneado
DRUMPI muchismas gracias por la respuesta me has aclarado muchisimos aspectos, y supongo que a mas gente del foro.
Un lujo
Baneado
Hola, soy nuevo y he leido sobre lo que hablais de DIV2. Yo fui programador en DIV2 hasta que aprendi ensamblador y a programar por mi mismo en pmode (con y sin DPMI) los perifericos que necesitaba (raton, teclado, PIC, PIT, VESA, SB...). La razon de abandonar DIV2 no fue por su modo8 que funcionaba mal al informar de colisiones, si no porque "misteriosamente" el soporte VESA desaparecio en WinNT y sus sucesores. Y tambien porque SoundBlaster se fue al garete y AC97 no habia manera de encontrar info relativa al hardware.
La empresa desarrolladora de DIV2 fue Hammer Technologies y fue vendido a fasttracker, una empresa inglesa que lo compro para que no le hiciera la competencia a DarkBasic, que tambien lo tengo.
Las buenas noticias son que logre encontrar, gracias al DJGPP, la razon de porque los programas MsDOS no tienen acceso a VESA: por que los imbeciles de M$ han estado usando codigo del Windows 3.11 (si, Windows 3.11) en el NT (en la serie Win9x no). Dicho codigo es de 16bits y trabaja con descriptores de 16bits, no de 32bits, asi las llamadas a "set segment limit" solo veian 64MB, y no los 4GB de limite que se necesitaban para el acceso FLAT a la memoria. ¿Forma de solucionarlo? Muy simple. WinNT hace llamadas al DOS para ajustar sus descriptores, luego, basta con seguir dichas llamadas: "get descriptor attributes" y "set descriptor attributes". Perdi, por una estupidez mia, el programa que hice durante el verano que parcheaba ejecutables EXEs descomprimidos y con su perte binaria extraida para sustituir las llamadas a "set segment limit" por "get descriptor attributes" y "set descriptor attributes".
Fue entonces cuando me di cuenta que Windows no merece la pena y me pase a Linux.
Actualmente estoy desarrollando un juego ActionRPG para Linux con personajes en 2D (¡que remedio!) y escenarios en 3D con efectos de iluminacion y sombras arrojadas y deteccion de colisiones triangulo vs triangulo en trayectorias rectilineas y con offscreen rendering usando OpenGL 2.0 que, espero, lo terminare para el final del verano y si la cosa me queda bien lo portare a Wizz
Bueno, que me lio con mis cosas, en resumen, DIV2 R.I.P y Fenix, pues esta muy bien como curiosidad, pero es mejor que aprendas ensamblador (aunque las arquitecturas actuales son una mierda para aprender) y C. Del C++ y de la POO no te preocupes; es para tontos y ademas es una estafa creada para justificar las patentes de sw, porque al final todo debe traducirse a ensamblador y ensamblador no es un leguaje de la POO.
Yo uso el GAS y el GCC, incrustando el codigo ASM en los fuentes de C.
< - >Ejem.... eso depende del ancho del bus de datos. Sin son 8bits por transferencia, si, va mas lento, pero si son 16bits reales de transferencia entonces va exactamente igual. Otro tema es que para cambiar un color en toda la pantalla solo tengas que alterar un color de la paleta. Yo aun no se casi nada sobre la Wizz, pero si tiene OpenGL ES1.1 me parece que el ancho de bus va a ser de >=16bits seguro.
No importa la cantidad de informacion a mover, si no el numero de trasferencias necesarias y la velocidad del BUS por el cual se van a realizar los movimientos.
En suma, que 8bits NO son mas rapidos que 16bits en sistemas de 16bits o más.
He dicho
Última edición por flozanot; 04/03/2009 a las 13:37 Razón: Edición automática anti doble-post.
Super Moderador
Hola y bienvenido.Ejem.... eso depende del ancho del bus de datos. Sin son 8bits por transferencia, si, va mas lento, pero si son 16bits reales de transferencia entonces va exactamente igual. Otro tema es que para cambiar un color en toda la pantalla solo tengas que alterar un color de la paleta. Yo aun no se casi nada sobre la Wizz, pero si tiene OpenGL ES1.1 me parece que el ancho de bus va a ser de >=16bits seguro.
No importa la cantidad de informacion a mover, si no el numero de trasferencias necesarias y la velocidad del BUS por el cual se van a realizar los movimientos.
En suma, que 8bits NO son mas rapidos que 16bits en sistemas de 16bits o más.
He dicho
En cuanto a lo que comentas, para refrescar toda la pantalla en 16bits tienes que transferir 16 bits por cada píxel que es lo que ocupa el color en memoria, en el caso de 8 bits lógicamente solo tienes que tranferir 8 bits por píxel que es lo que ocupa el índice de la tabla de colores.
Luego la información transferida es el doble y por tanto el doble número de transferencias y doble de tiempo en hacerlas.
Saludos
◄|| SECHS ||►
Respecto a lo que has dicho sobre programar en asm en lugar de fenix. Está claro que el asm es infinitamente más potente; pero si asumimos que programar un juego en fenix es igual de dificil que conducir un patinete; programar un juego en asm sería tan dificil como pilotar un boeing 747 con un ala partida y lleno de botellas de nitroglicerína apiladas sobre mesas cojas.
Google stadia es un fracaso, google stadia funciona mal, google admite su fracaso con stadia
Baneado
Hombre, si lo combinas con C o Pascal y lo usas para funciones que realmente se requiera pues es como conducir un coche con cambio de marcha manual para cuando te apetece conducir o automatico para cuando no.
En cuanto a las transferencias de 8 o 16 bits yo hablo por mi experiencia en arquitecturas x86. En mi viejo Pentium 166MMX constate que una transferencia de 16 bits tomaba el mismo tiempo que una de 8 bits. En lani idea, ya que se poco sobre su arquitectura, casi nada, pero en buena logica, deberia aceptar el mover 16bits de una tacada, asi que 8 bits, 1 transferencia, 16bits, 1 transferencia.
Si me dices que la
Aunque a lo mejor estoy
Super Moderador
A ver, que nos estamos liando...
Estoy contigo en que dependiendo del bus si lo tiene de 16 bits (que en realidad creo que eran 32) puede mover 16 bits de una tacada en el mismo tiempo que 8 bits, hasta ahí bien.
Pero si tenemos por ejemplo 100 píxeles en la pantalla, en 16 bpp esos 100 píxeles serían 200 bytes mientras que en 8 bpp serían 100 bytes.
Ahora podemos mover 2 bytes en cada transferencia, luego en 16 bpp necesitaremos 100 transferencias mientras que en 8 bpp serían 50 transferencias.
¿Lo ves ahora?
Baneado
Os cuento que ya voy progresando, como me gusta el tema siempre que no tengo nada que estudiar hasta los examenes estoy con ello.
Tengo a veces todabia errores tontos y uno de los que mas odio y no entiendo es que muchas veces al llamar a funciones como "put_screen(2,fondo)" me dice que tengo un error por expected
"("...
Bueno a seguir y si saco algo cuando wiz ya lo subire para que me lincheis a criticas
Permisos de publicación
Citar
Marcadores