Gráficos fallados (gliches)

[Anyeos]

Hola, acabo de descargar el svn y lo compilo todo perfecto. El asunto es que cuando corro el mismo juego que en la versión anterior de BennuGD me anda muy bien (también compilada desde fuentes) los gráficos me aparecen con deformaciones pixeladas. O sea, es como si fuera una textura que se desplaza un poco y se cortan un poco los bordes y sino aparecen pixeles de cualquier color en los bordes como si estuviera cargando datos de un área de memoria que no corresponde.

Ahora no entiendo por qué si la versión anterior me anda bien.

Y tengo otro problemita que en esta versión tampoco está corregido pero no sé si es un error o es por como tengo mi código, por ejemplo cuando hago:

        while ( colID = collision( type Laser ) )
        colID.energia = 0;
        EmitirSND(snd_impactoposte, CANAL_FXS, x, y, 0);
        FxChispa(colID.x, colID.y, colID.angle);
        end

EmitirSND es una función que llama a la de reproducir sonido.
FxChispa es un Process que hace una chispa nada más.

Bueno, que sucede, resulta que el punto de ejecución de este Process, el que ejecuta el código de arriba, no corre, se queda colgado en esa parte siempre y cuando el Laser esté impactando o sea porque la nave dispara muchos lasers entonces impactan continuamente y funciona, impacta, hace la chispa, el sonido, todo eso Ok, pero el process en cuestión no continúa su ejecución, sólo detecta colisiones, pero no hace otra cosa.

O sea que el código que continúa no lo ejecuta. No entiendo por qué si es la forma en que lo puse yo pero me parece raro porque es un código simple.

Yo esperaba que además de detectar todas las posibles colisiones con todos los posibles process Laser que hubieran, a su vez, continuara la ejecución del resto del código. Que es un efecto de explosión cuando se queda sin vitalidad. Sin embargo el process no ejecuta eso sino hasta que dejo de dispararle y deja de colisionar.

Pero puede ser problema de las prioridades no sé. Porque el que destruyo es un process anterior que cuando está destruido se destruye también este. Éste sólo detecta colisión para detener los Laser.

Pero igual sigo sin entender como que no respeta el orden de ejecución? O algo hice mal?

De todos modos me interesaría más solucionar el tema gráfico porque está muy feo y quisiera usar la nueva versión que seguro tiene otros arreglos.

Aah otra cosita: Con esta nueva versión apenas ejecuto el juego se me aparece una ventana gigante ocupando toda la pantalla y luego se achica al tamaño que yo le configuré (todo eso en menos de 1 segundo). Sirve para algo que haga eso? Porque me molesta, es como muy brusco y molesto porque se aparece de golpe y luego desaparece es como un flash que me hace en la vista, es molesto y la versión anterior tampoco hacía eso.

No quiero ser pesado y entiendo que cuesta trabajo desarrollar este software, y hay mucha gente que contribuyó, pero si es posible que me ayudaran un poco con el tema este gráfico (las fallas de pixelado) que por el momento es el que más me imposibilita.

Gracias

[SplinterGU]

es el bug que vengo mencionando desde hace un tiempo...

la version anterior no anda bien... no dibuja el tamaño correcto, pero si no lee mas alla de los limites.

a mi tambien me imposibilita a continuar con el desarrollo de otros temas.

[Anyeos]

Ah yo leí que hablabas de algo de video pero yo pensé que lo habías solucionado (era viejo el mensaje que vi) y me quedé pensando que podía ser pero bueno después de esto ya estaba pensando en que eran algunas bibliotecas de mi sistema.

Y tenés alguna referencia como para ver que podría ser?

Probé reemplazando los archivos que hacen referencia al video, por la versión vieja, y aparentemente el problema está relacionado con la biblioteca del render. Que desconozco como trabaja pero sospecho de que está vinculada con todo el tema de video. Pero también puede estar limitado al render, ni idea, tendría que ponerme a probar.

Pero bueno, escarbando por ahí se descubre la causa.

Donde puedo ver lo que mencionaste sobre este error?
Sabes cuándo comenzó a suceder?

Con esas referencias por ahí se puede ir buscando el origen.


