Cada vez se programa peor?

Buenas, primero antes de todo, quiero decir algo

Como programador, entiendo la larga, y dificil tarea de programar y crear algo. No es facil, y me quito el sombrero ante todos aquellos que programan dia a dia, para hacer un juego, un emulador, un plugin...etc mis respetos


Dicho esto, no les parece que cada dia se programa peor? da la sensacion que la optimizacion es cosa del pasado, y muy pocos respetan esa sagrada tarea, antes tan obligatoria

Puede ser que los MHZ esten matando la buena programacion? creo que si, hace que los programadores se olviden de que existe gente que no tiene un C2D a 3ghz? seguro

Me gustaria señalar por ejemplo los emuladores. Aqui no tenemos que quejarnos de nada, todo lo contrario. Hay alguien que destina su PROPIO tiempo en programar un emulador de forma gratuita, para que todos disfrutemos

Pero que pasa con las optimizaciones? que pasa con el buen programar? que pasa con las opciones de core, tweaks, speedhacks... etc que antes existian??


Por ejemplo, tenemos el Kega Fusion, es increible, en el Pentium 3 M a 800mhz del portatil q tengo, corro 32x a sin frameskip, y usando el filtro simple4x+reescalado!!!!

Y luego tenemos el emulador TurboEngine, que emula la PCengine, usa los mismos plugins que el Kega Fusion... usando el filtro simple4x+reescalado, apenas llego a los 8fps.... y emulando un simple juego de PCengine como el bomberman!!!

O el snes9x, usando el filtro simple4x+reescalado, apenas llego a los 35fps, que le paso al snes9x?

O el mess!!! dios santo, me lo baje.. configure correctamente... y si logre sacarle 5fps al core de snes fue de milagro...



No se, me da que cada vez se optimiza menos, y ya ni siquiera se presta atencion en que el codigo sea limpio. que opinan?
Pues eso es muy cierto, hay muchos programas que requieren unos requisitos que realmente pueden ser bastante menos.
Ya que hablamos de emus, menciono que esto se podía comprobar hace unos años con el emulador Project 64, la versión 1.7 requería más de la gráfica que la 1.6, teniendo una variación de fps bastante notable.
También supongo que las empresas esto lo hacen con razón de marketing, para que la gente cambie antes de ordenador, o en otros casos, un componente, sin tener por que hacerlo, ya que como bien dices se puede optimizar el código.
El problema ya no solo es "la programacion" pues antes casi todo era desde cero y dirigido a maquinas con hard determinado. A dia de hoy casi siempre se tira de librerias y/o motores y tanto en ordenadores como dispositivos moviles, por mucho que digan que se esta estandarizando, es un baile de cifras en relacion al hardware que marea...

No es lo mismo tener control absoluto sobre lo que haces y poder probar, testear, optimizar, etc.. que ya partir de una base como es un motor grafico, motor que ya no vas a poder tocar y que los bugs y limitaciones que tengan iran de serie desde el minuto cero en tu juego. Tambien hay que tener en cuenta que comenzar desde cero supone tiempo y el tiempo como se sabe es dinero y no todo el mundo se puede permitir estar mucho tiempo perdiendo dinero (se puede ver como inversion de futuro pero es ser muy optimista).

En relacion al baile de hardware, no es lo mismo programar para nes y punto o snes y snes solamente o ps2, 360,.. estamos hablando de programar en exclusiva para dicha plataforma (ya no hablo de ports que eso es otra historia y depende del presupuesto y tiempo y calidad del estudio...) y se sabe con que especificaciones se cuentan y esas no van a cambiar, eso es una gran ventaja pero en tema pc o mobiles esto es matador..lo que pruebas en un movil puede ir de perlas y de repente en otro de similar "potencia" va como el culo...porque? implementacion de opengl especialita, velocidad de la ram, que si la abuela fuma,...

Luego hay que pensar en que por norma un juegazo de hoy en dia es muuuucho mas complejo que uno de hace años. Los standares de calidad son muy altos a dia de hoy...otra cosa que salgan juegos que aburran a un muerto y mierdas por doquier pero los juegazos de hoy en dia tienen un acabado de impresion. El ocarina es para mi un juegazo pero el TP es impresionante lo pulido que esta, el metal gear original es otro juegazo del copon pero ves el metal 4 (y aunque duerma a las vacas) y te das cuenta de que ese juego es algo mas...un poquito...complejo que el original y que esta cuidado hasta el minimo detalle. Luego tema fisicas y graficos estan a un mundo de lo que vimos en el comienzo de las 3d.

Al final, como siempre, hay de todo, juegos optimizados y con trucos por todos lados (pero que quedan bien y cumplen su labor) que te hacen quitarte el sombrero (shadow of colossus en ps2, zelda TP en la gc, re4 en gc, doom3 en xbox, heavy rain en ps3,...) y que nadie podria decir que no estan optimizados y que menuda mierda de curro se ha hecho PERO luego tienes otros juegos que piensas a ver en que gastaron el tiempo no solo los programadores sino grafistas y todo el equipo, porque ese plaston no se lo explica nadie.

El hecho de programar en C o Ensamblador no conlleva hacer un juego mas optimizado, a dia de hoy los compiladores estan tan bien desarrollados, en su mayoria, que el codigo resultante y la velocidad de ejecucion es igual o superior al mismo codigo en asm. Ademas el tiempo, la dificultad y facilidad de resolucion de errores de hacer uso de asm a otro lenguaje de mas alto nivel...no comment.

Tochito inside [+risas]

Edit: En relacion a emulacion...no tengo mucha idea pues nunca he programado nada similar pero la base es que para emular x plataforma en y plataforma se necesita que la velocidad y sea igual a x * 2...3...4. En muchos emuladores antiguos se usaban muchos trucos y "atajos" para conseguir resultados realistas pero se supone que la meta de la emulacion es conseguir correr por soft un sistema de la forma mas realista posible y claro esta cuanto mas te quieras aproximar a ese realismo mas maquina se pedira. Pero la verdad de este tema poco puedo decir mas de estas lineas.
Resulta q quiero un emu de snes que corra bien en mi Pentium 3 M a 800mhz, con reescalado simple4x, llevo provados varios sin buenos resultados.

Justo ahora mismo, estoy probando el bsnes y me encuentro que no puedo usar filtros, porque mi grafica no tiene soporte de pixel shader...

Es gracioso, el portatil tiene una grafica GMA 915, y otros emus, como el Kega Fusion, Fburn..etc, usan filtros tan avanzados como los del bsnes, y van de maravilla

No critico el bsnes, ni al autor, pero alguien programa lo mismo para que necesite un Pentium III 800 y una grafica de mierda, y para exactamente lo mismo, otro pide una Geforce 9500 minimo.... :-?


No entiendo
A dia de hoy los emuladores tiraran de opengl para el dibujado y los efectos o filtros iran mediante shaders aplicados a la imagen durante el proceso de renderizado por lo que si la tarjeta no soporta ... mal pero no es culpa del programador, el se centra en el hardware actual, es como que un juego basado en directx antiguos que tire de direct draw no tiene porque ir ahora o que juegos antiguos preparados para cierta tarjeta de sonido funcione el juego pero no el sonido y haya que andar usando programas para solucionarlo.

Tambien tener en cuenta que un emulador es algo por norma no oficial y la calidad y optimizaciones, ideas y sistemas de cada uno es un mundo...
theelf escribió:Resulta q quiero un emu de snes que corra bien en mi Pentium 3 M a 800mhz, con reescalado simple4x, llevo provados varios sin buenos resultados.

Justo ahora mismo, estoy probando el bsnes y me encuentro que no puedo usar filtros, porque mi grafica no tiene soporte de pixel shader...

Es gracioso, el portatil tiene una grafica GMA 915, y otros emus, como el Kega Fusion, Fburn..etc, usan filtros tan avanzados como los del bsnes, y van de maravilla

No critico el bsnes, ni al autor, pero alguien programa lo mismo para que necesite un Pentium III 800 y una grafica de mierda, y para exactamente lo mismo, otro pide una Geforce 9500 minimo.... :-?


No entiendo

¿Has probado a usar versiones anteriores del emu que va bien?
Se que suena a tontería, pero a veces funciona, como dije en mi post de antes.
¿Has probado a usar versiones anteriores del emu que va bien?
Se que suena a tontería, pero a veces funciona, como dije en mi post de antes.
.

