Ver la versión completa : SDL aceleradas por hardware
Como algunos ya sabéis (Puck2099 como mínimo :)), Paeryn ha compilado unas SDL aceleradas por hardware (http://www.gp32x.com/board/index.php?showtopic=23819&st=0).
¿Alguien las ha probado? Ostras, es que he recompilado Tilematch y ahora tira a 160 fps cuando antes iba a 45. Y aún me he sorprendido más con un juego de naves que estoy programando, que no pinta imágenes sino directamente píxeles al framebuffer, y he pasado de 46 fps ¡¡¡a 730!!! Yo flipo... Sólo he tenido tiempo de recompilar y probar 5 minutos, pero todo ha funcionado correctamente.
Muhahahaha, los emuladores ahora tienen que ir como un tiro!!
Saludos
kronosMan
03/01/2006, 08:45
Se supone entonces que los emus de neogeocd, nes y snes (bueno y todos los que usen sdl) irán mucho más rapidos no?
Pero, Habría que volver a compilar los emus?
Ojo, que el de naves pinta pocos píxeles en pantalla, así que el incremento en FPS no es nada representativo. Con Tilematch, 3/4 de lo mismo: cada vuelta de bucle pinta 64 imágenes de 30x30 píxeles más texto, o sea que no es precisamente complejo.
Vaya, que yo diría que sí que mejorarán las aplicaciones que usen esas SDL, pero que los aumentos de velocidad no serán tan grandes.
Pero, Habría que volver a compilar los emus?
Correcto.
kronosMan
03/01/2006, 08:55
hombre pero si pasan de 40 a 80 fps por ejemplo, se notaria lo suficiente.
hombre pero si pasan de 40 a 80 fps por ejemplo, se notaria lo suficiente.
Sí, claro, pero un emulador o según qué juegos hacen un uso muchísimo más intensivo del render. Por eso digo que probablemente el incremento no sea tan grande.
kronosMan
03/01/2006, 09:00
ok, gracias por las aclaraciones, solo queda comprobar como irán esas librerias. Me voy a la cama, Buenas noches a todos.
Lo que me he leido del post original deja ha entendre que lo ha optimizado un poco, es decir, todavia se puede sacar mas rendimiento, no?
Saludos
Qué bien!
Espero que gracias a este avance se puedan llevar a cabo proyectos más ambiciosos :babea:
vaya, no habia visto estas libs, gracias por avisar miq01. mañana las probare :)
Esto servira mas que nada para juegos, en el tema de la emulacion, todo lo que va a acelerar es el volcado a pantalla del buffer en el que esta la pantalla de la maquina emulada, asi que el aumento de velocidad sera minimo.
Para que nos entendamos, un emulador no pinta los sprites uno a uno ni nada de eso, copia la pantalla una sola vez por frame, un emulador es tonto, no se entera de lo que hace, solamente hace.
Para que nos entendamos, un emulador no pinta los sprites uno a uno ni nada de eso, copia la pantalla una sola vez por frame, un emulador es tonto, no se entera de lo que hace, solamente hace.Quieres decir que no sería posible optimizar la emulación del hardware gráfico emulado?
Creo que lo que quieres decir es que la pantalla emulada se genera en un buffer de memoria y una vez terminado (el frame) se vuelca a nuestra memoria de vídeo (la real vamos) y es únicamente en este momento donde se podría aplicar esta aceleración. Pero no se podría ir más allá indangando en el código del emulador destinado a la emulación del hardware gráfico?
En mi vida he programado ni portado un emulador, por lo que hablo desde mi profundo desconocimiento del tema. Pero bueno, algo de teoría tengo.
Qué te parece? he dicho alguna animalada? hehe!
PD: Después de bastante tiempo, me está picando el gusanillo de la programación...
Hombre, todo es relativo, se puede usar esa aceleracion grafica tratando los sprites directamente en vez de volcar el buffer de la maquina emulada a la pantalla, creo que chui lo hacia asi con el emulador de neogeocd para dreamcast, no se hasta que punto aceleraria la emulacion, pero tal como lo hacen los emuladores que tenemos actualmente en gp2x, no serviria de mucho.
Son diferentes maneras de acercarse al mismo problema, en el caso de tratar directamente los sprites en vez de un buffer, el emulador seria algo mas complejo, y tendria mas control sobre lo que pasa en la pantalla, pero eso tambien puede llevar a una bajada de compatibilidad, o a errores graficos, esas cosas.
Pero no tiene por que ser asi, no?
Lo que dice K-teto sobre los emuladores es cierto. Pero pensemos en todas esas aplicaciones y ports que se verán beneficiados. Creo que uno de los más beneficiados será el ScummVM. Por otra parte me progunto como afectará esto a juegos 3D como Quake, Hexen, etc...
oCHARLIEo
03/01/2006, 14:44
Gracias por el post miq01, no habia leido ese hilo. Me parece una gran idea, no se me habia ocurrido incorporar la aceleracion 2D nativa de la GP2X a las SDL y me parece una muy buena iniciativa. Teniendo en cuenta (por lo que he leido) que esto solo es una primera aproximacion, la verdad es que la cosa promete bastante. Tal vez los emuladores no se vean tan afectados por la mejora en el rendimiento, pero juegos como el exult, el quake, el duke nukem o el transport tycoon tendran un aumento bastante considerable en su velocidad.
Yo al contrario que miq01 pienso que en los programas que mas uso hacen del pintado en pantalla es donde mas se notara. ^_^
Puck2099
03/01/2006, 14:54
Como bien dice miq01, yo ya sabía de estas librerías hace un tiempo, pero me pasó algo rarísimo en las pruebas que hice (obtenía un ejecutable de exactamente el mismo tamaño usando las libs viejas o éstas, pero luego borraba ambas y seguía compilando exactamente igual :confused: ) y lo dejé aparcado hasta arreglar ciertos fallos gráficos en el Exult.
Luego probaré con la nueva versión que han sacado, pero por ejemplo el Exult creo que va lo suficientemente rápido para no necesitar de la aceleración (aunque no sería mala idea usarla y reducir la velocidad de reloj de la máquina :D ).
Saludos
cagonto. Me voy a dormir tan feliz, y el foro se llena de novedades y de SDLs aceleradasss. Ahora mismo las pruebo.
EDIT: Probado, IT WORKS!
EDIT2: Lo acabo de probar con BFW, sigue teniendo los fallos graficos de siempre, pero se ve mas fluido. :brindis:
EDIT3: He notado que tarda considerablemente menos a la hora de ejecutar funciones que actualizan la pantalla, asi que, los emuladores que usan SDL si que puede que vayan un pelin mas rapidos.
Bueno , cualquier aumento de un par de frames , sera bueno.
Aun asi , me gustaria ver portados muchos juegos de gp32 a gp2x. Espero que fenix solucione el problema en gran medida.
un emulador es tonto, no se entera de lo que hace, solamente hace.
Qué buena, tu descripción de un emulador... :) Vale, o sea que si lo que casi todos los emuladores hacen es "pintar" en memoria y luego volcar a pantalla, tiene sentido que no se gane mucho en velocidad.
Luego probaré con la nueva versión que han sacado, pero por ejemplo el Exult creo que va lo suficientemente rápido para no necesitar de la aceleración (aunque no sería mala idea usarla y reducir la velocidad de reloj de la máquina :D ).
EDIT: Probado, IT WORKS!
EDIT2: Lo acabo de probar con BFW, sigue teniendo los fallos graficos de siempre, pero se ve mas fluido. :brindis:
¿Tenéis alguna manera de calcular los FPS? Estaría bien saber la diferencia de frame-rate.
Puck2099
03/01/2006, 19:48
¿Tenéis alguna manera de calcular los FPS? Estaría bien saber la diferencia de frame-rate.
Échale un vistazo a este topic (http://www.gp32spain.com/foros/showthread.php?t=25017&highlight=frames) . Si no te queda claro dímelo y te pego código "real" :)
Saludos
¿Tenéis alguna manera de calcular los FPS? Estaría bien saber la diferencia de frame-rate.Pues va de 3 a 7 frames mas rapido, pero tratandose de BFW es normal.
Échale un vistazo a este topic (http://www.gp32spain.com/foros/showthread.php?t=25017&highlight=frames) . Si no te queda claro dímelo y te pego código "real" :)
Saludos
No, no, si ya se calcularlo, gracias. :) De hecho, yo mismo añadí al Wiki (http://wiki.gp32spain.com/index.php/FAQ_de_programaci%C3%B3n#C.C3.B3mo_calcular_los_FP S) un pseudocódigo para calcular los FPS basado en el algoritmo que enviaste en ese mensaje. Me refería a vuestras aplicaciones, si teníais alguna manera de saber qué diferencia de FPS hay entre la versión acelerada y la versión sin acelerar. Por curiosidad.
Pues va de 3 a 7 frames mas rapido, pero tratandose de BFW es normal.
Bueno, pues bienvenidos sean esos 3 a 7 frames por la cara, ¿no? :)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.