Y la versión anterior qué tamaños dibuja mal? Porque yo veo aparentemente todo bien. Porque tanto en la versión nueva como la anterior salvo por el error ese gráfico el tamaño de los dibujos es igual. O estoy usando una versión demasiado vieja yo.

Y eso de la colisión entonces también puede ser otro bug?
Pregunto porque por ahí estoy interpretando mal como funciona.

[SplinterGU]

collision usa render

si reemplazas la anterior librender ya no vas a tener problemas.

se dibuja mal el tamaño segun usas size y angle... en determinados casos, la precision no es correcta y se dibuja 1 pixel demas (o de menos, ya no recuerdo como estaba la version anterior).

tengo mas que claro donde esta el problema, pero no se trata de un problema de un buffer overflow o un puntero sin chequear, se trata de precision trigonometrica y logica en los calculos.

[Anyeos]

A ver, a mi me pasó en un programa que hice para animar con imágenes y para que sea rápido trabajé con valores enteros. Pero después tuve unos problemas extraños porque para mantener precisión multipliqué por miles. Bueno, ya debes saber, es como correr la coma es como la resolution.

El asunto es que igual seguía teniendo los problemas y yo pensé que sería que le faltaba precisión, y me terminé cansando y pasé todo a double. Nada, igual seguía el problema.

El problema era cuando hacía un paso de escala de una imagen pequeña para agrandarla a un tamaño mayor. O sea, en el cálculo al agrandarla estaba descartando sin darme cuenta en mi fórmula, estaba descartando los pixeles impares. O sea, si vos redimensionás exactamente al doble de tamaño, todo bien, pero cuando redimensionás a un tamaño que no es múltiplo del doble, te queda un valor impar que no encaja en ninguna parte.

El resultado era un efecto de movimiento de la imagen, como si temblara. Claro, cuando estaba en un valor par no había problema pero cuando se obtenía un valor impar la imagen se corría un pixel.

Entonces la solución que encontré fue agrandar la imagen de destino a un tamaño que permitiera hacer encajar el valor par. Por ejemplo 300x300 para hacer encajar algo de 299x299 (o 299x300). Y luego los pixeles que sobran los dejás simplemente transparentes, pero hay que aplicar una corrección de ubicación de la imagen dentro de esa otra para que encaje correctamente. Sino va a dar la sensación de que tiembla.

Capaz que por algo similar el tamaño no es el correcto en el código anterior de BennuGD.

Pero entonces si se desarrolla un algoritmo así, el trabajo sería un poco más pesado (o eso creo, no estoy seguro hasta cuánto se puede optimizar).

Pero al final lo solucioné usando una biblioteca que aplicaba una textura a un polígono. Simplemente utilicé un polígono rectangular que sería el nuevo recuadro del nuevo tamaño de imagen. Y el solito se encarga de plasmar la textura sobre eso redimensionada o más bien ajustada al polígono.

Aparentemente la solución podría pasar por ahí, alguna fórmula trigonométrica para aplicar textura ajustada a un polígono rectangular utilizando matrices.

[SplinterGU]

todo eso lo tengo claro, es mas, usamos numeros con coma flotante... y enteros en los que sabemos que no tendremos problemas (tambien probamos con decimales, y no va)

si, tiembla, pero el problema de que tiembla en la version anterior y en la actual un poco menos, pero el problema en este caso es que el pixel central no esta centrado, y entonces cuando rota se mueve, ya que el centro se mueve...

esto falla tanto en tamaños par o impar, no estamos con el problema que mencionas, eso lo tenemos controlado (parcialmente)

tenemos 2 problemas, siempre hablando de graficos escalados/rotados.

- problemas para central el pixel central cuando esta escalado, y con esto tenemos que decir que no solo es calcular el pixel sino que esto incluye que deslizar el vertice por donde se centra, para que el angulo continue correctamente (no se si logre explicarme, posiblemente suene a chino)

- problema de que el pixel 0 no vale 0, sino que vale 1... y para los calculos ahi la cagamos.

pensemos que tenemos, no solo angulos y size, tambien mirrors y sizes por cada una de las coordenadas.

[edit]
se me fue la olla... edito y borro...

[Anyeos]

