Hilo de detalles y curiosidades de N64

@Calculinho estoy de acuerdo, por lo menos la parte ARCADE (conducción), en general, está sobresalientemente bien cubierta en N64; es uno de sus tres únicos puntos fuertes junto a las plataformas y los fps.

Diskover escribió:Después de haber visto este Die Hard 64 moverse en la consola tan bien, me da la sensación de que se pudo haber hecho un Half Life bastante decente para Nintendo 64.

Recuerdo un hilo de hace años (ya es raro en mi acordarme ) sobre si hubiera sido posible llevar Half-Life a N64.
Si se hizo el port de Daikatana, se podría haber hecho el de Half-Life, pero a saber que le hubieran capado y cuantas pantallas de carga tendría.

@MyoCid llevaría de serie el movimiento ese con el mando original xDDD

Sexy MotherFucker escribió:@MyoCid llevaría de serie el movimiento ese con el mando original xDDD

En PC no siempre te salia a la primera.

daytona 64
creo que se moveria mejor que en saturn.

@Sexy MotherFucker
En la propia descripción del vídeo explica que está ejecutando el juego en emulador: "Being played in an emulator an obvious bug is present where the rear light/break lights don't work. I played in Bizhawk with the Glide 64 Mk2 plugin. Apart from defaults, I also enabled 'Force Calc Sphere' which added the shine onto the cars. No setting would fix the lights. Rice plugin however would show the lights correctly, but there were other issues like texture pop and filled transparent textures so I chose the better of the two. I will re-render the video if this is ever fixed of course."

De todas formas Ridge Dacer 64 es uno de los juegos más agradables a la vista del catálogo de la consola. Es muy nítido y suave, y las texturas tienen una gran definición y muy buena elección de colores. Otros juegos cojean de uno o más de estos aspectos. Incluso World Driver Championship falla en la nitidez de la pantalla (en modo de alta resolución sí que tiene muy buena nitidez, pero a costa de ocupar sólo 1/3 de la pantalla).
Me van a caer piedras, pero el Automobili Lamborghini también me parece muy sólido visualmente, aunque el juego sea muy corto, fácil y el control muy mejorable.

Yo no he jugado mucho al Ridge Racer 64 porque no me gustan algunos detalles de su jugabilidad como que un pequeño roce prácticamente detenga el coche en seco y ese sistema de derrapes tan raro que tiene, pero es un juego muy bien hecho. Y como han dicho no lo programó Capcom sino un estudio americano de Nintendo, Nintendo Software Technology, que también hicieron los Wave Race y 1080º de Gamecube entre otros.

Juegos de velocidad la Nintendo 64 tiene para hartarse, pero es cierto que muchos no son nada populares y han caído en el olvido.
F-Zero-X, World Driver Championship, Excitebike 64, Diddy Kong Racing, Mario Kart 64, Wave Race 64, Rush 2049, Ridge Racer 64, Beetle Adventure Racing, Star Wars Racers, Top Gear Rally y los F1 World Grand Prix 1 y 2 serían los mejores. Pero luego tienes los otros Rush, la saga Cruis'n con tres juegos, los dos Extreme G, Top Gear Rally 2, Mickey Mouse Speedway USA, los dos V-Rally, Wipeout 64... es uno de los géneros más abundantes en realidad.
Ya digo que en PS1 eran juegos más destacables porque era un género que explotaba las bondades de la consola, al igual que los juegos de lucha o los RPGs con fondos prerrenderizados.


@MyoCid
Recuerdo el hilo porque yo mismo participé en él.
Sigo creyendo que es posible y que se podría conseguir un aspecto visual muy logrado. Mi mayor preocupación sería que el juego encajase en un cartucho, aunque fuese de 512 Mb, sin tener que recortar secciones de los niveles.
Habría recortes obligados en texturas porque las originales no cabrían en los 4 kB de la caché, aunque sabiendo lo que se hace y al correr el juego en menor resolución podrían dar el pego perfectamente. Se simplificarían elementos del escenario como escaleras de mano y barandillas que pasarían a ser un plano texturizado para ahorrar carga poligonal. Quizás los personajes perderían sus cutres animaciones faciales, pero son tan simples que no creo que se ganase mucho con ello. Habría que bajarle la calidad a los diálogos, sobre todo por el tema de capacidad del cartucho (o eliminarlos por completo). También seguramente reducir los modelos poligonales de los enemigos, especialmente los que suelen aparecer en grupos.

Creo que el juego más similar en concepto a Half-life que hay en Nintendo 64 es el Turok 3: Shadow of Oblivion.

Sexy MotherFucker escribió:@Calculinho estoy de acuerdo, por lo menos la parte ARCADE (conducción), en general, está sobresalientemente bien cubierta en N64; es uno de sus tres únicos puntos fuertes junto a las plataformas y los fps.

En éso coincido, pero juegos tipo Gran Turismo...
Ya digo, los pocos juegos de carreras que caté en su día los fundí: V-Rally 99, Mario Kart 64, F-Zero X, F-1 World Grand Prix, Ridge Racer 64... el día que se mueran las partidas de ésos juegos me va a dar un chungo.

Una espinita clavada que tengo desde peque es el Beetle Adventure Racing. Me lo pintaron muy bien las revistas de la época, pero nunca le pude echar el guante. Y ahora, me da un poco de cosa pillarlo y que no sea lo que tengo idealizado desde que era peque.

@Sogun gracias por la aclaración, pero insisto; ¿la velocidad es la original o no?

@viper2 le parece que sí.

Es que yo soy fan de la saga Ridge Racer hasta el V, los he exprimido todos tanto en consolas como ARCADES, salvo por el Rave Racer de recreativa, y el RR64 el cual probé fugazmente en la época, y alguna vez cuando (aún no sé porqué) me da por jugar borracho al Everdrive 64 los veranos, pero ninguna partida realmente seria en que haya avanzado hasta conseguir los coches más avanzados.

Siento que me he perdido una entrega de cierta calidad. Si el 1 en PlayStation que es el de derrape más incontrolable, y los son choques como tú los describes, me sigue gustando; este RR64 que a todas luces estará más pulido debería encantarme.

@jordigahan me sigue pareciendo mucha tralla para una N64 300.000 polígonos por segundo a 60 fps, 496x384, todos esos coches en carrera, y aplicando los... ¿mip Maps que se marca el Model 2?:

https://m.youtube.com/watch?v=R3qhDxGq_uk

