Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Menu

Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menu

Mensajes - Mandelbrot

#1
General Programadores / Directx9
08 de Noviembre de 2005, 04:07:49 PM
 Efectivamente no es mi caso, pero de ser así no me explico porqué los juegos comerciales del año pasado siguen funcionando aunque actualices las runtime.

Creo que es algo mio que no hago bien, pero es que tampoco se me ocurre el qué, tampoco hago nada especial porque recibo un error de excepción en la función Direct3DCreate9.

He pensado en compilar con las últimas librerías pero creo que me tengo que bajar otra vez el SDK por narices,¿ hay alguna forma de conseguir las librerías sin tener que descargar los casi 200 megas?
#2
General Programadores / Directx9
08 de Noviembre de 2005, 03:33:44 PM
 Hola gente.

Hace algún tiempo hice un juego en DX9, pero ahora resulta que no me vale en otros ordenadores dependiendo de la revisión que tengan instalada.

No se si tenéis o habéis tenido vosotros ese problema o soy yo solo.
¿Hay alguna forma de solucionar esto?, supongo que sí, porque a los juegos comerciales no les ocurre eso.

un saludo y gracias.
#3
Programación gráfica / Parpadeo En Movimiento
11 de Agosto de 2005, 07:18:01 PM
 Al principio pense que glSDL usaria otras librerias o dll mejoradas, pero por lo que veo se trata tan solo de una ampliacion del propio SDL. Decirte que aunque no he hice todas las pruebas, lo he encontre muy estable y rapido. (efectivamente el error que me daba al final era por no tener .Net 2.0 y el DirectX Managed)


Citar
La historia es que en un futuro CERCANO, se incluya glSDL en la propia SDL

Me parece una buena idea el incluir glSDL en el propio SDL, he echado un vistazo al codigo al codigo fuente del Benchmark y efectivamente el modo de video se crea con SDL_OPENGL. Entonces ¿sabes si de momento glSDL solo usa 2D porque esta en fase de pruebas?, ¿se ha previsto una ampliacion a 3D y al aprovechamiento maximo de las tarjetas de video cuando se incorpore definitivamente a SDL?.

seria interesante que fuera asi, y como ya te dije anteriormente las tarjetas graficas no solo son para calculos 3D, los efectos a nivel de pixel, las mejoras y facilidades en cuanto al tratamiento de la imagen 2D que se pueden aplicar por hardware sin apenas usar el procesador son lo suficientemente importantes como para tenerlas en cuenta en un futuro. sobre todo en lo que se refiere a efectos. Y a la larga facilita mucho el poder hacer algo facil y directamente por hardware mediante una simple llamada que tener que crearlo uno mismo consumiendo procesador o metiendose en mas lios.

He quedado gratamente sorprendido al comprobar como una pequeña demo OpenGL en 3D, incorporada a una ventana creada con SDL no ha sufrido ninguna diferencia de velocidad ni calidad, aunque lo tengo que mirar mejor en principio me parece genial SDL. esperemos que llegue a buen puerto la incorporacion de glSDL.

Saludos.
#4
Programación gráfica / Parpadeo En Movimiento
11 de Agosto de 2005, 04:22:03 PM
 Quizas no he hecho bien la prueba, porque el SDL a secas me va lentoooo lentoooo, efectivamente el uso de glSDL es muy efectivo al comprobar el Benchmark. aunque en mi opinion todavia limitado si no se puede usar el depth y stencil buffer,  rotacion en cualquier grado, mezclas, filtros, luces, niebla, etc. por no hablar de la 3ª dimension, pero todo se andara.

De todos modos a mi personalmente ya no me preocupa demasiado porque he descubierto y probado que añadiendo el flag SDL_OPENGL  en la funcion SDL_SetVideoMode se crea un contexto de ventana para OpenGL en el cual se pueden lanzar comandos sin haber apreciado en un principio perdida de calidad o velocidad, de modo que me metere en ello, me parece muyyyyyyy interesante el poder combinar la versatilidad de SDL (timer, audio, input, etc.) con la potencia grafica de OpenGL.

Ahora con mas razon recomiendo SDL+OpenGL (autentico) para los que ya controlen en 2D o DirectX, aunque para los iniciados seguramente sea lo mejor empezar con SDL a secas o mejor aun glSDL.

Un saludo a todos.


#5
Programación gráfica / Parpadeo En Movimiento
10 de Agosto de 2005, 09:13:02 PM
 Pues aqui dejo el codigo que he usado para mis pruebas por si alguien lo quiere mirar o le interesa probarlo

He usado DevC++
para compilarlo y las librerias mingw32  (hace falta winrar o otro parecido para descomprimirlo)

Hay que copiar la carpeta include\SDL a la carpeta include del DevC++ y copiar los archivos de lib junto con las demas librerias.