La biblioteca que utilicé para lo que te conté fue una para Lazarus, o sea, está en Pascal, nada que ver, pero como sé trabajar con Pascal podría ver su algoritmo (es GPL LGPL) y pasarlo a C. Y a ver si usamos su código sino, digo, que se yo.

Para poder mejorar la calidad de las imágenes redimensionadas utiliza técnicas con filtros. Por supuesto, existe siempre el filtro "lineal" que sería un equivalente a no usar filtro.

Pero yo creo que sería buena idea implementar esa funcionalidad en BennuGD porque permitiría volcar los sprites de distintas formas y con filtro o sin filtro lo que te mejoraría la calidad a la hora de graficar tus juegos. Pero no sé si le quitaría velocidad (se podría implementar una técnica de caché en todo caso).

A no ser que en modo 24 bits BennuGD ya haga eso. Porque esto que yo digo la biblioteca lo aplica con canal alfa y en 24 o 32 bits (acabo de leer que son 4 bits por pixel, más el canal alfa, así que trabaja en 16 bits y eso es más rápido que trabajar con 24 o 32 porque requiere menos proceso obviamente). Aunque se puede no usar ese canal si se quiere. No sé, hay que ver.

La verdad que es una idea que tiro, porque sería algo demasiado trabajoso lo que propongo. Y puede ser que necesitemos modificar bastante código de BennuGD para poder implementar todo eso.

Bueno, la biblioteca que te digo es la BGRABitmap.
Fijate si querés como trabaja: http://wiki.freepascal.org/BGRABitmap/es
Pero creo que te va a interesar más ver la parte del código que podría servir para esto.

Yo quisiera probar a ver que tal esos algoritmos de esa biblioteca. Porque cuando los pongo a correr no son tan pesados. Al menos en mi PC de 2.5 Ghz corre a una velocidad decente, pero claro, estoy hablando siempre de un par de sprites (aunque eran gigantezcos como de 5 megapixeles, eran dos fotos que puse a rotar con esa técnica de aplicar textura al polígono). Pero no sé qué tan rápido andaría si ponga 200 sprites pequeños por ejemplo (igual puedo hacer la prueba si es necesario).

Pero al menos puede servir esa parte de su código, ojalá porque la verdad quiero terminar de desarrollar mi juego en BennuGD y también le va a solucionar el problema a todos los que usen BennuGD.


El código ese de div2, realmente a esta altura sería ilegal utilizarlo? Digo porque las leyes de propiedad intelectual tienen vencimiento y si no las renuevan no corren más. Y aparte me parece que la empresa que la registró ya no existe más (no me acuerdo). Sino habría que preguntarle a los autores originales pero no creo que tengan demasiado problema si ya de alguna forma han entregado el código de div2. no? supongo.

[SplinterGU]

tendre que revisar esas cosas... la verdad que estoy muy desaminado, tengo todo aparcado hace bastante tiempo.

con respecto al codigo, no he dicho nada... :D

[Anyeos]

Jua, mirando el código de la BGRABitmap dice 32 bit... al final en qué quedamos? jaja

Bueno, yo voy a mirarlo y me manejo bien con esa biblioteca de Pascal pero con BennuGD ando perdido a ver si me podés orientar a dónde está el código que maneja ese asunto de los gráficos?

Mencioname los archivos y las funciones si no es mucha molestia, sino con los archivos al menos me alcanza.

[SplinterGU]

perdon, bennugd no soporta 24 bits actualmente... solo 32... perdon por no responder eso.

g_blit.c

[Anyeos]

Hola, estoy mirando el código y comencé a encontrar algunas cosas casi al pedo (en mi opinión).

Por ejemplo las blendop no está bien claro como se le piensa sacar provecho a eso ya que por lo visto (tengo que seguir mirando mejor pero casi lo tengo entendido) aplica una tabla de operación blend consumiendo más recursos en el proceso. O sea, crea la tabla, crea una copia en algunos momentos y aplica operaciones también según el caso.

Como resultado vamos a perder rendimiento o consumir más CPU al pedo porque hay situaciones en las que se requieren hacer operaciones dos veces (para obtener un solo efecto).

