Avances, Diario de...

[AmakaSt]

Rivalidad ninguna, este es el mejor ambiente posible :)

De hecho, como parten de una base parecida, tanto PixTudio como BennuGD2 pueden aprovechar mejoras que implemente uno u otro.

Por otro lado, tengo planes de dar soporte también a BennuGD (1 y 2) en PixTudio Project Manager

Eso es bueno, yo con Div GO tampoco veo que haya rivalidad con ningún div-like, esto nos beneficia a todos.  :D

[SplinterGU]

asi es AmakaSt

[Drumpi]

¿Rivalidad? Creo que me has entendido mal :D
Me refería a que, por ejemplo, por cada cosa que publico del editor de mapa de tiles, aparece Momia con algo de gameplay de su demo de Spiderman, tu de Bennu2, Josebita o Pixel de PixTudio, Amaka de DivGo o Ulthar con su creador de aventuras, y eso genera que otro hable de su respectivo proyecto, y otro post y otro :D :D :D

¿Que qué voy a echar de menos? Todavía no hay nada seguro, pero para empezar tanto BennuGD2 como Pixtudio se van a centrar en los 32bits de color, y aun tengo aparcado FenixLand, que iba a ser un juego en el que quería usar la paleta de color para provocar transiciones suaves entre el día y la noche, algo imposible en 16 o 32 bits sin recurrir a complejos efectos de iluminación y cambios de gráficos.
O los cambios de color en el prota en función del poder que esté usando.
Por no hablar de los juegos que sigo haciendo para GP2X y Wiz, para los que no hay SDL2 portado (aunque estén en desuso, me las sigo llevando de vacaciones, y siempre cae una partidita a algún juego mío o a algo que haya hecho alguien y no tengo en las otras).

Pero digo que no es nada seguro porque debería centrarme ya en producir cosas para PC, y según los planes, la próxima revisión del Echo va a incluir efectos que sólo se podrán ejecutar en la potencia extra de un ordenador (la Wiz se me queda pequeña, si no consigo arreglar el último motor de scroll tileado).

[SplinterGU]

es bueno aclarar... gracias...

ahora la transcision de dia a noche la vas a poder hacer mucho mas simple ahora, con la modulacion de colores. cambios de color algo se puede hacer.

con respecto a todo lugar donde no esta portado sdl2, pues ahi si lo extrañaras... al menos por el momento, luego quizas se requiera solo opengl...

[l1nk3rn3l]

exacto algunas plataformas no soportan SDL2 asi que toca dejar

alguna version aparte(deprecated/unsupported) SDL1 para el que quiera tomarla y portarla a la plataforma X



;D

[SplinterGU]

bien, me he vuelto loco hoy con la screen_get(), pensaba que no capturaba por mas que intente mil codigos diferentes... y finalmente era que me habia olvidado que ahora los cpoints no son necesarios definirlos a nivel codigo C, colo lo era en bennugd y fenix, donde se les ponia un centro X e Y con un valor alto, ahora simplemente se centran al medio si no existen cpoints, los cpoints son cpoints y no valores inventados. asi que estaba dibujando el grafico fuera de pantalla. ( hasta que me di cuenta.. :D )

en fin, ya hay screen_get()! pero es infinitamente lento el get del render de video, de un proceso de 1600fps, si estoy capturando constantemente pasa a 135fps, esta bien que tengo una intel y que me sobran fps, pero igual la caida de rendimiento es terrible. tengo que agregar que la operacion esta usando la menor cantidad de operaciones posibles, y capturando solo cuando se pide de pantalla... estuve cureoseando un poco el codigo de SDL, lo que toca de opengl, y la verdad que parece que SDL hace una cantidad tremenda de conversiones sobre los datos graficos... no se si son realmente necesarias todas, pero bueno, las hace...

en fin, creo que mañana me pondre a trabajar en el cross para windows, a ver si puedo generar un binario para testear...

espero no asustarlos como quedo el lenguage, de todo lo que recorte, el nombre de funciones compatibles que elimine, y el cambio de algunas funciones... por ejemplo, todas las que eran *TEXT*, pasan a ser WRITE_*, salvo TEXT_WIDTH y TEXT_HEIGHT.

tampoco se si tome la mejor decision, pero al menos estan (casi todas) agrupadas por categoria.

otra duda que tengo es si meter las screen_put, screen_xput, etc... creo que no son necesarias, pueden hacerse un proceso "fondo" para eso, cuando se necesite...

en fin, mientras sigo avanzando...

[Drumpi]

Hasta donde yo sé, las SCREEN_PUT, PUT, etc estaban por dos razones (tu que te has leido el código deberías saberlo mejor que yo):
- Las operaciones sobre el fondo de pantalla son más rápidas que sobre los graphs. No me preguntes cómo, pero creo que era algo sobre dibujar sobre el render frente dibujar sobre una SDL_surface y posteriormente las funciones de render.
- Para los novatos, PUT_SCREEN es tremendamente claro: cojo un gráfico y lo pongo de fondo de pantalla. Más que MAP_PUT, que tienes que saber que el fondo es el file 0 - graph 0.

[SplinterGU]