crear un proyecto vacio, pegar el codigo y enlazar las librerias

copiar un par de archivos bmp a la carpeta de proyecto, uno de 640x480 y otro pequeño que hara de sprite

y compilar y ejecutar (F9)


// enlazar  las librerias -lmingw32 -mwindows -lSDLmain -lSDL
// en proyecto/opciones de proyecto/Parametros/Linker

#include <windows.h>
#include <SDL\sdl.h>

int STDCALL
WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow)
{

// Iniciar SDL
if ( SDL_Init(SDL_INIT_VIDEO) < 0 ) {
   MessageBox(0,"lo siento, no se pudo iniciar el SDL",0,0);
   exit(0);
   }
atexit(SDL_Quit);

// Cargar el archivo de fondo
SDL_Surface *fondo;
if ((fondo = SDL_LoadBMP("fondo.bmp"))==NULL) {
   MessageBox(0,"no se pudo abrir el archivo fondo.bmp",0,0);
   return 0;
   }
 
// Cargar el archivo de sprite
SDL_Surface *sprite;
if ((sprite = SDL_LoadBMP("sprite.bmp"))==NULL) {
   MessageBox(0,"no se pudo abrir el archivo sprite.bmp",0,0);
   return 0;
   }

// Iniciar la pantalla
SDL_Surface *screen;
screen = SDL_SetVideoMode(fondo->w, fondo->h, 32, SDL_HWSURFACE | SDL_DOUBLEBUF | SDL_FULLSCREEN  );

// variables del sprite    
int px=0, py=0;
int left=0, right=0, up=0, down=0;

// bucle principal
bool jugar=true;
SDL_Event event;

while (jugar) {
   if (SDL_PollEvent(&event)>=0) {
       switch (event.type) {
           case SDL_KEYDOWN:
               switch( event.key.keysym.sym ){
                   case SDLK_LEFT:  left = -4;  break;
                   case SDLK_RIGHT: right = 4;   break;
                   case SDLK_UP:    up = -4;    break;
                   case SDLK_DOWN:  down = 4;   break;
                   case SDLK_ESCAPE:  jugar=false;  break;
                   default: break;
                   }
           break;
           case SDL_KEYUP:
               switch( event.key.keysym.sym ){
                   case SDLK_LEFT:  left = 0;  break;
                   case SDLK_RIGHT: right = 0;   break;
                   case SDLK_UP:    up = 0;   break;
                   case SDLK_DOWN:  down = 0;  break;
                   default: break;
                   }
           break;
           case SDL_QUIT:
               jugar=false;
           break;
           }
       }  
// comprobar limites del sprite
   if (px+left < 0) left=0;
   if (px+right+sprite->w >= fondo->w) right=0;
   if (py+up < 0) up=0;
   if (py+down+sprite->h >= fondo->h) down=0;

// desplazar sprite
   px+= left+right; py+= up+down;

// borrar con el fondo    
   SDL_BlitSurface(fondo, NULL, screen, NULL);

// dibujar el sprite
   SDL_Rect rect={px,py,px+sprite->w,py+sprite->h};
   SDL_BlitSurface(sprite, NULL, screen, &rect);

//mostrar el resultado en la pantalla
   SDL_Flip(screen);

   //Sleep(10);
   }
   
SDL_FreeSurface(sprite);
SDL_FreeSurface(fondo);

return 0;
}


no se si me dejo algun paso o algo
#6
Programación gráfica / Parpadeo En Movimiento
10 de Agosto de 2005, 08:14:38 PM
Cita de: "J_F_NASH"¿Que es glSDL?
Trabajar con openGL en sdl ¿o al revés?


La verdad, no se todavia lo que es.  Yo supongo que sera OpenGL en SDL, y desconozco si se puede usar 3D.

Yo sigo opinando que sera buena idea usarlo conjuntamente siempre que no afecte mucho al rendimiento de OpenGL y que no moleste.


#7
Programación gráfica / Parpadeo En Movimiento
10 de Agosto de 2005, 08:09:34 PM
 Si, ya hice las pruebas, las he repetido para asegurarme, cargo un bmp de 640x480 en una superficie para luego copiarla en pantalla como fondo.

fondo = SDL_LoadBMP("fondo.bmp"))

y luego creo el modo de video del mismo tamaño.

SDL_SetVideoMode(640, 480, 32, SDL_HWSURFACE | SDL_DOUBLEBUF | SDL_FULLSCREEN  );

primero desplazo un sprite de lado a lado de la pantalla y tarda 2 segundos

despues al añadir esto como fondo y borrado:
SDL_BlitSurface(fondo, NULL, screen, NULL);

el sprite tarda 4 segundos!!!! cuando deberia ser imperceptible la diferencia.