Primero creo yo, en este tema, hay que verle la relación costo / beneficio. Sino yo creo que sería mejor aplicar la tabla blend únicamente en el blit, para evitar ejecutar dos operaciones similares. E implementar entonces en el blit más operaciones tipo blend (que si no se quiere no se usan y listo).
Sería algo como agregar esas funciones de blendop directamente sobre el blit para que se ejecuten una vez. O más bien creo yo que añadiría más operaciones de blend en el propio blit y en una de esas queda obsoleto el blendop.
En realidad al blendop no tengo pensado tocarlo. Pensaba mejorar el blit en lo más que se pueda.

Porque me parece muy bueno poder hacer operaciones de blend que sean permanentes como hace blendop, pero me parece malo tener que repetirlas para cada situación: una para crear la tabla y la operación, y otra para montarla finalmente.

Así que en mi opinión utilizar blendop es un poco pesadito / consumidor de recursos. Cosa que se podría optimizar (no digo cambiar totalmente su funcionamiento) pero combinándolo un poco con el blit o reemplazándolo por este. Creo que el tiempo lo dirá, jaja.

No me estoy quejando, aclaro, sólo doy a conocer mi opinión al respecto. Tampoco digo que eso esté mal hecho, porque como no entiendo completamente en su totalidad qué han querido hacer con esos algoritmos, por ahí mi opinión es parcialmente válida.

Ahora en el blit encontré muchas funciones que convierten a 32 bits. Estaba pensando que quizá sea mejor idea trabajar con una sola función que trabaje en una sola forma de bits pero en el caso de solamente requerir menos bits, simplemente no utilice los que le sobran (los vaya salteando obviamente y por lo tanto va a demorar menos tiempo en ejecutar todo el proceso). Creo que sería un poco más fácil de implementar y sólo usaríamos una función para ese trabajo en lugar de una para cada situación. Cosa que si tenemos algún fallo sería más fácil de corregir porque no tendríamos tantas funciones que arreglar.

Observando un poco la BGRABitmap de Pascal me di cuenta que trabaja con un escaneo lineal. Y utiliza una forma particular de mezclar los pixeles, resulta que al primer pixel le suma la mitad de su ubicación. Suena lógico, ya que es al medio donde queremos estar para procesar el pixel. Pero todavía me falta interpretarlo mejor así que esto que digo es algo un poco apresurado.

Luego para plasmar la textura lo hace en un polígono, y el escaneo lineal es por líneas horizontales. Cosa que si no usas un filtrado se podrían observar líneas horizontales en algunos casos.
Pero es la forma más rápida de dibujar y veo que BennuGD también utiliza el mismo método (dibuja por línea horizontal).

Ahora para rotar la textura es otra historia, le aplica una rotación a una copia de la textura que sólo tiene información necesaria para eso. Eso hace BGRABitmap. Con eso consigue una mejor calidad de rotación. Porque la textura ahora está rotada entonces el dibujado por línea no afecta ya que dibuja la textura estando rotada.

Quizá ese proceso no sea tan rápido, no lo sé, pero nos vamos a dar cuenta si logro implementar ese código. Ya que ahora como lo veo de todas maneras ejecuta varios procesos que quizá comparado al otro anden más o menos igual con respecto al consumo de CPU.


De todos modos voy a tratar de experimentar primero un poco. O sea, no quisiera que la cosa esté peor de lo que está o que se pierda rendimiento aunque cree código que funcione bien.
Así que tengo pensado hacer desde cero el g_blit.c, volverlo a codear pero copiándome un poco de las ideas de BGRABitmap y otro poco del g_blit.c original.


Bueno, no lo puedo prometer ya ya y quizá sea un fracaso así que no cuenten con eso por ahora. Es un experimento que voy a hacer a ver qué resultados me da.


Ahora queda también el asunto de que capaz laburo al pedo porque aunque simplifique el g_blit.c a lo mejor los problemas de esos glichs gráficos aún persistan jajaja. Pero bueno, el que no arriesga no gana.

Saludos.

[SplinterGU]

olvidate del blendop... eso esta perfecto como esta, y el usar tablas es para que vaya mas rapido y se crean solo una vez, la gracia del blendop es que el usuario pueda crear sus propias tablas con sus propios valores... pero no viene al caso... no siempre se usan, no en todos los modos se aplica... el blendop, esta bien... deberia explicar demasiadas cosas, es muy extenso y no es el objetivo del glitch.