Si, el problema es que mi portatil tiene una resolucion de 1024x768, y la pantalla es de 10", asi q me gustaria aprobecharla toda

Asi que la unica opcion es un filtro de 4x y bilinear, para poder ver la imagen clara y nitida

Las versiones antiguas de los emuladores no tienen este filtro, en realidad, pocos emus lo tiene lamentablemente, la mayoria se queda con suerte en el simple2x

El kega fusion es el que tiene el mejor de todos a mi entender, el filtro Quad que es una marabilla


Si quiero emular snes a tope de velocidad, ya uso el zsnes, pero este emu tambien se queda en 2x
KEGA Fusion está escrito en ensamblador x86, solo el interface Windows está escrito en C... y es que juer, he visto emuladores de NES o GB hechos en Visual BAsic [+risas] [+risas] [+risas] [+risas]
theelf escribió:Resulta q quiero un emu de snes que corra bien en mi Pentium 3 M a 800mhz, con reescalado simple4x, llevo provados varios sin buenos resultados.

Justo ahora mismo, estoy probando el bsnes y me encuentro que no puedo usar filtros, porque mi grafica no tiene soporte de pixel shader...

Es gracioso, el portatil tiene una grafica GMA 915, y otros emus, como el Kega Fusion, Fburn..etc, usan filtros tan avanzados como los del bsnes, y van de maravilla

No critico el bsnes, ni al autor, pero alguien programa lo mismo para que necesite un Pentium III 800 y una grafica de mierda, y para exactamente lo mismo, otro pide una Geforce 9500 minimo.... :-?


No entiendo


Esto es porque son cosas muy distitnas. El bsnes es un emulador orientado a la perfeccion , la calidad es tatal y los timings perfectos, es la emulacion ideal de la snes sin usar truquillos ni hacks como otros. Es normal que consuma muchisimo mas. Ademas tiene otra filosofia del autor tan respetable como cualquier otra, digamos que es un emulador como a nivel "cientifico", pq por ejemplo, no soporta ciertos formatos de roms y tal y cual porque el tio dice que esto son lastres del pasado y aportan tales o cuales problemas, idem com hacks o modificaciones de cierto tipo que solo serviran bajo ciertas arquictecturas y tal y que quedaran totalmente inservbles con el tiempo. El bsnes es como muy "cinetifico y de alto nivel".

Luego en medio tienes el 9x, que no te ira porque han ido augmentando los requisitos minimos a la vez que mejoraban los timings i otras cosillas.

No veo en que fallan los desarrolladores, no se puede tener todo, xD.

Luego esta claro el zsnes que va divino en todos lados, incluso en msdos,XD.

theelf escribió:Buenas, primero antes de todo, quiero decir algo

Como programador, entiendo la larga, y dificil tarea de programar y crear algo. No es facil, y me quito el sombrero ante todos aquellos que programan dia a dia, para hacer un juego, un emulador, un plugin...etc mis respetos


Dicho esto, no les parece que cada dia se programa peor? da la sensacion que la optimizacion es cosa del pasado, y muy pocos respetan esa sagrada tarea, antes tan obligatoria

Puede ser que los MHZ esten matando la buena programacion? creo que si, hace que los programadores se olviden de que existe gente que no tiene un C2D a 3ghz? seguro

Me gustaria señalar por ejemplo los emuladores. Aqui no tenemos que quejarnos de nada, todo lo contrario. Hay alguien que destina su PROPIO tiempo en programar un emulador de forma gratuita, para que todos disfrutemos

Pero que pasa con las optimizaciones? que pasa con el buen programar? que pasa con las opciones de core, tweaks, speedhacks... etc que antes existian??


Por ejemplo, tenemos el Kega Fusion, es increible, en el Pentium 3 M a 800mhz del portatil q tengo, corro 32x a sin frameskip, y usando el filtro simple4x+reescalado!!!!

Y luego tenemos el emulador TurboEngine, que emula la PCengine, usa los mismos plugins que el Kega Fusion... usando el filtro simple4x+reescalado, apenas llego a los 8fps.... y emulando un simple juego de PCengine como el bomberman!!!

O el snes9x, usando el filtro simple4x+reescalado, apenas llego a los 35fps, que le paso al snes9x?

O el mess!!! dios santo, me lo baje.. configure correctamente... y si logre sacarle 5fps al core de snes fue de milagro...

No se, me da que cada vez se optimiza menos, y ya ni siquiera se presta atencion en que el codigo sea limpio. que opinan?


Pero hombre, no se puede comparar. El snes 9x tiene requisitos mas altos porque no esta programado en ASM como el kefa fusion(esta hiper otpimizado si, pero tb es hiper antiguo, de varias consolas y con mucho interes, compararlo con el turbo duo es comparar el emulador de la psx con la saturn..., ponte tu a optimizarlo)

Aun asi el kega dudo que sëa muy fiel tampoco. No sera tan poco como el zsnes pero ninguna barabridad.

No me parecen muy razonables tus quejas la verdad. Ademas, queramos o no, el hard avanza. Ahora a ti te parece raro porque has crecido en esta epoca, pero imaginate si alguien años atras abriera un post qujandose del kega porque no le va en su pentium 1 o msdos?

Hay un standard tecnico medio que ha ido avanzando y es lo que hay.
gerkrt, sobre el bsnes, no dije nada sobre el emulador en si, lo que si no me parece correctos son los filtros

Mientras los mismos filtros en otros emuladores, piden pocos recursos de hardware, los mismos filtros en el bsnes, piden un exceso

Para mi eso es simplemente, que no hay optimizacion

Por lo que veo el snes9x cambio los cores de ASM antiguos por otros de C.... para que? porque de seguro cores en C son mas faciles de seguir desarrollando, el ASM es complejo y lento. Total, para que perder 10 dias... si lo programas en 1 dia, y solo necesitas 100mhz mas... los mhz son casi gratis actualmente...


Sobre el KEGA, para mi es un ejemplo de programacion, un emulador actual, uno de los mejores, si no el mejor de megadrive, que sigue funcionando correctamente en ordenadores antiguos

Y sobre lo que comentas de un Pentium 1, si el Kega Fusion, sigue funcionando correctamente en mi Pentium 1 233mmx

Al igual que la ultima version del MagicEngine, que en el 233mmx, creo q aun le sobra CPU para la TurboGrafx



Y no, para mi NO es lo que hay. Si los programadores comienzan asi, se acabo ese arte de la programacion llamado optimizacion

Sin ese arte, jamas hubieramos tenido practicamente nada ni en la NES ni en la Megadrive, ni SNES....


Durante años, entre el 94 al 96, estuve involucrado en la programacion de un interprete de instrucciones motorola 68k para x86 en asm . Nos tiramos horas y horas para optimizarlo, junto a otros colegas del BBS....

Y ahora veo que para lograr lo mismo, exactamente lo mismo, se requiere al menos 10 veces los mismos mhz que en la epoca



Y me da pena, no es una queja, es una observacion
Hoy en dia no se optimiza casi nada debido al derroche de potencia del hardware... :( No solo en emuladores, aun recuerdo el Nero Burning Rom 6 en mi PIII 500MHz/256MB... hoy para grabar un puto CD con el Nero actual hace falta un pepinaco de tropecientos GHz, MB de RAM, no se cuantos cores,.... y aun asi no va como en aquel PIII.... :-?
Si es verdad, el software esta terrible actualmente, haces lo mismo que antes, pero necesitas 10 veces mas PC... XD jjaja

Puse como ejemplo los emuladores por estar en clasicas, me parecio un ejemplo perfecto
theelf escribió:1 - Por lo que veo el snes9x cambio los cores de ASM antiguos por otros de C.... para que? porque de seguro cores en C son mas faciles de seguir desarrollando, el ASM es complejo y lento. Total, para que perder 10 dias... si lo programas en 1 dia, y solo necesitas 100mhz mas... los mhz son casi gratis actualmente...

2 - Sobre el KEGA, para mi es un ejemplo de programacion, un emulador actual, uno de los mejores, si no el mejor de megadrive, que sigue funcionando correctamente en ordenadores antiguos
3 - Y sobre lo que comentas de un Pentium 1, si el Kega Fusion, sigue funcionando correctamente en mi Pentium 1 233mmx

4 - Y no, para mi NO es lo que hay. Si los programadores comienzan asi, se acabo ese arte de la programacion llamado optimizacion

5 - Sin ese arte, jamas hubieramos tenido practicamente nada ni en la NES ni en la Megadrive, ni SNES....
Expongo mi opinion y no va a malas en ningun punto, aunque pueda sonar asi ;)