Pero mejor que los de Saturn por descontado, y ya que estamos programando a bajo nivel y con los efectos justos; mejor que cualquier cosa que veamos en PlayStation.

Me mola tu idea

por supuesto, no se podria hacer un pixel perfect., pero creo que podriamos ver algo bastante decente.

@Sexy MotherFucker @jordigahan si tuvo uno Saturn, malo será que la 64 no pudiera con uno también. Sexy te has tirado a la placa recreativa cuando la norma general es que hasta después de los 128bits placa siempre es más potente que las consolas

La consola en teoría puede mover 600 mil polígonos de calidad PSX con el microcódigo Turbo3D. Pero Nintendo nunca dejó usarlo en juego (sinceramente no entiendo esto, pero es lo que dicen en internet).

No hay más datos sobre esos 600 mil polígonos, así que imagino que serán a resolución mínima, 30fps y planos.

En cualquier caso leyendo todo lo que nos ha descubierto este hilo podríamos concluir que la consola sí podría tener un port bueno de Daytona y otros muchos juegos (siempre que quitemos música CD y cinemáticas claro). Pero en la época sería algo más complicado tanto por falta de pericia (lo de que el Z-buffer no es necesario, ahorrarse el filtro AA, etc que se ha comentado aquí) como porque Nintendo se columpiaba.

Pese a ello, una desarrolladora que supiera exprimir al consola como Rare o Factor5 podría hacer un Daytona ligeramente recortado a 320x240 ¿no?

Visitando un poco el homebrew..

Existe un port del FlappyBird a N64.


Si os gusta leer desarrollos recomiendo echarle un ojo a la web del autor porque explica como lo hizo paso por paso, también allí se encuentra la descarga, el juego tiene sonido, es un detalle interesante porque mucho homebrew no lo lleva.

Descarga:
http://www.christopherbonhage.com/FlappyBird-N64/

Evil Australians, otro jueguecillo que viene con código, se renderiza todo con la CPU.


Descarga:
http://ludumdare.com/compo/minild-71/?action=preview&uid=132358

Una compilación de homebrew de N64, alguien del foro del Everdrive 64 hizo una compilación, hay lo típico que te puedes encontrar, el Pong, un Arkanoid bastante interesante, etc. Muchos de estos juegos tienen efectos interesantes como semitransparencias porque usan la libultra en lugar de un sdk libre.

Descarga:
https://mega.nz/#!9npn2BZC!ylT6ELZ-I49xkTrGuOIWvz-FC89Fc7nc-icG9RyF2Mg

--
He realizado algunos tests de fillrate para ver lo poco que sirven si no se conocen las condiciones, por supuesto con la maquina lastrada pero para hacerse una idea aproximada.

Modo 16bits / texturas 16bits / Sin AA

16x32
COPY - 35,1MP/s
1CYCLE - 13,4MP/s

64x32
COPY - 64,3MP/s
1CYCLE - 22,3MP/s

320x240 (textura de 64x32 repetida hasta rellenar el rectángulo)
COPY - 84,4MP/s
1CYCLE - 26,8MP/s

Primero está claro que COPY es mucho más rápido que 1CYCLE, cuanto más grande es la superficie mayor es el fillrate, tiene sentido, pero además libdragon no usa el RSP y apenas hace cosas en paralelo, así que verdaderamente el último test es el que está siendo ehm más cercano, porque hay menos tiempos en blanco.

A N64 le gustan más las lecturas secuenciales que aleatorias, trabaja mejor en bloques mayores que menores, los juegos de la consola ya están diseñados para usar superficies muy grandes.

Todo esto es sin recargar la textura o los resultados serían peores, pero por otro lado la variedad de texturas que te encuentras en un juego 3D es de igual 15 texturas diferentes en ese momento concreto, así que no es tan terrible como parece, si lo es más para detallar 2D, que podrían ser 200 recargas de textura entre las distintas capas, fondos y sprites.

Estos resultados son a 50fps (PAL), la consola se siente más cómoda cuando la tasa es menor y aumenta el fillrate con ello, el rendimiento no es lineal, en todos los tests de cualquier tipo que he realizado puedes hacer más con una tasa más baja y no de forma proporcional, sino más, igual la latencia de la RAM tenga algo que ver.

Tiene sentido pensar en los 20fps de Zelda OOT o Majoras Mask, no es que usen 1CYCLE sino 2CYCLE para muchas cosas como hacer la textura doble del suelo, del agua, del templo del agua y muchos otros efectos.

Como primitivas de color para todas las superficies, dado que todo es afectado por la hora del día, eso requiere que todas las superficies estén por lo menos en 1CYCLE para ser tintadas de color.
--

He subido lo que llevo hecho de librería a Github haciendo un fork de la original, ya se empiezan a animar algunos programadores de N64 para mejorarla.
https://github.com/conker64/libdragon

Genial saber que algunos programadores se empiezan a animar, pueda que después se empiecen a ver más ports en n64, creo que el mejor juego homebrew hasta el momento es el arkanoid que mencionas voy a probar el flappybird,

ya no se ha sabido nada sobre los emuladores en desarrollo de snes o gameboy?

@john D9
Sí, se va a crear un subforo para libdragon en los foros de CEN64, hasta ahora no había nada de soporte en internet, ningún foro donde ir a preguntar.

Se subirán ejemplos, se pondrá ya compilada con el sdk de n64chain para evitar todo el tedioso paso de compilación y se irá avanzando hasta soportar 3D, teniendo el sdk y el emu CEN64 en 5 minutos cualquiera podría estar compilando y probando los ejemplos sin necesidad de tener la consola o un cartucho flash.

Existe n64lib con mejor core, así que se irán migrando cosas de una a la otra.

Krom es quién hace el emu de SNES, pero trabaja en mil proyectos a la vez

--
Test a prueba de fuego:


Esto ya está más en condiciones que aquel test de alpha que hice, si lo vemos de cerca hay deformación localizada en el framebuffer, allí donde pones la llama se deforma el fondo.

La luz que emite la llama usa filtro bilinear, es la gracia de N64, suavizando cosas como luces queda genial.

Si pulsamos A vamos dejando llamas cual pirómano, con Z se aplica un efecto de rastro con semitransparencias, parecido al movimiento de Alucard del SOTN.


He subido el ejemplo a github donde se puede ver el código (no está nada optimizado y en inglés de pueblo pero se entiende ), también se encuentra el .z64 ya compilado para probar en consola o emulador.
https://github.com/conker64/libdragon/tree/master/examples/fire

