Jump to content
  • Buscar en
    • Más opciones...
    Encontrar resultados que contengan...
    Encontrar resultados en...

xarmanista

vida restante: 100%
  • Contenido

    27.508
  • Ingreso

  • Última visita

Reputación comunidad

4.093 Excellent

4 Seguidores

Acerca de xarmanista

  • Rango
    Stinger

Visitantes recientes al perfil

El bloque de visitantes reciente está desactivado y no se está mostrando a otros usuarios.

  1. Ya te lo he dicho, pero lo repetiré: métete en ajustes/controladores/menu Hay 4 para elegir. Pruébalos. No es ningún frontend modificado ni he añadido ningún mod. es el retroarch estándar y tiene ozone desde hace mil millones de años.
  2. por alguna razón no se captura el contenido del frame derecho. el caso es que para este sistema de menús más normal, sólo hay que trastear los ajustes de Controladores/Menu. Hay 4 a elegir. el que he puesto también se controla con mando además de ratón o teclado.
  3. lo serán. la tecnología de psvr data de 2014 con el oculus dk2 de 1 sola cámara, salió obsoleta de salida en 2016 frente al tracking de htc vive y oculus rift del mismo año. rift usaba 3 cámaras por la habitación y te veía en 360 grados. ahora se usan cámaras en el visor, por lo que te mueves libremente sin sensores externos, en vez de atarte a lo que ve tu ps camera. los visores pico neo usan mandos magnéticos, no dan problemas de oclusión ni se limitan al fov de las cámaras del visor. parece que sony, que fabrica cámaras y le cuestan 2 duros, va a meter cámaras a los mandos además de al nuevo visor, por lo que tampoco habría problemas de tracking con los mandos ni siquiera usándolos con psvr 1. creo que abajo a la derecha ese "ojo" representa una cámara. hacerlo así permitiría que los usuarios de psvr 1 se compren estos mandos y consigan este tracking, sin depender de ps camera, que sería sólo para el visor. dado que sony fabrica cámaras no le resultaría más barato usar en su lugar el sistema magnético de pico.
  4. Se me olvidó añadir que además haciendo streaming por app, la pantalla de la consola puede funcionar como el mando de wii u, por lo que el modo sobremesa sería imitando a la wii u. -modo wii u por app en smart tv/chromecast/firestick/receptor de nintendo vendido por separado. Para vender más receptores podrían salir juegos de switch lite que lo soporten. -modo portátil -accesorio gear vr sin mando (desacoplas los de la consola), evolución del de cartón con tecnología punta de 2013 (3dof oculus dk1, metido en gear vr de 2015 para el móvil galaxy)
  5. Coño, ya decía yo que era muy raro que últimamente todos los sticks de todas las consolas derrapaban Me pasó hace años con un ds4 v1, ahora con el v2, le pasa a switch, a dual sense... Espera, en mi mando de one v1 lo que falla es la cruceta. ¿? No me han derrapado nunca los de xbox
  6. Para la próxima espero streaming via app en tv/chromecast/firestick por wifi 5 (estos no meten wifi 6 ni de coña) Esto debería tenerlo la lite para no romper con la anterior, pero bueno, es nintendo, lo suyo es la cutrez El tegra de switch creo que se hizo en 20 nm en vez de los 14 habituales con ese chip, seguro para ahorrarse 2 céntimos por consola a costa de capar frecuencias. En la próxima me espero el estreno de tegra derivado de la arquitectura de rtx 3.000 o 4.000 a 7 nm en móviles y a "8" (10 ) de samsung, el nodo actual de las rtx 3.000 (peor que el de rdna2 de tsmc de 7 nm) Lo de nuevas formas de entretenimiento podría ser que al subir a full hd tuviera un accesorio de realidad virtual de plástico en vez de cartón estilo gear vr, desacoplando los mandos como en switch 1 para la rv. El de cartón fue un globo sonda y practicar los de desarrollo de juegos. El de 2017 con mando a 60$, ergo nintendo a 80€ sin mando en 2022 Y seguro que 3dof com oculus dk1 de 2013, eso es sólo rotación del visor y mandos. Barato y sin moverte de la silla giratoria. Y mareandote al cambiar de postura no moviéndose en consecuencia la imagen. Y sin las optimizaciones de software de oculus y john carmack como asw2 y patw, y me sorprendería si usaran atw aunque sea, estos meten el timewarp básico y se felicitan entre ellos.
  7. Dime un sólo juego que use AVX 256, que no existía en amd hasta el ryzen 2.
  8. Bueno, la arquitectura power vr estrenada en Dreamcast es que es la polla, es en la que se basan los móviles, sobre todo las gpus de iphone e ipad Por eso casi todos los juegos de DC van a 6480x480 y eso era anecdótico en ps2 y gc, permite altas resoluciones con mínimo ancho de banda El blitter de Atari y similares permitía manipular pedazos de imagen además de sprites, evitando necesitar un framebuffer de pantalla completa que requiere mucho más ancho de banda y vram. Supongo que el blitter es el antecesor de power vr y el caso de saturn, 3do y s3 virge sería algo intermedio, quizás, pero muy chapucero. Gracias al poco ancho de banda que necesita una arquitectura tile renderer, el iPad 3 de 2011 movía los mismos juegos de 2010 a 4x la misma resolución en cuanto cuadruplicaron la de la pantalla, nada menos que 2560x1440 en juegos en 2011. Amd y nvidia se acercan poco a poco a ello usando tiles en la L2 de la GPU. NVIDIA desde maxwell, AMD con rdna 2. Es transparente a los programadores. Pero están empezando y les queda mucho.
  9. Lo que digo es que no partieron de cero, es materialmente imposible por tamaño del equipo, tiempo y coste. Reunirían piezas de código open source y construirían desde ahí Hoy en día probablemente llamen a eso "desde 0" cuando quieren decir que no han licenciado un motor completo como unity o unreal. Dado el buen rendimiento no me extrañaría nada que para la parte gráfica hubieran partido de quake 3 o doom 3 en versión multinúcleo y tras adaptarlos a directx 11. Lo de simulación en sí probablemente sí sea casi desde 0. Lo de modear es 100% sello de id software, desde doom están hechos para modear fácilmente. Pues blanco y en botella
  10. Cuando leí sobre el funcionamiento de thief (x software), el programador lo comparó con quake. Al parecer quake usaba el algoritmo del pintor, de cerca a lejos, lo que permite ahorrar recursos evitando pintar objetos que van a quedar tapados, mientras que thief pintaba de lejos a cerca Imagino que lo de saturn, 3do y s3 virge era lo mismo: no sólo se perdía rendimiento al hacer transparencias, también se impedía el algoritmo del pintor que era más eficiente porque aportaba culling Ese culling luego mejoró más en quake 2 con zbuffer, pero los requisitos mínimos eran mayores Leyendo sobre el motor de q2, Carmack logró "zero overdraw", teóricamente no pintaba absolutamente nada que no fuera visible (y era por todas sus características combinadas, no por el zbuffer)
  11. si he entendido bien, lo que hacía saturn era tener primero las texturas listas y luego mirar dónde había que colocarlas. y todo el resto del hardware primero se topa con un sitio donde hay que texturizar, y busca la textura correspondiente.
  12. un equipo pequeño no puede parir "desde 0" ese mostrenco gráfico así por las buenas y en tan poco tiempo. se tienen que haber basado en código open source, bibliotecas, apis, sdk... por ejemplo alguno de los motores de id software. si no, sería reescribir y reinventar la rueda desde décadas atrás. trabajo de chinos. como muestra están los cutrejuegos de linux de tercera división, hechos con material open source por equipos pequeños. son muy cutres a pesar de que no empiezan desde 0. se libran de la cutrez sólo los que llevan muchos años de desarrollo, los que son poco más que mods de juegos open source (como los de id) y los indies 2d. me viene a la cabeza el open arena, casi un mod de quake 3. todas las empresas que tienen motores propios llevan reciclando piezas desde que empezaron o licenciaron su primer motor (y en muchos casos hay restos de id software) modificando sólo lo que se necesita.
  13. eso era ahorrar costes (junto a usar lo más pequeño y cutre que pudieran), las apus son diferentes, están optimizadas, diseñadas para bajar latencias y cosas así. he revisado las fechas, el mos no es del 73, eso era la primera cpu completa de intel de 8 bits. es del 75. el z80 del 76, y sí, era muy superior al mos. mejores instrucciones y podía funcionar en modo 16 bits usando un segundo conjunto de registros, para malgastar menos ciclos. no es lo mismo que una cpu 16 bits "nativa", era un apaño. la cpu de snes deriva del mos para ports fáciles desde nes. es raro que en game boy usaran un derivado de intel que no llega ni a z80, para eso que usaran un mos y también portearían desde el código que tuvieran en nes. y la consola salió 2 años antes que snes, tendría mas sentido hacerlo ahí que en snes. el mos derivaba de motorola.
  • Crear nuevo...