1 - Antes ya lo he comentado y esta mas que probado. A dia de hoy y desde ya hace años, programar en ensamblador no tiene logica pues los compiladores estan tan optimizados que el codigo resultante en ejecucion es igual o incluso mas rapido que el realizado en asm. Por lo cual si tienes un codigo igual o mas rapido y ademas mucho mas legible, facil de modificar y depurar, es muuuuuy raro el decantarse por asm salvo por fanatismo o algo extremadamente puntual...que no un programa entero o gran parte de el.

Me hace gracia cuando alguien dice "asm es la repolla y no hay nada mas rapido" o "visual basic o c# son una mariconada...no se puede hacer nada con ellos"...ajam...inicialmente, que luego creo quitaron soporte pues microsoft queria potencia C#, en xna se podia programar con vb.net o c# y ya habeis visto algunos juegos del livearcade como el outrun 2, super street fighter 2 remix hd... El unity se usa unityscript o c# y se consigue el mismo resultando con ambos aun siendo muy diferentes y ninguno es un lenguaje de bajo nivel como C o maquina como asm, en unreal se tira de UnrealScript, en wow y algun otro motor de lua y siguen siendo lenguajes de alto nivel y no veo los juegos que usan estos motores que tiren mal...

Si mirais en foros especializados en asm sobre hacer demos en opengl (api para dibujo y procesado de 3d usada de forma standard en casi todo aparato salvo 360 y directX) tirando de asm para "to" y tras muchas pruebas todos dicen o recomiendan lo mismo, dejarse de intentar usar asm para hacer llamadas al api pues no se va a conseguir mejora alguna y solo usarlo mediante linkados o importaciones de funciones criticas.

2 y 3 - A ti te encantan los sistemas antiguos, como aqui a la mayoria PERO que un emulador actual o bastante reciente funcione en un ordenador de hace muchos años no es que sea el mejor...y es que te lo han explicado bien ya arriba, unos emuladores buscan "poder jugar" y otros buscan "emular" de verdad y de la forma mas fiel el sistema. Es como lo que comentabas antes de tu tarjeta sin soporte para pixel shader y que menuda mierda...no, simplemente lo normal a dia de hoy es disponer de dicho soporte y por lo tanto usarlo es muy logico y practico...que te toque la moral por tener una grafica antigua y no te funcione? eso ya es tema personal.

4 - Y nuevamente te comento, los emuladores los hacen sin animo de lucro y por amor al arte, generalmente o una sola persona o un equipo muy pequeño, por lo cual hacen todo como quieren, con o sin planificacion, mas o menos exaustiva esta, las decisiones de ciento en viento pueden cambiar, ahora tengo tiempo en mi vida y me pongo con esto mas en serio o ahora no y solo hago arreglillos, etc... Que no te funcione un emulador, recien salido o hace poco, de forma decente o incluso que no tire en un pentium 1 o 2....eso realmente te importa a ti y a otros dos...

5 - Si hablas de emuladores y freeware se habla de eso pero no vale despues decir que de haberse hecho las cosas asi no habrian salido juegos buenos en nes, etc... y es que si hablamos de juegos, quien puede decir que en le hardware de una 360 muuuy limitado en comparacion a los ordenadores de hoy y viendo los juegos que se consiguen, las cosas se hacen sin optimizar o a desgana? un gears of war 3? un skyrim? gta 4?
Es que no todo es potencia bruta tio. El mantenimiento, soporte, facilidad, divertimiento, mantenimiento, herramientas, etc, son tan importantes o mas importantes que el rendimento. Y si que vale la pena pasar de asm a c y perder 100mhz, que habra que verlo, y mas hoy en dia.

Y la optimizacion es relativa a su epoca y standard tecnico. Lo que no puedes pedir es que en una epoca de standard tecnico actual, se programe pensando en el standard tecnico de hace 10 años o mas, absurdo, igual que entonces no se hacia y tampoco en la epoca de la NES ni nunca. Y lo siento pero optimizar mal hoy en dia es otra cosa y ya no tanto si usar asm o no cosas asi que son de contextos distintos, hay mejores o peores formas de programar pero no definen la cosa en el viejo estilo porque la tecnologia avanza.

En la epoca de la NES el standard tecnico era asm total. Hoy en dia voy a hacerlo? porque? soplapolleces. Ademas, optimizar se debe hacer segun el uso y las herramientas y al final. Por lo demas, el rendimiento no importa tanto. Si por ejemplo, puedes hacer algo en un lenguaje como ruby, python y c sharp sin problemas, debes hacerlo porque estos son mejores en otros aspectos.
KFR tio, escrives mucho, no puedo leer tanto seguido, me pierdo, lo siento!! :(


Yo la verdad q ya no me (gracias a dios) gano la vida programando, pero la verdad, q a casi nadie que conozco que sigue en el rubro, le das un 386 a 40mhz, y te puede hacer siquiera un pong, cuando antes te metian un Doom

Es que para mi no existe un "viejo" o "nuevo" estilo. Si no, hacer bien o mal las cosas


Hace unos años atras, cuando aun usaba mi buen ibook G3, se me dio por ver MKV y MP4

Segun lei en foros, era imposible, bla bla, el G3 es muy lento, bla bla que Quicktime es tu mejor opcion, que Mplayer no esta optimizado, que VLC es una mierda... bla bla nada, no veras ni un puletero AVI....

Asi que me tire casi un mes reescribiendo codigo en assembler de powerPC y recompilando, hasta q obtuve un mplayer q se comia los MKV y MP4 en mi querido G3 .LLege a ver videos de 720p

Recuerdo que postee una de las primeras versiones de mi mplayer, las versiones mas nuevas, sabra dios si aun estan en el ibook

http://www.elotrolado.net/hilo_mplayer-en-g3-sin-altivec_1239132


Los G3 se desperdiciaron, no habia buen software, y nadie optimizo correctamente la mayoria del software para OSX para este procesador, cuando aun tenia mucha vida... total, para que.... si hay mas y mas Mhz


Entiendo q ahora, a diferencia de antes, el hardware es mas economico que el software, pero justamente eso, creo, esta matando/cambiando las vieja costumbre de optimizar el codigo
No es "soplapolleces"...es que no ganas nada! si usas un motor como unreal o unity olvidate de programar en asm porque no puedes, directamente y vuelvo a repetir, los compiladores de hoy dia al convertir a codigo maquina lo hacen tannnn bien que la diferencia entre asm es minima o nula e incluso en algunas pruebas que he hecho o algun conocido, los resultados han dado ganador a c con respecto a asm.
Ademas, no es ni de lejos lo mismo programar en ensamblador para un zx80 o un 68000 que para una maquina con el cell o la cpu, creo que de tres o cuatro nucleos, de la 360.
Y una vez mas, optimizar...la gente dice eso como los politicos utilizan el termino democracia...ais...
Pero realmente no voy a insisitir pues quien quiera pensar que es "vagancia" y que "todo lo pasado fue mejor", el mismo.
Pues si tan bien optimizan los compiladores, muy mal programa la gente, para que el software salga tan rana!
ais....que un emulador pida la de dios es solo culpa de que al programador: a) le haya dado igual el hard y solo busque el mayor realismo b) tenga errores en ciertas areas criticas y el rendimiento se vea afectado...que no optimizacion, lo que requeriria seria arreglo que es diferente. c) el que programa es algo patan y es que no por hacer un emulador pasas a ser dios hecho carne... d) porque es facil conseguir un ordenador a dia de hoy con los requisitos que pide y a bajo coste

Pero vuelvo a decir que un pavo que have un emulador no sirve para generalizar pues emuladores podras contar...yo que se...1000? tirando a lo bestia pero cuantos juegos tienes? y como van estos? mal se ha programado siempre y mierdas no son exclusivas de ahora ni mucho menos...me he leido la de dios de documentos y articulos sobre desarrollos antiguos y en muchos juegos miticos a dia de hoy el codigo era un puto caos.