no se puede usar 1 sola profundidad de color en todos los graficos, se necesita poder tener mixeadas.

si, bennugd dibuja por lineas horizontales.

teniendo en cuenta que se debe mantener el uso de graficos de varias profundidades, blendop, transparencias, alpha (incluso modo 8bpp y 16bpp), y todo lo que actualmente tiene... si quiere hacerlo desde cero, genial, pero tiene que soportar todo ello... sino no sirve, porque estas cosas se usan, por ejemplo, para ahorrar memoria en dispositivos con poca memoria, o usar paletas individuales en graficos de 8bits y un largo etc.

gracias, por verlo.

:)

[Anyeos]

Buenas, necesito una mano porque todo bien con el código fuente, pero me lleva mucho tiempo tratar de entender el algoritmo.

Hay muchas funciones que casi hacen lo mismo, quisiera entender cuál es la idea principal en realidad, para luego tratar de hallar una solución al problema. Lo que no quiero es hacer una copia de la misma solución, lo que quiero es saber cuál es el problema y estudiando el código fuente actual me puede llevar demasiado tiempo. Es mejor si alguien que ya lo sabe más o menos me explica lo que tiene que hacer.
Es más, ya me está llevando tiempo tratando de entenderlo.

Me di cuenta de que hay otra forma de solucionar el problema, no la inventé yo, son algoritmos más modernos de gráfica computacionales que se utilizan en los programas modernos de vectorización, y también en programas como Blender3D.

Utilizando esas nuevas técnicas es que quiero aplicar una nueva solución al blitter de BennuGD (esa era mi idea original). Que aparentemente también son más eficientes y rápidas. Pienso que si no fuera así no las usaría nadie, pero son las que se usan ahora en todos los programas de gráficos.

Por lo visto el código actual en g_blit.c utiliza otras técnicas. Entonces me lleva tiempo entenderlo. Sumando a que las técnicas nuevas tampoco son cosas básicas y también lleva su tiempo comprender, pero ya las he empleado antes y tengo parte de ese conocimiento. Y es que se hace uso de transformaciones por matrices (donde aplica toda la trigonometría matemática, seno, coseno, etc), escaneo de texturas, algoritmos de escaneo bicúbicos, lineales o bilineales, filtrados, las transformaciones por matrices para rotar, escalar, transportar, etc.
Indiferentemente de los bits empleados, que sólo se aplicarían en el escaneado de la textura.
Y con eso creo que ahorraríamos trabajo.

Por lo tanto yo creo que si implemento esas técnicas el código quedará mucho más reducido y legible.
Dividiría la tarea en:
Transformaciones (donde aplica escalado rotación etc)
Escaneado y filtrado (o sin filtro)

A su vez, esto facilitaría implementar un modo OpenGL combinado con el mismo código sin tener que hacer un módulo aparte.
Por qué, porque todo ahora trabaja de esa forma y es más fácil implementarlo así. O sea, el OpenGL también utiliza unas técnicas similares.

Por ejemplo tienes una textura que le aplicas el escaneado para rotarla. Eso lo puedes hacer con shaders. Entonces el código nuevo sería parecido al código para OpenGL, sólo habría que cambiar la llamada a unas funciones en las que en un caso usaría una por software y en el otro caso usaría una llamada por OpenGL.