bien, es posible que haya que crear una superfice en la memoria de video y luego copiar a ella el bmp cargado en la memoria de sistema, pero... joer, vaya forma de facilitar las cosas, yo eso lo puedo deducir porque ya conozco DirectDraw, pero para alguien que empieza.....

no se que opinas tu si puede ser de eso.

Citar
y bueno, actualmente si hay muchas siglas pero el que quiera hacer un juego... tendra q aprender tantas cosas... jejeje, eso es lo q mola, q nunca llegaras a saberlo todo

yo todavia estoy buscando un sendero en este laberinto
#8
Programación gráfica / Parpadeo En Movimiento
10 de Agosto de 2005, 07:12:43 PM
 perdon, me lie con otra cosa, el benchmark si funciono al principio, pero tras un rato se bloqueo o aparecio un error (la verdad no lo recuerdo), bueno, es lo mismo, yo solo daba mi consejo, imagino que cada cual usara lo que mas le guste.

Ya te digo que me gusta la idea de poder usar SDL+OpenGL como entorno general de trabajo para pasar ya definitivamente de DirectInput y DirectSound. pero no se como estara de maduro el tema ese. Mas que nada por que bastante mareado anda ya uno con siglas, apis, versiones, y demas locuras. no quiero ni imaginar para el que empieza de 0

PD: Juraria que el BltFast de directdraw 6.0 era muchisimo mas rapido (mil millones de veces) que el SDL_BlitSurface, quizas hice mal las pruebas.
#9
Programación gráfica / Parpadeo En Movimiento
10 de Agosto de 2005, 06:42:30 PM
 Quizas no me explique bien, pero al final una de mis recomendaciones era usar OpenGL+SDL aunque aclaraba que desconocia los resultados, y una de mis intenciones es estudiar la posibilidad de usarlo,  y puede que sea una buena opcion para mi y para mucha gente.

Pero es que me sorprendi bastante al ver como se enlentecia enormemente un sprite que puse en movimiento al limpiar toda la ventana con SDL_BlitSurface cuando pensaba que al menos seria igual de rapido que el Blt de DirectDraw (¿que menos no?),. y la verdad..., empezar ya con limitaciones como esa, la del modo de color, no poder usar doble buffer en una ventana, y alguna que otra mas pues hace pensar mal de ello en un principio y "desconfiar" no?.

Creo recordar que probe ese benchmark (no estoy seguro pero creo que fue ese) y me daba error, imagino que me haria falta un dll o algo que no hacia bien, (se me quitaron las ganas de ponerme a "arreglarlo")

Digo yo que de lo que se trata es de que funcione por igual en cualquier modo de pantalla en cualquier pc actual sin tener que volverse demasiado loco y volver locos a los demas, y sin tener que hacer montones de pruebas en cada uno para conseguirlo, tambien lo ideal es tener el mayor control posible sobre el ordenador, no que el te controle a ti, te ponga trabas, y te obligue a hacer cosas que no quieres hacer. Una vez que se consigue esto pues ya que cada cual se apoye en las herramientas, utilidades, capas, librerias etc.. que mejor le convengan.

Yo si quiero hacer algo "pequeño" uso OpenGL 1.1, y me funciona en cualquier tarjeta incluso en una Riva TNT2, sin necesidad de dlls ni que el usuario tenga que instalar nada, ni configurar nada, ni volverse loco, por mi como si lo quiere usar en modo de 8 bits, sencillamente un pequeño exe de 100k que sabes que funcionara al ejecutarlo y que lo habre compilado como sea y con lo que sea, cosa que por otro lado no puedo decir de DirectX con sus cambios de versiones y su politica habitual.

De todos modos si me dices que con SDL puedes hacer lo mismo que con DirectX o OpenGL te creo, hay que acabar con los mitos. Y ademas quizas para alguien que empieza sea lo mejor, pero a mi personalmente no me gusta que me pongan limitaciones o me marquen las pautas de lo que debo hacer o lo que no y la verdad el SDL no me dio una buena primera impresion.

#10
Programación gráfica / Parpadeo En Movimiento
10 de Agosto de 2005, 04:46:15 PM
 Bueno..., realmente el SDL es bastante lento,  se pasa de un movimiento suave al dibujar solo un sprite a uno a saltos al hacer el blit de toda la pantalla, no quiero ni pensar como ira de lento cuando empiecen a rular mogollon de bichos por ahi.

pues nada, mi consejo para todo el mundo es pasar definitivamente ya de GDIs, SDLs, SVGAs y otros apaños que aunque para empezar a probar o como ayuda puntual de alguna funcion en un momento dado estan bien, pero que casi siempre conducen a callejones sin salida si se usa como contexto principal.

Lo mejor es empezar ya a usar OpenGL o DirectX aunque no se tenga mucha idea, eso si... apoyado en librerias y utilidades preparadas para facilitar el uso de estas APIS, solo asi (que yo sepa) se puede aprovechar toda la potencia grafica de los ordenadores actuales.