Un caso divertido ha sido el silent hill 2 que para hacer el port se han vuelto locos y que directamente tuvieron que rehacer casi todo e incluso no fueron capaces de entender como hostias iban algunas cosas, que era un galimitais y la propia konami admitio que no fue su trabajo mas fino en su dia. Lo mismo con el prince of persia y muchos otros y el mismisimo Miyamoto hace cosa de un año o dos o algo asi, al ver de nuevo el mario 3 dijo sin dudarlo que a dia de hoy eso no pasaria su baremo de calidad y que muchas cosas las cambiaria y/o mejoraria...no digo mas y es uno de los juegos mas potentes de nes. El halo 1 admiten fue un caos y en el 2 rehicieron todo. Se noto real mejora o un cambio impresionante? mejora si por ser la segunda entrega y graficos algo mas cargados etc..., cambio...no.

Y en pc lo ves "evidente" pero en consola no? porque un juego de snes no se preparaba para ir en nes tambien? porque no tiene sentido y juegos de pc que pedian cierta tarjeta de sonido o una aceleradora 3d...el desarrollador usa la tecnologia disponible que le facilite y permita conseguir llevar a delante sus ideas y si tu pc no tiene una aceleradora y quieres jugar pues la compras y no dices que "joder que mierda de optimizacion". Es como pedir que el photoshop cs6 funcione en un pentium 4 con soltura...arrancar supongo arrancar, soltura....no se yo y hacer cosas serias..xD pero es "lo normal".

Ya se han visto demos muy brutas hechas en atari 2600, spectrum, gameboy,... pero eso luego en un juego no lo metes ni fumao porque te has comido ya todos los recursos o en si solo podrias tener un pong y poco mas.

Edit: En relacion a empresas y pc, tambien es cierto que les encanta sacar burradas que pidan lo que sea...que salen productos muy brutos como el crisys? si pero tambien se ha comprobado que se podria conseguir lo mismo pidiendo bastante menos...posibles acuerdos entre desarrolladoras y creadoras de hard/cpus/graficas? casi seguro. Pero en consolas? no...la consola es la que es y con 360 llevamos ya unos añitos y ps3 casi igual y la wii lo mismo.
Es muy simple: el hardware es mas barato que las horas de un programador.
Es muy simple: el hardware es mas barato que las horas de un programador.


+1 el hardware es mas economico que el software, no hay con que darle. Se dio vuelta la tortilla, antes, tenias q matarte para ahorrar unos pocos KB, que la memoria costaba fortuna... hoy para jugar si no tienes 2GB o mas de ram, ni puedes comenzar la partida....
Que facil es quejarse...antes te ponian un 3d de mierda, literal o un 2d muy bonito para ser pixel art pero en su mayoria nada que a dia de hoy no se pueda conseguir muuucho mejor (otra cosa es que pasen del 2d por norma por ser mucho curro y el publico mayoritario preferir el 3d cuanto mas realista mejor) y todo impresionante!!! hoy en dia te sacan virguerias de quitarse el sombrero en 3D, inteligencia, control, sonido envolvente, cantidad de enemigos, escenarios llenos de detalles, texturas en hd, etc etc.. pero no, es todo una mierda sin optimizar. OLE!

Gears 1,2,3 caca, metal gear 3,4 caca x 2, skyrim...buag, fallout 3...arg, forza 3,4 y gt5 ...buf, heavy rain ...aisss, mario galaxy 1,2 ...uagg, metroid prime 1,2,3 quita quita, cave story grimita, halflife 2 penoso, osx snow leopard, lion, mountain lion van como el culo, windows 7 ..quiero volver a dos!, gimp repulsivo viva el paint, vuze/azureus/.. donde este mi kazaa, resident evil remake...que me den el original!!!!, etc etc...pero se hace to mal por norma.
KFR, sin ofender, ya te he visto en mas de un hilo arruinarlos, no en los mios por favor
KFR escribió:No es "soplapolleces"...es que no ganas nada! si usas un motor como unreal o unity olvidate de programar en asm porque no puedes, directamente y vuelvo a repetir, los compiladores de hoy dia al convertir a codigo maquina lo hacen tannnn bien que la diferencia entre asm es minima o nula e incluso en algunas pruebas que he hecho o algun conocido, los resultados han dado ganador a c con respecto a asm.
Ademas, no es ni de lejos lo mismo programar en ensamblador para un zx80 o un 68000 que para una maquina con el cell o la cpu, creo que de tres o cuatro nucleos, de la 360.
Y una vez mas, optimizar...la gente dice eso como los politicos utilizan el termino democracia...ais...
Pero realmente no voy a insisitir pues quien quiera pensar que es "vagancia" y que "todo lo pasado fue mejor", el mismo.


un lenguaje de alto nivel jamas podrá igualarse al código maquina en optimizacion de recursos, de la conversión del código humado a maquina se pierde potencia si o si, no es lo mismo programar un juego de NES en asm que en basic o C, la diferencia de potencia es abismal, y alli están las pruebas, emuladores hechos en asm como el zsnes, kega fusion, corn (increible emulador de n64), entre otros, la diferencia de potencia contra otros emuladores programados con lenguajes de alto nivel es muchisima. y hablando de tiempos modernos, claro, a dia de hoy seria inviable programar en asm, seria una tarea titanica hacerlo con la potencia y complejidad de las computadores de hoy en dia, programar en asm antaño era una tarea casi romantica, debías saber hablar en maquina prácticamente, hoy en dia, seria humanamente imposible hacerlo con los procesadores y gpus actuales, para eso están los lenguajes de alto nivel, para abstraer el lenguaje de la maquina a uno que podamos entender más fácilmente y no nos lleve decadas programar, pero aquello conlleva perder potencia, porque ya no le decimos directamente a la maquina que hacer, sino que utilizamos codigo ya pre-hecho para aquello que sirve de intermediario entre los humanos y la maquina y nos ahorra el tiempo de reinventar la rueda (de hecho, dudo que haya alguien hoy en dia que programe algo "desde cero" en una maquina actual, es casi imposible), y cada vez más la abstracción es mayor añadiendo capas y capas que facilitan y acortan los tiempos del desarrollo de software, pero que conllevan una perdida de optimización enorme. Por eso, lo mejor hoy en día es adaptarse a las nuevas tecnologías de desarrollo y no dejarse llevar por la tentación de la programación fácil y los Mhz gratis de la tecnología actual
KFR escribió:hoy en dia te sacan virguerias de quitarse el sombrero en 3D, inteligencia, control, sonido envolvente, cantidad de enemigos, escenarios llenos de detalles, texturas en hd, etc etc.. pero no, es todo una mierda sin optimizar. OLE!


Lo hemos discutido en algún hilo... que hoy los juegos sean 3D y luzcan sofisticados, no implica que los programadores sean mejores ni siquiera que tengan mas mérito o dedicación, sino que el nivel de capital instalado de 2012 es muy superior al de 1994. Nada mas.

Los programadores de 16 bits, también utilizaban el tope tecnológico de la época y lograr lo que lograban era una pasada impresionante que requería tanto o mas trabajo/talento que el requerido a un programador actual (que posee herramientas mas sofisticadas, IDEs increíbles, presupuestos mas altos, etc, etc).

De hecho, el software de hoy tiene mas fallos y es mas chapuza porque cualquiera es programador. Hay una facilidad de acceso enorme, hoy todo es muy sencillo y automatizado, las empresas hacen outsourcing de sus proyectos a pica-codigos del 3er mundo que son quienes desarrollan los juegos (los motores los compran hechos).

En el pasado los programadores eran auntenticos frikis que dominaban el hardware a fondo... por eso lograban lo que lograban sin mas recursos que sus cerebros, un editor de texto y 8Kb de RAM. :o
KFR escribió:1 - Antes ya lo he comentado y esta mas que probado. A dia de hoy y desde ya hace años, programar en ensamblador no tiene logica pues los compiladores estan tan optimizados que el codigo resultante en ejecucion es igual o incluso mas rapido que el realizado en asm. Por lo cual si tienes un codigo igual o mas rapido y ademas mucho mas legible, facil de modificar y depurar, es muuuuuy raro el decantarse por asm salvo por fanatismo o algo extremadamente puntual...que no un programa entero o gran parte de el.

Me hace gracia cuando alguien dice "asm es la repolla y no hay nada mas rapido" o "visual basic o c# son una mariconada...no se puede hacer nada con ellos"...ajam...inicialmente, que luego creo quitaron soporte pues microsoft queria potencia C#, en xna se podia programar con vb.net o c# y ya habeis visto algunos juegos del livearcade como el outrun 2, super street fighter 2 remix hd... El unity se usa unityscript o c# y se consigue el mismo resultando con ambos aun siendo muy diferentes y ninguno es un lenguaje de bajo nivel como C o maquina como asm, en unreal se tira de UnrealScript, en wow y algun otro motor de lua y siguen siendo lenguajes de alto nivel y no veo los juegos que usan estos motores que tiren mal...

