¿Publicará (algún día) las tools marcan?

Te sugiero que cambies el titulo de tu post.
Ya que das la impresión de que ya tienes información al respecto cuando en realidad las estas solicitando.

Pues estaría bien para que se abriera un poco mas la Scene y puedan salir cosas nuevas.

Dijo que no las iba a publicar. Mas que nada pq bootmii va a ser una plataforma homebrew con sus propios banners.

Asi que si se matan a hacer un custom firmware dual normal que no quieran sacar los programas chapucilla que usaron para trastear los banners que no va a servir de nada para el homebrew.

Igualmente, si a alguien le interesa hacer banners legales para el menu normal de wii, porque deberia volver a revertir los formatos y crearse unas herramientas para tal faena cuando los de hackmii ya tienen unas hechas?

Es mi humilde opinion, luego que hagan lo que quieran claro.

Es que es verdad, ya que tienen eso echo, por que no compartirlo?

En definitiva....., a seguir leyendo hilos con el BL me da esto, ¿el mejor el gamma?, porqué no puedo instalar el HBC?, etc etc

Toca seguir esperando algo que anime la cosa.

No.

Porque:

1) No considero la creación de canales como beneficiosa para la scene
2) Es mas, no considero nada que interactúe con el software de Nintendo como beneficioso para la scene, visto lo visto con las actualizaciones y las limitaciones del mismo
3) Es una tontería supina perder el tiempo con las cosas de Nintendo cuando se pueden hacer mejor y sin tener que reversar nada
4) He cambiado de opinión sobre algunas cosas, cosa que creo tener derecho a hacer
5) Las tools están diseñadas para que las utilicen la gente en la que confío. Es decir, no son "seguras" de usar para la gente que no las conoce, y no voy a invertir el trabajo necesario para hacer que sí lo sean.
6) Cuanto mas se interactúe con software de Nintendo (sobre todo en lo que concierne a instalar cosas), mas importante es el control de calidad (para evitar bricks). Considero que el control de calidad de la mayoría de la gente que hace esto es bastante inferior a lo que yo considero oportuno (que comparen la cantidad de bricks causados por nuestro software con la media del software que toquetea la NAND), y no estoy dispuesto a sacar utilidades que se puedan usar malamente con tanta facilidad.
7) Hacer cosas sin que se sepa lo que se hace es receta para el desastre, y ya pasa lo suficiente como para sacar herramientas que la gente, sin duda, usará sin el mas mínimo interés por comprenderlas.

Eso va por pywii y por Alameda.

En mi opinión, la actual scene de Wii está estancada, y parece que lo único que va mejorando son las utilidades de piratería. Y, que digan lo que quieran, pero EOL da soporte a la piratería - o si no mirad a todos esos hilos sobre downgradear que proclaman "busca el IOS16" y que se consideran válidos, cuando todos sabemos que no existe forma legal de conseguirlo.

La gente está que no para con las mismas tonterías de siempre. Que si juankear el menú del sistema, que si toquetear archivos de la NAND a pelo, que si parchear IOS, o lo que es peor reemplazar varios IOS masivamente, que si hacer canales (o ilegales, o inseguros, o las dos cosas, casi siempre), que si trampas en los juegos (que encima luego las usan online y nos jodemos los demás), etc.

Y luego el homebrew de verdad tiene:
libogc
- una librería donde la mitad ha sido robado del SDK (cosa que nadie sabía al principio, porque shagkur ha consdiderado conveniente no decírselo a nadie, pero que poco a poco se ha hecho mas y mas evidente). Hasta incluye algunos trozos de código binario sacado literalmente del SDK, como por ejemplo el programa de desbloqueo de las memory cards
- con un sistema de threads casero (de shagkur) que sigue siendo muy frágil (y muy dificil de comprender) y que ha tenido bugs tan gordos como que los cálculos de coma flotante con mas de un thread se iban al garete (supongo que tan poco interés / tan poco homebrew hay que nadie se había dado cuenta hasta que intentamos portar mplayer)
- depende de IOS para todo el tema de Wii, así que nos obliga a mantener IOS operativo
- no tiene un historial seguible y además contiene partes (tales como la librería Wiiuse) que causan conflictos de licencia
libfat
- una librería FAT que intenta ser compatible con sistemas tan distintos como la GBA y la Wii, y que al final consigue unas prestaciones bastante pésimas en la Wii
- ha tenido bugs de corrupción gordos
- es totalmente insegura frente a threads, al menos hasta que se añadió un lock alrededor de todo (cosa que tampoco es buena solución)
- el autor pasa de integrar los parches de terceros (como los de rodries o Hermes) y en su lugar dice de solucionar los problemas a su manera cuando al final la gran mayoría se quedan ahí
devkitPPC
- una distribución de GCC con parches raros y unida a newlib, además de mezclada con algunas partes de libogc sin necesidad
- segher (que es un desarrollador de GCC) ha revisado el parche de GCC que usa devkitPPC. El 90% es basura o, peor, directamente incorrecto.
- newlib también tiene problemas gordos con threads

Voy a ahorrarme comentarios sobre algunos de los responsables de estas tres cosas, pero sobra con decir que no me llevo muy bien con ellos últimamente. Bueno, nunca me he llevado especialmente bien con ellos (parece que resentían que yo me "metiera en sus asuntos" y en especial odiaban libogc.git, los parches no oficiales de libfat, y todo lo que no sea su bendita distribución oficial), pero últimamente ya me he cansado.

En mi opinión, la gente capaz tiene que dedicarse a cosas que, a la larga, nos van a salvar el culo, tales como:
- documentar el hardware del PPC, con detalles. Sobre todo el GX, sobre el cual hay muy poco documentado, y el código de libogc está descompilado directamente del SDK de nintendo
- explorar y documentar el hardware de Starlet, gran parte del cual es desconocido
- buscar exploits en juegos o en IOS que nos puedan servir en un futuro (y callarselos, hasta que nos hagan falta)
- Linux para la Wii, que tiene mucho que ganar con bootmii y en especial con un mini-proxy ejecutándose en el Starlet, ya que nos permitirá reutilizar sus drivers (USB 2.0, WiFi, SD, y todo lo demás)
- desvincularse de devkitPPC, porque teniendo en cuenta los graves problemas de libogc, tiene poco que ofrecer, al reducirse a un mal parche de GCC y newlib, y experimentar con builds normales de GCC

Y no a hacer animaciones. Que quedan muy bonitas, pero no sirven para nada.

Porque si esto sigue así yo desde luego que voy a tirar la toalla.

marcan42 escribió:No.

Porque:

1) No considero la creación de canales como beneficiosa para la scene
2) Es mas, no considero nada que interactúe con el software de Nintendo como beneficioso para la scene, visto lo visto con las actualizaciones y las limitaciones del mismo
3) Es una tontería supina perder el tiempo con las cosas de Nintendo cuando se pueden hacer mejor y sin tener que reversar nada
4) He cambiado de opinión sobre algunas cosas, cosa que creo tener derecho a hacer
5) Las tools están diseñadas para que las utilicen la gente en la que confío. Es decir, no son "seguras" de usar para la gente que no las conoce, y no voy a invertir el trabajo necesario para hacer que sí lo sean.
6) Cuanto mas se interactúe con software de Nintendo (sobre todo en lo que concierne a instalar cosas), mas importante es el control de calidad (para evitar bricks). Considero que el control de calidad de la mayoría de la gente que hace esto es bastante inferior a lo que yo considero oportuno (que comparen la cantidad de bricks causados por nuestro software con la media del software que toquetea la NAND), y no estoy dispuesto a sacar utilidades que se puedan usar malamente con tanta facilidad.
7) Hacer cosas sin que se sepa lo que se hace es receta para el desastre, y ya pasa lo suficiente como para sacar herramientas que la gente, sin duda, usará sin el mas mínimo interés por comprenderlas.

Eso va por pywii y por Alameda.

En mi opinión, la actual scene de Wii está estancada, y parece que lo único que va mejorando son las utilidades de piratería. Y, que digan lo que quieran, pero EOL da soporte a la piratería - o si no mirad a todos esos hilos sobre downgradear que proclaman "busca el IOS16" y que se consideran válidos, cuando todos sabemos que no existe forma legal de conseguirlo.

La gente está que no para con las mismas tonterías de siempre. Que si juankear el menú del sistema, que si toquetear archivos de la NAND a pelo, que si parchear IOS, o lo que es peor reemplazar varios IOS masivamente, que si hacer canales (o ilegales, o inseguros, o las dos cosas, casi siempre), que si trampas en los juegos (que encima luego las usan online y nos jodemos los demás), etc.

Y luego el homebrew de verdad tiene:
libogc
- una librería donde la mitad ha sido robado del SDK (cosa que nadie sabía al principio, porque shagkur ha consdiderado conveniente no decírselo a nadie, pero que poco a poco se ha hecho mas y mas evidente). Hasta incluye algunos trozos de código binario sacado literalmente del SDK, como por ejemplo el programa de desbloqueo de las memory cards
- con un sistema de threads casero (de shagkur) que sigue siendo muy frágil (y muy dificil de comprender) y que ha tenido bugs tan gordos como que los cálculos de coma flotante con mas de un thread se iban al garete (supongo que tan poco interés / tan poco homebrew hay que nadie se había dado cuenta hasta que intentamos portar mplayer)
- depende de IOS para todo el tema de Wii, así que nos obliga a mantener IOS operativo
- no tiene un historial seguible y además contiene partes (tales como la librería Wiiuse) que causan conflictos de licencia
libfat
- una librería FAT que intenta ser compatible con sistemas tan distintos como la GBA y la Wii, y que al final consigue unas prestaciones bastante pésimas en la Wii
- ha tenido bugs de corrupción gordos
- es totalmente insegura frente a threads, al menos hasta que se añadió un lock alrededor de todo (cosa que tampoco es buena solución)
- el autor pasa de integrar los parches de terceros (como los de rodries o Hermes) y en su lugar dice de solucionar los problemas a su manera cuando al final la gran mayoría se quedan ahí
devkitPPC
- una distribución de GCC con parches raros y unida a newlib, además de mezclada con algunas partes de libogc sin necesidad
- segher (que es un desarrollador de GCC) ha revisado el parche de GCC que usa devkitPPC. El 90% es basura o, peor, directamente incorrecto.
- newlib también tiene problemas gordos con threads

Voy a ahorrarme comentarios sobre algunos de los responsables de estas tres cosas, pero sobra con decir que no me llevo muy bien con ellos últimamente. Bueno, nunca me he llevado especialmente bien con ellos (parece que resentían que yo me "metiera en sus asuntos" y en especial odiaban libogc.git, los parches no oficiales de libfat, y todo lo que no sea su bendita distribución oficial), pero últimamente ya me he cansado.

En mi opinión, la gente capaz tiene que dedicarse a cosas que, a la larga, nos van a salvar el culo, tales como:
- documentar el hardware del PPC, con detalles. Sobre todo el GX, sobre el cual hay muy poco documentado, y el código de libogc está descompilado directamente del SDK de nintendo
- explorar y documentar el hardware de Starlet, gran parte del cual es desconocido
- buscar exploits en juegos o en IOS que nos puedan servir en un futuro (y callarselos, hasta que nos hagan falta)
- Linux para la Wii, que tiene mucho que ganar con bootmii y en especial con un mini-proxy ejecutándose en el Starlet, ya que nos permitirá reutilizar sus drivers (USB 2.0, WiFi, SD, y todo lo demás)
- desvincularse de devkitPPC, porque teniendo en cuenta los graves problemas de libogc, tiene poco que ofrecer, al reducirse a un mal parche de GCC y newlib, y experimentar con builds normales de GCC

Y no a hacer animaciones. Que quedan muy bonitas, pero no sirven para nada.

Porque si esto sigue así yo desde luego que voy a tirar la toalla.

Marcan todo lo que dices es completamente cierto pero cuanta gente tiene el nivel necesario de habilidad o de inteligencia para hacer eso. Hermes, rodries, el italiano del devopttab, bushing y tu.

Aqui en EOL y entuwii cuantos programadores tienen el nivel suficiente para pegarse con los registros del ppc para crear un sistema de multihilo. Cuantos son capaces de entender las instrucciones mas basicas de gx. No me imagino a ningun eoliano pegandose con el broadway.

Yo sinceramente lo mas que podria decirte es que te busques un pequeño padawan y lo pongas a prueba para que no te salga otro waninkoko.

Axlaro que lo que hace waninkoko no me parece mal. Mintiendo con su politica de precios y marketing en ds y wii no se merece ningun miramiento.

Vrsquid escribió:

marcan42 escribió:No.

[...]

.

[...]

Yo sinceramente lo mas que podria decirte es que te busques un pequeño padawan y lo pongas a prueba para que no te salga otro waninkoko.

Axlaro que lo que hace waninkoko no me parece mal. Mintiendo con su politica de precios y marketing en ds y wii no se merece ningun miramiento.

Si no es mucha indiscrección... por qué dices "para que no salga otro waninkoko" o "Mintiendo con su politica de precios y marketing en ds y wii no se merece ningun miramiento" ?

suelo leer de vez en cuando, pero no tenía ni idea de que hubiese "movidas" entre los pocos sceners activos de wii que hay...

"para que no salga otro waninkoko", es porque Waninkoko tiene una filosofía muy distinta a la de Marcan, y en muchos casos, ha aprovechado enseñanzas de Marcan para hacer aplicaciones que Marcan no quería que salieran.
La frase "Mintiendo con su politica de precios y marketing en ds y wii no se merece ningun miramiento", entiendela por "Mintiendo = Nintendo", no dice que Waninkoko esté mintiendo con ... (no tendría mucho sentido esta afirmación tampoco). De hecho esta frase es cuando defiende a Wanin diciendo que no le parece mal lo que hace, y da como motivo la política de precios de Nintendo.

Espero que ahora el mensaje quedara más claro aunque quizas el propio Vrsquid debía responderte.

Por otra parte, me parece que Marcan tiene razón en lo que comenta pero que realmente, aunque se mueve menos la scene que no tiene que ver con cargar copias que la otra, están saliendo cosas muy interesantes, juegos cada vez más currados, ports interesantes, actualizaciones de emuladores y demás homebrew, y también hay cosas como el Revolution, etc, etc.
Vamos, que creo que la scene de Wii es una de las mas "sanas" que hay, pero que, como dice Vrsquid, es complicada, y, por tanto, no al alcance de cualquiera.

Para mí es una pena que marcan se haya "retirado" de EOL (que no de la scene de wii, donde parece que sigue currando en ese megaproyecto del bootmii, espero que todo vaya bien). No creo que pasara nada por la salida del BL y todas esas cosas, sólo creo que hubiese hecho falta ser más precavido con ciertas cosas y no haber andado con prisas, sobre todo para algunos sceners ávidos de fama (y no critico a nadie, todos han sacado cosas útiles, lo único que igual con más calma todo hubiese sido mejor y más provechoso). Espero que estos más que brillantes sceners nos sigan deleitando con nuevos descubrimientos para nuestra blanquita, esa que parecía la hermana pequeña y pobre de las consolas de nueva generación y mira qué paliza les está dando a las otras con todas las limitaciones que tiene desde un punto de vista del hardware...

Marcan, hace un tiempo postee en el foro de entuwii sobre las GX, probablemente no habras visto el mensaje.
El caso es que, aunque por una cosa o por otra, nunca he podido dedicarle mucho tiempo, siempre me ha interesado el tema de meterme mas a fondo en la Scene. Lo que iba diciendo es que postee sobre las GX porque tengo implementadas (por mi mismo, no copiadas de ningun sitio) algunas funciones que faltaban en GX y GU (faltaban porque el SDK tiene unas equivalentes). El caso es que si supiera como, contribuiria subiendo esas funciones a donde corresponda. De hecho me gustaria colaborar mas a fondo, no solo con funciones que tengo implementadas porque un dia me hicieron falta. Si puedo ayudar avisame, sobretodo en tema de GX, ya que estoy bastante familiarizado por el tema del engine.

Bueno marcan, en primer lugar agradecerte que fueses tu uno de los primeros en contestarme. Seguramente tengas razón en casi todo lo que has dicho, pero por desgracia las cosas no son siempre como deberían ser

Yo no creo que "hacer banners" sea bueno para la scene, igual que no creo que tú pensases "estoy haciendo un banner" cuando hiciste el de hbc. Si hubiese sido solo eso lo que te (nos) motiva, el banner seguiría siendo una imagen estática, o simplemente no tendría.

Sabes que la investigación muchas veces es únicamente una inyección moral de ver que comprendes cómo funcionan las cosas, y "hacer banners" se convierte simplemente en intentar comprender cómo funcionan los .brlan y los .brlyt, en ir avanzando y que tu interés por conseguir las cosas vaya creciendo (y por desgracia, lo primero que deseas es ver a un conejito saltar en tu wii)

Seguramente en tu posición lo que te acabo de decir es una chorrada, pero nadie empieza por arriba, todos hicimos el "Hola mundo" el primer día. Ni siquiera todos los sceners tienen la misma capacidad de comprender ni llegarán al nivel más alto.

Con este post yo no quería pedirte las tools, solo quería saber (aunque fuese un "no") qué habías decidido finalmente. Te quedas corto diciendo que estás en tu derecho de cambiar de opinión, porque siendo el creador de las mismas, tu derecho sobre ellas es inapelable.

Tomaré como siempre tus palabras en consideración, intentaré hacer algo de lo que propones para la scene, pero seguramente y al igual que muchos, acabaré dándome cuenta que mis propósitos personales han llegado a ser demasiado grandes.

marcan42 escribió:No.

Porque:

1) No considero la creación de canales como beneficiosa para la scene
2) Es mas, no considero nada que interactúe con el software de Nintendo como beneficioso para la scene, visto lo visto con las actualizaciones y las limitaciones del mismo
3) Es una tontería supina perder el tiempo con las cosas de Nintendo cuando se pueden hacer mejor y sin tener que reversar nada
4) He cambiado de opinión sobre algunas cosas, cosa que creo tener derecho a hacer
5) Las tools están diseñadas para que las utilicen la gente en la que confío. Es decir, no son "seguras" de usar para la gente que no las conoce, y no voy a invertir el trabajo necesario para hacer que sí lo sean.
6) Cuanto mas se interactúe con software de Nintendo (sobre todo en lo que concierne a instalar cosas), mas importante es el control de calidad (para evitar bricks). Considero que el control de calidad de la mayoría de la gente que hace esto es bastante inferior a lo que yo considero oportuno (que comparen la cantidad de bricks causados por nuestro software con la media del software que toquetea la NAND), y no estoy dispuesto a sacar utilidades que se puedan usar malamente con tanta facilidad.
7) Hacer cosas sin que se sepa lo que se hace es receta para el desastre, y ya pasa lo suficiente como para sacar herramientas que la gente, sin duda, usará sin el mas mínimo interés por comprenderlas.

Eso va por pywii y por Alameda.

En mi opinión, la actual scene de Wii está estancada, y parece que lo único que va mejorando son las utilidades de piratería. Y, que digan lo que quieran, pero EOL da soporte a la piratería - o si no mirad a todos esos hilos sobre downgradear que proclaman "busca el IOS16" y que se consideran válidos, cuando todos sabemos que no existe forma legal de conseguirlo.

La gente está que no para con las mismas tonterías de siempre. Que si juankear el menú del sistema, que si toquetear archivos de la NAND a pelo, que si parchear IOS, o lo que es peor reemplazar varios IOS masivamente, que si hacer canales (o ilegales, o inseguros, o las dos cosas, casi siempre), que si trampas en los juegos (que encima luego las usan online y nos jodemos los demás), etc.

Y luego el homebrew de verdad tiene:
libogc
- una librería donde la mitad ha sido robado del SDK (cosa que nadie sabía al principio, porque shagkur ha consdiderado conveniente no decírselo a nadie, pero que poco a poco se ha hecho mas y mas evidente). Hasta incluye algunos trozos de código binario sacado literalmente del SDK, como por ejemplo el programa de desbloqueo de las memory cards
- con un sistema de threads casero (de shagkur) que sigue siendo muy frágil (y muy dificil de comprender) y que ha tenido bugs tan gordos como que los cálculos de coma flotante con mas de un thread se iban al garete (supongo que tan poco interés / tan poco homebrew hay que nadie se había dado cuenta hasta que intentamos portar mplayer)
- depende de IOS para todo el tema de Wii, así que nos obliga a mantener IOS operativo
- no tiene un historial seguible y además contiene partes (tales como la librería Wiiuse) que causan conflictos de licencia
libfat
- una librería FAT que intenta ser compatible con sistemas tan distintos como la GBA y la Wii, y que al final consigue unas prestaciones bastante pésimas en la Wii
- ha tenido bugs de corrupción gordos
- es totalmente insegura frente a threads, al menos hasta que se añadió un lock alrededor de todo (cosa que tampoco es buena solución)
- el autor pasa de integrar los parches de terceros (como los de rodries o Hermes) y en su lugar dice de solucionar los problemas a su manera cuando al final la gran mayoría se quedan ahí
devkitPPC
- una distribución de GCC con parches raros y unida a newlib, además de mezclada con algunas partes de libogc sin necesidad
- segher (que es un desarrollador de GCC) ha revisado el parche de GCC que usa devkitPPC. El 90% es basura o, peor, directamente incorrecto.
- newlib también tiene problemas gordos con threads

Voy a ahorrarme comentarios sobre algunos de los responsables de estas tres cosas, pero sobra con decir que no me llevo muy bien con ellos últimamente. Bueno, nunca me he llevado especialmente bien con ellos (parece que resentían que yo me "metiera en sus asuntos" y en especial odiaban libogc.git, los parches no oficiales de libfat, y todo lo que no sea su bendita distribución oficial), pero últimamente ya me he cansado.

En mi opinión, la gente capaz tiene que dedicarse a cosas que, a la larga, nos van a salvar el culo, tales como:
- documentar el hardware del PPC, con detalles. Sobre todo el GX, sobre el cual hay muy poco documentado, y el código de libogc está descompilado directamente del SDK de nintendo
- explorar y documentar el hardware de Starlet, gran parte del cual es desconocido
- buscar exploits en juegos o en IOS que nos puedan servir en un futuro (y callarselos, hasta que nos hagan falta)
- Linux para la Wii, que tiene mucho que ganar con bootmii y en especial con un mini-proxy ejecutándose en el Starlet, ya que nos permitirá reutilizar sus drivers (USB 2.0, WiFi, SD, y todo lo demás)
- desvincularse de devkitPPC, porque teniendo en cuenta los graves problemas de libogc, tiene poco que ofrecer, al reducirse a un mal parche de GCC y newlib, y experimentar con builds normales de GCC

Y no a hacer animaciones. Que quedan muy bonitas, pero no sirven para nada.

Porque si esto sigue así yo desde luego que voy a tirar la toalla.

Bueno, yo no estoy de acuerdo ni nunca lo he estaré con la opinión de marcan, que si hay que reconocerle algunos meritos no se puede negar, pero tampoco andar por alli atacando deliberadamente a otros sceners porque hayan realizado una aplicación u otra. Eso no es tu problema marcan cuando lo vas a entender? "Quemas con tu soberbia!". Acaso tu eres el unico que tiene derecho de... o es que acaso sigues indignado porque un joven de 20 años logro hacer lo que tu no? Nintendo no distingue entre software bueno o malo que no sea el de ellos! si fuese asi no hubiesen intentado capar el Twilight Hack cuando aun no existía el Backup Launcher o ya se te olvido? Para Nintendo Homebrew, menuloader, Mplayer Dvd, Emuladores Nes, SNES, y pare de contar todos son malos... porque? simplemente porque les resta la posibilidad de que ellos puedan vender algo. o es que acaso los emuladores no contribuyen a la piratería? para mi simplemente sientes resentimiento para cualquier persona que haga algo que tu no "consientas" porque "deberian" pedirte permiso. es que acaso tu eres el abuelito de la wii? Por otro lado "EOL NO DA SOPORTE A LA PIRATERIA" eso lo hemos demostrado! pero no quiere decir tampoco vayamos a dejar ignorante a la gente por no responderle sus dudas! Nosotros no pasamos archivos de codigo propietario de nintendo! y eso esta claro! Piensa, sientate, analizate y rectifica date cuenta de los errores que cometes y no quieras echarle la culpa a los demas de la casería de nintendo sobre la Scene, cuando tu eres uno de los principales precursores!

...Y volviendo al tema principal de este hilo, simplemente pienso que aplicaciones como "Bootmii", "tal vez" sean publicadas cuando ya la scene de la wii este muriendo como consecuencia de la salida de una nueva consola de nintendo, por culpa del egoismo de una persona que lo unico que sabe es hablar mal de aquellos quienes no lo son.

Mis saludos y mis respetos a todos lo colaboradores y programadores de la Wii, sobre todo a mi querido Wanin!

technik escribió:Marcan, hace un tiempo postee en el foro de entuwii sobre las GX, probablemente no habras visto el mensaje.
El caso es que, aunque por una cosa o por otra, nunca he podido dedicarle mucho tiempo, siempre me ha interesado el tema de meterme mas a fondo en la Scene. Lo que iba diciendo es que postee sobre las GX porque tengo implementadas (por mi mismo, no copiadas de ningun sitio) algunas funciones que faltaban en GX y GU (faltaban porque el SDK tiene unas equivalentes). El caso es que si supiera como, contribuiria subiendo esas funciones a donde corresponda. De hecho me gustaria colaborar mas a fondo, no solo con funciones que tengo implementadas porque un dia me hicieron falta. Si puedo ayudar avisame, sobretodo en tema de GX, ya que estoy bastante familiarizado por el tema del engine.

Si lees detenidamente el mensaje de marcan puedes ver que cuando saque el bootmii y haga el proxy con el starlet se accederá de forma nativa a la wii usando linux, eso es una de las cosas por las que cada día le dedico menos a buscar fallos en las librerías, ya que las gx o los devoptab de samba o de dvd no harán falta, ya que se usarán driver nativos de linux, que irán mucho mejor que los parches que se hacen ahora (veanse los devoptab), por lo que en lugar de usar gx se usará opengl, de todas formas para colaborar mas activamente usa el irc (EFNET, wiidev), allí podrás hablar con shagkur que revisará tus mejoras y si las ve correctas las integrará, me alegra de que halla gente como tú que quiera aportar algo de verdad a la scene.

marcan42 escribió:No.
Y, que digan lo que quieran, pero EOL da soporte a la piratería - o si no mirad a todos esos hilos sobre downgradear que proclaman "busca el IOS16" y que se consideran válidos, cuando todos sabemos que no existe forma legal de conseguirlo.

Por fin alguien tiene los huevos de decir algo que algunos llevamos pensado hace tiempo.

Princess Peach escribió:Bueno, yo no estoy de acuerdo ni nunca lo he estaré con la opinión de marcan, que si hay que reconocerle algunos meritos no se puede negar, pero tampoco andar por alli atacando deliberadamente a otros sceners porque hayan realizado una aplicación u otra. Eso no es tu problema marcan cuando lo vas a entender? "Quemas con tu soberbia!". Acaso tu eres el unico que tiene derecho de... o es que acaso sigues indignado porque un joven de 20 años logro hacer lo que tu no? Nintendo no distingue entre software bueno o malo que no sea el de ellos! si fuese asi no hubiesen intentado capar el Twilight Hack cuando aun no existía el Backup Launcher o ya se te olvido? Para Nintendo Homebrew, menuloader, Mplayer Dvd, Emuladores Nes, SNES, y pare de contar todos son malos... porque? simplemente porque les resta la posibilidad de que ellos puedan vender algo. o es que acaso los emuladores no contribuyen a la piratería? para mi simplemente sientes resentimiento para cualquier persona que haga algo que tu no "consientas" porque "deberian" pedirte permiso. es que acaso tu eres el abuelito de la wii? Por otro lado "EOL NO DA SOPORTE A LA PIRATERIA" eso lo hemos demostrado! pero no quiere decir tampoco vayamos a dejar ignorante a la gente por no responderle sus dudas! Nosotros no pasamos archivos de codigo propietario de nintendo! y eso esta claro! Piensa, sientate, analizate y rectifica date cuenta de los errores que cometes y no quieras echarle la culpa a los demas de la casería de nintendo sobre la Scene, cuando tu eres uno de los principales precursores!

...Y volviendo al tema principal de este hilo, simplemente pienso que aplicaciones como "Bootmii", "tal vez" sean publicadas cuando ya la scene de la wii este muriendo como consecuencia de la salida de una nueva consola de nintendo, por culpa del egoismo de una persona que lo unico que sabe es hablar mal de aquellos quienes no lo son.

Mis saludos y mis respetos a todos lo colaboradores y programadores de la Wii, sobre todo a mi querido Wanin!

No se si no "lo logró" o no lo quiso hacer, en todo caso, Waninkoko fue el primero en sacarlo y eso no se lo quita nadie, pero es que me hace gracia como dices lo de alguien de 20 años... ¿cuantos años crees que tiene Marcan?
Por otra parte... crees que es más dificil el BL que las tools de Marcan? O incluso que es más dificil BL que el HBC? A veces los que no somos desarrolladores hablamos muy rapido y nos creemos que algunas cosas son muy faciles y otras muy dificiles y nos equivocamos bastante, por eso mismo, a todo el mundo hay que reconocerle su trabajo y nunca asumir que algo en programación es sencillo. Es más... hacer comparaciones sobre la dificultad de varias aplicaciones cuando no sabríamos ni entender el código nunca es buena idea. Tengo claro que BL es dificil, pero creo que cualquier emulador también debe serlo, y los juegos, y todo el homebrew vamos.

Lo de "Piensa, sientate, analizate y rectifica date cuenta de los errores que cometes"... a mi si que me parece soberbio, decirle eso a una persona por el simple hecho de que no opina lo mismo que tu. Lo que tu quieres es que recapacite para que piense más parecido a como piensas tu.

...Y volviendo al tema principal de este hilo, simplemente pienso que aplicaciones como "Bootmii", "tal vez" sean publicadas cuando ya la scene de la wii este muriendo como consecuencia de la salida de una nueva consola de nintendo, por culpa del egoismo de una persona que lo unico que sabe es hablar mal de aquellos quienes no lo son.

Aqui si te luces...

Por otra parte, Boot Mii llegará cuando esté completamente acabado, haya pasado todas las pruebas y sus autores lo quieran sacar, que es lo lógico. Solo faltaba que estuvieras obligado a dar tu trabajo gratuitamente por el simple hecho de que alguien lo quiere tener! Y si liberan o no el codigo, mientras no incumplan ninguna licencia también es decisión unicamente suya.

PD - Sobre el tema que EOL no da soporte a la piratería... yo creo que Jamonazo está haciendo todo lo que puede, que sin duda no es suficiente a veces, pero no se puede pedir más.

rodries escribió:Si lees detenidamente el mensaje de marcan puedes ver que cuando saque el bootmii y haga el proxy con el starlet se accederá de forma nativa a la wii usando linux, eso es una de las cosas por las que cada día le dedico menos a buscar fallos en las librerías, ya que las gx o los devoptab de samba o de dvd no harán falta, ya que se usarán driver nativos de linux, que irán mucho mejor que los parches que se hacen ahora (veanse los devoptab), por lo que en lugar de usar gx se usará opengl, de todas formas para colaborar mas activamente usa el irc (EFNET, wiidev), allí podrás hablar con shagkur que revisará tus mejoras y si las ve correctas las integrará, me alegra de que halla gente como tú que quiera aportar algo de verdad a la scene.

Eso lo he leido, pero supuse que eso iba por el tema del USB y demas, que son standards...No se hasta que punto sera la integracion, pero supongo que las GX siempre iran mas rapido que openGL en una Wii por el simple hecho de que estan diseñadas especificamente para su hardware.
Al fin y al cabo la Wii tiene su propio hardware 3D, que será mas o menos parecido al que se usa para la aceleracion Hardware de
OpenGl. Si se usase OpenGL en wii, a lo maximo que se podria llegar es a una adaptacion usando el hardware de GX...y para eso usamos las GX directamente, no? Si me equivoco prefiero saberlo desde ya para no desperdiciar trabajo, pero creo que las GX seran de las unicas o las unicas cosas que se deberian conservar (o rehacer, pero no olvidar). Cuando leo cosas del Tev o del sistema de iluminacion, etc veo claramente la integracion directa de las GX con el hardware de la Wii (De la GC en realidad, pero para el caso...)

technik escribió:Eso lo he leido, pero supuse que eso iba por el tema del USB y demas, que son standards...No se hasta que punto sera la integracion, pero supongo que las GX siempre iran mas rapido que openGL en una Wii por el simple hecho de que estan diseñadas especificamente para su hardware.
Al fin y al cabo la Wii tiene su propio hardware 3D, que será mas o menos parecido al que se usa para la aceleracion Hardware de
OpenGl. Si se usase OpenGL en wii, a lo maximo que se podria llegar es a una adaptacion usando el hardware de GX...y para eso usamos las GX directamente, no? Si me equivoco prefiero saberlo desde ya para no desperdiciar trabajo, pero creo que las GX seran de las unicas o las unicas cosas que se deberian conservar (o rehacer, pero no olvidar). Cuando leo cosas del Tev o del sistema de iluminacion, etc veo claramente la integracion directa de las GX con el hardware de la Wii (De la GC en realidad, pero para el caso...)

Creo que no te equivocas, no conozco a fondo la ati hollywood, pero supongo que en todo caso lo suyo sería hacer un driver nativo para las X y un port para OpenGl para el tema de los juegos y emus. Lo bueno es que en gx.c está toda la información de como funciona internamente aunque eso ya tendrías que verlo con la gente que controla mas, supongo que Isobel ( o Marcan) es el mas idoneo para aclararte como irá el sistema.

Princess Peach escribió:Bueno, yo no estoy de acuerdo ni nunca lo he estaré con la opinión de marcan, que si hay que reconocerle algunos meritos no se puede negar, pero tampoco andar por alli atacando deliberadamente a otros sceners porque hayan realizado una aplicación u otra. Eso no es tu problema marcan cuando lo vas a entender? "Quemas con tu soberbia!". Acaso tu eres el unico que tiene derecho de... o es que acaso sigues indignado porque un joven de 20 años logro hacer lo que tu no? Nintendo no distingue entre software bueno o malo que no sea el de ellos! si fuese asi no hubiesen intentado capar el Twilight Hack cuando aun no existía el Backup Launcher o ya se te olvido? Para Nintendo Homebrew, menuloader, Mplayer Dvd, Emuladores Nes, SNES, y pare de contar todos son malos... porque? simplemente porque les resta la posibilidad de que ellos puedan vender algo. o es que acaso los emuladores no contribuyen a la piratería? para mi simplemente sientes resentimiento para cualquier persona que haga algo que tu no "consientas" porque "deberian" pedirte permiso. es que acaso tu eres el abuelito de la wii? Por otro lado "EOL NO DA SOPORTE A LA PIRATERIA" eso lo hemos demostrado! pero no quiere decir tampoco vayamos a dejar ignorante a la gente por no responderle sus dudas! Nosotros no pasamos archivos de codigo propietario de nintendo! y eso esta claro! Piensa, sientate, analizate y rectifica date cuenta de los errores que cometes y no quieras echarle la culpa a los demas de la casería de nintendo sobre la Scene, cuando tu eres uno de los principales precursores!

...Y volviendo al tema principal de este hilo, simplemente pienso que aplicaciones como "Bootmii", "tal vez" sean publicadas cuando ya la scene de la wii este muriendo como consecuencia de la salida de una nueva consola de nintendo, por culpa del egoismo de una persona que lo unico que sabe es hablar mal de aquellos quienes no lo son.

Mis saludos y mis respetos a todos lo colaboradores y programadores de la Wii, sobre todo a mi querido Wanin!

Princess Peach (¿tienes algún rollete con Waninkoko? tranqui, es solo un poco de cotilleo...), está bien que quieras defender a gente que igual ha sido aludida más bien indirectamente por marcan, pero no te pongas así tampoco ya que quien abrió la veda en esto de la scene de wii fue marcan, así que es muy injusto llamarle egoísta. Simplemente vuelvo a repetir lo que dije: un poco más de calma y menos luchas de méritos le hubiesen venido mejor a la scene, y eso también implica a gente como Waninkoko, que a mí me parece todo un crack como scener. Y creo que el bootmii llegará, y además será lo mejor de la scene con diferencia porque eso sí será poder manejar la wii a nuestro antojo, y no esos "parcheos" (muy útilos por cierto), que no dejan de ser formas indirectas de controlar la wii. Venga, que haya paz.

Me parece muy interesante el hilo y aunque no pueda aportar nada sí que prefiero scene a carga de backups. Yo provengo de PSP, donde la piratería está matando a la consola pero afortunadamente hay programas que permiten usarla como reproductor multimedia, ejecutar el doom, entre otras cosas. Supongo que eso se debe a que en la scene de psp los firms ya están hackeados y cargan backups sin hacer nada.
Sin embargo si no se hace todo el trabajo de portar librerías, drivers y demás al final la wii puede ser pasto de la piratería y sin tener ninguna función añadida. Por suerte una gran cantidad de juegos de wii los hace nintendo, por lo que dificilmente se dejarán de sacar juegos precipidademente, como pasó con Dreamcast, pero si solo se apuesta por la carga de bacups al final se va todo a la mierda en una consola con excelentes posibilidades multimedia.

self escribió:Me parece muy interesante el hilo y aunque no pueda aportar nada sí que prefiero scene a carga de backups. Yo provengo de PSP, donde la piratería está matando a la consola pero afortunadamente hay programas que permiten usarla como reproductor multimedia, ejecutar el doom, entre otras cosas. Supongo que eso se debe a que en la scene de psp los firms ya están hackeados y cargan backups sin hacer nada.
Sin embargo si no se hace todo el trabajo de portar librerías, drivers y demás al final la wii puede ser pasto de la piratería y sin tener ninguna función añadida. Por suerte una gran cantidad de juegos de wii los hace nintendo, por lo que dificilmente se dejarán de sacar juegos precipidademente, como pasó con Dreamcast, pero si solo se apuesta por la carga de bacups al final se va todo a la mierda en una consola con excelentes posibilidades multimedia.

Antes de Dark_Alex ya habia scene en psp, con carga de backups y todo eh . Aunque es cierto que la psp esta reventada hablando de pirateria, tambien lo es que hasta donde yo se (que es poco, pa que engañarnos) es la consola con mas aplicaciones homebrew hasta el momento. La verdad es que yo uso la psp para todo menos para lo que sony la diseño xD

Perdon por el oftopic pero no he podido resistirme

suloku escribió:Antes de Dark_Alex ya habia scene en psp, con carga de backups y todo eh . Aunque es cierto que la psp esta reventada hablando de pirateria, tambien lo es que hasta donde yo se (que es poco, pa que engañarnos) es la consola con mas aplicaciones homebrew hasta el momento. La verdad es que yo uso la psp para todo menos para lo que sony la diseño xD

Perdon por el oftopic pero no he podido resistirme

Es que con la mierda de juegos y cutreports no puedes hacer otra cosa. La psp tiene menos juegos buenos que la gamecube1.2.

Las GX habrá que conservarlas inicialmente (bueno, reescribirlas, porque como ya digo la legalidad de gx.c es cuestionable), pero estaría bien tener una adaptación OpenGL en el futuro. No tiene por qué ser mucho mas lento, sobre todo si nos permitimos salirnos un poquito del estándar, o añadir extensiones a OpenGL que hagan las cosas "a la manera del GX".

Yo creo que una cosa importante ahora sería analizar gx.c (recordando, en todo momento, que por muy relacionado con el homebrew que esté, al final estás básicamente leyendo el SDK de Nintendo, así que nada de copiar - y igualmente, no va a ser trivial, porque es código decompilado) y traducirlo a una explicación del hardware detallada, al estilo de yagcd, pero con todos los comandos que se pueden enviar al pipeline gráfico y cosas así. Luego ya se encargará otra persona de reescribirlo sanamente, y yo creo que acabaremos con un producto mejor y demostrablemente legal (ya que se tratará de ingeniería inversa "limpia", o al menos lo mas cercano a eso posible).

La cuestión mas interesante ahora mismo es curiosa y se aplica a ambos: el problema de la memoria gráfica. La Wii no tiene memoria gráfica dedicada (bueno, sin contar las cachés y el FB). Cuando corres bajo Linux, la memoria vista por un proceso no es contigua físicamente (al estar paginada), por lo que no podemos hacer un simple memalign() para crear una textura, por ejemplo. Y hete aquí el problema: no hay una solución "facil" para, a nivel de kernel, combinar la memoria contigua (sobre todo en trozos grandes) con la no contigua. La solución fácil es dividir la memoria en un área de gráficos y un área normal, pero eso impone una limitación a las aplicaciones, que pueden necesitar mas o menos memoria de texturas. Sospecho que la solución estará en una de las APIs del kernel relacionadas con los gráficos (DRI o algo así), pero mis conocimientos en ese área son practicamente nulos.

Por otro lado, un kernel como es debido tiene muchas ventajas con respecto a libogc (y al SDK de nintendo). Debugging mas fácil, todo mas estable, aplicaciones mas pequeñas (al no incorporar todo libogc en cada una), drivers mas que testados y estables, multitarea como es debido (por ejemplo, se podría hacer el menú home al estilo de la 360 o la PS3, generico para todas las apps), cosas como la posibilidad de música de fondo para todo el homebrew, y detallitos como no causar la reconexión del Wiimote o la reinicialización de internet para cada app.

Por cierto, la idea es tener un Linux minimalista. Ni X ni nada de eso (que no digo que no se pueda usar, pero no sería parte de la "base"). No se trata de convertir la Wii en un PC, sino de aprovechar Linux como kernel para crear aplicaciones.

A mi para lo de la memoria se me ocurre usar un ramfs al iniciar la app montas un sistema de ficheros donde metes las texturas.

ramfs tiene exactamente el mismo problema que memalign. No es contiguo.

Quizás se podría hacer como en las Intel integradas: mediante el módulo agpgart se reserva una parte de la memoria y según la necesidad se va reservando más o menos de forma dinámica.
http://en.wikipedia.org/wiki/AGPgart

Wikipedia escribió:Desktop computers using Intel 810/815g/855-series graphics devices can achieve higher resolution of screen images under Xorg xserver with only 1 mebibyte of BIOS-allocated video RAM. Developers of video drivers can utilize the AGPgart driver to allocate system memory for 2D display or 3D display and to manage AGP devices.

La solución fácil es dividir la memoria en un área de gráficos y un área normal, pero eso impone una limitación a las aplicaciones, que pueden necesitar mas o menos memoria de texturas. Sospecho que la solución estará en una de las APIs del kernel relacionadas con los gráficos (DRI o algo así), pero mis conocimientos en ese área son practicamente nulos.

No estoy seguro, pero creo que lo mejor sería que el driver de video se encargara de la gestión de la memoria gráfica. Reservar una zona de memoria contigua y no cacheable creo que es fácil, al menos lo hizo isobel para el driver framebuffer. Si el problema es que no es contigua por ser cacheable, creo que se podría solucionar haciéndole las peticiones de memoria para texturas al kernel directamente (¿un node nuevo? ¿usando /dev/fb directamente con un ioctl dedicado? nose, lo digo por dar soluciones...). Es decir, se reserva una zona de memoria solo para gráficos, y según lleguen las peticiones se va reasignando la zona de memoria libre. Otra forma sería con mallocs dentro del kernel (¿se podían hacer?, no lo recuerdo) y luego marcarlo como no cacheable.

No se si servirá de algo, pero ya existía el driver de GX para gamecube-linux. No me he metido mucho en como está hecho, pero tiene un par de funciones (gx_alloccontiguousmemory y *dealloc*) que sirven precisamente para eso (bueno, están en la librería de gx adaptada). No estoy muy seguro de lo que hace, pero la idea es pedirle a /dev/fb la memoria, marcarla como no cacheable, y luego llevar el conteo de la memoria que queda.

PD: Por cierto, que isobel estaba trabajando en recuperar las GX para wiilinux. Por lo que me contó, había hecho bastantes avaces así que posiblemente funcione GX en la próxima versión del kernel

Un hilo interesante en el que nadie pregunta "como cargo las backups de juegos que aun no he comprado¿?"

Se echa en falta mas hilos como este por el foro


Saludos

nuvalo escribió:No estoy seguro, pero creo que lo mejor sería que el driver de video se encargara de la gestión de la memoria gráfica. Reservar una zona de memoria contigua y no cacheable creo que es fácil, al menos lo hizo isobel para el driver framebuffer. Si el problema es que no es contigua por ser cacheable, creo que se podría solucionar haciéndole las peticiones de memoria para texturas al kernel directamente (¿un node nuevo? ¿usando /dev/fb directamente con un ioctl dedicado? nose, lo digo por dar soluciones...). Es decir, se reserva una zona de memoria solo para gráficos, y según lleguen las peticiones se va reasignando la zona de memoria libre. Otra forma sería con mallocs dentro del kernel (¿se podían hacer?, no lo recuerdo) y luego marcarlo como no cacheable.

El problema es que la memoria de gráficos tiene que ser contigua. ¿Que haces si necesitas mas memoria de gráficos pero te topas con memoria ya usada? Si son páginas normales puedes moverlas claro... aunque eso supone una demora de tiempo importante si ocurre a menudo, sobre todo si te toca tirar de swap. Pero si te topas con una página bloqueada en RAM, entonces ya no hay quien te salve.

Es decir, no es un problema trivial de resolver - pero estoy seguro de que hay herramientas disponibles para resolverlo (bueno, o por lo menos para hacer un buen trabajo) - pero desconozco como funcionan.

Hay que tener en cuenta que en los PCs de hoy día existen mecanismos - IOMMU, periféricos con capacidad scatter-gather, cosas así - que no existen en la Wii. En un PC con AGP, el AGP GART es en efecto un tipo de IOMMU que se encarga de presentar las áreas de memoria RAM usadas para gráficos como si fueran una memoria contigua, de cara a la GPU. Esto no existe en la Wii.

nuvalo escribió:No se si servirá de algo, pero ya existía el driver de GX para gamecube-linux. No me he metido mucho en como está hecho, pero tiene un par de funciones (gx_alloccontiguousmemory y *dealloc*) que sirven precisamente para eso (bueno, están en la librería de gx adaptada). No estoy muy seguro de lo que hace, pero la idea es pedirle a /dev/fb la memoria, marcarla como no cacheable, y luego llevar el conteo de la memoria que queda.

Por lo que recuerdo, ese driver usa kmalloc, que en efecto usa memoria contigua. Pero tiene sus limitaciones, y en realidad está pensado para cositas del kernel, no para sacar tochos de memoria para gráficos. Vamos, no es realmente la solución correcta.

nuvalo escribió:PD: Por cierto, que isobel estaba trabajando en recuperar las GX para wiilinux. Por lo que me contó, había hecho bastantes avaces así que posiblemente funcione GX en la próxima versión del kernel

Estamos en contacto con el respecto a todo este tema

Yo creo que al final la solución puede ser algo dinámico pero a bloques. Por ejemplo, que se vayan obteniendo trozos de memoria de 4MB para gráficos según sean necesarios. Eso depende de haya memoria contigua de ese tamaño, y causa algo de fragmentación si usas texturas grandes (no se aprovecharía el final de los bloques). La idea sería que fuera dinámico, pero que una aplicación pueda pedir de antemano que se reserve una cantidad de RAM para gráficos, para mejorar la fragmentación y evitar tener que realizar el proceso sobre la marcha.

Marcan, como ya he dicho me gustaria meterme un poco mas en el tema, por esta parte de las GX y demas. Visto como enfocais el futuro de la Scene de Wii, estaria encantado de ayudar. A ver si me puedes contar un poco por aqui, o por mp o por correo los frentes que hay abiertos o por donde puedo ayudar. Gracias.

Estamos en contacto con el respecto a todo este tema

Yo creo que al final la solución puede ser algo dinámico pero a bloques. Por ejemplo, que se vayan obteniendo trozos de memoria de 4MB para gráficos según sean necesarios. Eso depende de haya memoria contigua de ese tamaño, y causa algo de fragmentación si usas texturas grandes (no se aprovecharía el final de los bloques). La idea sería que fuera dinámico, pero que una aplicación pueda pedir de antemano que se reserve una cantidad de RAM para gráficos, para mejorar la fragmentación y evitar tener que realizar el proceso sobre la marcha.

Oks, era solo que creía que era un problema solucionado. En su momento lo miré y parecía que funcionaba, pero claro una cosa es que funcione y otra que lo haga correctamente.

Digo yo se lo mismo que mi abuelita de programacion, ingenieria inversa y demas, pero dadas las caracteristicas del hardware en el Wii, sera posible conseguir lo que estan tratando de hacer..?? segun lo que leo, eso de memoria contigua es en base al hardware, no?? porque si fuera en software lo unico que se haria seria reescribir esa parte de para que ya no este chingando y les deje leer y escribir a sus anchas sin estar con que me faltan 3 pesos para esto, y aqui me sobraron 50 centavos, verdad..??


offtopic: Vaya es primer foro que leo que Marcan no esta mentando madres a todo el mundo y realmente esta esparciendo sus conocimientos, ojala lo vieramos asi mas seguido (o siempre si se aceptan peticiones cual estacion de radio de cumbias, jajajaja)

ether2802 escribió:Digo yo se lo mismo que mi abuelita de programacion, ingenieria inversa y demas, pero dadas las caracteristicas del hardware en el Wii, sera posible conseguir lo que estan tratando de hacer..?? segun lo que leo, eso de memoria contigua es en base al hardware, no?? porque si fuera en software lo unico que se haria seria reescribir esa parte de para que ya no este chingando y les deje leer y escribir a sus anchas sin estar con que me faltan 3 pesos para esto, y aqui me sobraron 50 centavos, verdad..??


offtopic: Vaya es primer foro que leo que Marcan no esta mentando madres a todo el mundo y realmente esta esparciendo sus conocimientos, ojala lo vieramos asi mas seguido (o siempre si se aceptan peticiones cual estacion de radio de cumbias, jajajaja)

Pues en EOL jamás le he visto "mentar madres" de nadie, ni en ningún otro sitio.

Pues se ve que no sales de aqui , no estoy intentando ofender a nadie, solo digo lo que veo, si mi comentario ofende o perturba la salud mental de cualquier usuario de EOL, puedes ordenar que borren mi comentario y eliminen mi cuenta, de haber sabido que la sensabilidad estaba a roce de piel no hubiera escrito lo ultimo, pero se me olvida que es mas facil comenzar una discucion que realmente discutir de un tema en especifico, saludos maestro..!!

ether2802 escribió:Pues se ve que no sales de aqui , no estoy intentando ofender a nadie, solo digo lo que veo, si mi comentario ofende o perturba la salud mental de cualquier usuario de EOL, puedes ordenar que borren mi comentario y eliminen mi cuenta, de haber sabido que la sensabilidad estaba a roce de piel no hubiera escrito lo ultimo, pero se me olvida que es mas facil comenzar una discucion que realmente discutir de un tema en especifico, saludos maestro..!!

Discusión? No se como te habrás tomado mi mensaje, solo digo que por lo menos aquí yo no he visto eso que dices, nada más, ni te he criticado a ti, ni he criticado al foro, ni siquiera he dicho que mientas o que me cites ejemplos, solo digo que aquí yo no he visto nunca eso. Take it easy hombre!

Como tu bien dices, será que no salgo de aquí y que casualmente los pocos (porque son pocos) foros que visito donde escribe Marcan no se mete con las madres de nadie.
No te preocupes hombre, que ni te reporté antes ni te voy a reportar ahora, en todo caso que lo haga Marcan si lo cree oportuno.

offtopic: Vaya es primer foro que leo que Marcan no esta mentando madres a todo el mundo y realmente esta esparciendo sus conocimientos, ojala lo vieramos asi mas seguido (o siempre si se aceptan peticiones cual estacion de radio de cumbias, jajajaja)

Pueden haber muchas cosas que criticale a marcan (y si hay ganas de criticar), pero justamente que no esparza su conocimiento no es una de ellas. Puede entrar a hackmii, a los foros donde escribe, o simplemente en algún post que haya escrito aquí y darte cuenta que siempre explica lo que hace. Otra cosa es que los pobres mortales no lo entendamos o que necesitemos la O con un canuto para comprenderlo.

Quizás se podría hacer como en las Intel integradas: mediante el módulo agpgart se reserva una parte de la memoria y según la necesidad se va reservando más o menos de forma dinámica.

Y teniendo en cuenta que Intel tiene código GPL de alguna de sus gráficas, ¿no se podría aprender de su implementación?

Otra pregunta simplemente por curiosidad. Hasta hace poco Apple creo que tenía códio abierto de su kernel ¿es muy diferente el PPC de la wii al de los mac's antiguos? ¿Sería un buen camino para descubrir su funcionamiento?

Ya tenemos la respuesta de Marcan y este hilo esta degenerando mucho