BdM escribió:user2000 escribió:Cuando dicen que van a hacer un juego sobre un tema, además de analizar muchos factores (económicos, etc...), la idea de la jugabilidad sobre el papel puede ser muy buena y sobre la práctica ser muy mala. Entonces para no invertir un dineral durante X años de desarrollo se hace (o deberían haber hecho) un prototipo de poco tiempo en el que dejarse la menor pasta posible (y con menos programadores y artistas) y comprobar si el proyecto tiene futuro; ese prototipo no tiene porque ser en la máquina destino. Si mola y pinta bien, entonces se continua/empieza el desarrollo del producto gastándose más recursos (pasta y gente) desde el 2006 hasta el 2008 que es cuando salió y suponiendo que el juego no va a ser desastroso; que oye siempre puede ser una caca aún así, pero con eso te cubres algo las espaldas cuando te pidan cuentas los que han puesto el dinero.
Sí, esto es una hipótesis, pero muy cabal y convincente creo yo.
No creo que vayan a hacer un prototipo al nivel técnico de los mejores títulos de xbox si precisamente lo hacen en xbox porqué quieren ahorrar tiempo
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
. Y sinceramente, siendo 360 de 2005 los primeros sdk's deben estar disponibles desde la mitad/finales de 2004, por lo que precisamente tampoco creo que les faltara dominio y experiencia de los mismos, y más siendo ea
e incluso en la propia descripción de youtube pone que el evento en el que se muestra el vídeo es de 2009.
Creo que es bastante más cabal y convincente pensar que los que han colgao el video se han equivocado o es un fake.
Ahorrar tiempo, es ahorrar pasta porque el tiempo de los trabajadores es pasta y yo te estoy hablando de un prototipo para probar las ideas a nivel jugable y ver que el proyecto tiene futuro para seguir desarrollando desde el prototipo o desde cero en la máquina final (en Xbox360 se presupone que podrás tener mejores efectos/ambientación que en Xbox 1). Este prototipo indudablemente incluye usar efectos técnicos pero no de perfeccionarlos o alcanzar el excelente nivel técnico que tiene el producto final, porque para eso hay que emplear más tiempo y recursos; y no merece la pena invertir tiempo y dinero en algo que no va a dar finalmente la talla. Y bueno, a partir de ahí no sigo porque tu intento de rebatir mi razonamiento parte de algo que no he dicho (tú de nivel técnico y yo jugable).
Sobre si es falso o no, yo creo que no porque en el video comenta el que habla lo de la Xbox 1, etc y además la conferencia o charla es del Animex 2009 (primeros de febrero de este año) y puedes ver que la charla está indicada a las 11.30 en
http://animex.tees.ac.uk/events_game_schedule2.cfm coincidiendo con la descripción de Youtube en el autor y nombre de la charla.
Y que tendrá que ver que sea del 2009 para que el video sea más antiguo, y aunque no fuese antiguo podría haberlo generado el video este año 2009 para la charla usando el prototipo creado antes del 2009. Si yo grabo este año 2009 un video del Super Mario Bros. de Nes y lo subo, eso no implica que el juego fuese creado hace poco aunque el video si lo sea.
Rebate mis argumentos, pero si lo haces no lo hagas intentando justificar los tuyos sino dando una posibilidad de porque los míos pueden estar equivocados aunque ni los tuyos ni los míos sean verdaderos.
BdM escribió:Ruby Gloom escribió:Uno cosa que se me había olvidado, Wii supongo que se programa igual que Gamecube, y esta era la que más fácil se le sacaba el máximo rendimiento; según Retro, una vez habías llegado al límite de la consola, poco más podías hacer, por todo era tan fácil, que no dejaba lugar a probar cosas nuevas, como pasaba con PS2; así que yo no esperaría cosas mágicas de esas con las que sueña más de uno por aquí.
Imagino que se referirían al desarrollo usando los kits estándar de gekko y flipper. Meterte en tev's es otra cosa. De hecho recuerdo una entrevista con los tíos de factor 5 sobre se lo montaron y lo hacían todo con su propio código hecho desde cero en plan control total, desde los datos que metían en cada buffer, pasando por utilización de buses y todos los cálculos en cada componente para mejorar la concurrencia de todo el proceso.
Para decir esto, por lo menos dí que lo haces a grosso modo para que la mayoría de la gente que no lo interesa el funcionamiento hardware o no sabe nada de arquitecturas de computadores lo entienda, porque dices cada barbaridad que tela.
El acceso a más bajo nivel para ejecutar instrucciones máquina en Gekko (CPU) y Flipper (GPU) en software (programación) se hace normalmente a través de ensamblador. Y lo normal es que Nintendo ofrezca herramientas que encapsulen en una capa o más capas de mayor nivel (lenguaje C u otros) esas instrucciones máquina y además permita ejecutar instrucciones en la capa más baja posible (ejemplo ensamblador) para mayor rendimiento posible; lógicamente yo también estoy saltándome muchos aspectos para que cualquier purista no me de un toque de atención.
Los tev's son registros/unidades fijas de muy alto rendimiento propios de la GPU (Flipper) que operan con datos 'gráficos' (en el fondo todo es lo mismo), y no son otra cosa independiente como indicas; el problema de estos a la hora de utilizarlos es que no son como los shaders, es decir, no son programables a alto nivel. Los shaders dicho de forma basta vienen a ser como operadores que permiten manipular los datos/pixeles que se muestran en pantalla para crear cualquier efecto gráfico 'general' (hay diferentes versiones de shaders porque hay limitaciones en el número y complejidad de operaciones a ejecutar en las primeras versiones...), y a gran velocidad de ejecución.
Es como lo que una CPU puede hacer, que puede hacer casi cualquier tarea, pero al permitir hacer cualquier tarea no puedes optimizar para todos los usos posibles, porque es imposible, por ello pierdes velocidad en tareas concretas pero ganando en variedad de tareas; por ejemplo un reproductor MP3 no necesita una CPU compleja, porque como normalmente sólo se dedica a reproducir MP3s puedes centrarte y utilizar los mínimos elementos hardware necesarios, y con bastante mucha menos potencia que una CPU.
Bueno, pues como decía los TEVs, salvo funciones preprogramadas de Nintendo habrá que programarlos en ensamblador, lo cual implica un buen conocimiento (a gran nivel) del hardware de la máquina, cosa que puede parecer simple pero requiere su experiencia; porque normalmente el uso de un SDK te intentará evitar pensar en ello, a costa a veces de mermar un poquito la optimización aunque se supone que los SDK ejecutan las funciones que ofrecen de la forma más optima que da la máquina, pero como un SDK se ofrece para programar cualquier juego/cosa, es imposible ser óptimo para tal cantidad de posibilidades.
Lo de los buffers me ha matado, porque es un concepto muy genérico o abstracto, que vale tanto a nivel hardware o software. En hardware, un valor temporal que almacenas estará en una memoria RAM, banco de registros, memoria cache, disco duro... y atemporal en una ROM o algo parecido.
Y lo de los buses también porque parece que quieres decir que el programador puede elegir que bus usar, y salvo que no sea una arquitectura muy avanzada que no es el caso, lo dudo porque es una cosa que es muy estricta. Vamos que un bus es el camino que une dos o más elementos hardware (CPU con GPU) para enviar/recibir datos y están determinados por el ancho de datos (número), velocidad de transmisión de los mismos y/o forma de transmisión (serie, paralelo...).
A nivel hardware (dicha de forma ortodoxa) la concurrencia es que todos los elementos hardware estén ejecutando a la vez siempre operaciones sobre datos que pueden ser utilizados o útiles, y es uno de los ideales de la informática que no se da siempre. Porque si yo tengo varios núcleos en una CPU (o datos de la CPU a enviar a la GPU) y quiero que cuando necesite obtener resultados, se den de la forma más rápida posible, pero si uno de los núcleos está realizando un cálculo que necesita el otro núcleo, hasta que el primero no lo calcule no puedo operar con él, sin embargo seguramente haya luego que hacer más operaciones y entonces ese segundo núcleo que está esperando ese cálculo, en vez de no hacer nada, puede mientras realizar otra operación que no sea dependiente en ese instante y así aprovechar el hardware y no perder tiempo... pero este tema es complejo y dificil de explicar así a primeras...
PD: Esto es para que la gente intente darse cuenta cuando habla de los muchos factores que influyen en el desarrollo de un juego, que el jugador no tiene porque conocer cuando se queja con razón pero que a veces influyen algo, y por supuesto no va/trata de lo guay que soy por lo que he dicho, que puedo estar equivocado seguramente. Y lo siento por las patadas técnicas y errores de ortografia, semántca y gramática.
![[bye]](/images/smilies/nuevos2/adio.gif "adios")
porque no juzgo nada "de forma totalitaria" hasta que no lo pruebo, no sería el primer juego con malos gráficos y un desarrollo divertido o inmersivo como fue el disaster o como está siendo el House of Dead: Overkill que sin tener buenos gráficos está dejando "corridos" a todos los que lo meten en su wii.![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[flipa]](/images/smilies/nuevos2/flipando.gif "flipando")
![[tadoramo]](/images/smilies/adora.gif "Adorando")