Si mirais en foros especializados en asm sobre hacer demos en opengl (api para dibujo y procesado de 3d usada de forma standard en casi todo aparato salvo 360 y directX) tirando de asm para "to" y tras muchas pruebas todos dicen o recomiendan lo mismo, dejarse de intentar usar asm para hacer llamadas al api pues no se va a conseguir mejora alguna y solo usarlo mediante linkados o importaciones de funciones criticas.



La diferencia principal entre los "nuevos" lenguajes de alto nivel y los lenguajes de bajo nivel (C no es que se considere muy de bajo nivel) no es que el código resultante sea mas rápido o no (que lo dudo, y si no en ASM siempre podemos tirar a RTL). La eficiencia tiene mas que ver con la gestión de memoria, que en los lenguajes de alto nivel se deja que se encargue el sistema con el consecuente caos que eso puede ocasionar (sobretodo en sistemas no unix) y la poca eficiencia que esto conlleva, por que tienes un proceso adicional que va preocupandose de vigilar y limpiar.

No es lo mismo dejar que los recolectores pasen a limpiar cuando les salga de la entrepierna y tener memoria ocupada que podriá ser aprovechable por otras rutinas o para cargar otras cosas que poder elegir tu exactamente cuando o no es limpiado el sobrante que no se utiliza.

Con asm y hasta con C sabes exactamente lo que hay en los bancos en cada momento y lo que no debería de haber, por que eres tu el que lo a metido ahi directamente y el que da la orden de liberarlo.
Pues hablando de obras de ingenieria, el emulador itmightbenes de psx, dicen que fue hecho en ensamblador
Si jugais al Minecraft, sabreis que es el culmine de todo esto. En un Core Duo de 2 GHz, Radeon X1800 de 256 MB y 2 GB de RAM, si paso de 30 FPS es un milagro. Y en un ordenador con una gráfica de gama alta del 2009, 8 GB de RAM y un C2Q a 2.4 GHz aun me dan bajones cortos de FPS en distancia larga de render... [toctoc]
andoba escribió:Si jugais al Minecraft, sabreis que es el culmine de todo esto. En un Core Duo de 2 GHz, Radeon X1800 de 256 MB y 2 GB de RAM, si paso de 30 FPS es un milagro. Y en un ordenador con una gráfica de gama alta del 2009, 8 GB de RAM y un C2Q a 2.4 GHz aun me dan bajones cortos de FPS en distancia larga de render... [toctoc]


Depende el motor grafico que use. Yo por ejemplo juego al world of tanks, que un juego online gratuito. Hasta hoy se veia como la ps2 pero con alta resolucion. Ahora se han dignado a comprar un motor grafico de pago. El resultado es que ahora el juego se ve con graficos actuales y pide meno potencia, doble combo.

Moraleja, los motores graficos valen pasta por que son utiles y son software. Por lo tanto el software cuesta mucho dinero desarrollarlo.
sabran escribió:
andoba escribió:Si jugais al Minecraft, sabreis que es el culmine de todo esto. En un Core Duo de 2 GHz, Radeon X1800 de 256 MB y 2 GB de RAM, si paso de 30 FPS es un milagro. Y en un ordenador con una gráfica de gama alta del 2009, 8 GB de RAM y un C2Q a 2.4 GHz aun me dan bajones cortos de FPS en distancia larga de render... [toctoc]


Depende el motor grafico que use. Yo por ejemplo juego al world of tanks, que un juego online gratuito. Hasta hoy se veia como la ps2 pero con alta resolucion. Ahora se han dignado a comprar un motor grafico de pago. El resultado es que ahora el juego se ve con graficos actuales y pide meno potencia, doble combo.

Moraleja, los motores graficos valen pasta por que son utiles y son software. Por lo tanto el software cuesta mucho dinero desarrollarlo.


Imagen

[qmparto]
Yo mas bien diría que las empresas quieren resultados muy rápidos en poco tiempo y los programadores tiene que utilizar muchas capas de software y herramientas de otras empresas(que suelen ser multiplataforma) para desarrollar el producto en el menor tiempo posible. No creo que los programadores sean peores sino que las empresas han cambiado la forma en la que desarrollan sus productos.

P.D: Lo que si que ocurre en mi opinión es que a causa de esto ahora tenemos la generación de programadores C# y Java.
Yo soy programador autodidacta(como con todo...xD), hize un modulo pero sude a saco, solo lo queria por tener un titulo oficial y tal.

Y nose que decirte. Es cierto que se se usan muchas herramientas y cosas de alto nivel, pero esque esto tambien es porque hay que aprovechar la suerte que tenemos hoy en dia de que la potencia media actual te permita usar lenguajes muy currados y sistemas donde el mantenimiento(que acaba siendo lo mas importante) sea mejor o mas facil.

Me hablais de c o asm, pues estos lenguajes estan bastante caducos en varios aspectos. Por ejemplo tienen muchas fallas de seguridad y bugs faciles debido a la gestion de memoria y acceso al hardware. No es que los demas no tengan pero si son mas seguros.

En cuanto a rendimiento, lo que hay hoy, son diversos estilos. Si te gusta programar en c o asm, pues te pones a programar kernels, so, drivers, cosas criticas, etc.

Pero esque para lo demas no es necesario y es una suerte esto, los costes han bajado en general en todo en la informatica. Se ha abierto y para bien. Y las cosas importantes siguen optimizadas y muy trabajadas: compiladores, interpretes, cosas de bajo nivel en los SO, librerias, engines, etc.

Sin embargo hoy en dia puedo pillar python, pygame, y hacer un juego 2d bien majo. O ruby y gosu, o sfml, o xna, etc. Y tardar nada y disfrutar mucho mas, tener un codigo mil veces mejor con herramientas mil veces mejores.... en fin,

Y si que hay gente que reescribe todo de 0, maniaticos de la programacion hasta la obsesion, quizas? pero si hay unos cuantos, y siempre los habra, y de mientras la oferta y demanda se ha expandido al millon y las herramientas tambien, por supuesto. Tambien quieres que se programen webs en asm?
gerkrt escribió:Me hablais de c o asm, pues estos lenguajes estan bastante caducos en varios aspectos. Por ejemplo tienen muchas fallas de seguridad y bugs faciles debido a la gestion de memoria y acceso al hardware. No es que los demas no tengan pero si son mas seguros.


Eso de "Tienen" prácticamente la única fuente de errores cuando se programa en C o ASM bienen de errores de diseño por parte de los diseñadores del hardware o por parte del programador.

P.D: Entiendo a lo que te referías , que es muy fácil provocar un error por gestionar mal la memoria pero el programador es quien tiene la culpa no la herramienta.
kappa64 escribió:P.D: Lo que si que ocurre en mi opinión es que a causa de esto ahora tenemos la generación de programadores C# y Java.


Ésto es lo que realmente pasa hoy en dia, la generación de programadores de Java, .NET, máquinas virtuales y cuanto menos bajo toques mejor, aunque te cueste lo mismo programarlo. La de caras de éste tío está flipao que te ponen los compañeros de carrera cuando dices que programar para Windows o cualquier plataforma actual en C++ e incluso mezclándolo con ensamblador si no hubiese más remedio para optimizar no es tan raro...

Un programa del estilo del Notepad de Windows que necesite 2 GB de RAM, 1 GHz de CPU y el ejecutable ocupe 60 MB no es el futuro que quería... [snif]
andoba escribió:
kappa64 escribió:P.D: Lo que si que ocurre en mi opinión es que a causa de esto ahora tenemos la generación de programadores C# y Java.


Ésto es lo que realmente pasa hoy en dia, la generación de programadores de Java, .NET, máquinas virtuales y cuanto menos bajo toques mejor, aunque te cueste lo mismo programarlo. La de caras de éste tío está flipao que te ponen los compañeros de carrera cuando dices que programar para Windows o cualquier plataforma actual en C++ e incluso mezclándolo con ensamblador si no hubiese más remedio para optimizar no es tan raro...

