Avances, Diario de...

[l1nk3rn3l]

Hay librerias Boost Y PTHREAD compatibles con windows ,linux, android, macos

si deseas te colaboramos en el codigo que sea lento...  o en que te podemos ayudar seria un placer...

[SplinterGU]

pthread la uso, estoy mas pensando en opencl... pero bueno, estoy investigando sobre colisiones complejas, digamos que circulares y rectangulares (estas ultimas no rotadas) son simples, pero cuando mezclamos circulares con rectangulares y rotadas o rectangulares con rectangulares rotadas la cosa se complica un poco... tengo ideas para resolverlo de forma matematica, por medio de un par de formulas, evitando bucles y cosas apañadas, pero quiero leer un poco mas a ver si encuentro algo mejor ya hecho... pero apuntando a opencl podria hacer colisiones con poligonos irregulares... creo que hacer lo tipico en colisiones 3D sobre 2D optimizado por GPU, donde puedo procesar muchas comprobaciones en paralelo (quizas incluso el chequeo de collision contra todos los procesos en 1 solo paso) y no tener que iterar desde el proceso principal, sino hacerlo directo en el GPU... creo que el rendimiento seria asombroso... no lo se, todo es teoria por ahora...

claro que toda ayuda es agradecida... si tienen alguna experiencia en eso (opencl, o algoritmos de collision, no pixel perfect, sino en cuanto a poligonos irregulares) bienvenido sea...

[l1nk3rn3l]

 ;D


yo creo que lo mas optimo seria incluir una librería 
como box2d o chipmink que ya vienen aceleradas por hardware...
para no reinventar la rueda...

[SplinterGU]

p

;D


yo creo que lo mas optimo seria incluir una librería 
como box2d o chipmink que ya vienen aceleradas por hardware...
para no reinventar la rueda...

podria ser tranquilamente, voy a echarle un ojo a eso... gracias!

[JaViS]

Yo se que por ahi ya cansa el topic, pero realmente estoy lamentando la perdida de soporte a graficos de 8 bits y el manejo de paletas. El pallete swap, rotation, etc es algo muy util y que ya pocos engines conservan.


No hay forma de implementarlo de alguna manera compatible con en nuevo engine?

[panreyes]

JaViS, lo más parecido a eso en OpenGL es utilizar "color tints".

http://gamedev.stackexchange.com/questions/43294/creating-a-retro-style-palette-swapping-effect-in-opengl

La otra opción sería absurda, porque requeriría actualizar todos los mapas en memoria en cada color swap que hicieras.

[SplinterGU]

Yo se que por ahi ya cansa el topic, pero realmente estoy lamentando la perdida de soporte a graficos de 8 bits y el manejo de paletas. El pallete swap, rotation, etc es algo muy util y que ya pocos engines conservan.


No hay forma de implementarlo de alguna manera compatible con en nuevo engine?

te entiendo, y lo intente, pero no se permiten texturas con colores indexadas, al menos en mi tarjeta de video... lo mismo que las transparencias en mapas de 16bits (todo quizas porque el renderer es de 32bits, no probe con renderers de otras profundidades)

ahora estoy leyendo un poco sobre librerias fisica, por ahora la decision que tengo es integrar un motor de fisica a bennugd, posiblemente chipmunk..

[JaViS]

JaViS, lo más parecido a eso en OpenGL es utilizar "color tints".

http://gamedev.stackexchange.com/questions/43294/creating-a-retro-style-palette-swapping-effect-in-opengl

La otra opción sería absurda, porque requeriría actualizar todos los mapas en memoria en cada color swap que hicieras.

ahh, o sea, haces el grafico en 50 shades of gray y despues le chantas tinturas?

[panreyes]

Es una forma...

[Drumpi]

Mmmm, o lo que dice de "paletted texture" parece interesante: crear un shader que lea un pixel del gráfico, por ejemplo, el valor del color azul (ya que cada componente es de 8 bits), y lea de una tabla de 256 posiciones un color RGBA, y se pinte en dicha posición. Si se puede aplicar un shader a un gráfico concreto, podría ser la solución.

Para los que no lo sepan: un shader es una pequeña función que se ejecuta en la tarjeta gráfica, y que sirve para aplicar efectos gráficos exclusivamente, en lo que se llama post-proceso (la fase después de hacer los cálculos con la CPU y antes de dibujar en pantalla... Lo que en BennuGD pasa justo después del frame y antes de comenzar a ejecutar de nuevo el código).

Podría servir: se carga un MAP de 8 bits en una SDL_surface o lo que use OpenGL de 32 bits, aunque sólo le estemos dando valor a la componente alpha del pixel RGBA, cuando está en la gráfica se le aplica un shader con la tabla de valores de la paleta y listo. Lo que ya no sé es cómo de difícil sería de implementar, el cómo pasar la información de la paleta al shader (no haría falta al revés, si mantenemos una copia de la paleta en RAM, eso ocupa poco y es común a los gráficos). No es óptimo en memoria, pero no nos dejan mucho margen de maniobra... a menos que se hagan auténticas locuras (que cada pixel de un mapa de la gráfica en 32bits contenga la información de 4 pixels de un .map 8bits...).

Debería irme a la cama.

[SplinterGU]

todavia no probe nada shaders

[SplinterGU]

bien, voy a aparcar un momento el tema de las fisicas... voy a concentrarme en meter multiprocesamiento en el core (para paralelizar la ejecucion de procesos) y en bennugd 64bits, agregando tambien nuevos datos 64bits.

creo que esto es mas importante ahora que luego tener que cambiar todos los modulos que tengo escritos.

espero con la multitarea lograr aun mejor performance.

[JaViS]

bien, voy a aparcar un momento el tema de las fisicas... voy a concentrarme en meter multiprocesamiento en el core (para paralelizar la ejecucion de procesos) y en bennugd 64bits, agregando tambien nuevos datos 64bits.

creo que esto es mas importante ahora que luego tener que cambiar todos los modulos que tengo escritos.

espero con la multitarea lograr aun mejor performance.

Eso va a ser un cambio realmente importante :D

[Drumpi]

Pues mucho ánimo con la tarea.
Si ves que no todo se puede paralelizar, pues te centras en lo qe sí se pueda, y poco a poco se irá mejorando. Si de momento se puede paralelizar la ejecución de los procesos, dejando el render final como un único hilo, pues se hace, mejor tener un 50% de ejecución paralela y otro 50% de secuencial que todo secuencial, o todo paralelo si Bennu2 se retrasa hasta 2025 :P

Ah, y mucha suerte con los tipos de 64 bits, no queremos que pase como con Fenix 084 ;)
Desde aquí todo mi apoyo :)

[SplinterGU]

gracias a ambos... espero sea un cambio importante...

Pues mucho ánimo con la tarea.
Si ves que no todo se puede paralelizar, pues te centras en lo qe sí se pueda, y poco a poco se irá mejorando. Si de momento se puede paralelizar la ejecución de los procesos, dejando el render final como un único hilo, pues se hace, mejor tener un 50% de ejecución paralela y otro 50% de secuencial que todo secuencial, o todo paralelo si Bennu2 se retrasa hasta 2025 :P

Ah, y mucha suerte con los tipos de 64 bits, no queremos que pase como con Fenix 084 ;)
Desde aquí todo mi apoyo :)

algunas cosas se pueden paralelizar y otras no, por cuestiones logicas y otras que escapan a bennugd.

que paso con fenix 084?