Bueno, ya habéis visto que hemos decidido programar el juego en C++ y Lua, con la librería de SDL y el IDE Code::Blocks.
¿Qué os parecen estas decisión?
Estuvimos valorando otras IDEs como Dev-C++, pero al final nos decantamos por CodeBlocks por estar más actualizada y tener un buen soporte. Como restricciones teníamos que fuera gratuito y es aquí cuando las alternativas se reducen considerablemente.
Lo mismo con SDL. Investigando un poco (en 2D) y viendo alternativas (como Allegro), nos decantamos por SDL, los motivos no los podemos decir claramente (fue bastante arbitrario dada la similitud de las librerías), pero al programar nuestro juego en C++ hemos encontrado más acertado SDL que no Allegro que esta programada en C.
¿Opiniones? (supongo que por aquí ya habéis discutido más de una vez el tema de Allegro vs. SDL y me podéis redirigir a otro hilo)
Finalmente, ¿Qué opináis sobre la decisión de utilizar Lua para parámetros de configuración y estas cosas?
La decisión no me parece mala, pero el motivo por el que habeis elegido SDL en vez de Allegro no es correcto:
Citar
Lo mismo con SDL. Investigando un poco (en 2D) y viendo alternativas (como Allegro), nos decantamos por SDL, los motivos no los podemos decir claramente (fue bastante arbitrario dada la similitud de las librerías), pero al programar nuestro juego en C++ hemos encontrado más acertado SDL que no Allegro que esta programada en C.
Tanto una como otra están programadas en C. La verdad es que no sería una mala decisión escoger Allegro, pero tampoco lo es escoger SDL :D Y las dos puedes usarlas perfectamente en C++ (cuidado con los constructores y destructores de las clases que creeis si usais Allegro).
Allegro es quizá más fácil de usar (otra cosa: tal vez sean bibliotecas con el mismo propósito, pero son muy diferentes en sintaxis) y su interfaz es algo a más alto nivel que SDL (tiene hasta un sistema propio de empaquetado de recursos).
Es cuestión de gustos, la verdad. Si se montara algún flame Allegro/SDL defendería a ambos a capa y espada xD.
Con respecto al IDE habeis hecho bien al no coger Dev-Cpp. Tiene muchísimos bugs. CodeBlocks es muy buen IDE, aunque no es mi favorito (Eclipse).
Y el tema de LUA, pues si solo vais a usarlo para modificar parámetros de configuración, sería matar una mosca a base de BFG10K. Allegro tiene funciones para leer y modificar estos parámetros, que serían guardados en un fichero .ini . Ahora, si vais a usar LUA para la IA y otras cosas de la lógica del juego, perfecto.
Espero que os haya servido de ayuda.
Sobre SDL/Allegro ya comento que es bastante arbitrario y como SDL ha sido la que he pillado primero y mirado más a fondo pues hemos cogido esta. Lo que si he visto es que Allegro no se lleva muy bien con algunas bibliotecas de c++ como fstream o iostream.
Como experimento tambien puedes probar a buscar en el google:
"allegro c++ tutorial" resultados encontrados: 383.000
"sdl c++ tutorial" resultados encontrados: 755.000
Pero ya te digo que nunca he utilizado alguna de las dos y desconozco el tema por completo :roll:
Sobre el IDE Eclipse... tienes razón esta muy bien, pero creo que el problema de Eclipse es que es un MONSTRUO de IDE y que se puede hacer de todo... por eso nos enfocamos en un IDE específico de C++
(y que conste que yo utilizo Eclipse habitualmente).
Por último sobre LUA puede que tengas razón que para solo utilizarlo con los parametros de configuración es demasiada cosa. Pero creo que tiene mucho potencial y me gustaria experimentar sus posibilidades. Una opción como bien dices es hacer la IA, otra también siguiendo la idea de WoW es poder ajustar el interface a través de LUA..... vamos, ideas y teoría tengo, pero mi práctica es nula :P
Aqui hay una discusión SDL vs Allegro y al final el chico escoge SDL
http://gamelab.uniovi.es/foros/forum_posts.asp?TID=154&PN=2
PD. Barriendo para casa jeje :P
Yo utilizo Allegro para programar juegos,nunca e probado SDL,y es verdad que hay muy poca información sobre Allegro y mucha de SDL.
A favor de Allegro tengo que decir(desconociendo SDL)que me parece muy intuitivo y facil de utilizar.
Allegro es una libreria mas completa que SDL de cara a programar un juego, lo malo es que inicialmente da bastantes problemas a la hora de compilar y el diseño de la libreria es bastante antiguo.
SDL viene "pelado", aunque podeis encontrar muchas librerias adicionales que os facilitaran la vida. En windows es bastante lenta.
Cita de: "Snakers"A favor de Allegro tengo que decir(desconociendo SDL)que me parece muy intuitivo y facil de utilizar.
Mmmm por lo poco que he visto de SDL también parece muy intuitiva...
Cita de: "seryu"SDL viene "pelado", aunque podeis encontrar muchas librerias adicionales que os facilitaran la vida. En windows es bastante lenta.
Esto no lo llego a entender, si viene "pelado" ¿cómo puede ser más lenta? Me parece que no te he entendido bien...
Cita de: "Vicente"Lo mismo si vais a usar SDL os interesa echarle un ojo a la CRM32Pro de Azazel
Buf... a ver, usar CRM32Pro quiere decir poner otra capa de abstracción más al tema. Estoy de acuerdo en que esto te facilita más la vida a la hora de programa, que te ahorra tiempo, etc... Pero hay que tener presente que nos estamos
iniciando en el tema, y creo que es importante comenzar poco a poco y entendiendo como funcionan las cosas (incluso me gustaría no tener que utilizar SDL, pero entonces perderíamos demasiado tiempo peleandonos con el sistema operativo, drivers, hardware,...).
Mmmm creo que sería interesante desarrollarlo primero sólo con SDL y después "actualizarlo" utilizando CRM32Pro (el bomberman a priori es un juego sencillo y no creo que cueste mucho "envolverlo" con el CRM32Pro sobretodo si esta en SDL). De esta manera también podríamos observar la s repercusiones en el rendimiento.
Comentar tambien que todo esto son conjeturas, os recuerdo que no tengo experiencia en el tema y jamás he utilizado estas librerias, por eso espero consejo y ayuda ;)
Muy buenas! estaba oculto en la cueva sin querer decir nada pero ya que he salido por ahi jeje, vamos a despejar un par de dudas/mitos:
- SDL y Allegro son practicamente clavadas, sus desarrollos iniciales fueron mas o menos por las mismas fechas, la diferencia mas notable es que Allegro fue creada como una lib que reuniera por defecto mucha mas funcionalidad y de mas alto nivel y SDL fue lo contrario, mantenerlo lo mas reducido posible y algo mas de bajo nivel pero HAY miles de plugin, librerias y demas que te permiten hacer cualquier cosa con ello, que quieres reproduccion de mpeg? pues toma! y asi con todo. De hecho, hay versiones de SDL para moviles, PDA, GP32X, etc..
Actualmente y bajo mi punto de vista, Allegro se esta quedando un poco olvidada y SDL sigue evolucionando mucho, de hecho, ya estamos(aunque he colaborado muy poquito jeje) con la 2.0 que como ya dije en otro post, traera backend de video muy mejorados aprovechando D3D y OpenGL.
- Si Allegro es intuitiva, SDL tambien lo es, vamos, son bastante sencillas de utilizar, pero que muy mucho! Solo necesitas tener claro un par de ideas generales y el resto es coser y cantar.
- En cuanto a la doc, ejemplos y demas... ambas estan muy bien documentadas, quizas de SDL haya mas ejemplos... pero es porque es valida para casi cualquier tipo de plataforma.
- Seryu, respecto a eso de que SDL es lento en windows... es un mito :). SDL en windows es casi tan rapido como usar solo DirectDraw. Esto lo he repetido en multitud de ocasiones y podeis consultar un programita que hice que se llama glSDLBenchmark donde podreis probarlo por vosotros mismos. Lo que me gustaria saber es...de donde ha surgido ese mito tan extendido... me recuerda a lo de hace tiempo: "No no, que los AMD son incompatibles!!" :P
- Con respecto a utilizar SDL y CRM32Pro... vereis, CRM32Pro no es un reemplazo de SDL, es mas bien una extension de algunas funciones para que sea mas rapido desarrollar juegos. Es decir, si haces el juego con SDL, pasarlo a CRM32Pro no tiene ningun sentido porque ya te habras currado tu mismo "partes" de CRM32Pro, me refiero a tiles, sprites, fuentes, botones, etc... y por otro lado, si lo haces con CRM32Pro no significa que no aprendas SDL, todo lo contrario, lo necesitas porque seguiras usandolo. Y que sea mas lento? NO!. De hecho los blitters cuando estas en modo software seran mas rapidos ya que esta todo bastante optimizado dependiendo de la CPU que utilices y el resto de cosas que agrega CRM32Pro, SDL no se mete con ello por lo que no hay ningun compromiso en rendimiento.
Espero haber despejado varias dudas y si surge alguna mas, preguntar preguntar! ;)
Saludos
Cita de: "warwolf"Cita de: "Vicente"Lo mismo si vais a usar SDL os interesa echarle un ojo a la CRM32Pro de Azazel
Buf... a ver, usar CRM32Pro quiere decir poner otra capa de abstracción más al tema. Estoy de acuerdo en que esto te facilita más la vida a la hora de programa, que te ahorra tiempo, etc... Pero hay que tener presente que nos estamos iniciando en el tema, y creo que es importante comenzar poco a poco y entendiendo como funcionan las cosas (incluso me gustaría no tener que utilizar SDL, pero entonces perderíamos demasiado tiempo peleandonos con el sistema operativo, drivers, hardware,...).
Mmmm creo que sería interesante desarrollarlo primero sólo con SDL y después "actualizarlo" utilizando CRM32Pro (el bomberman a priori es un juego sencillo y no creo que cueste mucho "envolverlo" con el CRM32Pro sobretodo si esta en SDL). De esta manera también podríamos observar la s repercusiones en el rendimiento.
Comentar tambien que todo esto son conjeturas, os recuerdo que no tengo experiencia en el tema y jamás he utilizado estas librerias, por eso espero consejo y ayuda ;)
Mmm, hombre, aprenderéis más pegándoos con SDL a pelo, pero yo creo que para el primer juego lo importante es que lo consigáis terminar (ya de por si todo un reto) y luego poco a poco empecéis a profundizar en temas más complicados. Yo por eso creo que para un primer contacto tiraría por CRM32Pro.
Un saludo!
Vicente
jejeje, como se nota que somos pkm06 members! jajaja
el tema tambien podria apuntarse de otra forma:
- Quieres saber como se puede llegar a hacer un juego y todo lo que hay debajo de el? Pilla SDL, DirectX, Allegro o lo que quieras y empieza a aprender todo.
- Quieres hacer un juego, terminarlo y poco a poco aprender los conceptos que hay debajo? Pilla algo de mas alto nivel y centrate en el juego que ya de por si tiene tela.
Si no, cualquier cosa que se salga de eso entra en el termino utilizado por lex: Sindorme de NIH jejeje
Saludos
Hum.. yo también creo que para comenzar es muy útil la lib de Azazel, sobre todo porque como dice él, usando tb SDL te da ya mucho curro hecho. Por ejemplo, a la hora de hacer un menú, hacerlo a pelo con SDL significa que tengas tú que implementar clases, controlar cuando alguna opción se pincha.... i con la crm32 eso se simplifica mucho ;) :) Pongo este ejemplo porque para un proyecto estoy usando la crm y para otro sdl a pelo y, lo dicho, para empezar o para ahorrar tiempo y quebraderos de cabeza varios... un lib de alto nivel como ella viene de perlas. ;) :) (imagina tb a la hora de gestionar sprites, tiles, efectos, el log, la música, el timing... realmente mucho curro que os retrasará bastante...)
Sobre allegro, no lo llegué a probar, tb circulaba la leyenda urbana que parece ser cierta de que da muchos problemillas al compilar... desde luego por parte de SDL, sus extensiones y la crm, ningún problemilla... :D
Saludeteees!
Solo le falta un buen tutorial para terminar de cogerle el punto a la libreria :P :lol:
Por lo demas si que es util, te lo puedo asegurar.
Harko.
Bueno, por mi parte decir que me habéis convencido y encuentro muy interesante, pero sobre todo útil, utilizar la librería CRM32Pro (tengo curiosidad de dónde viene el nombre). Además, el soporte técnico seguro que será muy bueno :D
Sobre la lentitud de SDL... jeje me imaginaba que sería una especie de mito (no le encontraba el sentido) y también me hizo sospechar mucho cuando vi el programilla ese de Benchmark que tiene Azazel.
Sobre la explicación de la finalidad de la lib CRM32Pro. Gracias, me has despejado algunas dudas y por eso encuentra muy interesante utilizarla ya que mi máxima prioridad primero es terminar el juego y todo lo demás ya vendrá poco a poco.
Nuevas duda que me han surgido:
Veo que en el empaquetador puedes guardar archivos de .xml (útiles para la internacionalización de los juegos) así como archivos .ini (parámetros de configuración). Así pues, ¿creéis necesario/interesante utilizar LUA? Si es así para que ambitos, ¿IA? ... ahora estoy muy perdido en el tema :?
Y por acabar otra cosilla, he visto que hay una librería muy interesante llamada Boost (http://www.boost.org/) para facilitar la portabilidad y estas cosas, pero no acabo de entender bien los beneficios que aporta utilizar esta librería y si sería interesante tenerla en cuenta o no.
PD. Azazel, donde si que me he perdido es cuando me has hablado de blitters :?:
También he visto que el próximo juego que estas haciendo es TitanBomber, si quieres (y si nuestro proyecto llega a buen puerto) no tendré ningún problema en compartir todo para que lo puedas poner en tu sección ;) siempre y cuando estés interesado claro.
PPD. Juer, si que es difícil esto de decidir que librerías utilizar y toda la pesca, no me quiero imaginar cuando intentemos alguna cosa en 3D donde la oferta es muuuucho más amplia :?
Cita de: "TheAzazel"
- Seryu, respecto a eso de que SDL es lento en windows... es un mito :). SDL en windows es casi tan rapido como usar solo DirectDraw. Esto lo he repetido en multitud de ocasiones y podeis consultar un programita que hice que se llama glSDLBenchmark donde podreis probarlo por vosotros mismos. Lo que me gustaria saber es...de donde ha surgido ese mito tan extendido... me recuerda a lo de hace tiempo: "No no, que los AMD son incompatibles!!" :P
No es ningun mito, en windows utilizan dx5 osea directdraw como tu bien dices que es mucho mas lento que utilizar 3d aplicada a 2d, aprovechando asi el hardware de la tarjeta mucho mejor.
El nombre viene de una movida que hice hace muchisimos años en el Amstrad CPC 464... se llamaba CRM, despues solo hubo que añadir el 32 por los 32bits tan de moda cuando empece con ella y el Pro...pues porque yo lo valgo :P jejeje. Y en sus origenes, CRM viene por el modelo de Honda que hace tantisimos años me hizo disfrutar de lo lindo... en fin, que cosas jeje
Respecto al empaquetador, puedes empaquetar lo que tu quieras, cualquier fichero, cualquier estructura tuya, eso a gusto del usuario. Lo que tiene el EditorDPF es que si agregas un fichero y es de texto podras modificarlo directamente desde alli sin tener que extraer/modificar/volver a guardar.
Sobre LUA.. lo desconozco, pero un tal Lex(quien sera? jeje) me comento que fue una locura usarlo asi que basado en eso... te aconsejo que pases de cualquier lenguaje de scripting por ahora y hagas la IA de otro modo, todo con vistas a agilizar el desarrollo del juego.
La Boost esa... NPI, la primera vez que la veo nombrar...
Los blitters son las funciones que vuelcan las superficies a otras superficies (incluida otra que la que se mostrara en el monitor). Si son por hardware van como un tiro porque lo hara la tarjeta de video pero si son por software...tiran mucho del memcpy() y yo estuve optimizando varias rutinas en ASM(usando MMX y SSE) que dependiendo del procesador donde esta corriendo y el tamaño de la transferencia, utilizan una u otra rutina, resultado: un SDL_BlitSurface() es mas rapido usando CRM32Pro que sin utilizarlo, y tengo pruebas de ello :P
Acerca del TitanBomber... me parece genial cualquier tipo de colaboracion :) y si hay que crearte una subpagina o un enlace en la web, eso esta hecho!. El TB esta casi terminado, no sera un juego singleplayer... lo enfoque para probar el sistema de red y bueno, basicamente se pueden jugar 2-4 jugadores y 4 mapas y el que mas puntos consiga en la ronda sera el ganador. Toda la logica esta hecha, graficos warris y la red funcionando, solo me falta encontrar tiempo para terminar un menu simple para agregar mas players, un tablon de puntuaciones y luego buscar un grafista y que le de a todo un lavado de cara :). La verdad es que podria acabarlo...total, ya me queda muy poco... pero necesito tiempo!!!
No te creas que es tan dificil escoger una lib... aqui lo tienes tirao... si estas en modo 2D...hay varias opciones de gente del foro(dx_lib32, etc...) y si quieres 3D...esta clarisimo...Jad rulez!!
Ya no me enrollo mas, un saludo!
Cita de: "seryu"Cita de: "TheAzazel"
- Seryu, respecto a eso de que SDL es lento en windows... es un mito :). SDL en windows es casi tan rapido como usar solo DirectDraw. Esto lo he repetido en multitud de ocasiones y podeis consultar un programita que hice que se llama glSDLBenchmark donde podreis probarlo por vosotros mismos. Lo que me gustaria saber es...de donde ha surgido ese mito tan extendido... me recuerda a lo de hace tiempo: "No no, que los AMD son incompatibles!!" :P
No es ningun mito, en windows utilizan dx5 osea directdraw como tu bien dices que es mucho mas lento que utilizar 3d aplicada a 2d, aprovechando asi el hardware de la tarjeta mucho mejor.
Eso es cierto..pero de ahi a decir que SDL en windows es lenta!?? entonces SDL es "lenta" en todos los sistemas salvo que utilices glSDL!.
Yo me referia y lo entendi por el lado que su backend por software (ya sea volcando en windib, ddraw, etc..) era peor en windows que en otros sistemas y eso no es cierto ni mucho menos.
Allegro que yo sepa tampoco utiliza el hardware 3D en modo 2D. Si conozco varias lib que utilizan D3D para trabajar en 2D (LooverLib es una y HGE es otra) pero yo no comparo una lib trabajando en modo soft contra otra en modo hard...
A mi me quedan semanas para liberar la v5.0 con glSDL integrado y entonces hasta acelerara todo el 2D usando OpenGL :). Que bueno, no llega a ser el rendimiento igual a usar D3D u OpenGL en modo puro pero se acerca bastante y sobre todo...esta a años luz del modo software!!
Pues na, mito resuelto :P
Vamos, que me estais contando que ahora mismo SDL (y CRM32Pro) trabajan más lento en modo hardware que en modo software... curioso teniendo en cuenta todos los avances gráficos en tema hardware que se han realizado.
Pero veo que tambien esto esta a punto de "arreglarse" con la v5.0 ;) mmm ¿se implementará tambien para trabajar en D3D? o no merece la pena ya que el rendimiento es practicamente igual que con OpenGL?
Hey TheAzazel hace tiempo que queria preguntarte algunas cosillas y ahora voy a aprobechar ahora que parece que estas activo :twisted:
- Que tipo de ficheros graficos se pueden utilizar en la CRM? Me refiero a extensiones, por ahora lo he hecho todo usando BMPs (no me pegueis :D) porque no estaba muy seguro.
- Hay una funcion que se llama SDL_SaveBMP que guarda la imagen que haya en una superficie en un bmp. Hay alguna otra para guardarla en otro tipo de formato? Esque ocupa mucho :P. A esta funcion le tengo que dar unas vueltas para encontrar la forma de que no me sobreescriba la imagen anterior jeje.
Mmm, seguro que tengo mas dudas pero ahora no me acuerdo. La proxima vez las ire apuntando :D
Cita de: "warwolf"PPD. Juer, si que es difícil esto de decidir que librerías utilizar y toda la pesca, no me quiero imaginar cuando intentemos alguna cosa en 3D donde la oferta es muuuucho más amplia :?
Calla, calla, no me lo recuerdes :roll:
Cita de: "warwolf"Pero veo que tambien esto esta a punto de "arreglarse" con la v5.0 ;) mmm ¿se implementará tambien para trabajar en D3D? o no merece la pena ya que el rendimiento es practicamente igual que con OpenGL?
Pues no creo que lo haga, ten encuenta que la idea es mantener tanto a SDL como a CRM32Pro como librerias multiplataforma y Directx no es precisamente conocido por ese "detalle". Aparte del tema de que cada X tiempo cambian la libreria de tal forma que ya no te vale para nada lo que habia antes, como va a pasar con la version 10 por lo que parece.
Harko.
Cita de: "Harko"
Cita de: "warwolf"Pero veo que tambien esto esta a punto de "arreglarse" con la v5.0 ;) mmm ¿se implementará tambien para trabajar en D3D? o no merece la pena ya que el rendimiento es practicamente igual que con OpenGL?
Pues no creo que lo haga, ten encuenta que la idea es mantener tanto a SDL como a CRM32Pro como librerias multiplataforma y Directx no es precisamente conocido por ese "detalle". Aparte del tema de que cada X tiempo cambian la libreria de tal forma que ya no te vale para nada lo que habia antes, como va a pasar con la version 10 por lo que parece.
Harko.
Mmmm a ver, SDL
YA utiliza Directx, más concretamente DirectDraw. Su habilidad de ser multiplataforma es el hecho de que internamente (según en que máquina se ejecute) utiliza unas librerias u otras. Por eso la pregunta de si se dara soporto también a utilizar los drivers de D3D en windows ;)
No te acostaras sin saber una cosa mas :lol:
Uff, cuantas cosas!! :)
Espero no olvidar ninguna...
- SDL (y CRM32Pro) trabajan mas rapido en modo hardware. Lo que en modo software no hay ninguna restriccion y en modo hard hay que tener cuidado con un par de cosas. glSDL soluciona en gran parte estos problemillas secundarios. En concreto, en modo hardware hay que tener cuidado con las surfaces que tengan alpha(per surface o per pixel) ya que creo que no hay ninguna tarjeta grafica/drivers que soporte en ddraw en modo hard el alpha... glSDL si lo hace :P
- Sobre el tipo de ficheros graficos, nativamente y como ya sabes admite cargar y grabar en BMP. El EditorDPF ademas admite importar/exportar en PNG (por el canal alpha y para dar algo de compresion). Internamente, usa un formato propio que comprime mas o menos como un GIF/PNG. No inclui en CRM32Pro el soporte directo a PNG por temas de espacio pero bajo demanda no hay ningun problema en hacerlo, de hecho, incluso un TGA que podria ser util, tambien podria añadirlo de modo sencillo. JPG descartado por el momento ya que para juegos 2D (sin texturas) eso de tener que perder calidad no tiene tanto sentido...
Si quieres exportar a algun otro formato que no sea BMP... podria incluir el soporte PNG en CRM32Pro y asi tener la opcion de guardar tambien en PNG... convenceme :P
- El tema de un backend que use D3D esta en desarrollo... pero no para SDL 1.2, si no para SDL 2.0. Yo con usar glSDL en CRM32Pro que ademas es multiplataforma ya sera mas que suficiente...de DirectX siempre me he alejado todo lo que he podido y mas y por el momento seguira siendo asi. En velocidad...pues tal como indicaron pruebas con glSDLBenchmark... parece que en picos altos (1000,2000 fps) d3d era mas rapido que opengl pero eso podria ser por cualquier cosa extraña, a rates mas normales son practicamente iguales.
Creo que mas o menos esta todo no? jejeje
Me estas exprimiendo hoy eh? anda! las 6, me piro para casa que ya es finde!
Saludos
Cita de: "TheAzazel"
Eso es cierto..pero de ahi a decir que SDL en windows es lenta!?? entonces SDL es "lenta" en todos los sistemas salvo que utilices glSDL!.
Yo me referia y lo entendi por el lado que su backend por software (ya sea volcando en windib, ddraw, etc..) era peor en windows que en otros sistemas y eso no es cierto ni mucho menos.
Cuando lo probe y en mi experiencia SDL es mas rapida en linux que en windows. ¿Tal vez ya no sea asi?
Cita de: "TheAzazel"
Allegro que yo sepa tampoco utiliza el hardware 3D en modo 2D. Si conozco varias lib que utilizan D3D para trabajar en 2D (LooverLib es una y HGE es otra) pero yo no comparo una lib trabajando en modo soft contra otra en modo hard...
No pretendia decir que SDL era mucho mas lenta que allegro, perdona la confusion.
En cuanto a comparar librerias, yo prefiero compararlas por la categoria que por la cantidad de aceleracion que metan, que si es mucha, pues mejor para todos. Pero ni SDL es todo por software ni una que use ogl es todo por hardware. Para mi cumplen una funcion y es eso lo que valoro, a mi me da igual si ellas internamente utilizan buffers de memoria de video o incluso usan la gpu para calcular los "sprites" como poligonos o lo que sea. Yo lo que quiero es algo comodo y que funcione lo mejor posible.
De hecho, si alguno se ha quedado con la impresion de que desaconsejaba SDL, todo lo contrario. Solo habia comentado un par de impresiones de las dos librerias, no pretendia sentar catedra :wink:
Es posible que cuando lo probaras, tirara mas rapido en linux que en windows... si hace bastante tiempo de tus pruebas casi seguro.
Digamos que primero optimizaron para "Linux" (ensamblador del gnu) y luego fueron portando a Windows ese codigo, incluso creo que hoy en dia, hay funciones que solo estan muy optimizadas para Linux, luego eso que dices, en determinadas situaciones es posible :)
De todos modos, voy a probar... como tengo los mismos ejemplos para linux que para windows... probare y ya te lo dire en la quedada del proximo viernes :P
Tambien parece que a mi no me mola Allegro... y bueno, tampoco es asi, hace mucho tiempo...por aquellos años del MSDOS y el Watcom.. utilizaba Allegro asi que tanto a una como a otra, las tengo bastante "cariño". El unico que me despierta todos mis males internos son las directX jejeje
Saludos!
Bueno, gracias a todos, creo que el tema de SDL-Allegro-CRM32Pro (curiosa historia la del nombre :D) me ha quedado bastante claro.
Me quedan pendientes valoraciones del Lua (http://es.wikipedia.org/wiki/Lua) (de momento solo hay una negativa) y si alguien tiene idea de la lib Boost (http://www.boost.org/)
PD. Mmmm y a los que no vamos a la quedada nos quedaremos con las ganas de saber el resultado de tus experimentos?
Lua gusta mucho principalmente por la facilidad a la hora de integrarlo en tu programa.
Yo despues de probar unos cuantos me quedo con angelscript:
http://www.angelcode.com/angelscript/
Sobre lenguajes de scripts 2 cositas:
1- LUA es muy usado pero tienes el problema de no tener más que un tipo de dato numérico (coma flotante por defecto) con los problemas que ello implica para según que usos. Es pequeñito y se integra muy facilmente. Tiene JIT para x86, eso es un plus.
2- Angelscript casca en arquitecturas bigendian, como el MACOSX PPC.
Tira con LUA, pero ten presente el tema de los números. O metes un parche para que los números sean enteros de 32 bits (bye bye decimales) o tiras con floats.
Tras ver todas las explicaciones expuestas, como a warwolf, tambien me esta picando la curiosidad sobre la CRM32Pro, por lo que entiendo en principio nos resultará algo más sencillo terminar si usamos esta, así pues veo bien empezar por lo mas sencillo y luego meternos más de lleno con algo mas complejo. Ya tuve un primer contacto con allegro y no nos llevamos mu bien jajaja. Ademas para mi cuantas mas plataformas sea capaz de abarcar mejor, segun creo entender SDL abarca más.
Saludos a todos
Cita de: "senior wapo"
2- Angelscript casca en arquitecturas bigendian, como el MACOSX PPC.
¿Estas seguro de eso? yo no lo he probado, pero que sepa, tiene soporte tanto para macos como ppc. ¿Tal vez hablas de una version vieja?