Una cosa si me pongo a ahcer un juego comercial para la 64 con libdragon ¿no tendre ningun problema?

Tambien en cuanto este pasa enlance para registrarme ¿o es la misma cen64 echo con phpbb?

Entonces ¿es posible que haya efectos que no se hayan usado nunca?

@Flash-Original
El SDK es libre, tendrías problemas si usaras el oficial, tienes pensado hacer algo comercial?

Sí, es el foro de la página de cen64, por alguna razón ahora no me deja entrar en su web

Lo de los efectos claro, hay efectos de framebuffer a pantalla completa en muchos juegos de N64, tendría que buscar alguno de zona localizada.

Por ejemplo el test de fuego que he enseñado es zona localizada, pero hacer el efecto tiene mandanga, si has visto el código verás que primero recojo el framebuffer y lo meto en una textura, luego trabajo sobre esa info para hacer la deformación y se lo devuelvo al RDP para que renderice, en realidad se puede trabajar directamente sobre el framebuffer sin hacer estos pasos, pero con esa función puedes cambiarle el color, hacerlo transparente, espejarlo, etc

Metroid Prime tiene efectos de zona localizada como cuando disparas con carga, en este efecto se contrae una pequeña zona por donde está el cañón (mirando las cajas), este efecto se puede recrear en N64 y puede que lo haga.


Incluso Castlevania SOTN tiene algún efecto de framebuffer, cada vez que se hace la magia se paraliza todo, supongo que forma parte del efecto, como cuando subes de nivel y en otros momentos también congelan la imagen o para que no te golpeen mientras lo haces.

@BMBx64 ¿cúal es el polycount en su pico máximo de Super Mario 64?

@BMBx64 En N46 me viene ahora a la mente el mismo Zelda OT cuando sales del agua o te quedas haciendo "el gamba" cerca dela superficie que se deforma la escena completa. Hay más juegos seguro.
De todas formas me parece que esta generación se vieron muy poco este tipo de efectos, entiendo que por su coste de CPU.

@BMBx64 Si estuve mirando el tst.c del fuego la tela que tiene copiar de un lado a otro y demas

Si la verdad quisiera hacer algo comercial especificamente 2 y 2 homebrews(para coger practica) la cosa es que para una que es resident evil tendre que aprender los algoritmos de compresion de mpeg-layer y demas que ya estuve curioseando alguno (especificiamente detecccion de colores y replica para que en los cambios minimos no requiera espacio) y ademas lo limitado de las texturas quizas me vea forzado a hacerlo con poligonos, aunque no he probado la velocidad con la que actualizaria las animaciones y tal de varios tiles

@Sexy MotherFucker
Entre 40-50K de superficies visibles sería una cifra bastante realista.

En las peleas de Bowser VS Mario ya se te van 752 en Mario y 1002 en Bowser, más unos ¿100? del escenario, luego añade detalles adicionales como todas las llamas que suelta, échale unos 1850 o 1900, más el OSD que podrían ser rectángulos y descarta un 40% de esa suma en efectividad borrando zonas tapadas, igual te salen 36K reales en esa batalla o 60K procesados.


Pero hay zonas que podrían tener otros detalles más complejos, por ejemplo la sala duplicada del espejo mete a 2 Marios o los cuadros cuando los tocas se subdividen en muchos triángulos para hacer la deformación (que también están los 2 presentes en la sala del espejo), de todas formas creo que Mario 64 está más pensado en poner superficies gigantes, tirar de corrección de perspectiva y todas las zonas van a estar muy bien compensadas.

@sgonzalez
Sí, el Zelda OOT tiene muy buenos efectos de framebuffer, debajo del agua, en el volcán, dentro de Jabu Jabu, o incluso al pausar el juego se hace una copia del buffer de pantalla para seguir mostrando todo, pero en realidad no produce la geometría 3D del escenario en el menú de pausa, es solo una copia, los emuladores se hacían un lío con esto al comienzo

@Flash-Original
Si quieres hacer fondos de tipo Resident ya puedes en la libdragon, más adelante ya piensas en los algoritmos de compresión

@BMBx64 gracias, entonces entre 40 y 60.000 polígonos por segundo siendo el apogéo las luchas contra Bowser.

Goldenfinger 64, una modificación del juego GoldenEye 007 de Nintendo 64 para poder encarnar a James Bond en la que es una de las películas más queridas de la franquicia acaba de salir a la luz en forma de beta.

Enlace a la página de descarga. El enlace está debajo de todo el texto descriptivo.

Después de muchos años de desarrollo y de soltar información a cuentagotas, diponéis de 20 niveles jugables para un jugador y 11 mapas multijugador totalmente nuevos para recuperar sensaciones de tiempos pasados.

No se trata de la versión final porque aún hay algún nivel a medio hacer y algunos más que necesitan pequeños retoques, pero creo que puede completarse de principio a fin. El equipo espera recibir la opinión de los jugadores para encauzar el proyecto en su recta final y lograr un producto más redondo todavía.

¡Espero que os guste!

SubDrag escribió:By:SubDrag, Trevor, Sogun, Zoinkity, Wreck, Dragonsbrethren, MRKane, 00action, Cyberen, Monkeyface, Kyle, Zmg88, Garabuyo, Comet, Stolen Textures, Spinout, ShiftClick

After two long decades and celebrating the 53rd anniversary of the movie, British secret agent James Bond makes his triumphant return to the Nintendo 64! His mission; to gather intelligence on a wealthy entrepeneur named Auric Goldfinger. The investigation will take 007 around the globe and back again, in twenty brand new levels that faithfully recreate the film, as well as previous entries into the series as bonus material. Tour the famous Fontainebleau Hotel in Miami, drive through the Alps in a classic Aston Martin, sneak inside a shady export company compound in Mexico, and shoot your way into the gold rich vaults of Fort Knox using a vast arsenal of weaponry. Mow down the enemy like a true gangster with the Thompson machine gun, use stealth at a distance with the AR-7 sniper rifle, or ramp up the fire power with a devastating RPG launcher. And once you've foiled Goldfinger's plans to dominate the world's bullion market, sharpen your skills against friends (or foes!) in multiplayer mode. With eleven maps to compete in, a wide range of weapon loadouts, and a comprehensive character roster to choose from, you'll soon be finding yourself crammed back on the couch again in split-screen fever. A completely original musical score accompanies every stage, and due to the inclusion of the Expansion Pak, are lengthier than previously possible. This memory expanding device allows Goldfinger 64 to go farther than the original game it was built upon. A greater amount of image textures can be loaded into a level at one time, mission setups filled with even more content, and maps larger than ever before. This fan-made sequel to GoldenEye 007 aims to bring players an exciting experience, while representing perhaps the most beloved Bond film of all time with much due respect. So if you think you're up to the task of putting an end to Operation Grand Slam, grab your controller and pull up a chair. It's about time Bond was back on the job.


