¡Oh no! ¿Dónde está el JavaScript? El navegador Web no tiene JavaScript activado o no es compatible con JavaScript. Active JavaScript en su explorador Web para ver correctamente este sitio Web o actualizar a un navegador Web que admita JavaScript.
Sabías que...
La protección anticopia de los BleemCast! era tan avanzada que no fue hasta finales de 2009 (8 años después) cuando se consiguió recrear un dump funcional.

Engine 2d - Desarrollo

Última actualización en 11 años hace
Guaripolo
Retomando la idea de Neoblast, al "duende del jarrón de monedas de oro" (baigos) le ronda por el marote la idea de desarrollar un engine 2D multiplataforma (por ahora Windows, Linux y por supuesto Dreamcast). El ya está desarrollando algunas cosas, probando implementar transparencias, patrones de movimiento y rotaciones. Estamos trabajando sobre SVN (ya les paso la dirección). A todos aquellos que les interese colaborar avisen, a ver si se puede armar algo interesante. Por ahora la idea es hacer un juego de disparo para utilizar la pistola de la dreamcast.

La dirección del svn es http://code.google.com/p/superjuego/

Ahí van a poder encontrar siempre lo último del desarrollo.
Indiket
Superjuego? Venga Guari, que todo el mundo sabe que "SuperGame" suena mejor jeejejjejeje. De dónde sale ese genial nombre?

Voy a probarlo, a ver qué tal anda cheeeeee :D
Guaripolo
si los japoneses hacen un juego que se llama "gran turismo" y se llenan de guita, nosotros le ponemos superjuego y nos la rebancamos.
Indiket
Leñe, no blasfemes el nombre de "Gran Turismo" = álbum de estudio del genial grupo "The Cardigans"..... Indiket dixit!
Guaripolo
uh por fin algo de música eh, yo pensaba ya que eras sordo jejejejeejeee (esta buena la cantante de the cardigans)
baigos
sobre el engine, hasta ahora hice unas cuantas funciones agrupadas en sprite.h y sprite.c para manejar frames y sprites estilo el ejemplo del 1945 en sdl con csprite, pero en c.
Ademas puedo controlar el delay de cada frame, el tema es que ahi no ahonde mas y se maneja con ciclos, tal vez seria mejor trabajar con milisegundos. Igual funciona bien.
Las funciones de rotacion, transparencia y zoom lo unico que hacen es setear las variables correspondientes en el struct frame. Posteriormente la funcion que hace el render -drawframe- se encarga de verificar esas variables y dibujar a conveniencia.
Los sprites son iteraciones de frames, y controlo el estado con una serie de variables y un contador de frames. Ademas posee funciones que trabajan sobre las funciones de frame.
Ahora, la idea es que pueda trabajar en SDL, opengl o en powervr, entonces estamos debatiendo algunas cosas. Cuando hago un drawframe(...) uno de los parametros es la superficie destino, ya que por ahora estoy desarrollando en sdl. Lo que podria hacer es "determinar" que dibujare si trabajo con SDL en una superficie "screen". Entonces no tengo parametro destino, y puedo trabajar mas libremente con otras apis.
Otra idea es hacer un grupo de funciones agrupadas en render.c y render.h, donde se agrupan funciones que tengan el mismo comportamiento de drawfram, pero para cada api.

