É exactamente o que o Morais disse e não vamos ter essa conversa. Está nas regras e é uma linha que não vamos pisar.
Elaborando desta vez, a Wii U não está a usar emulação, a nivel de CPU é code compatible por isso é desligar o multicore, e meter o CPU @ 729 MHz. A nivel de GPU há um converter block que traduz os calls para o Flipper/Hollywood para calls que a gráfica do novo entende, mas não os liberta, ou seja, está a correr tudo em SD na mesma, não faz uso nenhum do fillrate (massivo) adicional.
Em emulação não há upscale, há uprender, e era relativamente simples para a Nintendo neste caso ter desenhado o converter block (ou tê-lo feito por software) para também haver uprender.
As questões que levam a que tal não tenha acontecido, como referi, são muito Nintendo. É normal jogos Wii terem truques como a layer de efeitos correr a metade da resolução do jogo (320x240 ao invés de 640x480) e por vezes com dithering abusivo ou os jogos não usarem full buffers e correrem a resoluções estrambólicas centrados e com underscan. Mexer nestas coisas não é particularmente dificil, mas não vai dar resultados iguais aos originais em todos os casos.
E era muito fine tuning que eles tinham de dizer ao conversor para ignorar, porque não está a fazer nada ali e isso tornava a implementação mais dificil do que seguir documentação 1:1. Emulação por software "moderna" chama-se high level emulation porque não está focada no hardware, está-se largamente a c*gar para ele e por isso não é accurate em timings e afins, está a correr código e a traduzi-lo por via de dynarec (dynamic recompiler), não é preciso um recompilador dinamico para correr jogos Wii na Wii U quando o CPU é code compatible, é preciso é um wrapper para o GPU.
Accuracy no entanto é importante para a Nintendo porque eles não querem quebrar compatibilidade, criar glitches e ter de os resolver com compatibility lists. Um dos que está a ser lançado no inicio desta iniciativa, o DKCR tem um framebuffer por software a correr dentro do jogo (por isso o converter block nunca faria as alterações correctas, teriam de ser forçadas ou o jogo teria mau aspecto), as personagens e inimigos são renderizadas em offset, e aí era preciso dizer-lhe para ignorar as instruções originais de usar muito pouca memória, @ 16 bits de cor e ir para algo maior no que toca a resolução.
Isto é simples, é literalmente mudar valores, mas ao fazê-lo deixaria de ser um jogo Wii, estaria automaticamente a usar mais RAM. Complica as coisas desnecessáriamente para eles.
Não é muito diferente dos shadow maps, na GC e Wii eram tipicamente 128x128 best case scenario. É claro que mexeram nisso no Zelda WW HD, isto são coisas fáceis de mudar, mas não há um converter block que o faça, é preciso ter uma compatibility list, patch ou injector.
Outro problema é os HUD's, feitos para 480p e FMV's quando aplicáveis. Daria-lhe o aspecto de um emulador a correr algo, a melhorar o que pode e a deixar o resto na mesma.
Em vez de ir por esta via que era possivel mas não foram (e dependendo de como desenharam o sistema fazer hijack desse converter block pode ser impossivel) mas tendo em conta que estão a haver re-releases eles deviam era ter recompilado estas re-releases todas, cada jogo para correr em HD não tem mais de uma semana de trabalho e estou a ser simpático; é literalmente mandar fora o overhead gráfico do render to screen desses GPU's, condicionado pela memória disponivel a soluções tipo 18 bits de cor e optar por uma resolução maior sem optimizações, depois de mandar o overhead fora e implementar um "driver" do GPU mais moderno o que resta é tipo aqueles mods que eles fazem aos jogos de PC bloqueados a 720p para irem mais alto. É ir caçar onde estão essas coordenadas, resolução de shadow maps e afins, e aumentá-los.