(promotional material and text by Wreck)




http://goldeneyevault.com/viewfile.php?id=349




Also, some amazing box art created by Wreck as well:

@Sogun Gracias por avisar! Impresionante trabajo el que os habeis currado! Espero que sigais así y saqueis más cosas como estas, es una pasada.

@Sogun Pero bueno, ¡Quér sorpresa! enhorabuena, tiene muy buena pinta.

@Sogun
Lo he estado jugando un rato y mola

Creo que mucha gente se va a quedar sin probarlo por eso de tener que parchear la rom con el xdelta, no me he mirado que tenía que configurar el savegame del Everdrive, así que al iniciar cada nivel me salía con todos los parámetros a 0, sin sonido, sin música y con el resto de las opciones a la izquierda, tampoco se me ha salvado el progreso claro.

Qué hace exactamente el Expansion Pak? Pone más objetos destruibles por el escenario?

El nivel 3 tiene varios bugs:
- Si nada más empezar la fase te vas para el lado derecho de la piscina y empiezas a juguetear por ahí, dejará de cargar todos los sectores excepto en el que te encuentres, hay como un bar y un tío que te ofrece algo.
- Dentro del hotel tienes que llegar a la puerta del piso 5 la cual está cerrada con llave, si por un casual no llevas la llave hay un soldado dentro de esa puerta que te puede oír y abrirte la puerta, una vez dentro ya no puedes salir y tienes que reiniciar el nivel (de ahí consigues la llave para el piso 9, pero esa llave no abre la del 5).

En lo demás he visto pequeñas cosillas, como en la bodega del nivel 2 en los túneles hay un soldado mal situado en las cajas que no podrá disparar al jugador (de esos que están quietos y solo se agachan), en el nivel de Silo en el Goldeneye original también había un soldado en un pasillo que estaba atascado en una pared y me daba coraje cada vez que lo veía xD, en otros puntos también me he encontrado NPCs quietos sin hacer nada (no levantaban las manos ni reaccionaban), pero igual es intencional, la cosa es que estaban junto a enemigos operativos.

Otras cosillas a modo de opinión:
- Creo que se exige demasiado al jugador en los primeros niveles, registrar todos los apartamentos puerta por puerta, tanto en el nivel 2 como en el 3, he flipado de forma positiva con la cantidad de detalle que hay ahí metido y que todo se pueda seguir destruyendo, con todos los objetos y detalles nuevos, pero abruma un poco, quizás porque los 2 niveles van seguidos uno del otro y con objetivos similares, encontrar X, minimizar bajas civiles, etc
- Quizás no pondría el objetivo de colocar las 6 minas en el primer nivel como Agent.
- He visto a mucho enemigo con "arma de precisión" de esas que casi cada tiro es acierto, no es algo negativo pero en Goldeneye solo enemigos concretos apuntan así, en zonas localizadas o con distinto traje, como los que hay dentro del taller junto a la antena en la fase Dam.

Pero vamos son detalles solo por si sirven de algo, está genial, voy por el nivel 4 a ver que tal los siguientes

@BMBx64
El Expansion Pak permite niveles con más texturas, más objetos, más enemigos, mayor carga poligonal (aunque baja el framerate) y músicas más largas.

Respecto a los bugs que mencionas del tercer nivel:
-Parece que lo que mencionas es un "agujero" en el clipping. Algún triángulo del clipping no está perfectamente alineado y el jugador puede "salirse" del nivel por ahí. Ocurre si caminas por un sitio en concreto (si pudieras poner una foto indicando dónde es para poder arreglarlo...). Bond se sale del nivel y actúa como un fantasma, puede atravesar las cosas y si hubiese desniveles flotaría en el aire. Si vuelves a "entrar" por el punto de "salida", todo vuelve a la normalidad. Este tipo de errores es bastante puñetero, porque son difíciles de encontrar. Para solucionarlo suele bastas con rehacer esos triángulos del clipping.
Tengo un vídeo del desarrollo de la primera misión donde pasaba algo parecido pero más espectaular. Como podrás ver, me costó varios intentos dar con el punto exacto. Este error se arregló, pero más tarde encontré otro igual en un punto de la ciudad. Sólo me ocurrió aquella vez y no me volvió a pasar tras decenas de intentos.
-Me he dado cuenta de que eso también pasa en el primer nivel que los enemigos pueden abrirte unas puertas cerradas y si no tienes la llave (en nivel Agent no aparece el guardia que te la da) te quedas encerrado dentro del edificio. También viendo el el vídeo de Glennplant he visto que una vez llegas a la ciudad del primer nivel no puedes volver atrás (esto habría que arreglarlo al menos para el primer nivel de dificultad). Mira que he jugado los dos primeros niveles decenas de veces durante años porque los he hecho yo, y no me había dado cuenta de eso.

Lo del guardia de los túneles de Bodega se arregla posicionándolo de nuevo, pero creo que ese detalle le da carisma. De nuevo, siempre he ido a saco en esa parte y no le he prestado atención.
Los civiles que no reaccionan es algo que ya notamos al principio, pero no hemos sabido por qué ocurre. Todos los civiles tienen asignado el mismo comportamiento, pero unos son más pasivos que otros. Seguramente hay algo que se nos escapa.

Respecto al resto:
-En el nivel 2 sólo es obligatorio registrar todas las habitaciones en el último nivel de dificultad. En los otros dos basta con dar con la habitación de Bonita.
A veces es complicado plantear los niveles porque no hay mucho que sacar de la película. Ya es complicado expandir y unir los escenarios a partir de un par de escenas, y luego hay que decidir qué hacer con ello. En la película no hay nada de acción en las escenas del hotel.
-Mi idea inicial era que sólo se podría acceder al interior de un Silo, pero "órdenes de arriba" me dijeron que había que volar los 6. En la peli sólo se ve una explosión. También viendo el gameplay de Glennplant es un objetivo bastante confuso. Además puede ser que se coloque el explosivo de forma incorrecta (si lo lanzas muy plano contra el suelo comienza a resbalar y no te lo cuenta como colocado) y no se cumpla el objetivo. También he visto quejas de que la parte de los silos es muy grande y vacía (bueno, es así en la película) y sé que el nivel es muy oscuro y la distancia de dibujo no ayuda (ya va justo de framerate y aumentar la distancia de dibujo no es recomendable). Reconozco que probando la misión, el tener que entrar a los seis silos uno detrás de otro se me hacía un coñazo.
Cuando recojamos suficientes impresiones de la gente veremos qué cambios podemos hacer.
-No entiendo eso que dices de enemigos con "arma de precisión". ¿Podrías desarrollarlo más?