Un programa del estilo del Notepad de Windows que necesite 2 GB de RAM, 1 GHz de CPU y el ejecutable ocupe 60 MB no es el futuro que quería... [snif]


Yo ademas del problema del rendimiento veo muy grave el problema de dependencia de otro software o librerías.
Si ahora programo un juego en C y SDL lo puedo tirar con ligeros cambios en una WII , GP2X , Dreamcast , etc..
Es una opinión personal pero no me gusta nada que mi software solo sirva en las plataformas (y con el rendimiento) a las que los terceros de los cuales dependen esas tecnologías(muchas veces propietarias) les de la gana dar soporte , para mi eso es mutilar un software.
kappa64 escribió:Yo ademas del problema del rendimiento veo muy grave el problema de dependencia de otro software o librerías.
Si ahora programo un juego en C y SDL lo puedo tirar con ligeros cambios en una WII , GP2X , Dreamcast , etc..
Es una opinión personal pero no me gusta nada que mi software solo sirva en las plataformas (y con el rendimiento) a las que los terceros de los cuales dependen esas tecnologías(muchas veces propietarias) les de la gana dar soporte , para mi eso es mutilar un software.


Totalemente de acuerdo, la portabilidad es un aspecto que la mayoría de las veces queda en segundo plano y no prestarle atención es muchas veces una excusa para no hacer las cosas bien.
Es curioso, pensé que se hablaría de juegos y al final el hilo va de emuladores :-). Hombre en lo referente a emuladores está claro que no se optimiza como antes con los legendarios Callus, NeoRage y compañía. La gente que programa emus hoy día no tienen el nivel de aquellos monstruos, está claro...
theelf escribió:KFR, sin ofender, ya te he visto en mas de un hilo arruinarlos, no en los mios por favor
Primero dime donde he faltado al respeto o dicho algo fuera de lugar? pues eso.

Segundo, uno lo ha dicho bien, en asm o asm + c/c++ se pueden conseguir resultados inigualables PERO a dia de hoy no pues salvo que seas un puto crack y te sobre tiempo en tu vida como para regalarlo, ponerte a controlar la memoria y multitarea (porque de no usarla me pareceria no sacar provecho real a las cpus actuales) en las cpu/gpus actuales tiene que ser una tarea titanica y la posibilidad de conseguir algo "bueno" y optimizado en un tiempo relativamente corto, que es lo que se exige y es que las cosas tienen que estar para "ya", es anecdotica.

Y luego es siempre muy facil decir cosas como "es por vagancia y cualquiera puede ser programador...se usan lenguajes que desaprovechan por todos lados...etc etc..." pues quiero ver quien a dia de hoy se curra su juego sin tirar de sdl u opengl o directX o xna (que tira de directX) ademas de librerias como glut para el control estandarizado de i/o, frameworks o motores que permitan el desarollo y compilacion para diferentes SO's e incluso diferentes plataformas como pueden ser movil y pc, etc etc... A ver cuanto tiempo se tarda y como de optimizado sale el resultado.

La abstraccion es una puta gloria, tal cual y el trabajo a bajo nivel ya lo hacen otros que controlan muy mucho del tema y por eso despues podemos hacer uso de sdl u opengl y partir de una base buenisima. Que se podria optimizar mas opengl? seguramente pero no lo creo mucho pues es que habeis pensado que este estandar los desarrollan principiantes y tal...por citar algunos de los mas importantes apple, amd, intel, nvidia, blizzard, epic, samsung, sony,... de verdad pensais que ese codigo no esta optimizado?
Ahora se parte desde la idea Mame de: Tu ponlo, y ya se jugará bien.

Antes tenías una gran cantidad de nada, y te tocaba buscarte la vida porque no había pcs, ahora tienes un equipo de la leche, unos recurso casi infinitos y los programadores salimos como churros... si a eso se le une que somos unos cagaprisas (si, no me miréis así que aquí se cobra por trabajo y que funcione, no por calidad)... pues ya tienes todos.

PD: Tienes que tener en cuenta que antes se programaba como se podía, y sin lenguajes de alto nivel. Ahora todo se hace siguiendo normas, y en lenguajes "sencillos" pero de muy alto nivel (lentos). Sin contar los lenguajes multiplataforma, que se pueda portar, que uses herramientas especiales...
Es curioso, pensé que se hablaría de juegos y al final el hilo va de emuladores :-)


Si, pero como estamos en clasicas, no queria sacar el tema de juegos modernos. Creo q los emus son un buen ejemplo, y al menos coincide con el foro

Aunque con los juegos tambien puedo ser bastante critico, e incluso con mucos de los juegos mas "clasicos", jeje, madre mia, si hubo ports cutres en aquella epoca


Ahora se parte desde la idea Mame de: Tu ponlo, y ya se jugará bien.


Ostia, el otro dia, probando mame, me vino a la cabeza eso mismo. Buscando una info en el foro, ponian algo como "agregamos XX funcion, y cuando los ordenadores alcancen 8ghz podran usarla" WTF!! bueno es una opcion! jeje


sobre los lenguajes de alto y baho nivel, creo q que es una de cal y otra de arena. Yo mismo tengo un tutorial de basic para programar en megadrive, joder, basic es de alto nivel, y es super util para muchisimas cosas, pero por ejemplo, las rutinas de dibujado de graficos, acceso a memoria, etc te tiras un par de dias extras, las haces en asm, y ganas mucho, muchisimo

Pero claro eso es porque es una megadrive, si fuera PC, haces las funciones en basic, y subes un poco los requerimientos minimos.... [+risas]
De todas maneras entiendo que en el curro utilices tal herramienta o trabajes de tal manera pero siendo programador , no deberías querer conocer como funciona un sistema informático a todos los niveles y querer generar el mejor código posible , simplemente por la admiración y la curiosidad que sientes por los microprocesadores y arquitecturas de hardware? no quieres saber y comprender de donde sale y como toda la "magia"?
Veo mucha gente que defiende sus lenguajes favoritos con los argumentos que te daría un director de proyecto o un empresario , acaso eres no eres un apasionado de la informática? Donde esta tu placer por el trabajo bien hecho y tu ansia de conocimiento?
Entiendo que uses esas herramientas en el curro , pero que además sean tus herramientas "favoritas".

KAISER-77 escribió:si, no me miréis así que aquí se cobra por trabajo y que funcione, no por calidad


Exactamente lo que yo decía .

pues quiero ver quien a dia de hoy se curra su juego sin tirar de sdl u opengl o directX o xna


Hombre , creo que mucho no pensamos que el problema precisamente sea SDL , OpenGL o DirectX , si no mas bien el uso de lenguajes interpretados y excesivas cantidades de capas de software.

PD: Tienes que tener en cuenta que antes se programaba como se podía, y sin lenguajes de alto nivel. Ahora todo se hace siguiendo normas, y en lenguajes "sencillos" pero de muy alto nivel (lentos). Sin contar los lenguajes multiplataforma, que se pueda portar, que uses herramientas especiales...


Hoy "multiplataforma" se refiere a que exista soporte para la ultima versión de Windows , IOS , Android.
Bueno mas multiplataforma que C/C++ con el que puedes trabajar en cualquier cacharro medianamente potente(como SNES , MEGADRIVE , etc..) y no tiene porque significar una perdida de recursos muy grande.
Primero dime donde he faltado al respeto o dicho algo fuera de lugar? pues eso.


Que facil es quejarse...antes te ponian un 3d de mierda


Empezando por el lenguaje, y luego la forma de expresarse.

No tengo nada contra ti, y la verdad comparto bastante con tus ideas, pero si creo que deberías mejorar las formas.