Así que mi primer paso va a ser generar una estructura de matriz, y luego preparar matrices para aplicar las transformaciones.
Luego vendría la función de escaneo por línea horizontal. Primero la simple sin filtro. En la cual voy a manejar todo con valores de 32 bits, pero si se utiliza menos resolución por pixel, simplemente en la misma función dejaría de lado los bits no usados. Es así como quiero evitar generar tantas funciones para evitar confusión luego al tratar de leer el código.
Esa era mi idea @SplinterGU, no intentaba quitarle funcionalidades al blit. Solamente simplificar el código, porque de todos modos lo quiero reescribir, implementar una nueva solución.
Pero esa función aunque manejaría 32 bits máximo, no significa que le haría procesar todo en 32 bits, sino que usaría estrategias para trabajar con más o menos bits sin necesidad de hacer una función para cada una.  Esa era mi idea, pero no trabajar todo en 32 bits, sino que máximo soportaría 32 bits, luego utilizando las famosas técnicas de programación con lógica, and, or, o simplemente una sumatoria de valores más grandes, estaría dividiendo esos 32 bits logrando manejar menos y con menos pasos, o sea, es como dividir los 32 bits o usar un pedazo de ellos nada más.
Eso es lo que voy a intentar. Bueno, es más difícil de decir que de hacer jaja. No sé si me expliqué jaja. Pero son ideas ahora del dicho al hecho tengo que fijarme qué tan bien va, porque a lo mejor no resulta o es muy lento, no sé todavía, nunca lo hice así, siempre trabajé directamente en algo fijo como únicamente 32 bits.


Pero básicamente esas son mis ideas y tampoco pretendo reemplazar el blit actual. No me quiero imponer, solamente quiero ver si logro hacer uno que sea un poquito mejor y si cumple con las expectativas y los requisitos para ser oficial, bueno, mejor aún. De todos modos voy a intentar cumplir con eso para que le sirva a más gente. Porque a mi me alcanzaría conque funcione en los modos altos, de 16 a 32 bits, pero entiendo que hay gente que puede que use el modo de 8 bits, porque además podría utilizar paletas y se consiguen otros efectos con las paletas.


Bueno, voy a estar escribiendo esa parte a ver si para hoy tengo algo aunque sea elemental. Ojalá logre hacer funcionar algo ya con el nuevo blit.

De todos modos capaz que no es el blit lo que produce los gliches gráficos. Pero bueno, tengo que hacer el intento, no?


Saludos

[SplinterGU]

a ver, yo se que no es facil de entender, y quizas es mucho mas complejo de explicarlo todo.

hay tantas funciones, precisamente para ganar performance, ya que se activa cada callback cuando realmente se necesita y con esto se evita un codigo pesado o if pesados en una funcion generica... las funciones, son todas las combinaciones posibles, profundidades de bits, transparencias, blends, etc

el algoritmo actual utiliza transformacion por matrices, claro que lo hace, solo que estan simplificadas a su representacion mas reducida, asi que mas velocidad en ellas no logradas de ninguna manera.

creo que volvere a la version anterior, que al menos nadie reportaba los errores que yo note... asi que pasa desapercibido.

opengl y esto, son cosas diferentes, necesitamos un modulo opengl, como tambien necesitamos uno no opengl.

[Anyeos]

Bueno pero por qué lo dices como si estuvieras enojado.


Estoy tratando de entender como funciona, no me es fácil, me cuesta trabajo, por eso hago esas preguntas. Y me hubiera sido útil que alguien me explicara en resumen lo que actualmente hace el código o un buen consejo como: No te preocupes el código más o menos está bien sólo que está simplificado. O las funciones principales son estas tres, o leete que está en la documentación en esta web: bla bla.
Que se yo, algo más animante y que me sirviera para empezar. Pero bueno, no fue así, no importa, entonces no puedo ir más rápido, tengo que estar horas leyendo muchas cosas y hasta entenderlo que a veces me cuesta.


Ahora yo veo un comentario dentro del código que dice: "This file includes unoptimized C versions of those functions". A ver, yo entendí que no estaba al máximo de optimización según ese mensaje. Por ahí me equivoco, que se yo.


Sí, me di cuenta que cada función asigna en una variable para luego su ejecución. Y tampoco me parece muy óptimo si hay un montón de punteros haciendo un trabajo algo dudoso (que estoy tratando de entender). O sea, no está bien claro el código para mi, a eso me refiero, capaz que otros lo entienden a la perfección, que se yo.
Está mal hecho? No sé, pero si tiene un glich no parece que estuviera del todo bien. En alguna parte un error hay. Pero lo tengo que encontrar, y esa es la parte jodida. Bueno, preferí reescribirlo desde cero en vez de ponerme a buscar el error.

Ya que aparte por como hiciste el comentario @SplinterGU, a lo mejor te entendí mal, pero me dio la impresión de que el nuevo código te tenía frustrado y que estaba todo mal entonces a mi me pareció mejor idea reescribirlo todo. Que sería casi lo mismo que copiar el código anterior como dijiste más de una vez.
Entonces o lo reescribimos desde cero, o copiamos del anterior.


Yo no critico el trabajo ajeno más con lo que debe haber costado, al contrario, se han esforzado un montón en ese trabajo, estoy viendo que han abarcado cada situación en particular y eso es una locura de trabajo de sólo pensarlo. Pero yo en particular tengo otra forma de trabajar más simple. Y quería probar a ver si logro escribir un código a mi manera que cumpla las expectativas requeridas.

Ahora, no soy experto en todas las plataformas existentes ni tampoco las tengo. Y también todo esto lleva tiempo. Así que me voy a concentrar en desarrollar algo que funcione bien en la plataforma que tengo ahora.

Luego, voy a dejar las funciones organizadas de un modo tal que se puedan realizar optimizaciones específicas por cada plataforma que creo que sería buena idea hacer eso.
Si necesitamos optimización por cada plataforma me parecería bueno entonces usar ifdef para según donde se compile sea el código que use. Y de esa forma se le sacaría el jugo creo yo, supongo.


Si no te gusta como lo hice no estás obligado a ponerlo en el código oficial. Es más, la verdad yo nunca pensé en que lo pusieran en el oficial y sólo iba a hacer código para trabajar en 16 bits para arriba. Pero entiendo que hay gente que necesita todo tal cual, entonces por ellos lo haría pero esa parte a mi no me produce un beneficio.

Y aparte tampoco la tengo super clara sobre el tema del blit. Sólo tenía experiencia en la librería de Lazarus para manejo de gráficos esa que mencioné al principio y quería aprovechar sus algoritmos para implementarlos en BennuGD a ver si lograba arreglar el problema. Luego me di cuenta que dentro de todo los algoritmos que utiliza esa librería son los estándares que se usan en gráficos computacionales de hoy día.


Lo de OpenGL he visto muchos juegos 2D que usan OpenGL. Pensé que no sería mala idea aprovechar OpenGL en el blit. Sin que eso implique tener que cambiar nada en el código de los juegos actuales. Solamente si el desarrollador del juego quiere que su juego saque ventaja de OpenGL, al momento de iniciar el modo de video utilizaría una bandera lo cual haría que el bliter utilice OpenGL para algunas funciones. Si lo deja como está, usaría lo de siempre por software.
También se puede incluir un ifdef para compilar con ese soporte o no si no se quiere. Que se yo. Son ideas.

Un módulo de OpenGL podría reemplazar el blit? Si se puede hacer no me parece mala idea.


Igual yo no sé si es mi idea o qué, pero no me da la impresión de que BennuGD corra tan rápido graficamente. A ver, en Pascal hice un jueguito 2D que usa directamente SDL y supera a BennuGD gráficamente en velocidad, especialmente manejando transparencias y todos los gráficos en 16 bits.
Sin embargo no tuve que implementar código de optimizaciones gráficas. Simplemente usé las SDL en vivo y en directo.

Ahora, no soporta algunas cosas que BennuGD tiene (escalado, rotación). Pero entonces eso me hace dudar, aunque a lo mejor estoy equivocado, de si el código actual en el blit realmente es rápido.

Es muy subjetivo eso pero me da esa impresión. A lo mejor estoy equivocado pero cuando algo me da una impresión se me activa una especie de alarma que me indica que algo puede estar pasando. O no es totalmente óptimo, o es una percepción mía equivocada o simplemente es que no se puede mejorar porque implementa procesos más complejos y listo está todo bien así, no le debo dar bola a eso. Pero cuando me pasa trato de prestar atención, investigar, ver que puede ser lo que sucede para saber si está bien o si pasa algo realmente.



Igual todas estas son ideas mías, a quién le importan?
No es obligatorio que me hagan caso, ni que me presten atención ni nada.


De todos modos voy a intentar hacer eso que dije porque además de que me gusta y me sirve de práctica a lo mejor me sale algo bueno. Y quería compartirlo también.
O a lo mejor a nadie le gusta o sale una porquería, que se yo, pero el que no arriesga no gana así que voy a hacer el intento.


Saludos y gracias por sus respuestas (en serio).