Voy mirando lo que dice la gente. Me siento como esos actores de teatro que se compran todos los periódicos a la mañana siguiente para leer las críticas.

@Sogun
Claro es que es complicado, cuando haces las cosas muchas veces juegas de la misma forma o solo se te ocurren algunas maneras, falta que llegue alguien que juegue raro para que te desmonte el juego

Yo solo he jugado en modo Agent, del primer nivel destruir los 6 silos se puede hacer tedioso tal como dices, como el escenario es gigante además de andar mucho entre cada carga, te vienen disparos de por ahí y tienes que cambiar a arma para cargarte a los enemigos, luego lo que dices que la mina rebota ya me ha pasado si xD, digo vale las 6, no me digas que me he dejado alguna, entonces toca revisar y solo tienes 8 intentos, que son 2 minas mal tiradas.

En cuanto al segundo nivel es más si lo haces por primera vez, hasta que no revisas todo no llegas a Bonita que está de las últimas puertas, en las bodegas bueno, he descubierto el pasaje secreto pero porque alguien lo ha abierto, sino me veía dando vueltas un buen rato , de todos los niveles que he jugado el segundo es el que más me ha gustado.

El juego me da la sensación de que está diseñado por expertos jugadores de Goldeneye y que desde el primer minuto ya se pide saber manejar gadgets, abrir pasajes ocultos etc, es decir una continuación en toda regla para el que pide más.

El tercer nivel ya miraré de sacar una captura de donde se rompe, en ese nivel me despisté sin saber que hacer, ya te dice la chica que esperes y no te vayas, pero no sabía que de verdad tenía que esperar a que viniera alguien, también veo que te da el objetivo como completado muy deprisa, qué pasa si cojo, me largo y lo dejo con la palabra en la boca? xD

El cuarto nivel es demencial , no consigo pasarlo, donde están todos los lingotes de oro? Solo encuentro 1 en un contenedor y un fajo enorme en el barco que no se puede recoger.

Jugando en Agent me han llegado a matar en ese nivel, solo he encontrado un chaleco en el barco, no sé si hay más , pero serían necesarios varios, aunque sean de media vida, que es solo el cuarto nivel!

En cuanto a lo de los disparos certeros este nivel es el que peor lo lleva, escenario gigante con partes oscuras, disparos que te llegan y no sabes de donde, con pistolas que atinan al segundo o tercer disparo, con una ametralladora fallan más, hacen rafagas sin dar, en este nivel solo he visto pistolas y escopeta, estaría bien tener algo mejor para defenderte porque te pueden venir 5 enemigos de golpe como empiecen a perseguirte y que los enemigos lleven escopeta no facilita las cosas, es 1 disparo 1 impacto como te pillen de cerca.

Hay muchos fallos gráficos en ese nivel, detalles pegados en la pared que desaparecen al acercarte, como ventanas o puertas, no sé si se trata de uno de los niveles inacabados.

Pero me vendría bien tener un gameshark para desbloquear todas las fases.

@BMBx64
El juego se diseñó con la idea de que quien lo jugase ya venía experimentado con GoldenEye. El sistema de juego es el mismo, y los objetivos se cumplen de la misma manera. Quizás haya que revisar los textos para dejar algunas cosas más claras.

Los dos primeros niveles están basados en la introducción de la película.
Como verás apenas aparecen cinco escenarios y con eso tenía que plantear dos niveles. Primero hice la parte del muelle y los silos (también el interior) lo más fielmente que pude. Después el bar del hotel.
En la película parece que están una cosa al lado de la otra, pero no tiene sentido. Lo lógico es que el hotel se encuentre en una zona poblada, así que se hizo la ciudad (apenas un par de manzanas inicialmente, pero luego se expandió a lo que es hoy). Entre medias la zona de los almacenes y el edificio de oficinas. Las oficinas fue lo último que se hizo de estos dos niveles.
El interior del hotel se diseñó antes que la parte exterior. Encajan perfectamente una cosa con la otra, incluso las ventanas están en las mismas posiciones y respetando el grosor de las paredes. Se barajaron varias opciones para la habitación de Bonita (por la posición de la puerta no podía ser cualquiera) y se decidió que quedase a medio camino. En GoldenEye hay cosas similares como la posición del Dr. Doak en Facility (que además varía) o la habitación donde está retenida Natalia en Archives.

Spoiler del segundo nivel:


Yo también estoy atascado en el cuarto nivel . Es uno de los últimos niveles que se ha terminado y en las betas que yo tengo todavía no estaba hecha la misión (sólo podías moverte por el escenario). Lo habrán terminado durante este último mes. Sí que me he dado cuenta de que tiene muchos errores gráficos.

A parte de los niveles que he creado yo también ayudé asesorando en muchos otros, sobre todo en cómo diseñarlos para que la iluminación precalculada quedara mejor. Pero hay muchas cosas que también son desconocidas para mí. Mejor así, porque de lo contrario no sería lo mismo jugar a Goldfinger 64. De hecho mis niveles ya sabía como jugarlos antes de crearlos y ya has visto que hay varias cosas importantes que se me han escapado.

Como sé que no abundan y la gente muchas veces pregunta por ellos (y no recuerdo si ya lo puse antes ) dos juegos poco conocidos en 2D de la N64:

Bomberman 64 (2001): Sólo salió en Japón y es un bomberman 2D clásico de toda la vida, con multijugador para 4, minijuegos, etc. Luce muy bien y tiene traducción al inglés. Aclarar que en Japón se llama igual que aquí la primera parte que recibimos del personaje para N64 (ellos lo recibieron con el nombre Baku Bomberman) por lo que para encontrar el juego en los buscadores en occidente de forma no oficial se le conoce como Bomberman 64 Arcade Edition. Os lo recomiendo encarecidamente a los que os mola el personaje y debatís mucho sobre que versión del juego es mejor que suele ser un enfrentamiento entre Saturn vs NeoGeo.


Wonder Project J2 (1996): Continuación de Wonder Project J de Snes. Juego de Enix y también exclusivo de Japón con traducción al inglés. Tengo que profundizar más, pero es una especie de aventura gráfica y al mismo tiempo un simulador de IA, esto último es complicado de explicar: El juego rompe la cuarta pared y la protagonista le habla directamente al jugador por tanto existe una comunicación directa entre nosotros y ella a través de un código que ella misma te explica.

Bangai-O: No creo que tenga explicar este juego que tiene ports para cien máquinas y es bastante famoso, sobre todo en Dreamcast. El juego también salió para N64, pero sólo en Japón y en este caso, no he encontrado traducción alguna; pero a base de aporrear botones yo aprendí como jugar partida.


A esto le sumamos los conocidos Rakuga Kids, Mischief Makers, Magical Tetris y Pokemon League Puzzle y vale que no es para tirar cohetes; pero da para mirar las posibilidades 2D de la máquina al menos.

Calculinho escribió:Wonder Project J2 (1996): Continuación de Wonder Project J de Snes. Juego de Enix y también exclusivo de Japón con traducción al inglés. Tengo que profundizar más, pero es una especie de aventura gráfica y al mismo tiempo un simulador de IA, esto último es complicado de explicar: El juego rompe la cuarta pared y la protagonista le habla directamente al jugador por tanto existe una comunicación directa entre nosotros y ella a través de un código que ella misma te explica.

Este juego es precioso y una joya, yo lo tuve de importación en su época (solo conservo el Sin & Punishment de mis juegos japos xD) y el Wonder Project J2 me maravilló. El problema es que tiene textos a porrillo y en perfecto japonés y no podía entender qué pasaba, pero vamos el juego tiene un apartado gráfico y artístico precioso.

@Falkiño pues como comento, ahora hay traducción al inglés. Y sí, tiene bastante texto porque es aventura gráfica-conversacional o algo así. Es muy raro explicar este juego creo D

Calculinho escribió:@Falkiño pues como comento, ahora hay traducción al inglés. Y sí, tiene bastante texto porque es aventura gráfica-conversacional o algo así. Es muy raro explicar este juego creo D

Leí en diagonal y no vi lo de traducción al inglés. Espero que sea cierto porque me acabas de provocar una erección y es un sueño que tengo desde niño de poder jugar a ese juego en un idioma cristiano; y si no lo es cargarás con las culpas en tu consciencia por ilusionarme

@BMBx64 sobre el tema ya tan mareado de cómo sería la N64 con lector de CD en vez de cartuchos tengo una pregunta. Los defensores del cartucho en pleno auge del formato CD argumentan que Nintendo acertó porque los tiempos de carga eran innegociables; pero en una N64 con expansion pak ¿Habría tanto problema con las cargas? N64 tiene el doble de ram que por lo que tengo entendido es importante para ir cargando por adelantado elementos y que el jugador no tenga que esperar.

Calculinho escribió:@BMBx64 sobre el tema ya tan mareado de cómo sería la N64 con lector de CD en vez de cartuchos tengo una pregunta. Los defensores del cartucho en pleno auge del formato CD argumentan que Nintendo acertó porque los tiempos de carga eran innegociables; pero en una N64 con expansion pak ¿Habría tanto problema con las cargas? N64 tiene el doble de ram que por lo que tengo entendido es importante para ir cargando por adelantado elementos y que el jugador no tenga que esperar.

No es por los tiempos de carga seguro-
Si tenemos en cuenta que super mario 64 solo tiene 8 megas reales no se cuanto tardaria la consola en recibir la info suficiente para gestionar un nivel. Siempre hablando que super mario 64 tiene 8 megas todo el juego.

diego777 escribió:

Calculinho escribió:@BMBx64 sobre el tema ya tan mareado de cómo sería la N64 con lector de CD en vez de cartuchos tengo una pregunta. Los defensores del cartucho en pleno auge del formato CD argumentan que Nintendo acertó porque los tiempos de carga eran innegociables; pero en una N64 con expansion pak ¿Habría tanto problema con las cargas? N64 tiene el doble de ram que por lo que tengo entendido es importante para ir cargando por adelantado elementos y que el jugador no tenga que esperar.

No es por los tiempos de carga seguro-
Si tenemos en cuenta que super mario 64 solo tiene 8 megas reales no se cuanto tardaria la consola en recibir la info suficiente para gestionar un nivel. Siempre hablando que super mario 64 tiene 8 megas todo el juego.

Pues a mi me suena que los datos de los cartuchos tenían compresión y estos se descomprimían en RAM,no sé si en el caso de mario 64 es así ,pero yo la tuve en su época y me suena que decían eso en las revistas.

Salud.

@dirtymagic por ejemplo Ocarina of Time tiene mini-tiempos de transición en que la pantalla se difumina en blanco cuando entras/sales de sitios como Kakariko Village, o Hyrule Market. En esos momentos es donde se realiza la descompresión.

Quake II directamente tenía tiempos de carga con barra de espera incluída, momentos en que efectivamente se estaban descomprimiendo datos.

Resident Evil 2 es el mayor hito de compresión de datos en el sistema, y aún así las escenas cgi y algunas músicas tienen peor calidad que en PlayStation.

@Calculinho teniendo en cuenta que Nintendo con la consola buscó minimizar al máximo los costes del hardware empezando por una c.p.u capada, una fuente de alimentación externa, o una salida de vídeo lamentable; de haber Incluído un lector de CD-Rom seguramente hubiese sido 2X igual que el de la competencia, por lo que el acceso a los datos hubiese sido tan farragoso como el de la PlayStation. Comercialmente a lo mejor le hubiese ido mejor, pero unos Zelda con tiempos de carga de 20 segundos con una barra menguante hubiesen perdido mucho feeling.

A posteriori me alegro mucho de que N64 sea un sistema de cartuchos: le da personalidad, rápida accesibilidad a los datos, posibilidad de "power-ups" tipo chips de apoyo alojados en la rom, y permite a la consola ser pequeñita, ligera, y fácilmente transportable.

La scene del sistema me parece de las más interesantes y con mayor potencial.

Lo del CD es complicado, por una parte podrías reproducir música sin tener que cargar los instrumentos en RAM o castigar a la CPU para que reproduzca algún formato comprimido en tiempo real, como el ogg.

Generalmente se recomienda usar RAW para las voces / canales (ej. forma de onda de 16bit, entero con signo en big endian sin cabecera ni nada, se lo entregas directamente al DAC sin pasos intermedios), lo cual no impide que comprimas a nivel de datos esos archivos en el cartucho y luego los descomprimas a RAM y ya de la RAM al DAC, camuflando en los fundidos a negro, etc

Para tener a la música cantando mientras le pides que lea otros datos necesitarías un buffer de datos, como N64 tiene RAM unificada le vendría bien eso, incluso podría pescar la información directamente desde el buffer y no andar copiando bloques de un lado para otro (aunque igual se castigaría todavía más a la ya lastrada RAM y le vendría bien un buffer externo para el CD).

Creo que los 8MB se usarían mucho mejor de tener CD, eso en los juegos que apenas hacen más que incrementar la resolución, en PSX se recortaron niveles o metieron tiempos de carga entre medio, N64 tiene más memoria y un pozo unificado para cualquier dato, como GC tiene el suyo de 16MB, solo que aquí la RAM sería la principal.

Los tiempos de carga son una mezcla, en N64 los hay en algunos juegos porque usan compresión, pero si el mundo es complejo y tiene que procesarlo entero para darte las coordenadas finales de todos sus objetos, situarte en la sala, etc lo va a tener igual (en Goldeneye varían los tiempos de carga dependiendo del tamaño del mapa y número de objetos), esto también pasa en PSX, no es solo culpa del CD, pero N64 tiene una CPU más rápida para procesar toda esa información, yo creo que veríamos tiempos de carga pero no tan largos o molestos.

A mi me gusta la fuente externa de N64, ni dentro ni fuera, fácil de cambiar en caso de que se estropee y no es un tocho colgando donde los cables

@BMBx64 ¿le ves algún sentido y/o utilidad a implementar chips de apoyo de cualquier tipo en los cartuchos de N64?

¿Se te ocurre algún uso original y práctico?

@Sexy MotherFucker
Una antena wifi para online o un decompresor de datos para acelerar cargas o darle la información directamente en el formato de la consola, ya reproduzco ogg en streaming desde el cartucho, pero no quiero que esa información que llega en bloques tenga que ser transformada por la CPU, si ya viniera lista para enviarla al DAC mejor.

No sé, aún no me he estudiado la interfaz del cartucho y todas sus limitaciones.

.

@Calculinho gracias amigo

Hay que ESTUDIARLO.

Hoy le ha tocado el turno de nuevo a Hydro Thunder y buscando diferencias entre versiones (las cuales a nivel contenido no he encontrado por si alguien quiere aportar algo) he visto este vídeo sobre gráficos del juego en PSX-N64-DC en consola original. Los resultados son los esperados, la de PSX es la que peor luce al notarse bastante el pixelado aunque tiene pinta de funcionar fluidamente, el de N64 es bastante mejor y creo que se acerca bastante a la de DC para ser una consola menos potente.

Dicho esto a modo de introducción, me he dado cuenta de una cosa en la que gana la de PSX que me parece curiosa y es que en los saltos grandes al caer, el agua en las versiones de N64 y DC al intentar jugar con el efecto reflejo literalmente se convierte en un espejo; pero el efecto es chungo porque parece que caes al vacío sin saber cuando tocarás "suelo", en la de PSX hay reflejo, pero será por el "ensuciado" pixelado se ve donde caes. En el vídeo dejo un momento donde va mostrando una caída en las tres versiones:
https://youtu.be/F05QxlNWGGk?t=5m6s

En el resto del vídeo hay más saltos, por si queréis buscarlos.

Hay algo muy raro en ese vídeo.

Recordaba del Hydrothunder que es un juego que tenía un look muy PS1 en N64 por usar colores muy vivos, dientes de sierra muy evidentes y un framerate muy fluido que parece que a veces supera los 30 fps (Otro ejemplo sería el SCARS). Sin embargo en ese video se ve la versión de N64 muy apagado, y lo que es peor, es leeeeenta. Un rápido vistazo al contador de segundos nos hace ver que las partes de N64 están ralentizadas. Quizás porque realmente el juego va a más de 30 fps y al realizar el vídeo se muestran todos los frames a 30 imágenes por segundo. Otra cosa que no se aprecia en el vídeo es que seguramente la versión de Dreamcast funciona a 60 fps como rocas. Por cierto, que la versión de PS1 sufre un tearing brutal y muy molesto que, combinado con un bajo framerate, hace daño a la vista (no sé si será cosa del vídeo o es que el juego realmente es así).

He encontrado otro vídeo en el que se compara la versión de PS1 emulada en PS3, con la versión de PS2 (que según parece es igual que la de la Dremcast, aunqué quizás a menor resolución) y la de N64 y también está ralentizada. Voy a tener que jugar al juego para comprobarlo.

Dejo otro vídeo donde se ve lo que yo recuerdo, pero que al estar capado a 30 fps no se pueden apreciar las partes que digo que parece que supera esa tasa. Ya digo, jugaré un poco y editaré con las impresiones.

EDIT: Pues a mí también me va el contador de tiempo ralentizado jugando en un Everdrive PAL con la rom NTSC, me pregunto si está relacionado aunque no he tenido este problema con ningún otro juego. En emulador corre a la velocidad correcta, y funciona entre 25 y 30 fps según Glide64...

Se que hay una versión de pc, pero no he podido dar videos de calidad, de lo que se, es que es mas superior que la de ps1

Ya se extrañan los post informativos de @BMBx64

Han liberado una beta del The World is not Enough. No conozco mucho del juego así que no sé los cambios que ha habido. En el enlace hay imágenes:

https://www.obscuregamers.com/threads/the-world-is-not-enough-twine-beta.22674/

He estado probando la beta del TWINE

Quizás lo más interesante es el menú debug que trae, por fin se pueden desbloquear todos los niveles libremente, también tenemos contador de fps y el poder usar todas las armas, aunque no hay muchas para elegir en este build, los misiles por otra parte pueden bloquear la consola, yo creo que merece la pena tenerla, he notado bastantes cambios y eso que no me conozco demasiado el juego.


El contador de fps es interesante, el juego corre a 30fps y generalmente lo consigue en muchas zonas salvo que el escenario sea abierto.


El modo hi-color supone una limpieza de pantalla, a costa de 6fps de perdida de rendimiento, el juego va limitado de fillrate como la mayoría de juegos de N64, existe un modo hi-res que no sé exactamente que hace, se ve como el modo low-res pero consume los fps del hi-color, quizás solo sea alguna clase de escalado, no es de extrañar que ese invento raro lo sacaran o no me parezca recordarlo en la versión final.


