Dark_Alex...

Nadie te obliga a usar backpics.
Un Memstick de 1gb no vale un carajo, las sacas por 30 laureles en Ebay, e incluso menos.
Por unos pocos kbs que ocupa un backpic no creo que te cayan a entrar 3 isos mas.
Estas preguntas, por MP o hilo del Daxziso.

Salu2

Si ese supuesto fuera cierto.. por que no aligeras tu daxziso y le quitas los backpics y cosas de esas que al fin y al cabo... las ms siguen siendo muy caras y poca gente puede permitirse comprar una de 2 GB, por no decir de 1 GB. Por que claro, los backpics .. endima en formato bmp !! por que no un jpg para que ocupe menos ms ?

Si leyeses un poco el foro verías que Dark_Alex está de exámenes, como yo, y como muchísima gente de foro...

Asi que supongo que el chaval querrá "aligerar" sus estudios...que no creo que con el dax iso le convaliden ninguna asignatura...

Saludos

A falta de Dark_Alex o SiTWulf, me tomaré la responsabilidad de responderte yo, puesto que he estado colaborando con ellos sobre el tema del loader.

actualmente, el loader utiliza backpics para su presentación.
Tiempo atrás se sugirió a Dark_Alex, que utilizara JPGs en vez de BMPs, puesto que los jpg eran archivos de mucho menor tamaño, pero este tamaño solo es en espacio de disco, puesto que en memoria haría falta rutinas para leer y presentar este tipo de imágenes (un jpg es una imagen tipo BMP, a la cual se le ha aplicado un algoritmo de compresión)
Ahora, siendo un poco mas tecnico, el uso de una imagen JPG, implica la utilización de memoria dinámica en la psp, y el problema que supone este tipo de memoria es que no hay forma de "liberarla" o "limpiarla" después de su uso.

La solución empleada para los backpics, fué precisamente utilizar un espacio de memoria estática, que no supone un gasto extra de ram, puesto que esta memoria siempre está disponible y es el mismo tamaño siempre. Además, como es de una dirección de memoria fija, esta misma memoria es utilizada después por el loader (o lo que sea), por lo que esta area de memoria es re-utilizada.

resumiendo, el loader utilizará la misma memoria, estando o no el backpic cargado.

lo que si te puedo asegurar, es que en la ultima versión, la 0.62, dark_alex ha logrado optimizar mucho su código, ocupando menos espacio en memoria. Esta optimización fue producto de que en el loader 0.60, con la incorporación de la rutina que graba en formato ini los archivos, el loader habia crecido un poco en memoria, y esta diferencia hacía que juegos como el GTA no lograran arrancar o que les costara funcionar (incluso con la opción Tables In Ram=off)

te aseguro que Dark_Alex ha hecho un trabajo notable a la hora de optimizar códigos, y en conversaciones que he tenido con el, me ha comentado que siempre ha prevalecido la optimización del loader, antes que los "agregados".
Si decidió incorporar el tema de los backpics, fué por que no supone un problema de rendimiento al loader. Esto lo hemos conversado con Dark_Alex y SiTWulf.

y sobre el tema del espacio en memoria, también lo comentamos y la conclusión fue esta:
si bien es cierto que con 3 backpics ya ocupamos 1MB de la tarjeta de memoria, tambien es cierto que la probabilidad de que una persona tenga justo los juegos UMD, que una vez dumpeados, y rippeados, utilicen precisamente el espacio libre en la memory, es remoto. Esto quiere decir que es mucho mas probable que tengas algunos UMD (unos 3-4, por ejemplo), y que al momento de pasarlos a la memory, estos o te ocupan mas o menos del espacio libre, pero es poco probable que te ocupen justo justo el espacio... o te pasas o te sobra... me entiendes?
no te digo que no exista el caso, pero son muy pocos.
en todo caso, si lo que quieres es no tener los bmps en la MS, la gracia de este loader es que puedes eliminarlos (para liberar espacio), y el loader cargara sin imagenes de fondo.

bueno, espero haber aclarado algo, y veré si puedo hablar con Dark_Alex para que agregue lo que se me pueda haber quedado en el tintero (o en este caso... en el teclado... jijiji )

espero que a nadie moleste el que conteste a estas preguntas... en todo caso vere si puedo hablar con Dark_Alex para que se pase por este hilo.

Zalu2!

Deen0X
PD: Uf! veo que estan rapidos contestando... bueno, lo dicho, Dark_Alex está en examenes, asi que por eso está un poco perdido de los foros... como debe ser (para que estudie, por que los foros de EOL, SON UN VICIO!!!!)

El hecho de que haya posteado esto ahora no significa que Dark_Alex lo vaya a leer precisamente ahora... no obstante si tanto os molesta que haya puesto esto.. sois libres de no leerlo.

Yo dejo aki la idea de un daxziso mas ligero para que mas isos puedan operar en Ram y lo he posteado apra que la gente opine al respecto ya que tambien está por ahi Sit_Wulf, gente que conoce muy bien esto. Y NO he planteado esto para que me vengais con esas...

Saludos

EDitado: gracias Deen0X por una respuesta coherente... no como otros

Dark_Alex esta muy liado con los examenes!! De momento irá haciendo con el tiempo que pueda las mejoras que el crea apropiadas.

Sin animo de ofender, es solo opinión personal, pero me jode mucho que todo el trabajo de dark_alex se vea poco reconocido cuando sale un loader que carga 4 juegos (muy deseados algunos...no te digo que no...), que no se podian con su pedazo de programa... Si nos ha sorprendido tantas veces, no dudes que lo hará otra vez.... independientemente que lo que hayas puesto sea en un tono menos o mas apropiado, para mi parecer, no creo que Dark_alex se merezca tales "criticas", o así veo yo este post, como un poco de crítica (constructiva o un poco maliciosa, eso lo dejo en manos de cada uno...)

Un saludo!!

Zypo y quien ha dichoq ue esto sea una critica ?

ademas, una cosa...
cuando salio el Devhook 0.41, a Dark_Alex tambien le dio un orgasmo multiple, y no fué precisamente por que ahora pueda cargar un par de juegos ni nada de eso (a el, como a varios, nos gusta mas trastear con la psp que jugar a sus juegos...)

por que esta tan feliz Dark???? por que analizar el Devhook le supondrá varias mejoras a su loader... o quizas otras cosas nuevas...

ya saben, la mente de un genio no se está trankila, y es dificil predecir hacia donde ira...

(yo me contentaría con que Dark sacara algún utilitario que "emule la MS, desde el USB o el WIFI, jejeje... se imaginan el Devhook cargando una MS emulada de nuestro disco duro... y que lea DAX???? uf!)

y en todo caso, te he respondido en buen rollo... en buena onda...

y evidentemente, que se apuntan las sugerencias para el loader.


Zalu2!

Deen0X

Lo de critica lo he dicho yo, porque esa es la impresión que me ha dado a mi...

Lo digo por el titulo del post: "Dark_alex..." Para mi los puntos suspensivos en este caso me dan la impresión de un resentimiento hacia el o su programa. Corrigeme si me confundo, estás en tu derecho también...

Un saludo

Bronx escribió:

Si leyeses un poco el foro verías que Dark_Alex está de exámenes, como yo, y como muchísima gente de foro...

Asi que supongo que el chaval querrá "aligerar" sus estudios...que no creo que con el dax iso le convaliden ninguna asignatura...

Saludos

EXÁMENES... yo tambien, me uno al grupo de exámeenes!


me parece fatal que vengas a "pedirle cuentas" a dark... si no te mola.. pues no lo uses.. y punto!

zypo escribió:Lo de critica lo he dicho yo, porque esa es la impresión que me ha dado a mi...

Lo digo por el titulo del post: "Dark_alex..." Para mi los puntos suspensivos en este caso me dan la impresión de un resentimiento hacia el o su programa. Corrigeme si me confundo, estás en tu derecho también...

Un saludo

Ei Tio Tu Nick me MOla

tan solo dar desde aqui mi apoyo a dark_alex....seguire utilizando tu cargador ya que me parece el mejor con diferencia

DAX FOREVER !!!!



p.d: me parece muy mal que booster no de la opcion de utilizar .dax en su devhook.

cada cual hace lo que quiere y si a booster no le de la gana de incluir dax en su programa pues es muy respetable, con lo que ha hecho ya se ha ganado el cielo por lo menos por mi parte,

dark_alex ha hecho un curre de la ostia pero uno no es comparable con el otro puesto que realmente poco tiene que ver, booster ha conseguido emular un firmware entero sin necesidad de andar tocando la flash ni nada de eso cosa que nadie antes habia conseguido con tanta estabilidad con la que lo ha hecho y eso tiene muchisimo merito

Leman Rush escribió:cada cual hace lo que quiere y si a booster no le de la gana de incluir dax en su programa pues es muy respetable, con lo que ha hecho ya se ha ganado el cielo por lo menos por mi parte,

dark_alex ha hecho un curre de la ostia pero uno no es comparable con el otro puesto que realmente poco tiene que ver, booster ha conseguido emular un firmware entero sin necesidad de andar tocando la flash ni nada de eso cosa que nadie antes habia conseguido con tanta estabilidad con la que lo ha hecho y eso tiene muchisimo merito

hombre, esta claro que cada cual puede hacer lo que le de la gana con sus creaciones, pero no me negaras que hubiera sido un detallazo a toda la comunidad dar soporte a los .dax en su cargador.

no es que prefiera un loader o otro(antes usaba el dax 0.62 pero ahora me pase al devhook),pero creo que el .cso es el formato propio del devhook igual que el .dax del dax ziso,asi que creo que booster tenia la misma obligacion de incluir el soporte para .dax que dark_alex para .cso .
y ya se que esta mas extendido el .dax .yo mismo tengo todos mis backups en dax que ahora tengo que pasar a .cso (un coñazo) ,pero no veo esto un motivo para criticar al autor del devhook o echarselo en cara.

Salu2!

PD:lo ideal seria un formato comun o que ambos loader soportaran ambos formatos,pero os recuerdo que tambien hay que programar el loader para que soporte un formato más,que lleva su trabajo,y mas si tu no creaste o tienes la informacion necesaria de ese formato......

hombre, esta claro que cada cual puede hacer lo que le de la gana con sus creaciones, pero no me negaras que hubiera sido un detallazo a toda la comunidad dar soporte a los .dax en su cargador.

Pues si, mas que nada porque el formato .dax comprime mucho más que .cso, o por lo menos con las pruebas que yo he hecho.

saludos

rst escribió:Dark_Alex me pregunto como es posible que el devhook 0.40 pueda cargar el colin mcrae 2005 en formato cso y en cambio el daxZiso no lo cargue en formato dax.

Puestos a pensar, he imaginado que tu programa usa mas ram y que no deja espacio suficiente para el funcionamiento del juego,. Me equivoco ?

Si ese supuesto fuera cierto.. por que no aligeras tu daxziso y le quitas los backpics y cosas de esas que al fin y al cabo... las ms siguen siendo muy caras y poca gente puede permitirse comprar una de 2 GB, por no decir de 1 GB. Por que claro, los backpics .. endima en formato bmp !! por que no un jpg para que ocupe menos ms ?

que me dices ?¿

Saludos

Los backpics no afectan para nada el rendimiento de los metodos loadexec, solamente el de los direct, RUNUMD Direct, MPHGL, y direct load, pero no excesivamente. Esto es asi, porque el PBP desaparece totalmente de la memoria en los metodos loadexec y solo queda el core, donde solamente esta implementada la emulación de la iso.
(por cierto, que imagenes en formato jpg afectaarian mas al rendimiento de los metodos direct: las imagenes ocupan lo mismo en la RAM una vez descomprimidas, pero a parte , las librerias de descompresión de JPG necesitan memoria dinamica).



Cambiando de tema, en cuanto a lo del cso, no seria dificil implementarlo, incluso practicamente usando el mismo codigo que en el dax, pero probablemente la descompresión sería mas lenta. Booster ha elegido un tamaño de frame igual al tamaño del sector de un UMD (2048 bytes). Aunque esto pueda parecer lo más logico, yo me di cuenta de que las peticiones de lectura que el driver que lee el sistema de ficheros (isofs) hace al driver que lee los sectores del umd (umd9660) , eran en la mayoria de los casos un numero mayor que 1 de sectores. El numero variaba normalmente entre 1-5 sectores, es decir entre 2048 bytes - 10240 bytes. Elegi como tamaño del frame del dax 8192, el compromiso más adecuado que encontré.

buenas noches Dark_Alex, y gracias por responder en este hilo...



ya, es tarde y todavía te queda mañana de examenes... asi que a estudiar!
edito: no, mejor no, vete a dormir!!!! xD
Zalu2!

Deen0X

Dark_AleX escribió:
Los backpics no afectan para nada el rendimiento de los metodos loadexec, solamente el de los direct, RUNUMD Direct, MPHGL, y direct load, pero no excesivamente. Esto es asi, porque el PBP desaparece totalmente de la memoria en los metodos loadexec y solo queda el core, donde solamente esta implementada la emulación de la iso.
(por cierto, que imagenes en formato jpg afectaarian mas al rendimiento de los metodos direct: las imagenes ocupan lo mismo en la RAM una vez descomprimidas, pero a parte , las librerias de descompresión de JPG necesitan memoria dinamica).



Cambiando de tema, en cuanto a lo del cso, no seria dificil implementarlo, incluso practicamente usando el mismo codigo que en el dax, pero probablemente la descompresión sería mas lenta. Booster ha elegido un tamaño de frame igual al tamaño del sector de un UMD (2048 bytes). Aunque esto pueda parecer lo más logico, yo me di cuenta de que las peticiones de lectura que el driver que lee el sistema de ficheros (isofs) hace al driver que lee los sectores del umd (umd9660) , eran en la mayoria de los casos un numero mayor que 1 de sectores. El numero variaba normalmente entre 1-5 sectores, es decir entre 2048 bytes - 10240 bytes. Elegi como tamaño del frame del dax 8192, el compromiso más adecuado que encontré.

eres un genio, y seria genial que los genios hablaran entre ellos xD
ves factible en un futuro incorporar al daxziso loader el nuevo devhook como una opcion de carga?(funcionando con isos comprimidas en dax)

Por cierto, suerte en los examenes.