Hola.
Os cuento a ver si alguien me da una idea.
Estoy haciendo un mapa basado en una cuadricula, y muestro en pantalla cada vez sólo cuatro cuadros. (para ahorrar memoria).
Mi idea era ir sustituyendo cada cuadro por los nuevos cargandolos de disco.
En fin... que me lio, la idea básica es:
-cargar una imagen del disco durante el juego
-meterla en la memoria de una surface ya creada
¿o es mejor destruir la antigua y crear una nueva?
Cita de: "KACHORRO"Estoy haciendo un mapa basado en una cuadricula, y muestro en pantalla cada vez sólo cuatro cuadros. (para ahorrar memoria).
Mi idea era ir sustituyendo cada cuadro por los nuevos cargandolos de disco.
O_O Dios Santo eso no lo hagas nunca. Nunca vayas cargando y descargando nada de disco si lo has de ir usando contínuamente, porque consume muchísimo tiempo y la aplicación te irá a pedales.
De qué tamaño son los cuadros? Yo creo que hoy en día, hablando de programar para algo no móvil, no deberías tener ningún problema para tener esos cuadros en memoria.
mmmm....
veamos... el mapa completo es 8000x10.800 pixels x 24 bits color = 247 megas
No quiero meter eso en memoria.
Ademas, lo que digo tampoco es mucha barbaridad... Ultima 7 lo hacía sobre un 386 con 4 megas.
Pero vamos, me gustaria probarlo porque lo mismo el resultado me sirve.
Así pues, reitero mi duda... ¿cargo y meto en una surface ya hecha? o ¿destruyo, cargo y creo una nueva?
Bueno, eso es otra historia, peazo mapa :lol:
Lo más lógico me parece cargar y meter en una surface ya hecha ya que de esta forma no se tiene que volver a reservar la memoria de nuevo (suponiendo que las dos imágenes tengan el mismo tamaño).
He realizado una prueba y el acceso a disco no parece ser un problema muy grave (la caché del windows debe de servir para algo no? :D
Pero si he notado un leve parón que hace que el scroll vaya a tirones, y creo que es por el proceso de copia de los datos leidos del disco a la surface.
Mi pregunta es si hay alguna forma de leer del disco y pasar a la surface directamente sin tener que hacer un BitBlt entre medias.
Seguramente donde se queda parado es en la carga del disco, no en el BitBlt. Yo creo que deberías cargar las texturas desde otro hilo, y al pasar de cuadrícula ya la tendrías cargada. Esto trae otros problemas, como que debes ir cargando más cuadrículas de las necesarias, porque no sabes hacia qué lado va a salir el jugador.
un saludo
cargando desde otro hilo eliminaría los tirones ?
perdonad mi ignorancia, pero yo me quedé en el asm y el msdos :-)
Cita de: "KACHORRO"cargando desde otro hilo eliminaría los tirones ?
perdonad mi ignorancia, pero yo me quedé en el asm y el msdos :-)
Se eliminarian los tirones ya que la imagen ya estaría cargada en ram para cuando la necesitas, en el caso de que al otro hilo le dé tiempo de cargarla. Además, el hilo de carga debería tener una prioridad menor que el hilo principal, para que la reducción de CPU al tener dos hilos funcionando no afecte a la acción principal.
¿En qué formato cargas las imágenes?
Esto es importante, si es un formato no comprimido (BMP, TIF...) tiraría más de disco duro que los formatos comprimidos (JPG, PNG...). En general, se tarda menos tiempo en descomprimir una imagen, que en leerla descomprimida del disco duro. Tambien podrias tener todos los tiles comprimidos en JPG en ram, y descomprimirlos según los necesites, en vez de usar el disco duro.
un saludo
PD: Eres el mismo KACHORRO del foro de la abadia?
El mismo de La Abadia, el mismo de Fray Luis y el mismo del IRC desde el 95 :-)
Perro malo nunca muere. (aunque sea viejo) :lol:
Saludos noble KACHORRO!
Tiempo hace que no coincidiamos en un entorno Stratero, lo cual me llena de alegria!
Sigue usted todavia con asuntos isometricos? Le estariamos muy agradecidos si nos mostrase algo relacionado con ese hipotetico proyecto, o simplemente unas palabras de su correctisimo Castellano :lol:
Aparte de lo que comenta Fiero(cargar en un hilo aparte), tambien sería una buena idea mantener una caché de los tiles que rodean la superficie visible actualmente, en una distancia menor que "X".
Luego, si detectamos que la distancia entre lo visible y alguna imágen sin cachear es menor que cierto rango "Y", se precachean de nuevo los tiles. X deberia ser mayor que Y, claro.
La caché podría ser de un tamaño predefinido, o ajustarse segun la memoria libre de la máquina. En el último caso se le podría dar la opción al usuario de elegir qué porcentaje de RAM quiere usar.. algo así como
- Super suave ( 75% ram )
- Suave ( 50% ram )
- Normal ( 25% ram )
mai chu zents :ph34r:
Saludos AK47
pues si quieres ver algo...
http://kachorro.servegame.com/abadia2/Un saludo !
He visto el video y está estupendo, ánimo y pa lante.
Tiene muy buena pinta! y ademas, me trae muchos recuerdos de todos aquellos juegazos que utilizaban esa vista(jugasteis al Heimdall 2? o que decir del mitico Ultima 7...(genial) )
por cierto, que es eso de Medievo? alguna pagina? se termino?
Medievo fué un proyecto de hace ya algun tiempo, en el que llegamos a trabajar una veintena de personas durante dos años. Lamentablemente por una serie de catastróficas desdichas... se fué al garete.
No obstante estoy intentando, al menos, reciclar mi trabajo en Medievo para darle vida a La Abadia del Crimen 2, y por supuesto, intentar no tropezar dos veces con las mismas piedras.
Cita de: "KACHORRO"Mi pregunta es si hay alguna forma de leer del disco y pasar a la surface directamente sin tener que hacer un BitBlt entre medias.
Bloquear una surface y copiar en ella lo que quieras es perfectamente posible que yo sepa.
un saludo.
Bueno... voy a probar comprimiendo las imágenes.
¿Qué formato de compresión sin pérdida me recomendais para 24 bits de color?
Cita de: "KACHORRO"Bueno... voy a probar comprimiendo las imágenes.
¿Qué formato de compresión sin pérdida me recomendais para 24 bits de color?
PNG
Te recomiendo que en lugar de utilizar 24bits de color...utilices o bien 16 o 32.
24bits es un modo un tanto "extraño" y bastante lento que los dos anteriores....
Para comprimir tus imagenes sin perdida... tienes varias opciones... puedes pasarlas por un algoritmo RLE que a veces comprime bien aunque si no quieres complicaciones y quieres buena compresion...utiliza por ejemplo la lib UCL (http://www.oberhumer.com/opensource/ucl/).
UCL comprime un poco menos que un winzip normal y corriente(lib zlib) pero la descompresion es rapidisima! yo es la que utilizo para empaquetar los recursos :P
Por cierto, que estais utilizando para el game? DirectX? alguna lib? SDL? te lo digo porque tengo una lib que lo mismo has leido algo por aqui...utiliza SDL, es portable y estas cosillas te las quitarias de encima(esto de comprimir y demas) a parte de mas añadidos....
Muchas gracias por todos los consejos y opiniones.
Con un JPG al 95% ni se va a notar la diferencia con la original, y la diferencia de tamaño va a ser enorme, comparando con un formato sin pérdida.
saludos
He añadido FreeImage al programa y he cambiado los gráficos a PNG (antes usaba BMP sin compresión XDDD)
es decir, donde antes me ocupaba un fichero 1,7 megas ahora me ocupa unos cuantos k's.
No obstante he estado haciendo pruebas y tengo dos problemas:
1. FreeImage no carga bien los PNG ni los GIF (no he probado mas), solo me ha cargado bien los BMP (teniendo en cuenta que despues de cargarlos los tengo que copiar a la surface de ddraw , y puede que ahí esté yo metiendo la pata...)
2. El corte me lo da sin lugar a dudas por el acceso a disco, y es igual de molesto para BMP de 1 mega y pico como para PNG's de 5 ks... necesito una solución que suavice cuanto más los cortes, teniendo en cuenta que es inevitable cargar las imágenes sobre la marcha. (¿tenerlas en memoria en formato comprimido y descomprimirlas al necesitarlas?)
Ayuda !!!
Enrique Garcia (http://kachorro.servegame.com/abadia2/)
No logro bajarme el video ni ver las imagenes de los mapas :(
Salu2...
El servidor FTP es mio y falla más que una escopeta de feria. No obstante espero que cuando leas esto ya hayas podido descargar los archivos que comentas.
Un saludo
Ya logre ver el video! Me gusta el nuevo sistema que vas a implementar para la abadia del crimen, un pseudo-3D muy majo (ole)
Recuerdo hace tiempo que encontre por sorpresa un render 3D de una escena del juego que por lo visto iban a remakear en 3D puro aunque no se que paso con dicho proyecto:
http://usuarios.lycos.es/vhd/ex3/abadia3D.jpgLa
imagen original no tiene el paisaje y se veia algo peor de iluminacion, esta un poco mas contrastada e iluminada. Todo esto se lo añadi yo via photoshop para montarme un fondo de escritorio decente que poner :D
Animo con el proyecto que va tomando un camino muy interesante ;)
Salu2...
Cita de: "KACHORRO"Ayuda !!!
Me gustaría hacer unas preguntas antes de intentar ayudarte.
1- ¿Estas usando DirectX 9, cierto?
2- ¿que ancho y alto en pixels tiene cada celda o superfice?
3- ¿Cuantos colores diferentes tiene el mapa aproximadamente?, por la reducción tan enorme que se produce al comprimir en png deben ser poquitos ¿no?, ¿4?, ¿16?, ¿256?...
4- ¿El mapa ese para qué es concretamente?, ¿no es un juego en 3D?
pues eso.
...Que gran juego, fue uno de mis favoritos, ojalá os salga bién.
Hay una cosa que no entiendo... porque quieres tener ese pedazo de mapa cargado en memoria??
lo suyo seria que cargaras todos los elementos graficos y luego...los fueras volcando depende de donde estes...
que quieres un scroll super suave? pues... construye con estos elementos graficos en un buffer mayor(backbuffer) que la resolucion del juego y luego vuelcas el marco que quieras y podras moverte pixel a pixel por el... que te aproximas al borde de los "construido" pues...vuelves a generar otro backbuffer y fuera...
no se si me he explicado bien :blink:
Respondo a Ray
1- ¿Estas usando DirectX 9, cierto?
No sé si el 9 o el 8 o el 7 :P, pero simple y llano directdraw
2- ¿que ancho y alto en pixels tiene cada celda o superfice?
dado que quiero mostrar el mínimo de celdas simultáneamente (es decir, tener el mínimo en memoria), cada celda tiene el tamaño de la pantalla, lo cual hace que con 4 no sea necesario tener más.
3- ¿Cuantos colores diferentes tiene el mapa aproximadamente?, por la reducción tan enorme que se produce al comprimir en png deben ser poquitos ¿no?, ¿4?, ¿16?, ¿256?...
Ahora en las pruebas son dibujos muy básicos, por eso se reducen tanto. En los definitivos tendran 32 bits de color.
4- ¿El mapa ese para qué es concretamente?, ¿no es un juego en 3D?
Es el suelo de un juego en isometrica 2D
porque quieres tener ese pedazo de mapa cargado en memoria??
lo suyo seria que cargaras todos los elementos graficos y luego...los fueras volcando depende de donde estes...
no quiero tenerlo cargado en memoria, quiero ir cargandolo del disco poco a poco según se mueva la cámara.
Primero yo te recomendaría empezar a hacerlo en la ultima versión de Direct3D ahora que estás a tiempo, si no, creo que puedes tener problemas al usar tu juego en una tarjeta gráfica diferente a la que uses para programar y hacer las pruebas, aunque esto me gustaría que lo pudiera corroborar alguien más porque solo te hablo por experiencia propia, en concreto me refiero a la diferencia entre nVidia y ATI, creo que la versión 9 está más unificada en cuanto a compatibilidad.
Crea las surfaces (y por lo tanto cada archivo) de un tamaño igual de ancho que de alto y que sea potencia de 2 para que sean mas rápidas, por ejemplo 1024x1024 está bien. El mapa tendría que ser múltiplo de 1024 para facilitar su división con lo que deberías convertirlo a 8192 x 10240
De esta manera quedan 8 columnas x 10 filas = 80 surfaces, de 1024 x 1024 cada una
Si fuera posible sustituye el formato de color del mapa por una paleta de 8 bits de color, podrás usar un máximo de 256 colores diferentes pero cada uno de ellos podrá ser de 32 bits o los que quieras, quedará prácticamente igual ocupando una tercera parte.
De momento prueba a ver como va con archivos de 1024x1024 por que puedes ganar mucha velocidad.
De lo de ahorrar tanta memoria no creo que sea buena idea, creo que no le va a hacer mucha gracia al que se haya gastado un pastón en su P4 con 1Gb ver como el juego esta cargando cada vez que avanza un poco, los parones aunque sean pequeños suelen ser molestos, además supongamos que el jugador se desplaza por los alrededores del punto crítico de cambio de surface, y como por lo general se cargarán de 2 en 2, el tener que cargar consecutivamente semejantes imagenes puede tener unos efectos odiosos en el mejor de los casos.
Por lo tanto, mi alternativa es:
Crear un número adecuado de surfaces en la memoria de sistema (10, 20, 30... 50...) dependiendo de la memoria de sistema del ordenador de está forma además quedaría disponible toda la memoria de video.
Cargar del disco a las surfaces las más usadas al comienzo del juego, progresivamente deberán irse cargando grupos de archivos a medida que se avanza pero solo será necesario una vez (al menos cada cierto tiempo).
ya.
>> Primero yo te recomendaría empezar a hacerlo en la ultima versión de Direct3D ahora que estás a tiempo, si no, creo que puedes tener problemas al usar tu juego en una tarjeta gráfica diferente
¿puedo pasar a direct3d sin neceisdad de hacer muchos cambios? No estoy muy puesto y ya me costó bastante hacer la libreria con directdraw... y no sé, creo que directdraw desapareció en las ultimas versiones de directx y se llamaba direct graphics o algo asi... ponedme al dia por favor
>>Crea las surfaces (y por lo tanto cada archivo) de un tamaño igual de ancho que de alto y que sea potencia de 2 para que sean mas rápidas, por ejemplo 1024x1024 está bien. El mapa tendría que ser múltiplo de 1024 para facilitar su división con lo que deberías convertirlo a 8192 x 10240
Siempre se aprende algo nuevo :-) Tomo nota, esto no es problema
>>Si fuera posible sustituye el formato de color del mapa por una paleta de 8 bits de color, podrás usar un máximo de 256 colores diferentes pero cada uno de ellos podrá ser de 32 bits o los que quieras, quedará prácticamente igual ocupando una tercera parte.
También tomo nota.
>>De momento prueba a ver como va con archivos de 1024x1024 por que puedes ganar mucha velocidad.
Bueno, la velocidad no era problema, el problema eran los cortes al leer de disco.
>>De lo de ahorrar tanta memoria no creo que sea buena idea, creo que no le va a hacer mucha gracia al que se haya gastado un pastón en su P4 con 1Gb ver como el juego esta cargando cada vez que avanza un poco,
Es que voy a abusar (y a lo bestia) con los objetos 3D que hay en el juego, y no quiero que se la coma el puñetero suelo que es lo unico que no sirve nada mas que para decorar.
>>Por lo tanto, mi alternativa es:
>>Crear un número adecuado de surfaces en la memoria de sistema (10, 20, 30... 50...) dependiendo de la memoria de sistema del ordenador de está forma además quedaría disponible toda la memoria de video.
>>Cargar del disco a las surfaces las más usadas al comienzo del juego, progresivamente deberán irse cargando grupos de archivos a medida que se avanza pero solo será necesario una vez (al menos cada cierto tiempo).
Y aqui es donde tengo el problema, porque quiero cargar de disco, pero se produce un parón. Con una hebra se solucionaria el problema (he probado el juego con el winamp de fondo y así no da tirones, o sea, en segundo plano se puede acceder al disco sin que te pare lo demás).
Peroooo.... NO TENGO NI IDEA DE PROGRAMAR CON HEBRAS EN VISUAL C ¿algún tutorial o libreria que simplifique la tarea?
Muchas gracias por tanta ayuda a todos !!!
...Si ddraw te funciona bien y es estable en cualquier ordenador quizás no te convenga cambiarlo, pero tampoco perderías mucho (aparte de unas horas, o días) en convertirlo a Dx9 y poder ir probándo con que versión se comporta mejor, también piensa si te conviene tener la posibilidad de añadir 3D fácilmente en un futuro.
Si, ahora es DirectxGraphics, aunque el objeto principal es IDirect3D9, y con el hay que crear IDirect3DDevice9 que lo podrás usar para sustituir a DDraw. Entonces para que te hagas una idea:
Se crea Direct3D:
lpD3D=Direct3DCreate9(D3D_SDK_VERSION);Se crea el Device:
lpD3D->CreateDevice( 0, D3DDEVTYPE_HAL, hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &d3dParams, &lpDevice );y donde antes había un:
lpDDraw->CreateSurface(&ddsd, &lpSurface, NULL );Ahora habrá un:
lpDevice->CreateOffScreenPlain(1024, 1024, D3DFMT_X8R8G8B8, D3DPOOL_SYSTEMMEM, &lpSurface, NULL);Tambien deberás sustituir las funciones de copia de surfaces, obtención memoria de vídeo, capabilidades del dispositivo, etc..
¿dije capabilidades? :blink:
Mientras lo piensas ya puedes ir descargando el
DirectX 9 SDK, porque ocupa un huevo, consulta los métodos de IDirect3DDevice9 y de IDirect3DSurface9 desde el directx9_c.chm que incluye, son bastante intuitivos. Y si tienes alguna duda pues ya sabes... stratos.
En lo de los hilos no te puedo ayudar, y creo que no es buena idea trabajar con ellos si no se es un experto costurero.
y sigo insistiendo en cargar por zonas bien escogidas mejor que por recuadros 2x2, no veo nada malo en usar 32 Mb de ram o más para ello. Por muchos objetos que pongas te seguirá sobrando mucha memoria.
Un saludo y suerte con ello.