User Tag List

Página 2 de 2 PrimerPrimer 12
Resultados 16 al 22 de 22

Tema: Version beta del motor tileado V3

  1. #16

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,508
    Mencionado
    114 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    351
    Agradecer Thanks Received 
    1,281
    Thanked in
    Agradecido 641 veces en [ARG:2 UNDEFINED] posts
    Pues sí habrá que ver que dice sobre esto el maestro Puck.

    Aún con esto he estado haciendo pruebas en el PC con tu motor de tiles, utilizando color de 8 bits; rinde de una forma estupenda, y he comprobado que se pueden utilizar diferentes capas. Cuando funcione en la gp2x va a ser la solución definitiva al pobrísimo scroll de fénix, mira que no tener incluído un scroll de tiles... me parece rarísimo.

    A voz de pronto el peor caso para guardar el mapa de tiles puede ser la mitad de la memoria disponible para fénix en la gp2x (siempre permitirá mapas mucho más grandes que el scroll básico).
    Última edición por masteries; 17/11/2008 a las 19:09

  2. #17

    Fecha de ingreso
    Sep 2005
    Mensajes
    16,058
    Mencionado
    265 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    927
    Agradecer Thanks Received 
    2,262
    Thanked in
    Agradecido 1,551 veces en [ARG:2 UNDEFINED] posts
    Hombre, tanto como sustituir al scroll de fenix, lo dudo mucho, ten en cuenta que este scroll, ademas de por SW, está hecho con el propio Fenix. Llevo tiempo dándole vueltas a crear una dll o a integrarlo en el propio Fenix (algo así como una versiona 092a+d :P) pero mis conocimientos no llegan a tanto ^^U

    Lo cual me recuerda que por ahi tengo ESTE tscroll, que dibujaba sobre un gráfico. Está basado en el segundo motor y con ligeros cambios se podía hacer que dibujase todo el mapa en un MAP y luego usarlo en el scroll normal de Fenix... aunque lo dudo, por la memoria que ocuparía, no saldría rentable en GP2X.

    En fin, a ver si le meto mano a la programación avanzada y me pongo a crear librerías para Fenix (empezaré portando, supongo). Pero es como lo del WIFI: va para largo.
    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%

  3. #18

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,508
    Mencionado
    114 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    351
    Agradecer Thanks Received 
    1,281
    Thanked in
    Agradecido 641 veces en [ARG:2 UNDEFINED] posts
    Eso son grandes aspiraciones Drumpi, pero si te ves y sientes capacitado, ya sabes. Y desde el resto de nosotros, pobres mortales, no podemos hacer más que ofrecerte nuestro apoyo.

  4. #19

    Fecha de ingreso
    Sep 2005
    Mensajes
    16,058
    Mencionado
    265 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    927
    Agradecer Thanks Received 
    2,262
    Thanked in
    Agradecido 1,551 veces en [ARG:2 UNDEFINED] posts
    Eh! que yo no soy más Dios de lo que fue Ulises en su odisea (tambien me tendré que enfrentar a los dioses XD)
    Simplemente supongo que sabiendo algo de C, leyendo los códigos fuente de Fenix y aprendiendo a manejar el entorno (materia pendientísima desde que "aprendí programación") se podría hacer "algo". Según he leido, una dll internamente no son más que funciones que se llaman desde un programa, que en el caso de Fenix, deben integrarse usando las declaraciones del propio lenguaje si se quieren usar funciones internas. Pero bueno, seguramente me de el batacazo padre y se me bajen las ilusiones a la altura de un topo ^^U
    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%

  5. #20

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,508
    Mencionado
    114 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    351
    Agradecer Thanks Received 
    1,281
    Thanked in
    Agradecido 641 veces en [ARG:2 UNDEFINED] posts
    Yo preferiría enfretarme a Circe.

    Básicamente una dll es eso, aunque las únicas que yo he manejado, las del juego Enemy Territory, el gratis no el quake wars; prácticamente las dlls (la de cliente, la de servidor y la de interfaz) son el juego en sí y el ejecutable (que prácticamente es el ejecutable de quake 3), lo que contiene son las llamadas a opengl y el procesamiento de unas matrices de datos donde las dlls van colocando lo necesario para hacer fotogramas.
    Una dll puede contener cualquier tipo de código ejecutable, y a veces incluso otras cosas.

    De hecho el ejecutable que hace de servidor, es la dll de servidor cambiada de nombre a .exe y arrancada con el parámetro -game_server 1 -mapa -jugadores -bots ...etc.

    Pero ya me pierdo bastante en el código de ET (es C lineal sin concurrencia de procesos ni nada parecido, tampoco creais que crea procesos hijo de la forma en que se pueden crear en C ) como para meterme en otro código, aunque el código de Fénix seguro que es otro lío impresionante de líneas, ficheros .h y .c. En definitiva, mi capacidad de programación decrece con el tamaño del código.


    EDITO: He probado el scroll fw75 tuyo, del que has puesto enlace, cambiando cosas para que en la gp2x vaya a 320x240x8bits; compilado para el ultimate fénix, alcanza 15 fotogramas, lento. He visto el código y veo que también se utiliza la función "alloc", por lo que deduzco que el fallo se encuentra en un uso muy concreto de alloc. Alguna pequeña peculiaridad, supongo.
    Última edición por masteries; 18/11/2008 a las 20:51

  6. #21

    Fecha de ingreso
    Sep 2005
    Mensajes
    16,058
    Mencionado
    265 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    927
    Agradecer Thanks Received 
    2,262
    Thanked in
    Agradecido 1,551 veces en [ARG:2 UNDEFINED] posts
    Normal que vaya lento: redibuja cada frame el mapa de 320x240 Igual, con acceso directo al buffer del gráfico, o quitándome de encima la capa de interpretación de código Fenix... o simplemente si pudiera desplazar todo el gráfico y luego añadir los tiles de los borde (lo intenté, pero el desplazamiento de memoria se hace en un sentido, y si desplazo en el mismo, se me repiten los pixels) quizás podría ir más rápido, pero bueno ^^U

    Lo más curioso es que creo que el .inc que carga el mapa (el que usa el alloc) es exactamente el mismo en ambas versiones. Me lo tendría que mirar bien, pero juraría que es el mismo.

    Del código de Fenix solo me interesaría mirar el scroll.c, que es donde va todo el meollo del asunto de scrolls, para hacer algo similar, pero en lugar de usar un mapa, usando los tiles.

    PD: A lo mejor te tengo que pedir ayuda para que me digas cómo leches se compila una dll ^^U Hasta ahora, con DevC++ sólo he compilado "console aplication" :P
    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%

  7. #22

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,508
    Mencionado
    114 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    351
    Agradecer Thanks Received 
    1,281
    Thanked in
    Agradecido 641 veces en [ARG:2 UNDEFINED] posts
    He estado mirando por encima el g_scroll.c del código fuente del fenix092a; he podido deducir que lo que hace es cargar el gráfico entero (esto es obvio jeje) y posicionar la pantalla respecto del gráfico (o quizá el gráfico respecto de la pantalla, que lío) mirando los valores de x0 e y0. Es esta parte:

    Código:
    (línea 320)   
    scrolls[n].posx0 = data->x0 ;
    scrolls[n].posy0 = data->y0 ;
    scrolls[n].x0 = data->x0 % scrolls[n].graph->width  ;
    scrolls[n].y0 = data->y0 % scrolls[n].graph->height ;
    if (scrolls[n].x0 < 0) scrolls[n].x0 += scrolls[n].graph->width ;
    if (scrolls[n].y0 < 0) scrolls[n].y0 += scrolls[n].graph->height ;
    y otro tanto igual para el fondo, al que llama scroll[n].back

    Ahora viendo todo el trabajo que has hecho, veo posible que crees un nuevo código de nombre g_tscroll.c, basándote en la práctica totalidad de tu código y viendo como llaman a las "cosas" en g_scroll.c y como utilizar todo aquello que permanece "oculto" cuando usamos fénix. Es mi humilde opinión, por cierto que el código fuente viene preparadito para el visual studio. Por cierto que encuentro grandes similitudes entre este código y el de los comandos de consola de quake 3; claro los comandos de consola son un lenguaje interpretado que ejecutan una función en C.

    El código en su conjunto no es tan inmenso como me esperaba, claro que esto no quiere decir que me encuentre plenamente capacitado, espero poder acallar con esto algunas voces chillonas que puedan surgir.

Página 2 de 2 PrimerPrimer 12

Etiquetas para este tema

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •