Noticias sobre wii64

DRaGMaRe escribió:Te hace falta IOS 53, mira si es eso.

Lloyd Irving escribió:Al final la mejora del emulador Wii64 era fake o no?

shin-gori escribió:quizas se esperen a que nintendo saque el majora mask para analizar mejor el emulador de la propia ninty...

es solo una especulacion

shin-sepp256 escribió:April 1st Tiizer is Real & General Update
First off, the April 1st Tiizer video is actual gameplay using a recent dev build of Wii64. As you can tell, tehpola has made tremendous progress in debugging and optimizing the dynamic recompiling core. However, there are still a handful of showstopping bugs that we need to work through before we can make a public release. Also, you should be aware that not all of your favorite games will run on the initial release because of a variety of reasons. We are not planning on initially supporting the Expansion Pak because of memory limitations. After further optimizations, tweaks, and profiling to reduce our memory consumption, then we hope to add Expansion Pak support. We may not initially support games that execute code directly from the cart or that use virtual memory (i.e. Goldeneye) because this requires more investigation and significant code changes in the dynarec to implement. Also, some graphics microcodes aren’t supported in glN64, so a few games such as Conkers BFD won’t work just yet. But, sit tight and we’ll continue to work on more features for Wii64 after the initial release.

A complete re-code of the Wii64 gui is underway, so you’ll be able to enjoy using the wii-mote for navigation and also some sleek new graphics. We’ll have a new look for the initial release, but we also plan on adding more features to the gui over time for your enjoyment.

If you have watched any of the recent gameplay videos, then you know that the accuracy of the glN64 port has increased substantially since the Wii64 Tiizer release we made for the Homebrew Channel. Because GX is not 1:1 with openGL, there was a lot of investigation and tweaking required for me to get the behavior on GC/Wii close to what glN64 looks like on PC. There are still a variety of bugs for different games, so don’t expect everything to look perfect, yet. Emu_kidid is a great tester, and he is maintaining an internal graphical issue list to work on. I hope to add a couple more features to glN64 prior to release, including glN64’s primitive framebuffer texture support as well as 2xSaI scaling for textures. The plan is, of course, to continue hunting down bugs and adding features after the upcoming release.

As for the other graphics plugins, glN64_GX is much faster than both soft_gfx and GX_gfx, so we may only release a build with glN64_GX. The only drawback is that currently glN64_GX won’t render graphics for demos that only directly manipulate the framebuffer with the CPU. However, when I have time I’ll add a feature into glN64_GX that will allow it to render the N64’s framebuffer rather than rendering primitives passed through the N64’s graphics pipeline. Then, you can just flip an option in the menu when you are running homebrew N64 games and demos that write directly to the framebuffer. Also, I have already done some work on porting Rice’s video plugin to Wii64. Rice supports more microcodes than glN64, including the one that Conkers BFD uses, and it should be faster than glN64. We have a vision of supporting custom texture packs in Wii64, so we will implement that feature as well. We hope that you, our users, will contribute your creative talents in developing texture packs to share with the Wii64 community. We can’t say when custom texture pack support will be finished, but expect it sometime in the future.

Some of you have been asking for an update on WiiSX. We are planning on working on a release of WiiSX after the upcoming Wii64 release. The reason we have not done a release yet is because there were some serious bugs in SVN last fall, and we also wanted to focus on completing Wii64. We have since resolved some WiiSX issues, internally, and so once Wii64 is out the door, we feel that we can also follow up with a WiiSX release relatively soon afterwards.

Finally, we’d continue to ask that if you enjoy using Wii64 when it’s out that you consider donating to the project. Right now, most of the donations we receive go toward hosting costs. However, there are also some small accessories like component cables and classic controllers that we are considering purchasing with donation funds to aid in development.

xDaRkWaVexD escribió:Hay nuevas noticias sobre el Wii64 en emulatemii:EmulateMii

shin-sepp256 escribió:April 1st Tiizer is Real & General Update
First off, the April 1st Tiizer video is actual gameplay using a recent dev build of Wii64. As you can tell, tehpola has made tremendous progress in debugging and optimizing the dynamic recompiling core. However, there are still a handful of showstopping bugs that we need to work through before we can make a public release. Also, you should be aware that not all of your favorite games will run on the initial release because of a variety of reasons. We are not planning on initially supporting the Expansion Pak because of memory limitations. After further optimizations, tweaks, and profiling to reduce our memory consumption, then we hope to add Expansion Pak support. We may not initially support games that execute code directly from the cart or that use virtual memory (i.e. Goldeneye) because this requires more investigation and significant code changes in the dynarec to implement. Also, some graphics microcodes aren’t supported in glN64, so a few games such as Conkers BFD won’t work just yet. But, sit tight and we’ll continue to work on more features for Wii64 after the initial release.

A complete re-code of the Wii64 gui is underway, so you’ll be able to enjoy using the wii-mote for navigation and also some sleek new graphics. We’ll have a new look for the initial release, but we also plan on adding more features to the gui over time for your enjoyment.

If you have watched any of the recent gameplay videos, then you know that the accuracy of the glN64 port has increased substantially since the Wii64 Tiizer release we made for the Homebrew Channel. Because GX is not 1:1 with openGL, there was a lot of investigation and tweaking required for me to get the behavior on GC/Wii close to what glN64 looks like on PC. There are still a variety of bugs for different games, so don’t expect everything to look perfect, yet. Emu_kidid is a great tester, and he is maintaining an internal graphical issue list to work on. I hope to add a couple more features to glN64 prior to release, including glN64’s primitive framebuffer texture support as well as 2xSaI scaling for textures. The plan is, of course, to continue hunting down bugs and adding features after the upcoming release.

As for the other graphics plugins, glN64_GX is much faster than both soft_gfx and GX_gfx, so we may only release a build with glN64_GX. The only drawback is that currently glN64_GX won’t render graphics for demos that only directly manipulate the framebuffer with the CPU. However, when I have time I’ll add a feature into glN64_GX that will allow it to render the N64’s framebuffer rather than rendering primitives passed through the N64’s graphics pipeline. Then, you can just flip an option in the menu when you are running homebrew N64 games and demos that write directly to the framebuffer. Also, I have already done some work on porting Rice’s video plugin to Wii64. Rice supports more microcodes than glN64, including the one that Conkers BFD uses, and it should be faster than glN64. We have a vision of supporting custom texture packs in Wii64, so we will implement that feature as well. We hope that you, our users, will contribute your creative talents in developing texture packs to share with the Wii64 community. We can’t say when custom texture pack support will be finished, but expect it sometime in the future.

Some of you have been asking for an update on WiiSX. We are planning on working on a release of WiiSX after the upcoming Wii64 release. The reason we have not done a release yet is because there were some serious bugs in SVN last fall, and we also wanted to focus on completing Wii64. We have since resolved some WiiSX issues, internally, and so once Wii64 is out the door, we feel that we can also follow up with a WiiSX release relatively soon afterwards.

Finally, we’d continue to ask that if you enjoy using Wii64 when it’s out that you consider donating to the project. Right now, most of the donations we receive go toward hosting costs. However, there are also some small accessories like component cables and classic controllers that we are considering purchasing with donation funds to aid in development.

offspringboy escribió:

xDaRkWaVexD escribió:Hay nuevas noticias sobre el Wii64 en emulatemii:EmulateMii

shin-sepp256 escribió:April 1st Tiizer is Real & General Update
First off, the April 1st Tiizer video is actual gameplay using a recent dev build of Wii64. As you can tell, tehpola has made tremendous progress in debugging and optimizing the dynamic recompiling core. However, there are still a handful of showstopping bugs that we need to work through before we can make a public release. Also, you should be aware that not all of your favorite games will run on the initial release because of a variety of reasons. We are not planning on...

Nos podrias contar en que consiste. Mi ingles no es muy bueno.

April 1st Tiizer ies Real & Actualización General

En primer lugar, el video April 1st Tiizer son juegos corriendo usando una compilación reciente de Wii64. Como puedes ver, Tehpola ha echo un gran progreso en el debugging y optimación del nucle de recompilación dinámica. Sin embargo hay un puñado de errores en los que tendremos que trabajar antes de hacer una versión pública. Además, debe de tener en cuenta que no todos los juegos se ejecutan en la versión inicial, debido a una variedad de razones. No estamos pensando en un principio soportar la expansión de memoria (Expansion PaK), debido a limitaciones de memoria. Después de nuevas optimizaciones y ajustes, que permitan reducir el consumo de memoria, entonces esperamos soportar el Expansión Pak.porque esto requiere más investigación y significativos cambios en el código en el dynarec de aplicar. Inicialmente no se soprotará juegos que ejecuten directamente codigo del cartucho o que use memoria virtual (por ejemplo, el Gondeneye) porque requiere más investigación y significantes cambios de código en el dynarec para implementarlo. También, algunos microcódigos graficos no están soportados en glN64, así que algunos juegos como Conker BFD no funcionarán todavía. Sin embargo, no se preocupen que continuaremos trabajando en más funciones para Wii64 después de la liberación inicial.

Un nuevo código de la interfaz gráfica Wii64 está en marcha, por lo que usted podrá disfrutar de utilizar el wii-mote para la navegación y también de algunos nuevos gráficos mas elegantes. La GUI va a tener un nuevo look para la versión inicial, pero también continuaremos añadiendo más funciones para su disfrute.

Si has visto cualquiera de los videos recientes, entonces sabrás que exactitud del port de glN64 ha aumentado sustancialmente desde la liberación que hicimos para el Homebrew Channel. Debido a que GX no es 1:1 con openGL, se hizo un montón de investigación y ajuste necesario para obtener el comportamiento de GC / Wii glN64 cerca de lo que parece en la PC. Todavía hay una serie de errores para los diferentes juegos, así que no esperes que todo se vea perfecto, aún. Emu_kidid es un gran tester, y está aportando una lista de errores graficos sobre los que trabajar. Espero añadir un par más de características a glN64 antes de su liberación, incluyendo soporte para el framebuffer glN64 primitivo así como escalado 2xSai para las texturas. El plan es, por supuesto, a seguir en la caza de errores y la adición de características a partir de la próxima versión.

En cuanto a los otros complementos gráficos, glN64_GX es mucho más rápido que soft_gfx y GX_gfx, así que solo haremos una release basada en glN64_GX. El único inconveniente es que actualmente glN64_GX no renderiza gráficos para hacer demostraciones que manipulan el framebuffer directamente con la CPU. Sin embargo, cuando tenga tiempo voy a agregar una función en la glN64_GX que le permitirá renderizar el framebuffer de la N64 en lugar de reenderizar primitivas psadas a través del pipeline gráfico. Entonces, se puede voltear una opción en el menú cuando está ejecutando homebrew N64 juegos y demos que escribir directamente en el framebuffer. Además, ya he hecho algún trabajo en portar el Rice vídeo plugin para Wii64. Rice admite más microcodes que glN64, incluyendo el que utiliza Conkers BFD, y debería ser más rápido que glN64. Tenemos en mente soportar paquetes de texturas personalizadas, por lo que incluiremos esa función también. Esperamos que ustedes, nuestros usuarios, contribuyan con su talento creativo en el desarrollo de paquetes de texturas para compartir con la comunidad Wii64. No podemos decir cuando el soporte para texturas personalizadas estará terminado, pero esperamos que en algún momento en el futuro.


Algunos de ustedes han estado pidiendo una actualización de WiiSX. Estamos trabajando en una liberación de WiiSX después de la próxima liberación Wii64. La razón por la que no se ha hecho una nueva release se debe a que aún había algunos errores graves en SVN el otoño pasado, y también queriamos centrarnos en completar Wii64. Desde entonces hemos resuelto algunos errores de WiiSX, internamente, por lo que una vez Wii64 este liberado, creemos que también podemos seguir con una de WiiSX en relativamente poco tiempo.

Por último, si usted disfruta usando Wii64, por favor considere donar al proyecto. Ahora, la mayoría de las donaciones que recibimos las dirijimos hacia los costos de alojamiento. Sin embargo, hay también algunos pequeños accesorios como los cables de componentes y controladores clásicos que estamos estudiando comprar con las donaciónes para la ayuda en el desarrollo.

Lloyd Irving escribió:Y al final que pasa con esto. ¿ha salido algo nuevo?

nosekefik escribió:

Lloyd Irving escribió:Y al final que pasa con esto. ¿ha salido algo nuevo?

Yo diria que no, porque el blog sigue igual...

Lloyd Irving escribió:lol, justo habia revivido esto el dia anterior de una nueva noticia, soy un crack.

Que impaciente estoy por el emulador (aunque mas me interesa el de PSX )

Getting the floating-point and 64-bit instructions (which aren’t used all that often as the name N64 would lead you to believe) supported in the dynarec were important for improving the dynarec performance beyond that of the pure interpreter.

Mark R. escribió:Por mucho que se traduzca no nos van a contar nada importante a nivel de usuario. Son puros datos técnicos y cuentan por los problemas que han pasado.
Lo más importante es esto:

Getting the floating-point and 64-bit instructions (which aren’t used all that often as the name N64 would lead you to believe) supported in the dynarec were important for improving the dynarec performance beyond that of the pure interpreter.

Que han conseguido implementar las instrucciones con punto flotante, y han obtenido una mejora en el rendimiento.

Pero me ha parecido muy curioso que haya instrucciones de N64 que la Wii no pueda traducir. No sabía que tenía instrucciones de 64 bits, es muy interesante... Parece como si la N64 hubiera salido muy avanzada a su tiempo.

alaun escribió:Ojala se supiera algo en firme sobre este emulador, es lo que muchos soñamos: un emulador de N64 funcional... y sin embargo no hay nada . Ojala se saque una version beta o algo por el estilo en el que los juegos rulen + o -.

kape escribió:Yo con un emulador de N64 y otro de MAME ya me conformo y no pediria nada mas

sabandellos escribió:

kape escribió:Yo con un emulador de N64 y otro de MAME ya me conformo y no pediria nada mas

Y a que esperas para meter el Mame 0.125 versión wii?. Te digo esto porque me suena a que no lo conocías y te estoy dando el noticion del siglo

Yo lo tengo en la wii y estoy suuuuper contento. Nunca imagené jugar al Thunder Cross de konami en mi wii... una pasada!, sin contar las otras casi 7mil roms que soporta esa version de MAME (algo mas de 3mil distintas y el resto clones varios).

Espero que alguien mas haya hecho el descubrimiento del siglo con esto que estoy diciendo (supongo que solo la gente nueva en el mundillo de la wii), porque en el homebrew browser no aparece para descargarselo y no hay mucha publicidad sobre ello, sobre todo ahora que ya es una versión que salió hace mucho y la noticia es "vieja".

Saludos

sabandellos escribió:Con respecto al wii64, lo que mas rabia me da es que se le va a pasar el ciclo de vida util a la wii, y no lo van a tener terminado. El desarrollo está muy avanzado, y por ahí hay compilaciones NO oficiales de la ultima versión que muestran que ya estan cerca. También me da rabia que el emulador de Playstation esté parado, esperando a que acaben el wii64 (porque son los mismos autores), y que nadie con conocimientos ayude. A este paso, los emuladores estaran acabados, justo cuando todos tengamos en casa ya la "Wii 2"

Saludos

Mark R. escribió:¿Dónde hay esas compilaciones no oficiales? Si el repositorio de Google Code hace tiempo que no lo actualizan, el código solo lo tienen ellos.

sabandellos escribió:

Mark R. escribió:¿Dónde hay esas compilaciones no oficiales? Si el repositorio de Google Code hace tiempo que no lo actualizan, el código solo lo tienen ellos.

Será un placer proporcionarios a todos los que aun no lo tengais el enlace... aquí tenéis la penultima compilación no-oficial de este emulador de Nintendo64 para wii:

http://freefile.kristopherw.us/uploads/ ... 4-r474.zip

Creo que la compilación tiene a duras penas un par de meses o incluso menos.

Con la de playstation (WiiSX) pasó exactamente igual, alguien compiló la ultima version, la cincuenta y tantos, no recuerdo y también está por ahí rulando. La tengo en mi SD, si alguien la quiere, tiene sonido, pero aun no es muy jugable.

Debería haberme puesto como nick "el tonto de los emuladores". De siempre, es lo que mas me gusta en PC y lo que mas busco en Wii.

Saludos!

tehpola escribió:
The structure of the dynarec itself is an important factor in the performance of the emulator. In order to convey some of the changes we’ve made to the dynarec, you have to understand how its structured and how it works. You can divide my dynarec into a few distinct pieces: the translator, the trampoline, the code cache, and some run-time helper functions.

The translator is given an address at which it will translate a chunk of MIPS code into PowerPC. It uses a total of 3 passes to accomplish that. Pass 0 reads in a instruction at a time until it hits an unconditional jump, a jump register, or an exception return, which signifies the end of the function its trying to recompile. Its main purpose is to identify any branch instructions and determine where they are branching to; it does this to ensure that no branches will be branching into a register mapping. Pass 1 actually does the translation by converting each MIPS instruction to a sequence of PowerPC instructions. Branches are left unfilled because we don’t yet know how many PowerPC instructions will be between any given source instructions. Pass 2 then fills out the branch destinations now that every instruction’s position is known. The translator uses volatile and nonvolatile PPC registers in its generated code. Nonvolatile registers are used to store constants like the memory address to store the register values into, the address of the N64 memory, and a few other useful emulator variables. Volatile registers are used to temporarily store N64 registers for the generated instructions to operate on. These are mapped to hardware registers as needed, and stored to memory when changed and no longer needed.

The code that’s generated by the translator goes into the code cache. On a PC with no real memory limit this isn’t necessary. However, on the Wii, memory is quite constrained. In total, we have access to a little under 88MB of memory. However, using the larger MEM2, which is 64MB, is somewhat slower than using the 24MB of MEM1, so we have to limit the code to fit in MEM1 for it to run as fast as possible. Not to mention that the cache has to share MEM1 with all of the emulator code and static structures.

I have a few functions which the recompiled code will call in order to reduce the amount of generated code generated for complex instructions. For example, interpreted instructions, updating Count, and taking floating-point unavailable exceptions. These are just ordinary C functions which will only be invoked by the recompiled code. These functions allow for a reasonable trade-off: faster than interpreting and relatively small code generated for just the function call.

The trampoline, or dispatcher, is at the heart of the dynarec. The trampoline is responsible for determining if code at a given N64 address is recompiled, and if its not, recompiling it, and then calling the recompiled code. When the code that the trampoline invoked needs to branch to another block of code, it returns to the trampoline with the N64 address of the code it wants to run, and the process begins again: the trampoline looks up the new address, possibly recompiles, and then calls the desired recompiled code. Branches within a function don’t need to return to the trampoline, but because any function can be freed from the code cache at any time, every branch outside of the function must return to the trampoline to be dispatched.

Mark R. escribió:No dicen nada sobre el rendimiento del emulador o su compatibilidad, si es lo que os interesa
Es un blog muy interesante, están explicando cómo están haciendo su emulador en vez de dar noticias y fechas (que ni ellos saben si podrían cumplir) sobre éste. Un 10 para el equipo de EmulateMii Leyendo su blog no me estoy volviendo un súper-programador, pero estoy entendiendo cosillas que no sabía sobre el funcionamiento de las consolas y sus respectivos emuladores.

Mark R. escribió:

Getting the floating-point and 64-bit instructions (which aren’t used all that often as the name N64 would lead you to believe) supported in the dynarec were important for improving the dynarec performance beyond that of the pure interpreter.

Pero me ha parecido muy curioso que haya instrucciones de N64 que la Wii no pueda traducir. No sabía que tenía instrucciones de 64 bits, es muy interesante... Parece como si la N64 hubiera salido muy avanzada a su tiempo.

xDaRkWaVexD escribió:Por lo que cuentas se oye genial, por que no, nos lo traduces para saber también acerca de el tema!

Juriolo escribió:No le veo mucha utilidad a un emulador de 64 pudiendo incrustar roms a juegos de VC

Aunque si se pudieran poner filtrado de texturas estaria bien, pero no creo que la wii lo soporte

alaun escribió:Visto lo visto comparto la opinión de aquí, el amigo forero. Es un emulador que no cuento con él. De hecho creo que jamás saldrá una versión decente y ójala me tenga que tragar mis palabras.

zxc2 escribió:para todos los que decian que estaba abandonado, hoy acavan de anunciar que la primer release publica saldra pronto y para muestra aqui esta un video
http://www.youtube.com/watch?v=-x-XEAmh ... r_embedded


salu2

Elbarto777 escribió:un juego de Rareware funcionando bien

Sogun escribió:Del nuevo video me han gustado algunas cosas y otras no. Para empezar me ha chocado que hayan cambiado el logo poligonal de Nintendo64 dando vueltas por la M roja rotatoria (no sé ni a que hace referencia ¿a Mario?). Otra cosa que no me ha gustado es que la rom no arranque automáticamente al cargarla, sino que hay que pulsar después en 'Play game' (eso sí, las roms ahora cargan mucho más rápido o esa es mi impresión).
Tenemos soporte por USB, me gustaría saber si 2.0 y si hay que instalar algo nuevo o si servirían los Cios de Rodries y/o Hermes.

En las opciones de video hay una cosa que pone "FB textures" que no sé lo que es. (¿Serán texturas a mayor resolución creadas por los usuarios?)
No han mostrado si se pueden remapear los botones de los controles aunque espero que sí.

Respecto a los juegos que han mostrado, que no nos permitan escuchar el sonido me hace sospechar que aún no corren al 100% de velocidad (en el video del 1 de abril el sonido delataba que los juegos no funcionaban correctamente). Salvo el Banjo Kazooie (y un poco el F-Zero X) no se aprecian errores gráficos.