Salu2
kappa64 escribió:De todas maneras entiendo que en el curro utilices tal herramienta o trabajes de tal manera pero siendo programador , no deberías querer conocer como funciona un sistema informático a todos los niveles y querer generar el mejor código posible , simplemente por la admiración y la curiosidad que sientes por los microprocesadores y arquitecturas de hardware? no quieres saber y comprender de donde sale y como toda la "magia"?
Veo mucha gente que defiende sus lenguajes favoritos con los argumentos que te daría un director de proyecto o un empresario , acaso eres no eres un apasionado de la informática? Donde esta tu placer por el trabajo bien hecho y tu ansia de conocimiento?
Entiendo que uses esas herramientas en el curro , pero que además sean tus herramientas "favoritas".
Lo de la "magia" y conocer a fondo...ni tanto ni tan calvo, me encanta la programacion pero dentro de la programacion hay muchas ramas y mismamente un amigo mio es un puto crack en bases de datos y yo de eso controlo algo pero ni fu ni fa, vamos que no me va...y cosas que hace el para mi son chino, las puedo llegar a entender pero por encima y lo mismo cuando yo le comente algo de multimedia, le sonaban los fundamentos de programacion pero ahi se acabo. Tienes a gente especializada en kernels, bases de datos, paginas web, retro-ingenieria, ia, sonido... cada cual es un mundo y a mi lo que me gusta es la programacion de juegos, poder plasmar ideas, definir la interactuacion entre el jugador y el personaje, crear logicas de juegos, busqueda de caminos etc... y para este campo no necesito realmente para nada asm, c y c++ si puesto que para opengl es lo mas optimizado pero el 99% de proyectos serios o motores no van solo con c++, el nucleo lo hacen con c/c++ pero despues para que la programacion sea agil, sostenible y bien seccionada, se incopora un lenguaje de scripting o interpretado como javascript, lua, python,...

Un escritor necesita saber como funciona el boli? es algo muy similar y es que luego si que he programado algunas cositas para nes en asm y basic, para md en basic, etc.. pero eso es mas por el gunasillo y amor por el retro que otra cosa. Yo no quiero ni me gustaria estar aprendiendome de pi a pa la arquitectura actual de una gpu para poder crear una aplicacion de 4Kb con la que poder generar una demo 3d de cagarse sobre un core duo...a quien le llame la idea bien pero a mi eso no me va.
kappa64 escribió:Hoy "multiplataforma" se refiere a que exista soporte para la ultima versión de Windows , IOS , Android.
Bueno mas multiplataforma que C/C++ con el que puedes trabajar en cualquier cacharro medianamente potente(como SNES , MEGADRIVE , etc..) y no tiene porque significar una perdida de recursos muy grande.



Yo más bien me refería a algo tipo Java. Un emulador de nes en un 386-486 va sobrado, si usas un emulador escrito en Java, del P2 no baja xD. Respecto a portar, pues algo que con un simple código te de el mismo juego para PC que para Xbox como oi que tenía komani para hacer el PES (que por cierto, así salía xD).
KFR escribió:Un escritor necesita saber como funciona el boli? es algo muy similar y es que luego si que he programado algunas cositas para nes en asm y basic, para md en basic, etc.. pero eso es mas por el gunasillo y amor por el retro que otra cosa. Yo no quiero ni me gustaria estar aprendiendome de pi a pa la arquitectura actual de una gpu para poder crear una aplicacion de 4Kb con la que poder generar una demo 3d de cagarse sobre un core duo...a quien le llame la idea bien pero a mi eso no me va.


En el caso del informático programador, si que se necesita saber como funciona "el boligrafo".

No todas las empresas tienen equipos de los últimos 15-20 años, y muchas (muchisimas) veces vas a encontrarte que tienen programas "legacy" hechos con vete a saber que tipo de lenguaje raro y encima no posees los fuentes. De repente un tipo te dice que es el programa que han usado en los últimos 35 años, que debes añadir tal funcionalidad, y que pasar todos los datos que han acumulado durante ese tiempo para utilizarlos en otro programa seria tan costoso y resultaría una tarea tan titanica que obligaría a cerrar la empresa durante meses entre otras cosas.

¿Que hacen en un caso así? Llaman a un programador.

Se presentarán muchos, no lo dudo, pero el que parte la pana y se va a llevar el puesto es el que desensambla el ejecutable, y a partir de los requisitos y el tochaco en ensamblador hace hooks en C+asm o directamente modifica en asm.

El resto, con todo lo que ofrece java, C#, python y demas.... no podría hacer nada, y por supuesto se quedaría sin cobrar. El saber como funciona la maquina te permite programarla a niveles que mucha gente que se llama a si mismo programador no puede, no tiene mas vuelta de hoja.

La gente no se imagina la cantidad de sistemas empotrados que hay por ahí y que hay que programar, y la de empresas que siguen usando aplicaciones en fortran y lenguajes tan antiguos que los fuentes hace mucho que se han desvanecido en disquettes de 5 1/4.

Por cierto, lo bueno de todo esto, es que la mayoria de los ordenadores actuales estan basados en estandares de arquitectura de hace varias decadas, no tienes por que aprenderte la arquitectura de un ordenador actual para programar cosas en ensamblador. Mirar el juego de instrucciones que soporta, la palabra y dos o tres cosillas mas para empezar.... El tema de multihilos (que no multitarea) no es tan chungo como puede parecer y tiene que ver bastante con el planificador del ssoo.
Lo que comentas del tio que controla desensamblando y que sera el que se lleve ese curro en concreto que comentas, cierto, tendra que saber hacer eso para poder sacar adelante semejante proyecto PERO como ya he comentado arriba, para hacer eso tiene que gustarte ese campo en concreto pues no es algo que se practique porque si sino que requiere casi o directamente de una especializacion y ese no es el campo que a mi me llama, me parece muy curioso pero fin.

Lo de poder programar la maquina a nivel muy bajo, cierto que te da "libertad" de conseguir cosas muy brutas pero a dia de hoy hacer un juego con esa metodologia en mente, salvo que seas el amo de la barraca como se suele decir, te va a llevar muuuuucho tiempo y el resultado casi seguro quedara muy lejos de como te podria haber quedado tirando de librerias, apis, frameworks y lenguajes de alto nivel ya sean interpretados o compilados. Alguno podra decir "vago!" y yo le dire que se ponga a programar un jueguito tipo tetris que pueda compilarlo para android e ios o para 360 o para una plataforma social...espero. Edit: Es que por esa regla de 3 pues nada de usar librerias de ningun tipo, asm puro y todo desde cero...

Cierto, es multihilo que no multitarea, eso sera el sistema [+risas]

Y si, ya tenia buen conocimiento del "marron" que tienen muchas empresas con ese tema o cobol tambien, aplicaciones del pleistoceno y que solo una vez escuche algo relacionado con un banco grande de que iban a mirar a otro soft...y se quedo en eso, iban a.

Lo de la arquitectura tambien sabia pero no creo, y digo creo que de esto si que no mucho o nada idea xD, que sea "facil" en una cpu de hoy dia sacarle todo su partido o gran parte mediante asm mientras que a un x86k o un zx80 seguramente si se podria.

Edit: Ando haciendo un prototipo de una idea de juego para movil que se me ocurrio anoche, la tengo funcionando en el galaxy s2 a 30fps estables 100% y me ha llevado 30 minutos, con fundidos, traslaciones con inercia, calculos parabolicos, etc... no quiero ni pensar de tener que hacer esto en asm + c y sin tirar del framework que uso...de hacer lo haria en C o C++ e igualmente usaria opengl o sdl pues al final, acabamos igual.

Y curioso es esto "El saber como funciona la maquina te permite programarla a niveles que mucha gente que se llama a si mismo programador no puede, no tiene mas vuelta de hoja." es como decir que un jugador de un equipo mas modesto no se puede llamar futbolista porque existe messi o ronaldo... joder que extremismos.
Elcorteingles y cajasol han tenido que hacerlo hace muy poco. No puedes pasar 20 años de datos a un nuevo formato en una semana y comprobar posibles fallos y errores (que al final lo que se mueve es dinero) cuando tienes una fusión a la vuelta de la esquina.

... A ver, trabajar a bajo o medio nivel no lleva tanto tiempo, de hecho una vez que sabes lo que tienes que hacer y las interrupciones que tienes que usar, la cosa es bastante sencilla y rápida.

Tetris es la tipica practica de universidad que se suele enviar a los alumnos de primero de arquitectura (ahora con bolonia no se como se llamara, pero supongo que seguirán dando mas o menos lo mismo). En principio no necesitas mas de tres interrupciones : Capturar tecla, pintar pixel en formato fila*columna y la ah09 para poner texto si acaso. Para pintar los pixeles es casi seguro que necesitaras hacer una macro que te calcule el area de la figura, y ir actualizando el refresco para redibujar a medida que se mueve la pieza.

¿tiempo estimado? si ya has visto algo de ASM, hechale un par horitas yendo tranquilo.