es 1 proceso, no hace mucha diferencia, porque solo es cuando se necesita...

pero tampoco complica mucho agregarlo... asi que lo voy a agregar.

las map_put, solo deje 2, map_put y map_xput (con mas funcionalidad de la que ya existia)

[SplinterGU]

nueva estructura de archivos bennugd (librerias/modulos)

bajo nivel:

libbggfx
libbginput
libbgload
libsdlhandler

usuarios:
libmod_gfx
libmod_input
libmod_misc
libmod_sound

el background ahora se maneja por variables, tipo GRAPH, y tiene todas las caracteristicas de los mismos, escalado, rotacion, modulacion de color, mirror, etc.

ahora estoy trabajando en las colisiones, las colisiones pixel perfect desaparecen... ahora van a se podra definir en cada proceso el tipo de colision, si circular o rectangular, con lo que se comprobaran colisiones de formas circulares contra formas rectangulares, rectangulares contra rectangulares y circulares contra circulares, tambien se tendra en cuenta rotaciones y escalados (que venia faltando en la rectangular)

[Drumpi]

¿Y por qué desaparecen las colisiones pixel perfect?

[JaViS]

ahora estoy trabajando en las colisiones, las colisiones pixel perfect desaparecen... ahora van a se podra definir en cada proceso el tipo de colision, si circular o rectangular, con lo que se comprobaran colisiones de formas circulares contra formas rectangulares, rectangulares contra rectangulares y circulares contra circulares, tambien se tendra en cuenta rotaciones y escalados (que venia faltando en la rectangular)

Seguro que hay una buena razon para esto, pero no puedo evitar lamentar la perdida de una de las mejores features de BennuGD y DIV en general.


Quisiera pedirte que consideres la posibilidad de incluir colisiones elípticas y rectangulares. Cuadradas y Circulares a veces se quedan cortas.

[SplinterGU]

¿Y por qué desaparecen las colisiones pixel perfect?

porque bennugd2 es GPU, no tiene render por software, bajar texturas del render (que es donde hay rotaciones y escalado nativo) es pesadisimo, entonces no habra pixel perfect.

ahora estoy trabajando en las colisiones, las colisiones pixel perfect desaparecen... ahora van a se podra definir en cada proceso el tipo de colision, si circular o rectangular, con lo que se comprobaran colisiones de formas circulares contra formas rectangulares, rectangulares contra rectangulares y circulares contra circulares, tambien se tendra en cuenta rotaciones y escalados (que venia faltando en la rectangular)

Seguro que hay una buena razon para esto, pero no puedo evitar lamentar la perdida de una de las mejores features de BennuGD y DIV en general.


Quisiera pedirte que consideres la posibilidad de incluir colisiones elípticas y rectangulares. Cuadradas y Circulares a veces se quedan cortas.

elipticas se me complican las matematicas, desconozco si hay una forma matematica de hacerlo posible (considerando rotaciones y escalado), de haberla, si alguien puede aportar ayuda al respecto, sera bienvenida... con respecto a la colision box, obviamente las rectangulares estan incluidas.

La otra opcion que pienso agregar (no creo en la primera version) es multiples formas de colision por grafico, esto es 2 circulos 1 rectangulo o 5 rectangulos, etc...

[Drumpi]

Ok, no había caido en lo del espacio de memoria de GPU (la falta de costumbre ^^U).
Lo que habría que mirar, sin embargo, es que si estamos en una GPU, debería ser factible comprobar colisiones triangulares u otras formas geométricas, al fin y al cabo, se diseñaron para eso, para agilizar el cálculo de colisiones  de polígonos (es lo que se usa en los motores de físicas). Tener funciones de colisión con lineas, hexágonos (que no son más que 6 triángulos) o similares puede ser el sustituto perfecto. Tengo que buscarte un buen tutorial de físicas de colisión 2D en Unity para que los veas, Splinter, te puede dar ideas... si es que se puede llevar a cabo.

Es más, lo mismo ni siquiera tienes que hacer tú los cálculos para las box y los círculos de colisión :P

[panreyes]

¿Y por qué desaparecen las colisiones pixel perfect?

porque bennugd2 es GPU, no tiene render por software, bajar texturas del render (que es donde hay rotaciones y escalado nativo) es pesadisimo, entonces no habra pixel perfect.

Creo que éste es el exacto motivo por el cual Joseba decidió tener copia de los mapas en RAM y en VRAM. Aunque, si es sólo para colisiones pixel perfect, creo que se podría guardar una copia de los fpgs en 1bpp para comprobar colisiones.

Por otro lado, ¿y map_get_pixel? ¿Funcionaría con GPU?

[SplinterGU]

yo tambien tengo copias de los mapas en memoria, map_get_pixel trabaja sobre memoria, pero sin render por software, ya que no hay rotaciones ni escalados necesarios esta funcion, se leen directo.

por otro lado, funcionaria con gpu, pero lento.

las condiciones triangulares que plantea drumpi, me suenan ser un poco costosas en cpu, por lo poco que vi por ahi, creo que se necesitaria un mesh (malla) para eso, voy a analizar que tan factible es hacer estos calculos por GPU.