El juego usa triple buffering, no va pegando saltos tan bruscos de frame en comparación con el double buffer y en general es bastante suave, habría que averiguar si esto pasa al usar Expansion pak o sin ella, si jugamos en low-res lo más probable son cifras entre 20-30fps, en hi-color le descontamos 6fps a ese cálculo.


Vale, este escenario quería verlo en consola, algo horrible del modo low-res es que por alguna razón usan random filter, si dejas el mando y miras la imagen verás puntos aleatorios semitransparentes por toda la pantalla, no sé que sentido tiene esto salvo que piensen que estamos cerca del pueblo de Silent Hill.


--
He estado hablando con Krom sobre la idea que tenemos de hacer una librería libre y hay algunas novedades.

Por ejemplo ha conseguido procesar 8 triángulos por ciclo usando la VU dentro del RSP, resulta que libultra también hace uso de la VU pero no usa toda su capacidad, en el caso de libultra son 2 triángulos por ciclo y cálculo libre para otras tareas, por ejemplo Factor5 usa cálculo en la VU para sus librerías de sonido (MusyX).

El test escrito en ASM sobre los 8 triángulos por ciclo puede encontrar aquí.
https://github.com/PeterLemon/N64/tree/master/RSP/XBUS

Algo a destacar es que es un test usando XBUS, que es esto?

Para mandar comandos al RDP se puede hacer de 2 maneras, los escribes en una región de la RAM y el RDP lee de ahí, como hace ahora mismo la libdragon o el RSP se lo pasa directamente al RDP, ambos están en el mismo chip, por un bus mucho más rápido, así que este es otro terreno donde se ganará velocidad en la librería final que usemos.

Otro detalle, dado que la CPU de N64 tiene una FPU en realidad ya se podría hacer 3D con ella, saltándose completamente el RSP y pasando los cálculos directamente al RDP, aunque dado que los 3 chips pueden trabajar en paralelo estaríamos perdiendo mucho potencial.

Algo importante es que la maquina tiene potencia de cálculo de sobras, pero donde falla es en el fillrate, esta imagen es un ejemplo de lo que pasa en muchos juegos, he grabado un pequeño gif donde miro a una pared y luego giro la cámara hacia la derecha, igual no se ve muy suave en el gif, pero donde la consola sufre es mirando a la pared y no a partes más complejas del escenario.


A partir de la palmera y brillo de sol son 30fps constantes, lo cierto es que parece que muchos engines antiguos no eliminan las zonas tapadas por polígonos más grandes, por ejemplo esa pared gigante debería evitar que se procesara lo que hay detrás, como se ve, el barco, la montaña y casi que todo el resto del nivel.


Así que la idea sería crear engine que pintara de dentro hacia fuera, en orden de textura y que detecte cuando un polígono es lo suficientemente grande como para que valga la pena analizar toda esa zona para descartar pintado o incluso transformaciones.

BMBx64 escribió:Por ejemplo ha conseguido procesar 8 triángulos por ciclo usando la VU dentro del RSP

Pero planos, ¿no?.

¿Eso no son 4 veces mas polígonos que lo que vemos comúnmente en los juegos del catálogo?, es que si es así hablamos de muchos cientos de miles de ellos... supongo que no llegará a tanto por lo que comentas del fill rate con las texturas...

@Señor Ventura
Según entendí trabajará con 8 a la vez indistintamente, con valores válidos para activar la corrección de perspectiva, hay pasos previos donde el RSP o la CPU trabajan en la proyección de la escena y pasos posteriores por decidir, si se encargará el z-buffer o habrá un display list manual.

Si le entregas antes la información al rasterizador mejor, pero de por sí no es una multiplicación de rendimiento, si éste hace cuello de botella solo le darás algo más de tiempo, lo suyo es crear un engine que sea lo más limpio posible enviándole superficies, le restas tiempo al RSP o la CPU, pero igual ese tiempo es mucho menor en comparación con lo que tarda el RDP cuando se le acumula la faena.

BMBx64 escribió:@Señor Ventura
Según entendí trabajará con 8 a la vez indistintamente, con valores válidos para activar la corrección de perspectiva, hay pasos previos donde el RSP o la CPU trabajan en la proyección de la escena y pasos posteriores por decidir, si se encargará el z-buffer o habrá un display list manual.

Si le entregas antes la información al rasterizador mejor, pero de por sí no es una multiplicación de rendimiento, si éste hace cuello de botella solo le darás algo más de tiempo, lo suyo es crear un engine que sea lo más limpio posible enviándole superficies, le restas tiempo al RSP o la CPU, pero igual ese tiempo es mucho menor en comparación con lo que tarda el RDP cuando se le acumula la faena.

Si, a eso me refería. Al menos de esta forma te aseguras de que el cuello de botella nunca será la geometría, y a partir de ahí ir avanzando a otras partes del hardware hasta que no sea posible optimizar mas.

Una forma de acelerar la texturización no se si sería posible en todo caso... 8 polígonos texturizados por ciclo, aunque sea sin z buffer (para ir empezando), me parecería una tremenda burrada para una máquina de esa generación. Ignoro a que equivaldría eso porque desconozco cual es la cifra total de ciclos de proceso, pero aunque no sea realista... joder que me gusta emocionarme xDD

DITHER
Estaba haciendo una recreación día/noche y al ver el cielo he pensado que quedaría mejor con tramados.

Así que vamos a añadir nuevas funciones:
rdp_rgb_dither(num);
rdp_alpha_dither(num);

Cada una tiene 4 configuraciones dentro del chip, en el caso de RGB DITHER:
0 - Dither pensado para usar en conjunto con filtro.
1 - Dither estándar, para usar sin filtro.
2 - Dither aleatorio, agh.
3 - Desactivado.

Como no tengo pensado usar filtros vamos a ver el estándar..


Pues.. no es lo que esperaba, trabaja sobre toda la superficie, sean del mismo color o no.


Algo así hubiera estado genial para no tener que hacerlo manualmente:


Vamos a revisar el random dither, pero solo aplicándolo al cielo, igual eso da sensación de viveza o algo.. oye pues el granulado no queda tan mal si se aplica selectivamente, se pueden hacer cosas vistosas.


Al final el ciclo ha quedado más corto


Para conseguir tonos naranjas tendría que haber usado blanco/negro, modificando tan solo la escala RGB limita al color fuente de la textura, así que en este caso la transición a tarde no hubiera funcionado demasiado bien.

Volveré a esto cuando ya exista un motor 3D, en 2D puede que muchas cosas sean distintas y el código no valga después.