Lo multiplataforma esta "muy bien" pero luego ponemos un juego de la ps2 en la ps3 y notamos que va peor que en la maquina original para la que se diseño (heavenly sword por ejemplo, vaya cortes que mete). Es justo esta la diferencia que desmuestra que no es lo mismo que se ejecute directamente el codigo en la maquina para la que fue fabricado a que haya una maquina o un interprete por enmedio diciendole al ordenador lo que tiene que hacer. ¿Ahorras tiempo? si, nadie te dice lo contrario, pero tampoco es tan feo ni tan lento programar a bajo nivel. Es por esto mismo que en Microsoft utilizan intermediate lenguaje para todo lo que se necesite hacer rapido y que ademas sea eficiente.

Creo que las maquinas virtuales y los interpretes estan sobrevalorados, tienes que tener en cuenta el que existen interpretes de ASM de 80086 o de powerpc o de cualquier arquitectura para casi cualquier plataforma, y eso hace que trabajar a bajo nivel tambien pueda ser portable a otros sistemas.

¿Se programa peor hoy en dia? No, se programa distinto, el paradigma es diferente, no se pueden comparar peras con manzanas. ¿Es mas rápido de hacer a alto nivel? Sí, esto sin duda, pero trabajar a bajo nivel tampoco lleva tanto tiempo como supone la gente. ¿Es mas eficiente hacer algo a alto nivel? No, rotundamente no, la cantidad de código basura que se genera y la mala gestión de memoria es un derroche.

De lo que no cabe duda, es que el programador es quien conoce y puede programar la maquina en cualquier momento, eso no se lo puedes quitar a los que programan a bajo nivel.... y es algo necesario. Precisamente por esto los chicos de Electronica muchas veces tienen mas derecho que los que somos informaticos a decir dos o tres cosas sobre los ordenadores.
Si yo no quito nada a nadie, todo lo contrario, para mi todo aquel que sea bueno en su campo, me da igual si a bajo nivel o con ajax/python/... haciendo aplicaciones online dinamicas, tienen todo mi respeto :) a mi me la... y no hago distinciones entre cada cual pues cada uno es necesario. Yo mismo, me encanta programar juegos y/o aplicaciones multimedia pero si no fuera por aquellos que han desarrollado desde el editor que uso que me tiene enamorado (sublime text 2) a las empresas/organizaciones que se encargan de opengl o la empresa que crea y mantiene el sdk que uso, no podria hacer yo mi trabajo en el mismo tiempo con la misma calidad y rendimiento que lo hago ahora pues tendria que hacer muuucho trabajo por debajo que ya me dan a punto de caramelo.

Que podria aprender a hacer todo "desde cerito" y sin usar libreria alguna, podria... realmente me es util para mi campo? no mucho pues para cualquier consola o movil o pc me es mucho mas practico usar algun motor, sdk, framework que ya tenga opcion de compilado para dicho sistema y herramientas de carga de modelos, gestion de shaders, etc..

Ya me hice una documentacion, que me tire un mes enterito sin parar, de practicamente todo (porque al final me sature y lo deje casi al final xD) lo relacionado con c64 y como programar para el sabiendo hata el ultimo detalle de como se gestiona todo y si, muy curioso pero...pasando xD que algun dia igual haga algun jueguito simple por probar? tal vez pero que prefiero la linda abstraccion y librerias bien curradas? si padre. Que no sere el dios de la programacion? nunca he dicho que lo sea xD es mas, si yo fuera mi padre o alguien cercano a mi, no me dejaria tocar un pc pues tengo mas peligro que un niño tonto.

Edit: A mi lo unico que me toca la moral, como creo que le ocurriria a cualquiera, es que se generalice con cosas como esta pues me dejo los huevos en cada aplicacion que hago y pruebo todo lo pensable, dentro del tiempo que se me da y no sera por no meter horas..., para optimizar todo lo posible y que vaya siempre estable y sin bugs, que es mas importante que optimizar al 101% todo pues a partir de cierto punto la optimizacion es anecdotica. Vamos que es como o sin el como, un menosprecio al trabajo de los programadores en plan "son todos unos vagos, antes se curraba de verdad"...sera... Edit: Y no lo digo a malas, porque se que la gente no hace los comentarios con mala idea... pero joe, que parece que somos lo mas tonto y poco currante que se ha parido.
Eldiscipulo escribió:En el caso del informático programador, si que se necesita saber como funciona "el boligrafo".


soy informático programador con 7 años de experiencia y no sé como funciona "el boligrafo" además que no veo relación entre el símil y el caso expuesto...

para un informatico programador, el "boli" no es el programa. Si a mi me piden modificar un programa de hace mil años, el programa no es el boli, ni siquiera el lenguaje de programación es el boli, ni el soporte donde se encuentra (servidores y demás). Eso como mucho es el papel.

El boli de un programador es el framework que use. que puede ser eclipse, o el bloc de notas de windows o, si me apuras, hasta un boli bic tal cual sobre un folio de papel. Un buen programador es capaz de programar hasta con el ordenador apagado (cosa que he tenido que hacer más de una vez...)

y sinceramente, no se cual es el código fuente de los framework que he usado, que aunque no estaría de más saberlo, de momento no lo he necesitado...
Que conste que el símil no lo elegí yo. El paralelismo esta en que el ordenador es la herramienta con la que trabajas y enfrente de la que te pasas posiblemente entre 9 y 12 horas sentado y es el objeto final de todo tu trabajo y tienes que programar pensando en como se va a ejecutar el programa en la maquina..... y ensamblador y los lenguajes de bajo nivel lo que hacen precisamente es trabajar con los registros de la maquina y tal de forma directa. De hecho ese lenguaje se enseña para que la gente tenga idea de como es la arquitectura interna de la maquina.

Si se te pide modificar un programa del cual no tienes fuente, da igual la cantidad de frameworks y herramientas que tengas a tu alcance, que vas a tener que mirar registros, zona de memorias, ver lo que contiene, como se procesa... como ejecuta el ordenador el programa y a partir de ahí empezar a modificarlo. Eso le guste a mucha gente o no, tambien es programar el ordenador, implica conocer a fondo la maquina, y se espera que los ingenieros informaticos programadores sepan hacerlo. Hay que saber como funciona un ordenador por que se es INFORMATICO y se busca eficiencia y calidad. Por que las competencias de un informático son mucho mas que programar, no nos devaluemos.

Como dije antes y me autocito :
Eldiscipulo escribió:¿Se programa peor hoy en dia? No, se programa distinto, el paradigma es diferente, no se pueden comparar peras con manzanas. ¿Es mas rápido de hacer a alto nivel? Sí, esto sin duda, pero trabajar a bajo nivel tampoco lleva tanto tiempo como supone la gente. ¿Es mas eficiente hacer algo a alto nivel? No, rotundamente no, la cantidad de código basura que se genera y la mala gestión de memoria es un derroche.
Un buen programador es capaz de programar hasta con el ordenador apagado...
Y no te digo que no pero de esa frase es facil sacar que "un programador ha de saber programador todo o adaptarse"...ya...por esa regla de tres te plantan delante el cell de ps3 y ale, hagame vos una demo curradita, le doy dos dias...no hay que pasarse, sin ofender, de listos pues cada uno esta especializado en determinado area y aun tras años se siguen aprendiendo cosas y mejorando y para cada nueva tecnologia, framework/api, lenguaje,... se requiere de un tiempo de adaptacion, mayor o menor e incluso hay campos que si no has estudiado acerca de ello pues no llegaras salvo que te pongas ahora a estudiarlo y probarlo, vamos que no por ser programador "tichin!!!" sabes hacer lo que sea con un ordenador.

Hay que saber como funciona un ordenador por que se es INFORMATICO y se busca eficiencia y calidad. Por que las competencias de un informático son mucho mas que programar, no nos devaluemos.
Yo se como funciona el ordenador en relacion a lo que me interesa (si bien despues conozco a mas bajo nivel pero porque he mirado a lo largo de los años por curiosidad) y necesito y estoy estudiando todo el proceso de renderizado en opengl, aplicacion de shaders en las diferentes fases del proceso, conversion entre espacios,... ademas de repasando y haciendome apuntes algebra lineal, matrices, transformaciones, cuaterniones, c++, optimizacion en lua,... me da que demasiado curro ya tengo con esto y en el trabajo que hago no voy a necesitar desensamblar nada. Como he dicho ya, aqui cada uno se especializa en una o varias areas diferentes y no hay que y realmente no se puede saber todo de todo y a buen nivel...y si es asi, casi seguro perderan el culo para contratarte en algun otro pais xD
57 respuestas
1, 2