Podemos usarlo solo para 2D (si queremos evitar el tema del algebra, matrices y demas) y nos beneficiaremos de filtros para difuminar los pixels, mezclas de color para todo tipo de efectos, sombras, rotaciones de sprites, crear zonas donde se permita dibujar o no, z buffer para que queden ocultos los dibujos a partir de su distancia sin tener que dibujar primero los mas alejados,  y un monton de cosas mas que nos permitira hacer practicamente todo lo que se nos ocurra sin limite alguno, mas facilmente de lo que parece y todo ello sin preocuparse de perder velocidad, y con la ventaja de poder añadir objetos 3D facilmente en un futuro.

Asi se hizo commandos, es un juego en 2D usando la tecnologia 3D de las tarjetas, por eso tiene esos graficos tan buenos (aparte de los grafistas claro esta).

Yo personalmente recomiendo para empezar, por su facilidad, OpenGL con la libreria GLUT que trae funciones para simplificar la iniciacion y gestion de la ventana, teclado, timer, etc.. y crear unas sencillas clases de sprites y a partir de ahi ya se puede empezar a hacer muchas cosas al tiempo que se aprenden otras nuevas.

Tambien se puede usar SDL+OpenGL aunque no se como va ni que resultados tiene puesto que no lo he probado. Otra opcion es usar DirectX 9 y las librerias de apoyo D3DX que incluye, da lo mismo, de lo que se trata es de programar la tarjeta grafica como dios manda y todo ello pasa por DirectX o OpenGL.

un saludo a todos y espero haber animado a alguien.
#11
Off-topic / Donde Se Va Nuestro Dinero
09 de Agosto de 2005, 07:00:55 PM
 Yo creo que este mal solo se curara con el tiempo, de momento la sociedad es reacia a considerar cultura algo tan relativamente moderno.

Y en el futuro cuando los niños se conecten a la maquina de positrones a flipar, les diremos que deben jugar mas a los videjuegos, porque eso les estimulara la imaginacion, coordinacion, y el trabajo en equipo, etc...

Entonces si, habra un monton de subvenciones para hacer videojuegos y se podra ganar dinero haciendo un space invaders o un comecocos al año.
#12
Off-topic / Donde Se Va Nuestro Dinero
09 de Agosto de 2005, 06:38:23 PM
 
CitarYo preferiria que no considerarais el cine como cultura sino como producto

Si se considerase el cine como producto creo que iban a ir al paro todos excepto Amenabar, Almodovar y Garci con la pataky en pelotas.

y se me olvidaba.... Torrente!!!
#13
Off-topic / Donde Se Va Nuestro Dinero
09 de Agosto de 2005, 06:29:01 PM
 El problema es que el cine ya solo por el hecho de serlo se considera cultura, nunca se habla de cinebasura, aunque lo haya, al igual que pasa con los libros y el teatro.

Supongo que "los cultos" veran los videojuegos como algo dañino, perverso, o yo que se, yo desde luego prefiero un buen juego de estrategia en el que yo soy el que tomo las decisiones, a que cualquiera me cuente un rollo que ni me va ni me viene en un libro o en una pelicula.

No por eso quiero decir que no existan peliculas o libros que sean autenticas obras maestras (incluso españolas).
#14
Off-topic / Donde Se Va Nuestro Dinero
09 de Agosto de 2005, 05:58:59 PM
 No se de que va esa pelicula ni me importa.

Lo del cine español es que es repugnante, cualquier pelicula es cultura, aunque solo salga un tio con la chorra al aire diciendo gilipolleces es subvencionada (y no es broma).

En cambio cualquier persona que haga juegos educativos, o que permitan aumentar el conocimiento, la habilidad, la estrategia, el juego en equipo, etc... se morira de asco a menos que disponga de un paston.

y luego se quejan de que no va la gente y nos piden que vayamos!!!  JAJAJAJA!

me podran obligar a pagar una basura con mis impuestos, pero lo que no van a obligarme es a comermela, por eso no pienso ir a ver la mayoria de ellas ni gratis.
#15
General Programadores / Comprobar Versión De Directx
09 de Agosto de 2005, 05:08:51 PM
 Yo tenia un programa compilado con la version 9.0b y al instalar el runtime de la 9.0c me daba un error grave de excepcion (o como se llame)  en la funcion CreateDevice (creo recordar).

decidi instalar el sdk de la 9.0c y compilarlo con esta version, ya me fue bien, pero para mi sorpresa, al ejecutarlo sobre otro ordenador que tenia la 9.0b me daba el mismo error.

Igual alguien al que le haya pasado esto sabe como solucionarlo, y por lo tanto conoce en que version se esta ejecutando. De momento mi solucion a todos los problemas con DirectX ha sido pasar de el, y usar OpenGL





Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.