Otra cosa, si los japoneses hacen un juego que se llama gran turismo, otro que se llama viva piñata, otro que se llama libero grande, y los franceses un viva soccer, porque no superjuego, no es pretencioso como hiperjuego ni tan achicado como jueguito. A las chicas seguro que les va a gustar.
baigos
otra cosa, yo use unas funciones de manejo de timers, que estoy agrupando en timer.h y timer.c, y con ellas controlo el framerate constante.
Lo que no se si es mejor que utilizar SDL_framerate.h que viene en el SDL_gfx y que el todopoderoso chui la ha portiado. Habra que probar.
Indiket
En cualquier caso, con la ayuda de Guaripolo, ya conseguí compilarlo y ejecutar en DC la animación del hombre loco. Ahora, "sólo" queda hacer el juego jejejeje.
Dark Hayabusa
Me podria ofrecer para probar e intentar algo interesante!
Resulta que el Openbor me a quedado chico y ultimamente no han optimizado el video, esto me tiene un tanto frustrado
baigos
pero con todo gusto!
por ahora vas a encontrar solo un ejemplito de un tipo "nadando" -muy gracioso y simple-.
El engine usa SDL, pero en dreamcast intentaremos implementar un render en powervr. Igualmente SDL sera una opcion, al igual que opengl.
baigos
acá surgió una duda, queremos implementar un render que trabaje sobre varios blitters. El tema es como almacenamos las imagenes para que trabajen sobre varios blitters. Una es hacer una estructura de datos que varie segun el tipo de dato que cada blitter almacena las imagenes, esto seria algo asi:

typedef SDL_Surface *tipo_imagen

(si trabajara sobre SDL)

o algo parecido, y despues hacer un array de ese tipo para almacenar las imagenes.
Despues guaripolo mencionó algo de puntero nulo que no entendi porque tengo el cerebro quemado por ver peliculas con raperos.
baigos
el render del engine utilizará SDL+OpenGL para pc, y en dreamcast powerVR, pero estamos viendo si utilizar la api o usar parallax
Dark Hayabusa
En lo que respecta al Openbor iva por muy buen camino, pero me parece que se dejo a medias la optimizacion del video e implementacion de apoyo con el PowerVR y devido a esto no funciona a full el modo de video de 16 y 32 Bit.
Los soporta pero a un framerate muy bajo. Tambien se me olvido mencionar que tambien tiene problemas con la resolucion, en cuanto pueda les enviare unos ejemplos.
Dark Concept
baigos
y para desarrollar tu juego usas el lua del openbor? o modificas el codigo? parece muy potente el lua del openbor.
El problema de la api de powervr es que la documentacion esta toda por ahi desparramada. Hay que leer mucho codigo para ponerse al tanto, por eso tal vez la mejor opcion es usar parallax que funciona muy bien. No se si parallax soporta texturas paletizadas.
Dark Hayabusa
Es un punto interesante! Entiendo algunos conceptos, pero desgraciadamente no soy programador solo disenador. Y si es verdad que e conseguido acomodar algunos parametros del juego a la vercion de DC (por eso los problemas en las verciones de PC y PSP que son las que no tengo como prioridad) Pero los cambios solo fueron a trabes del Binario que no es gran cosa.
Dark Concept
Dark Hayabusa

Cita

Dark Hayabusa escribe:
Es un punto interesante! Entiendo algunos conceptos, pero desgraciadamente no soy programador solo disenador. Y si es verdad que e conseguido acomodar algunos parametros del juego a la vercion de DC (por eso los problemas en las verciones de PC y PSP que son las que no tengo como prioridad) Pero los cambios solo fueron a trabes del Binario que no es gran cosa.

Otra cosa! Me parece que por memoria RAM y modo de video RGB es mejor el PVR que el gif, pero me parece que por rasones legales o de menor conocimiento con respecto al formato no quisieron ocuparlo en Lavalit.
Esto tambien involucra el formato de sonido: Wav y Bor contra el ADX.
Dark Concept
Guaripolo
creo que hay una confusión Dark Hayabusa, cuando hablamos de powervr o pvr nos referimos a utilizar el hardware 3d de la dreamcast para hacer el dibujado (contrariamente al modo framebuffer que utiliza SDL por ejemplo). Vos te referis al formato de texturas PVR, este está soportado por kallistios y es 100% legal utilizarlo (sino el kallistios directamente ni lo soportaría).
Dark Hayabusa
Gracias por aclarar la duda.
puede ver todos los hilos de discusión en este foro.
puede iniciar un nuevo hilo de discusión en este foro.
no puede responder en este hilo de discusión.
no puede empezar en una encuesta en este foro.
puede cargar archivos adjuntos en este foro.
no puede descargar archivos adjuntos en este foro.
Afiliados
SEGA Saturno - Saturn, SEGA y Videojuegos