Ver la versión completa : El hilo del ocaso de Unity
Hola a todos:
No sabía si poner esto en cosas de PC, en proyectos o qué, pero como no es un contenido exclusivo de un proyecto, lenguaje o consola, pues lo pongo aquí.
Resulta que estaba comiendo, viendo mi ración de videos de yutú correspondiente, cuando veo un vídeo sobre la "polémica" de Unity de hace tres días, del canal secundario de "leyendas y videojuegos", y un par de vídeos más relacionados con el tema. Como tengo varios proyectos pendientes de dar el salto a este motor, por aquello del 3D, por curiosidad, decidí ver el vídeo.
Por lo general, soy muy escéptico (por no decir que no me creo "na") de los vídeos que anuncian el fin de una era, pero tras ver este vídeo, estoy convencido de que se nos va Unity.
https://www.youtube.com/watch?v=ka6QnIrofrM
Os lo resumo: a partir de enero, para las cuentas gratuitas de Unity, cuando un juego llegue a las 200.000 descargas, aprovechando un algoritmo que trae Unity, se le cobrará al desarrollador 0'20$ POR INSTALACIÓN del juego. Da igual que el juego sea gratuito, que salga en GamePass, que sea una reinstalación o que el juego sea pirata: una instalación, tracatrá, a pagar.
Hay que decir que, desde que se notificó, han habido miles de anuncios de empresas grandes quejándose (Silkson lo mismo se retrasa a 2578), de amenazas de borrar juegos de Steam, de cambios en el anuncio, de posibles condenas al CEO de Unity (ex-CEO de EA) por el uso de información privilegiada (lo mismo que le pasó a Yuji Naka, pero por el motivo opuesto), etc etc...
https://www.youtube.com/watch?v=GtG_xvE2538
No sé cómo andará la cosa hoy día, pero ya llevaba tiempo oyendo pestes de Unity, como que había demasiados parches demasiado rápido, que salían nuevas utilidades que, o estaban en versión beta o pasaban directamente a "desfasadas"... total que, @futublock, ¿qué decías tú sobre Godot?
Porque lo último que me gustaría sería hacer un juego gratuito, y que por arte de alguna hechicería vudú, el juego diese un pelotazo muy fuerte, y tuviese que pagar una factura del copón (algunos ejemplos en el primer vídeo).
Pues nada, eso que ¿impresiones? ¿Actualizaciones? ¿Reacciones? ¿Alternativas? ¿usas H&S?
josepzin
18/09/2023, 19:41
Estas cosas en C64 no pasan.
josepzin
18/09/2023, 19:42
Solo soy un espectador, asi que miro desde la distancia estas cosas.
futu-block
18/09/2023, 20:35
Pos si, como amante del software púbico... digo libre, he tirado por godot porque puedo trabajarlo desde mi linux y exportar al windros, que cada vez me gusta menos, y eso que hago el esfuerzo...
parecerá que lo hago por inercia, pero es que cada vez me agobia mas buscar un programa que sea compatible y que tenga que ponerle el crack porque resulta que es de pago y de pago caro, carisimo... después todos los tontos no paran de hablar de ese programa como si fuera el maná y es super difícil de usar cuando hay miles de alternativas para hacer lo que tu quieres, así que vete a la m¡erda potochork
y luego está godot, una especie de ''unity'' para los mas gilipoides que no entienden, que a mi se me está trabando eso de añadir una mierdecilla mas pa que el personaje haga algo mas, despues es mas rentable porque no hace falta programar la susodicha y ojo que lo entrecomillo ''sub-rutina'' pero a poquito a poco se llega lejos, echo de menos un foro, se podría crear aquí una sub-sección para usuarios del lado oscuro de Godot, que está dando el pelotaso, pero no te creas que pierda un poco de fuelle pronto, aunque a mi me da igual, ahora mismo está perfect y no me quiero pasar a la 4
A mi unity nunca me ha llamado la atencion, lo instale hice un tutorial y ahi lo deje.
El dia que me de por hacer algo usare Godot, entiendo que aprender otra herramienta, si tienes un proyecto avanzado o si quieres publicar en todas las plataformas te fastidia bastante, pero habiendo alternativas...
josepzin
18/09/2023, 21:10
El tema es que si buscas curro tienes que saber Unity
El tema es que si buscas curro tienes que saber Unity
Que mal, yo he hecho cosas en 3D pero a pelo. Ultimamente estoy actualizando/rehaciendo una libreria 3D para meterle cosas que he ido aprendiendo.
futu-block
18/09/2023, 23:00
El tema es que si buscas curro tienes que saber Unity
bueno, pa la obra me pidieron el diplomado de hormigonado en concreto
Perdón por usar como fuente un enlace a otro foro pero al parecer se han echado para atrás:
https://www.elotrolado.net/noticias/tecnologia/unity-tarifa-instalacion-juegos
Lo que dijeron era que si el juego (iba a proyecto, no a ganancias en general, por lo que si tienes 2 juegos y uno no genera nada, por ese no pagas), generaba +200k$ y tenía +200k instalaciones, empezarías a pagar por ese juego, que daba igual como fueran los ingresos de ese juego (pago, F2P, anuncios...), realmente esto afectaria a muy poca gente, pero llegados a ese punto, casi compensaba pagar la licencia pro (unos 1800$/año), ya que iban a quitar la plus (unos 400$/año).
El mayor problema de esto es, además de la desconfianza que ha generado con respecto a "te cambio las condiciones con caracter retroactivo cuando me sale de los webos", es: cómo van a hacer para controlar esas instalaciones?? qué tipos de datos se están compartiendo obligatoriamente al instalar un juego creado con Unity??? recordad que Unity compró una empresa que estaba especializada en hacer instaladores con "malware" (vamos, el típico instalador que te mete mil mierdas por detrás...)...
Ahora parece que se han echado para atrás (iban a perder más de lo que tenían previsto ganar), ya que muchas compañias, indies y demás relativamente grandes, anunciaron que retirarian sus juegos de las tiendas y que dejaban de usar Unity para futuros proyectos... "Os hemos escuchado. Pedimos disculpas..." pero la desconfianza ya está ahí (bueno, ya estaba, pero ahora ha explotado más).
Yo sigo pensando, que tenemos mucha dependencia de ciertos software propietarios y que no dejan de ser empresas que lo que le interesa es ganar, ganar y ganar.
El futuro del open source pasa porque Godot se convierta en el Blender de los engines de juegos....
saboteur
19/09/2023, 09:00
No dicen que se hayan echado atrás, sino que van a hacer cambios. Para mí que intentarán meterlo poco a poco para que duela menos.
Y lo raro es que el CEO parece estar oculto en el maletero de un coche esperando que pase el temporal.
Bueno sí, han pedido disculpas y van mirar las opiniones y tal, pero que si no meten el dedo índice por el culo, van a meter el pulgar... Parece que Unity tiene pérdidas y hay que sacar pasta por otro lao (o que no están ganando lo que quieren, que esa puede ser otra opción), el caso es que necesitan/quieren más ingresos y tienen que cambiar el modelo... a ver con que nos sorprende después xD
Es legítimo que Unity quiera cobrar más por las licencias de su motor, pero no la manera de hacerlo por instalaciones en la que el desarrollador no tienen ningún control. Además de que han cambiando las condiciones en pocos días desde el anuncio y ni siquiera ellos saben que hacer. Tiene pinta de que ha sido una idea loca de algún directivo que a la hora de definirla técnicamente no se sostiene por ningún sitio. Pensando mal no les trae cuenta detectar bien las copias piratas, porque si las detectan mal cobran más. Además de que es imposible, junto con la idea de hacer pagar a las tiendas digitales de videojuegos por las instalaciones. Veremos en que queda, pero lo que pienso es que lo suavizarán o cambiarán el modelo.
Sobre lo de cambiar de motor para los juegos, no es tan fácil porque cada motor tiene una API y una metodología, al final se puede hacer pero con unos costes que dependen de la complejidad del videojuego. En proyectos nuevos es posible, pero dile a los de Subnáutica que se cambien a Unreal, verás la risa tonta que les va a dar. Lo peor de todo es que Unity es un buen motor y un buen entorno, pero se van a ir al carajo y su imagen ya está manchada por culpa de la avaricia de sus políticas.
Es que lo dicen en el segundo vídeo: por lo visto, el actual CEO fue el antiguo CEO de EA, una de las empresas adalides de las microtransacciones y creadores de las cajas de botín aleatorias. Y parece que, en su momento (ojo, información no contrastada), fue despedido por proponer políticas de pago demasiado agresivas.
El comunicado de Unity no deja de ser más que una disculpa formal:
https://twitter.com/unity/status/1703547752205218265
"Os hemos escuchado" es la fórmula estándar de iniciar una disculpa porque los han pillado. "Nos disculpamos por la confusión sobre...", no dice que sea un error, sino que se han equivocado, como si hubieran querido decir otra cosa a la que ha entendido la gente, o sea, ¿que es culpa de la gente haber entendido mal sus nuevas tarifas?. "Hemos hablado con (...) y estamos haciendo cambios en nuestra política [de pagos]", o sea, que va a haber cambios en las tarifas sí o sí, esperemos que no la caguen más por las prisas. Y termina en un saludo en plan peloteo.
A ver, no estoy en contra de que quieran cobrar por su producto, es su derecho. Es más, a mi me sorprendió que, algo tan grande, tan potente y tan profesional fuera gratuito, aún con limitaciones. Yo empecé en la v4, y con la v5 añadieron aún más contenido que antes era de pago. Y sí, es gratuito hasta que el juego se convierte en un éxito, momento en que hay dinero para pagar una licencia, y eso era perfecto... Pero estos cambios iban a provocar que más de un desarrollador indie acabe en la quiebra por tener un éxito que no se esperaba... Y los grandes no se librarían: si un juego vendía la mitad de lo que se pirateaba, aun así podía tener muchos beneficios, pero con esto se penalizaría un montón.
Luego está el tema de cómo cuentan las instalaciones... bueno, con que el instalador mande una petición a una web cada vez que se ejecute correctamente, ya lo tienes. Hay muchísima información que se manda sólo para depuración y mediciones estadísticas por detrás, ya no sólo los datos del crash, el volcado de memoria, en qué nivel te matan más, o cuántos logros llegas a conseguir, también un identificador, configuración del sistema, HW utilizado... Cuando me lo dijeron me dieron escalofríos. Claro, es una herramienta excelente para depuración... pero es que hay empresas que lo dejan activo en la versión "release" y la usan para recabar datos con fines publicitarios o de cara a futuros proyectos (y no en el buen sentido).
Y es lo que decís, ahora mismo, la confianza en Unity está por los suelos. Yo ya tenía mis dudas de si empezar algo en Unity, o probar Unreal Engine, pero visto lo visto, casi que prefiero darle una oportunidad a Godot, igual que en su día decidí dejar de piratear y pasarme a Gimp, Blender, Audacity o KDEnLive. Me ha quitado las ganas hasta de irme a su competencia comercial más directa.
Respecto a cómo es Unity en sí: no es una herramienta que se aprenda a manejar en unos pocos tutoriales. La cantidad de herramientas que trae es bestial, tanto que una persona difícilmente puede llegar a abarcarlas todas. Hay herramientas para programación (aunque la principal no deja de ser Visual Studio de M$), para animación, para sonido, efectos, físicas... ahorra mucho trabajo, pero hay cosas que, si no eres el grafista o el programador, no tocas jamás. Es más, hay proyectos que no usan ni el 10% de las capacidades del entorno. Y por cómo está planteado, no sé cómo se puede portar un proyecto sin empezar de cero, porque en ocasiones, hasta los assets los haces en el propio Unity.
Es justo eso, Unity tiene todo el derecho del mundo de querer ganar dinero, pero no es ni medio normal el cómo lo han hecho (sobre todo por el tema del caracter rectroactivo), otra cosa es que las medidas que tomen sean mejores o peores, yo hubiera optao por una mayor variedad de licencias, con entradas de ganancias menores y progresivas (por ejemplo), pero claro, todo es muy facil visto desde la silla de tu casa jejeje
Con el tema de cambio de motor, totalmente de acuerdo con hardyx, pero con una excepción, una vez que aprendes Game Desing y conoces un motor, cambiar a otro cuesta mucho menos ya que suelen tener elementos comunes y definiciones "equivalentes", pasa lo mismo cuando cambias de un lenguaje de programación a otro (me pasó con el testing en PHP, cuando llegué a hacerlo en React que no lo había visto en la vida, el sistema era el mismo, por lo que no me costó mucho aprender esa nueva forma de hacerlo).
A día de hoy, Unity ha perdido muchos usuarios actuales y potenciales, solamente por el hecho de que han dado la imagen de "Unity es mio y me lo follo cuando quiero", hoy no te afectan los cambios, pero mañana el CEO se levanta del otro lao de la cama y te tocan....
Que moñas que es la gente, a ver si programan más en C con las SDL :D
josepzin
19/09/2023, 13:19
Ahí, ahí, pero la gente se ha vuelto muy vaga y quieren que un maker les haga todo el trabajo.
Le voy a pedir a ChatGPT que me cree un maker con el que pueda trabajar...y una vez lo tenga, le pediré que haga los juegos!
(...)
Con el tema de cambio de motor, totalmente de acuerdo con hardyx, pero con una excepción, una vez que aprendes Game Desing y conoces un motor, cambiar a otro cuesta mucho menos ya que suelen tener elementos comunes y definiciones "equivalentes", pasa lo mismo cuando cambias de un lenguaje de programación a otro (me pasó con el testing en PHP, cuando llegué a hacerlo en React que no lo había visto en la vida, el sistema era el mismo, por lo que no me costó mucho aprender esa nueva forma de hacerlo).
(...)
Estoy de acuerdo con la parte que he omitido. De hecho, el modelo de Unity era ese: más ganabas, más pagabas, pero claro, era responsabilidad de la empresa de desarrollo decir a cuánto ascendían las ganancias, y ahí cualquiera podía hacer trampas: "sí, he vendido 300000 unidades, pero si descuento las unidades gratuitas, las de prensa y lo que hemos gastado este año en cafés viendo si las cifras subían, hemos ganado en total 100€".
Y sí, han perdido confianza.
Ahora bien, eso de que "cambiar de motor es sencillo" no lo tengo yo tan claro.
Por un lado, cambiar de lenguaje, aunque sean muy similares, siempre trae consigo una serie de herramientas que uno tiene y el otro no. Yo aprendí Java, y luego tuve que aprender C#, y aunque básicamente son iguales, hay muchas cosas en C# que no había ni olido en Java, como LinQ o el binding de variables, y sólo con eso me ahorro el tener que crear funciones para listas o andar actualizando la interfaz constantemente.
Por otro lado, al igual que existen los "false friends" en inglés (palabras en inglés, que suenan como otras en español, pero tienen un significado totalmente distinto...), también puede suceder con funciones en los lenguajes. Yo tengo que hacer constantemente doble y triple check para saber si el valor de tamaño declarado al crear un array tiene en cuenta el valor 0 o 1 a la hora de contar, según el lenguaje (y todavía me peleo con el do...while o el repeat...until o cualquier combinación).
Incluso dentro del mismo lenguaje: fíjate que llevo años haciendo WebApis para APPs móviles, y ahora tengo que hacer webs en .NET Core, que también tienen controllers, models y vistas... y mi tutor se empeña en que no debo mezclar conceptos, aunque se llamen igual.
Por eso digo, cógelo con pinzas.
Como contraejemplo, diré que el aprender a usar los procesos de DIV, me sirvió de mucho a la hora de enfrentarme a las instancias de Unity, que vienen a ser lo mismo, pero sin un "frame" que me las sincronicen.
Que moñas que es la gente, a ver si programan más en C con las SDL :D
Ahí, ahí, pero la gente se ha vuelto muy vaga y quieren que un maker les haga todo el trabajo.
Llevo años oyendo a programadores con mucha más experiencia que yo, diciéndome que deje de reinventar la rueda.
Y cuando hay un programa que gestiona los objetos por mi, que incorpora un motor de scroll ya hecho, y todas las funciones para detectar y hacer funcionar las colisiones... es decir, el 90% del código que se repite de un proyecto a otro, y ahora salís a decir que hay que ser flojo...
¡Iros a programar en ASM en una Atari 2600!
:D :D :D
PD: ¿Por qué SDL y no OpenGL?
¿Porque se supone que necesitas sonido en un juego?
¿Porque se supone que necesitas sonido en un juego?
No seas moñas y usa OpenAl u otras libs de sonido, y create tus rutinas de I/O :lol:
No, en serio, me estoy planteando probar a hacer algo con 3D y no sé si hacerlo con SDL u OpenGL... o si eso es demasiado bajo nivel. Quiero ver si se puede pasar XNALara a algo que no sea XNA, y creo que es más fácil empezar por algo ya medio hecho que empezar de cero ¿no?
selecter25
19/09/2023, 19:41
Te quitan 2 cosas, te "devuelven" 1 y parecen hasta buenos, "os hemos escuchado", xDD.
Lo que no dicen es que han quitado Unity Plus y han dejado solo el Pro. Antes por 400$ (Plus) tenías ciertos beneficios para devs pequeñitos, entre los que entraba quitar el splash logo de Unity de tu juego. Ahora si no quieres que tu juego lo muestre, te toca pagar 1800$ por la Pro, menudos genios.
masteries
19/09/2023, 19:57
Que moñas que es la gente, a ver si programan más en C con las SDL :D
Como todo lo hago en C, y a veces hay algo de ensamblador por debajo...
y estructuro el código para que todo funcione como Fénix/Bennu,
que para hacer juegos (y otros programas en Tiempo-Real)
es una manera comodísima de programar y organizar las cosas.
De hecho, si recuerdo bien, los integrantes clásicos de ID software (no el ID moderno)
lo han hecho todo en C, desde el primer Doom hasta el último.
bueno, pa la obra me pidieron el diplomado de hormigonado en concreto
concreto de especifico o concreto de cemento?
futu-block
19/09/2023, 23:08
si... :awesome:
y los demas, no darsela de tan chulo y programadores, no sabeis el calvario que es programar en binario con un telegrafo T_T
josepzin
19/09/2023, 23:59
Programar en binario usando el telégrafo es lo mas facil del mundo, solo tienes que darle como loco a la palanquita.
fbustamante
20/09/2023, 06:59
Eso, menos samba y más programar. :D
55705
(Ya se que lo habíais puesto, pero esta es la versión resumida y ahora se ve. :D)
Viendo la imagen es para hacer single-button-games para la gente mayor y te forras, suponiendo que sean capaces de descargar la aplicacion :D
Te quitan 2 cosas, te "devuelven" 1 y parecen hasta buenos, "os hemos escuchado", xDD.
Lo que no dicen es que han quitado Unity Plus y han dejado solo el Pro. Antes por 400$ (Plus) tenías ciertos beneficios para devs pequeñitos, entre los que entraba quitar el splash logo de Unity de tu juego. Ahora si no quieres que tu juego lo muestre, te toca pagar 1800$ por la Pro, menudos genios.
Cuando yo hice el Máster, con la v4 había cosas a las que no tenías acceso, como el occlusion culling, el Level Of Detail, o bakear las luces de una sala (una función que "pintaba" las luces y sombras en las texturas del escenario, y luego simplificaba las luces que recibía el prota según la zona). Todo eso se hizo gratis en la v5, por lo que no entiendo por qué han mantenido las cosas gratis, y han penalizado tan severamente los juegos sin licencia con éxito.
Si necesitan dinero, pueden volver a eliminar funcionalidad para atraer a más gente a su versión de pago mínima: una versión recortada gratis, una versión con muchas utilidades desbloqueadas por 30€-60€ al año, y mantener las licencias plus y pro. Yo creo que por ese precio, mucha gente que usa la gratis se apunta a la básica, igual que mucha gente que pirateaba se pasó a Netflix.
Yo creo que les hace falta dinero: Unity ha crecido más de lo que esperaban y no tienen recursos para dar tanto soporte... aparte que UE5 salió hace relativamente poco y les está comiendo mucha cuota de mercado.
Como todo lo hago en C, y a veces hay algo de ensamblador por debajo...
y estructuro el código para que todo funcione como Fénix/Bennu,
que para hacer juegos (y otros programas en Tiempo-Real)
es una manera comodísima de programar y organizar las cosas.
Esto es interesante ¡Cuénta más! por favor.
De hecho, si recuerdo bien, los integrantes clásicos de ID software (no el ID moderno)
lo han hecho todo en C, desde el primer Doom hasta el último.
Sí, ya ¿Hasta qué año? ¿Hasta el 2007, cuando hacer un juego medianamente grande es imposible hacerlo de cero sin una librería o un motor?
De hecho ¿el motor Source no nació de las herramientas de diseño que se usaron para hacer versiones de Doom o Quake de esos años, más o menos?
Eso, menos samba y más programar. :D
Jo ¿Y cómo comunico mis juegos con carpetas de red sin Samba? :awesome:
masteries
20/09/2023, 13:34
Esto es interesante ¡Cuénta más! por favor.
Sí, ya ¿Hasta qué año? ¿Hasta el 2007, cuando hacer un juego medianamente grande es imposible hacerlo de cero sin una librería o un motor?
De hecho ¿el motor Source no nació de las herramientas de diseño que se usaron para hacer versiones de Doom o Quake de esos años, más o menos?
Empiezo por Doom; hasta Doom 2016 sé que está escrito en C+OpenGL y C+Vulkan;
el motor gráfico y de modelos (que tienen esqueleto claro) se escribió desde 0
todavía participó Carmack en este desarrollo, supongo que haciendo las funciones de
director de orquesta, e implementando aquellas partes en las que hacía falta una experiencia
en motores gráficos como la que tiene este señor.
También transmitió el mensaje de que la librería Vulkan te permite hacer cosas con el hardware
que tanto OpenGL como DirectX no te dejan, como crear nuevas fuentes de interrupción a nivel
interno en la tarjeta gráfica... bueno no hace falta decir mucho sobre lo bien que funciona
el motor de Doom 2016 bajo Vulkan; con un i5 de tercera generación y una RX 480 de 4GB;
a 1080p con todo en Ultra el juego se mantiene en más de 160 fps, abrasándose la RX 480
(siempre puedes activar el sincronismo vertical y quedarte con los fps que marque el
refresco vertical de tu monitor).
Así mismo se quejó de que con OpenGL no lograba sacarle el rendimiento que esperaba
al hardware de vídeo puntero en ese momento, pues no le dejaba plantear el funcionamiento
del dibujado en pantalla con las propiedades que Vulkan le estaba ofreciendo.
------------------------------
Ahora vamos a esto:
"Como todo lo hago en C, y a veces hay algo de ensamblador por debajo...
y estructuro el código para que todo funcione como Fénix/Bennu,
que para hacer juegos (y otros programas en Tiempo-Real)
es una manera comodísima de programar y organizar las cosas."
Te cuento de forma muy resumida:
Dado que le estamos dando duro a las máquinas antiguas; encuentras
funciones de vídeo para ellas; pero no dejan de ser algo relativamente básico,
te permiten dibujar sprites en pantalla y se encargan de gestionar los accesos
al cartucho cuando el frame del sprite cambia...
y ya está, no hay más; ni gestión de mapeados, ni durezas del mapa, ni colisiones entre sprites,
ni gestión del orden de dibujado, ni un mecanismo ni siquiera básico para que organices las funciones
que proporcionan funcionalidad a los sprites...
Todo eso te lo tienes que hacer a mano; así que después de mucho currar durante meses
en un motor 2D multiplataforma, pues tengo un repertorio de funciones como:
Identificador = EntitySpawn(tipo de entidad, posición x en el mapa, posición y en el mapa);
Identificador funciona como en Fénix/Bennu; te proporciona acceso a las variables internas
del proceso, que puede ser un sprite o no: Identificador.xworld , Identificador.yworld, Idenficador.layer,
identificador.health... y así
EntityRemove(Identificador);
Para eliminar un proceso de la lista de funciones tick a ejecutar.
Luego hay una lista de tick functions que se ejecutan al final,
dado que cada tipo de entidad declarada tiene asignada su función,
lo que viene a ser el process() de Fénix/Bennu
Y ya al final de todo, la lista de dibujado; ahora mismo dispongo de 6 capas
de dibujado; cada proceso tiene asignada una capa (layer) distinta.
En esa lista de dibujado también están los tiles de los planos de scroll;
en Atari STE y Megadrive, los planos de scroll son persistentes,
en el STE es un frame buffer del que debes limpiar los sprites, o parte
de los sprites si corresponde.
En MD la información sobre la posición de los tiles es persistente,
y o bien la actualizas (escribiendo y borrando valores de la tabla,
y si es necesario también escribes nuevos tiles encima de tiles
que ya no se muestren en pantalla).
En N64 tanto el mapeado como los sprites funciona todo igual,
todo son sprites o texturas colocadas sobre superficies definidas
por cuatro vértices; así que en cada pasada redibujas todo.
Con lo potente que es su adaptador de vídeo y CPU para dibujado 2D,
pierdes más tiempo en limpiar sprites del frame buffer,
que en redibujarlo todo.
El concepto de tablas con información de tiles para el mapeado
e información de los sprites es muy del mundo arcade de 16 bits;
y de MD y SNES; las máquinas de años posteriores perderían esas
capacidades hardware, pues son potentes, pero te limitan bastante
en lo que puedes llegar a hacer, pues están orientadas sólo a juegos 2D
y encajan mal con otros planteamientos de juego.
selecter25
20/09/2023, 15:38
Cuando yo hice el Máster, con la v4 había cosas a las que no tenías acceso, como el occlusion culling, el Level Of Detail, o bakear las luces de una sala (una función que "pintaba" las luces y sombras en las texturas del escenario, y luego simplificaba las luces que recibía el prota según la zona). Todo eso se hizo gratis en la v5, por lo que no entiendo por qué han mantenido las cosas gratis, y han penalizado tan severamente los juegos sin licencia con éxito.
Si necesitan dinero, pueden volver a eliminar funcionalidad para atraer a más gente a su versión de pago mínima: una versión recortada gratis, una versión con muchas utilidades desbloqueadas por 30€-60€ al año, y mantener las licencias plus y pro. Yo creo que por ese precio, mucha gente que usa la gratis se apunta a la básica, igual que mucha gente que pirateaba se pasó a Netflix.
Yo creo que les hace falta dinero: Unity ha crecido más de lo que esperaban y no tienen recursos para dar tanto soporte... aparte que UE5 salió hace relativamente poco y les está comiendo mucha cuota de mercado.
Que necesiten más dinero lo puedo entender, lo que cuestiono es cómo y de dónde lo quieren sacar, el tema del cobro por instalaciones por el "servicio de descarga del runtime" es ridículo, y el pasar de un plan "premium" mínimo de 399$ (que ya subieron en 2020, por cierto) a uno de 1800$, es otra barrabasada. Que no hablamos de una empresa indie! Menudas cabezas pensantes.
Yo no sé que ñoco se les ha pasado por la cabeza para intentar esto, pero espero que independientemente de que reculen o no, la gente reaccione y suponga una gran patada en sus gónadas a nivel económico. Que sí, que a nivel comunidad, soporte, librerías, assetts... Godot está en pañales y que UE5 para la mayoría de proyectos es matar moscas a cañonazos, pero quizás este sea el detonante que haga a Godot el "Blender" de los engines.
Empiezo por Doom; hasta Doom 2016 sé que está escrito en C+OpenGL y C+Vulkan;
el motor gráfico y de modelos (que tienen esqueleto claro) se escribió desde 0
todavía participó Carmack en este desarrollo, supongo que haciendo las funciones de
director de orquesta, e implementando aquellas partes en las que hacía falta una experiencia
en motores gráficos como la que tiene este señor.
También transmitió el mensaje de que la librería Vulkan te permite hacer cosas con el hardware
que tanto OpenGL como DirectX no te dejan, como crear nuevas fuentes de interrupción a nivel
interno en la tarjeta gráfica... bueno no hace falta decir mucho sobre lo bien que funciona
el motor de Doom 2016 bajo Vulkan; con un i5 de tercera generación y una RX 480 de 4GB;
a 1080p con todo en Ultra el juego se mantiene en más de 160 fps, abrasándose la RX 480
(siempre puedes activar el sincronismo vertical y quedarte con los fps que marque el
refresco vertical de tu monitor).
Así mismo se quejó de que con OpenGL no lograba sacarle el rendimiento que esperaba
al hardware de vídeo puntero en ese momento, pues no le dejaba plantear el funcionamiento
del dibujado en pantalla con las propiedades que Vulkan le estaba ofreciendo.
------------------------------
Ahora vamos a esto:
"Como todo lo hago en C, y a veces hay algo de ensamblador por debajo...
y estructuro el código para que todo funcione como Fénix/Bennu,
que para hacer juegos (y otros programas en Tiempo-Real)
es una manera comodísima de programar y organizar las cosas."
Te cuento de forma muy resumida:
Dado que le estamos dando duro a las máquinas antiguas; encuentras
funciones de vídeo para ellas; pero no dejan de ser algo relativamente básico,
te permiten dibujar sprites en pantalla y se encargan de gestionar los accesos
al cartucho cuando el frame del sprite cambia...
y ya está, no hay más; ni gestión de mapeados, ni durezas del mapa, ni colisiones entre sprites,
ni gestión del orden de dibujado, ni un mecanismo ni siquiera básico para que organices las funciones
que proporcionan funcionalidad a los sprites...
Todo eso te lo tienes que hacer a mano; así que después de mucho currar durante meses
en un motor 2D multiplataforma, pues tengo un repertorio de funciones como:
Identificador = EntitySpawn(tipo de entidad, posición x en el mapa, posición y en el mapa);
Identificador funciona como en Fénix/Bennu; te proporciona acceso a las variables internas
del proceso, que puede ser un sprite o no: Identificador.xworld , Identificador.yworld, Idenficador.layer,
identificador.health... y así
EntityRemove(Identificador);
Para eliminar un proceso de la lista de funciones tick a ejecutar.
Luego hay una lista de tick functions que se ejecutan al final,
dado que cada tipo de entidad declarada tiene asignada su función,
lo que viene a ser el process() de Fénix/Bennu
Y ya al final de todo, la lista de dibujado; ahora mismo dispongo de 6 capas
de dibujado; cada proceso tiene asignada una capa (layer) distinta.
En esa lista de dibujado también están los tiles de los planos de scroll;
en Atari STE y Megadrive, los planos de scroll son persistentes,
en el STE es un frame buffer del que debes limpiar los sprites, o parte
de los sprites si corresponde.
En MD la información sobre la posición de los tiles es persistente,
y o bien la actualizas (escribiendo y borrando valores de la tabla,
y si es necesario también escribes nuevos tiles encima de tiles
que ya no se muestren en pantalla).
En N64 tanto el mapeado como los sprites funciona todo igual,
todo son sprites o texturas colocadas sobre superficies definidas
por cuatro vértices; así que en cada pasada redibujas todo.
Con lo potente que es su adaptador de vídeo y CPU para dibujado 2D,
pierdes más tiempo en limpiar sprites del frame buffer,
que en redibujarlo todo.
El concepto de tablas con información de tiles para el mapeado
e información de los sprites es muy del mundo arcade de 16 bits;
y de MD y SNES; las máquinas de años posteriores perderían esas
capacidades hardware, pues son potentes, pero te limitan bastante
en lo que puedes llegar a hacer, pues están orientadas sólo a juegos 2D
y encajan mal con otros planteamientos de juego.
Ah, entiendo. O sea, que haces una lista de elementos que simulan los procesos, que ejecutan una función de acuerdo a su "tipo", y cuando todo está ejecutado, empiezan las funciones de "renderizado".
Es que como has dicho "C", y yo veía más práctico el uso de "C++", por el tema de usar clases, con sus propias funciones ya integradas, y poder emplear señales, o llamadas a funciones entre procesos (que sería más o menos lo mismo), pues eso, que no lo veía ^^U Al fin y al cabo, Unity funciona así, con métodos para antes de render, después de render y otros momentos del "frame".
Sé que he simplificado demasiado algo que tú ya habías simplificado, pero, creo que más o menos ¿lo he entendido?.
Que necesiten más dinero lo puedo entender, lo que cuestiono es cómo y de dónde lo quieren sacar, el tema del cobro por instalaciones por el "servicio de descarga del runtime" es ridículo, y el pasar de un plan "premium" mínimo de 399$ (que ya subieron en 2020, por cierto) a uno de 1800$, es otra barrabasada. Que no hablamos de una empresa indie! Menudas cabezas pensantes.
Yo no sé que ñoco se les ha pasado por la cabeza para intentar esto, pero espero que independientemente de que reculen o no, la gente reaccione y suponga una gran patada en sus gónadas a nivel económico. Que sí, que a nivel comunidad, soporte, librerías, assetts... Godot está en pañales y que UE5 para la mayoría de proyectos es matar moscas a cañonazos, pero quizás este sea el detonante que haga a Godot el "Blender" de los engines.
De eso hablamos, que a saber en qué andaban pensando. Si me dices que ha habido un cambio de CEO en los últimos 3 años, pues me lo creo, pero me parece que está el mismo tipo al cargo de Unity desde hace más de una década.
Pero es lo que dicen, que el tío era el que propuso microtransacciones en FIFA, o cobrar por los cargadores en Call of Duty.
Si precisamente, el dar gratis Unity a los pequeños desarrolladores es lo que les está haciendo mucho bien, y le han copiado la fórmula hasta los de M$ en Visual Studio con la licencia "comunity".
Han hecho lo contrario a lo que tendrían que haber hecho: en lugar de reducir las licencias a 2, ampliarlas a 4 o 5 (o limítalas por número de plataformas a las que se puede exportar). Mantener gratis el producto para los novatos que hacen juegos por diversión, o permitirles pagar una versión barata a los que saben que pueden dedicarle un poco más de tiempo, pero no saben si montar un estudio o si ganarán algo. Buscar una manera de saber cuánto se vende un juego, y no hacerlo de manera que el desarrollador no pueda detener el conteo cuando la cosa se va de madre (para bien o para mal). Monetiza las microtransacciones, pero no un juego que es gratis de base. Sube assets a tu propia tienda, o sube un poco el porcentaje de ganancias sobre los mismos. ¿Unity no tiene soporte para publicidad? pues saca dinero de ello (a ver si así los eliminan de una vez de todos los juegos :D).
Esta montado como un ECS, en una plataforma antigua (sin cache) no te da las ventajas de una moderna (las jerarquías de clases no son muy eficientes), pero queda un código mas simplificado.
selecter25
20/09/2023, 22:20
De eso hablamos, que a saber en qué andaban pensando. Si me dices que ha habido un cambio de CEO en los últimos 3 años, pues me lo creo, pero me parece que está el mismo tipo al cargo de Unity desde hace más de una década.
Pero es lo que dicen, que el tío era el que propuso microtransacciones en FIFA, o cobrar por los cargadores en Call of Duty.
Si precisamente, el dar gratis Unity a los pequeños desarrolladores es lo que les está haciendo mucho bien, y le han copiado la fórmula hasta los de M$ en Visual Studio con la licencia "comunity".
Han hecho lo contrario a lo que tendrían que haber hecho: en lugar de reducir las licencias a 2, ampliarlas a 4 o 5 (o limítalas por número de plataformas a las que se puede exportar). Mantener gratis el producto para los novatos que hacen juegos por diversión, o permitirles pagar una versión barata a los que saben que pueden dedicarle un poco más de tiempo, pero no saben si montar un estudio o si ganarán algo. Buscar una manera de saber cuánto se vende un juego, y no hacerlo de manera que el desarrollador no pueda detener el conteo cuando la cosa se va de madre (para bien o para mal). Monetiza las microtransacciones, pero no un juego que es gratis de base. Sube assets a tu propia tienda, o sube un poco el porcentaje de ganancias sobre los mismos. ¿Unity no tiene soporte para publicidad? pues saca dinero de ello (a ver si así los eliminan de una vez de todos los juegos :D).
Es que eso ya lo hacían, te dan la opción de monetizar la publi con ellos (para que a ti te salga más barata y ellos pillen cacho) o de gestionarla por tu cuenta y pagar tarifas más altas.
Es un disparo en el pie. Cómo sé yo que las cifras de instalaciones que monitorizan son reales? Cómo impido que un tipo de la competencia cree un bot que instale mi juego 30.000.000 de veces y me arruine?
PD: Los creadores de Terraria se han sacado el rabo
55706
futu-block
21/09/2023, 00:37
eah, ahora tol mundo pasandose a godot...
si es que la moda es lo que tiene, que atrae a los tontos
Es que eso ya lo hacían, te dan la opción de monetizar la publi con ellos (para que a ti te salga más barata y ellos pillen cacho) o de gestionarla por tu cuenta y pagar tarifas más altas.
Es un disparo en el pie. Cómo sé yo que las cifras de instalaciones que monitorizan son reales? Cómo impido que un tipo de la competencia cree un bot que instale mi juego 30.000.000 de veces y me arruine?
Más que eso. Suponte que tu juego tiene éxito, y que en la España de los 90, o en paises donde aún la piratería está a la orden del día, la gente empieza a instalarlo de forma ilícita. ¿Cómo previenes que la gente se lo instale? ¿Quitando el juego de la tienda? no, ya está en Internet. Puedes eliminar todas tus fuentes pero siempre habrá formas de descargarse el juego, y no puedes hacer nada por evitarlo, vas a seguir pagando hasta que te arruines, mientras Unity es el único que se beneficia de la piratería.
Habrá quien diga que eso hará que las propias desarrolladoras luchen contra la piratería, pero ¿qué lucha va a hacer un chaval de 15 años que ha subido su juego gratis o por unos 5€?
La única forma efectiva de saber cuánta gente se ha descargado tu juego es que, como la mayoría de usuarios se dedican a crear juegos para móvil, pueden mirar las descargas en la Google Play Store... pero aún así, la GPS sólo cuenta instalaciones únicas, no cuenta si desinstalas el juego y lo vuelves a instalar, aunque sea un dispositivo diferente. Pero eso no es lo que hacen las ex-nuevas políticas de Unity.
eah, ahora tol mundo pasandose a godot...
si es que la moda es lo que tiene, que atrae a los tontos
O sea, que si me paso a Godot soy tonto? :lol:
Unity no es que estuviera de moda: es que era la única plataforma de desarrollo de videojuegos, con la potencia para atraer a gente que no son ingenieros, y con licencias de desarrollo gratuitas para hacer crapgames y chorradas varias (y con suerte, monetizarlos). Y gracias a eso, se usó para enseñar desarrollo de videojuegos en escuelas y carreras (había una licencia de estudiante que duraba 2 años, que te permitía el acceso a casi todo el programa... ya no sé si seguirá existiendo), por lo que conseguían una gran base de potenciales usuarios.
Antes de Unity, sí, había Unreal E., pero era propietario. Godot no sé si existía, creo que no, y las alternativas eran GameMaker, RPGMaker, algún programa más genérico, programas específicos tipo OpenBOR, FPSMaker, etc... , y BennuGD :D
futu-block
21/09/2023, 11:54
tu lo has dicho, había alternativas buenas en plan gamemaker, con el que yo empecé, y después que no hay que ser tan fatiga, si tienes una versión mas o menos que te sirve pa lo que uno quiera, no hay que aventurarse y descargarse la última versión que puede que te añada un splash cartel de la marca al principio del juego y no lo puedes quitar cuando antes no lo hacía, actualizaste y la cagaste...
tusabe y esas cosas
Pero Futu, eso tiene muchísimos problemas:
Para empezar, tienes que buscar un programa que te sirva para lo que quieres hacer, porque no vas a usar el OpenBOR para hacer un clon de Doom, o RPG Maker para un plataformas 3D.
Segundo, tienes que aprender a manejarlo, ya no sólo la interfaz, que puede ser más o menos compleja, tener nombres parecidos para cosas distintas o llamar de forma distinta a lo mismo... ¿Has probado a usar Blender después de usar Maya... o al revés?. Porque luego tienes el lenguaje de scripting... si es que lo trae (y debería, porque si no las limitaciones te van a ahogar), que será de un determinado lenguaje, con sus palabros, su estructura y sus peculiaridades (vamos lo que comentaba más arriba). Si yo me meto en Godot tendré que aprender GDScripting, y todo lo que sé de C#, Java o ASM no me serviría, es un lenguaje nuevo con sus cosas y sus propias librerías.
Y luego reza para que el programa que has elegido tenga toda la funcionalidad que necesitas, que si no la tiene, te toca escribir código, escribir código muy complejo, o peor, escribir una librería que expanda la funcionalidad... si es que se puede. Imagina que llevas el 80% del juego hecho y ahora no puedes hacer el boss final porque el tamaño supera los límites permitidos por el motor, y tampoco lo puedes dividir en trozos porque has llegado al límite de sprites, por decir un ejemplo ¿Qué haces? ¿Cambias de programa y empiezas de cero? Y cuando digo el boss, puede ser algo imprescindible para el juego.
Lo bueno de motores como Unity o Unreal, es que no se orientan a un tipo de juego concreto, ni a una estética o al 2D/3D, que era lo que había entonces.
Por eso me metí en BennuGD, porque la única limitación que me imponía eran las 2D: lo que quisiera hacer era responsabilidad mía, dándome las herramientas de gestión de gráficos, sonido, input y procesos ya hecho.
bitrider
21/09/2023, 15:51
Godot tiene una versión oficial con C#. Si la memoria no me falla fue esponsorizada por M$.
MasterGame
22/09/2023, 00:25
ya sabia yo que ubisoft la habia cagado con assassins creed unity
Godot tiene una versión oficial con C#. Si la memoria no me falla fue esponsorizada por M$.
Pues eso, a todos los que usan Unity, yo incluido, nos viene de perlas para entrar en el motor.
Que ya sea mejor usar C# o el scripting de Godot, no lo sé, pero para empezar a hacer chorradas e irse acostumbrando a lo que sea más eficiente, viene de miedo.
Me vais a hacer instalarlo. Lo dicho, me estáis haciendo cada vez más tonto :D :D :D
futu-block
22/09/2023, 12:14
Godot tiene una versión oficial con C#. Si la memoria no me falla fue esponsorizada por M$.
sasto, eso no lo he comentado porque consideraba mejor aprender GDscript que usar C# que aunque se parezca a Bennu (o eso creo) no quería encontrarme con problemas de léxico o alguna palabra cambiada que no lo entienda porque estaba acostumbrado a algo parecido.
-----Actualizado-----
Pues eso, a todos los que usan Unity, yo incluido, nos viene de perlas para entrar en el motor.
Que ya sea mejor usar C# o el scripting de Godot, no lo sé, pero para empezar a hacer chorradas e irse acostumbrando a lo que sea más eficiente, viene de miedo.
Me vais a hacer instalarlo. Lo dicho, me estáis haciendo cada vez más tonto :D :D :D
no se instala, es un ejecutable que se guarda en una carpeta y santas pascuas...
No olvidarse de exportar vuestros juegos a ejecutable de linux, por favor T_T
El problema es que GDScript es mas lento que C#, pero vamos, a no ser de que intentes hacer un AAA creo que importa poco.
Lo que me gusta de godot es que tienes una API GDNative para ejecutar cosas en C++, o malo es cuando portes a otras plataformas, no se como ira eso porque necesitas todo el follon de meter un compilador de C++ para cada una.
josepzin
22/09/2023, 13:06
no se instala, es un ejecutable que se guarda en una carpeta y santas pascuas...
La magia de los portables, te adoramos señor.
No sabia de que Unity tuviera tantos gastos.
https://www.youtube.com/watch?v=CyAh-aca_Mo
Yo ahora estoy con Godot y gdscript. Para mis cosas de momento me vale y estoy aprendiendo bastante. A ver si lo hacen más estable y amigable pero no está en pañales tampoco.
Os animo a usarlo
Salu2 :P
Han recogido cable pero mientras sigan empeñados en cobrar por instalación, estamos en el mismo problema. Si alguien hace en unity un F2P de éxito se puede arruinar en menos que canta un gallo.
selecter25
25/09/2023, 01:18
Han dicho que solo cobrarán la famosa "Runtime fee" a partir de la versión LTS 2024, y en todo caso, el desarrollador decidirá si paga un 2.4% de los ingresos o una cantidad calculada a partir de las nuevas personas que interactúen con el juego cada mes.
Además, el splashart de Unity será opcional y varias reculadas más. La recogida de cable ha sido gorda, pero el daño a la imagen y a la confianza también.
Han dicho que solo cobrarán la famosa "Runtime fee" a partir de la versión LTS 2024, y en todo caso, el desarrollador decidirá si paga un 2.4% de los ingresos o una cantidad calculada a partir de las nuevas personas que interactúen con el juego cada mes.
Además, el splashart de Unity será opcional y varias reculadas más. La recogida de cable ha sido gorda, pero el daño a la imagen y a la confianza también.
Es que deberían haber hecho lo del 2,4% desde el principio en lugar de proponer una medida tan exploitable como la de las instalaciones. Si los usuarios protestan a lo bestia haciendo review bombing, imagínate lo que podría hacer una masa organizada si cada vez que desinstalan e instalan un juego le cuesta 20 céntimos al desarrollador. Y estamos hablando de protestas que pueden ser más o menos legítimas, imagínate ciberdelincuentes extorsionando a pequeños y medianos desarrolladores, "o me pagas X o pongo a toda mi red zombi a instalar y desinstalar tu juego y te arruino a comisiones".
josepzin
25/09/2023, 13:20
, imagínate ciberdelincuentes extorsionando a pequeños y medianos desarrolladores, "o me pagas X o pongo a toda mi red zombi a instalar y desinstalar tu juego y te arruino a comisiones".
Puede pasar :O
No sabia de que Unity tuviera tantos gastos.
https://www.youtube.com/watch?v=CyAh-aca_Mo
Yo no sabía que tuviera pérdidas, y más cuando hay juegos que están haciendo millonadas con su motor.
Hay algunas cosas que me parecen discutibles en el vídeo, como por ejemplo, que Unity no sea "tan complejo". Hablamos de un motor que es compatible con casi todas las plataformas de videojuegos existentes en todas sus versiones (Windows, Linux, MacOS, Android, iOS, PS3-5, XBox 306-series, WiiU-Switch...), que tiene herramientas de edición de escenas, animaciones, selección de animaciones, gestión de iluminación, sonidos, intérprete de scripts... Tantas cosas que una persona sola no las abarca, y encima las hacen sencillas de manejar. Y con sistema de addons. Y por lo que he visto, casi sin bugs y con un nivel de seguridad aceptable.
Después se compara la cantidad de empleados con otros motores y compañías: me creo que haya tanta gente, sobre todo, para soporte. ¿Alguna vez habéis tenido que atender preguntas de novatos en soporte? Sí, Unreal también tiene soporte pero, hasta hace no mucho, el que usaba Unreal tenía cierta experiencia o era un profesional, no un chaval de 15 años con una cuenta gratuita en su casa. Pero es una suposición mía, realmente no sé si la mayoría son desarrolladores o son de soporte, pero con millones de usuarios de todo tipo y condición...
Pero sí estoy de acuerdo en que están abarcando más de lo que pueden, y que deberían pensar en reducir costes antes de cobrar más a los que comienzan con el programa. O si no, volver al plan de cobro de la v4 (limitar funcionalidades según la licencia), en lugar de sacarse de la manga un nuevo plan que, como dicen en el vídeo, está totalmente desconectado de lo que realmente cobran los desarrolladores.
Es que no hay más que mirar el tema del F2P: el juego es gratuito. Cuesta 0€ comprarlo, cuesta 0€ instalarlo, y la persona puede invertir 0€ en él... salvo que pague por los DLCs o las microtransacciones, que no tienen nada que ver ni con descargas, ni instalaciones, ni compras en tiendas... todos son cobros "in-app", que no sé a través de dónde se hacen, si van a través de Steam, si puedes cobrar mediante un servicio externo o cómo va el desarrollo de eso.
Han dicho que solo cobrarán la famosa "Runtime fee" a partir de la versión LTS 2024, y en todo caso, el desarrollador decidirá si paga un 2.4% de los ingresos o una cantidad calculada a partir de las nuevas personas que interactúen con el juego cada mes.
Además, el splashart de Unity será opcional y varias reculadas más. La recogida de cable ha sido gorda, pero el daño a la imagen y a la confianza también.
Si tienes a mano la fuente, te lo agradecería.
Lo de quitar el logo siempre me ha parecido una tontería. De una forma u otra, hay que añadirlo al juego: hay que dar crédito a todos los que participan en el juego. Yo añado el logo de BennuGD a mis juegos y nadie me obliga a hacerlo.
Ten en cuenta que el tio del video trabajaba en EA en el motor frostbyte, y comparando Unity con Unreal o frostbyte segun él, no hay color.
selecter25
25/09/2023, 16:32
Si tienes a mano la fuente, te lo agradecería.
Lo de quitar el logo siempre me ha parecido una tontería. De una forma u otra, hay que añadirlo al juego: hay que dar crédito a todos los que participan en el juego. Yo añado el logo de BennuGD a mis juegos y nadie me obliga a hacerlo.
https://blog.unity.com/news/open-letter-on-runtime-fee
https://www.elotrolado.net/noticias/tecnologia/unity-cambio-tarifa-precios
Lo del logo, la mayoría de devs de Unity lo consideran poco profesional, da la imagen de juego genérico o de desarrollador que descuida su juego porque no quiere pagar por quitar el logo, al menos así lo menifiestan la mayoría con desarrollos de juegos medianamente serios.
Ten en cuenta que el tio del video trabajaba en EA en el motor frostbyte, y comparando Unity con Unreal o frostbyte segun él, no hay color.
Ese detalle no lo he oído.
Sí la comparación con Unreal: Unreal se enfoca mucho más hacia el fotorrealismo, y contra eso Unity no se le puede ni acercar, y que debería moverse con los indies, con el 2D y con los juegos móviles, que son la mayoría del mercado de desarrollo de juegos, en lugar de aspirar a todo. A Nintendo no le ha ido tan mal con una política similar.
https://blog.unity.com/news/open-letter-on-runtime-fee
https://www.elotrolado.net/noticias/tecnologia/unity-cambio-tarifa-precios
Lo del logo, la mayoría de devs de Unity lo consideran poco profesional, da la imagen de juego genérico o de desarrollador que descuida su juego porque no quiere pagar por quitar el logo, al menos así lo menifiestan la mayoría con desarrollos de juegos medianamente serios.
Gracias por los enlaces ;) les echaré un vistazo entre prueba y prueba.
Sí, lo de usar el logo es poco profesional, pero también usar los assets gratuitos de la store ¿entonces para qué están? ¿O pago o los tengo que hacer yo, aunque sean de peor calidad que los gratuitos?
También es "poco profesional" hacer juegos en Unity, es mejor hacerlo con Unreal (pero no uses un motor propio porque reinventas la rueda).
Y luego, esos mismos tipos empiezan a ponerte logos al empezar como Cryware, FMod, y así como tres o cuatro pantallas de 1'5 segundos de los motores que usan, el suyo, el del distribuidor...
Es que llega un punto en que cansa tantas pegas que te ponen los "pro" y terminas mandando sus recomendaciones a null, por no decir una bordería. A ver cuántos de ellos aún tienen la marca de agua para activar Windows :P
selecter25
25/09/2023, 17:28
Gracias por los enlaces ;) les echaré un vistazo entre prueba y prueba.
Sí, lo de usar el logo es poco profesional, pero también usar los assets gratuitos de la store ¿entonces para qué están? ¿O pago o los tengo que hacer yo, aunque sean de peor calidad que los gratuitos?
También es "poco profesional" hacer juegos en Unity, es mejor hacerlo con Unreal (pero no uses un motor propio porque reinventas la rueda).
Y luego, esos mismos tipos empiezan a ponerte logos al empezar como Cryware, FMod, y así como tres o cuatro pantallas de 1'5 segundos de los motores que usan, el suyo, el del distribuidor...
Es que llega un punto en que cansa tantas pegas que te ponen los "pro" y terminas mandando sus recomendaciones a null, por no decir una bordería. A ver cuántos de ellos aún tienen la marca de agua para activar Windows :P
No estoy de acuerdo, Unreal según para qué cosas es matar moscas a cañonazos, lo veo más para proyectos 3D grandes, Unity es multiplataforma y funciona hasta en tostadoras, y el abanico de juegos que puedes desarrollar es inmenso.
Te parece poco profesional Cuphead? los Ori? Escape from Tarkov? Genshin Impact? Star Rail? Subnautica? Hollow Knight? Hearthstone? Cities: Skylines? No sé...
Si has desarrollado cosas en Unity, es fácil que reconozcas assets o los típicos controllers gratuitos de la store. Si te dedicas solo a jugar es más complicado que lo hagas, sin embargo, el logo de Unity nada más abrir el juego ya te está dando mucha información. Yo solo usaría assets gratuitos en un proceso de aprendizaje o en proyectos playground para probar cosas.
Hoy en día tienes muchos juegos indies o shitgames en Steam (sobre todo de terror) que lucen muy decentemente con assets de pago, hay juegos como Madison (felicidades a los argentinos de Bloodious Games) que a mí me han flipado. Juegos para móviles, VR, le podemos meter toda la caña que queramos a Unity por otras cosas, pero es un motor de la poota hostia y es pa' tontos.
futu-block
25/09/2023, 20:35
Una pregunta...
¿Con Blender se pueden programar videojuegos? 3d obviamente
Hace años tenia su propio motor grafico, decian que lo iban a quitar, pero creo que lo han vuelto a poner. Lo poco que he visto y que no me gusta es que el lenguaje de programacion es python.
Tenía una GameEngine hasta la versión 2.8, pero dejó de mantenerse porque no tenía sentido gastar esfuerzos en que Blender siguiese ese camino: https://en.wikipedia.org/wiki/Blender_Game_Engine
Aún así hay gente que lo sigue intentando: https://upbge.org/#/
Lo que sí puedes hacer, por supuesto, es modelar las cosas en Blender e importarlas en cualquier otro engine sea Godot, Unity o lo que sea.
Blender hace muchas cosas aparte de modelar 3D. Por ejemplo, tiene un editor de vídeo no lineal decente, especialmente si ya conocer los atajos de teclado de blender. Puedes editar cualquier vídeo de tu gato hecho con el móvil, no hace falta que lo hayas modelado en 3D.
No estoy de acuerdo, Unreal según para qué cosas es matar moscas a cañonazos, lo veo más para proyectos 3D grandes, Unity es multiplataforma y funciona hasta en tostadoras, y el abanico de juegos que puedes desarrollar es inmenso.
Te parece poco profesional Cuphead? los Ori? Escape from Tarkov? Genshin Impact? Star Rail? Subnautica? Hollow Knight? Hearthstone? Cities: Skylines? No sé...
Si has desarrollado cosas en Unity, es fácil que reconozcas assets o los típicos controllers gratuitos de la store. Si te dedicas solo a jugar es más complicado que lo hagas, sin embargo, el logo de Unity nada más abrir el juego ya te está dando mucha información. Yo solo usaría assets gratuitos en un proceso de aprendizaje o en proyectos playground para probar cosas.
Hoy en día tienes muchos juegos indies o shitgames en Steam (sobre todo de terror) que lucen muy decentemente con assets de pago, hay juegos como Madison (felicidades a los argentinos de Bloodious Games) que a mí me han flipado. Juegos para móviles, VR, le podemos meter toda la caña que queramos a Unity por otras cosas, pero es un motor de la poota hostia y es pa' tontos.
A mi no me mires, que no es mi opinión :D
Es la impresión de "alguna gente" que he ido recopilando a lo largo de los años. Como "teleco", me tengo que codear de vez en cuando (tanto figuradamente con los codos, como con el código) con gente de informática, y como he comentado alguna vez, hay más de uno que va con el ego muy subido.
En mi opinión, es un excelente motor para juegos 3D, para todo tipo de perfiles (salvo, al parecer, AAA fotorealistas). También tiene buenas herramientas para el 2D, pero si no voy a usar el motor de físicas, prefiero usar BennuGD, porque hay cosas que son demasiado complejas o no las veo bien implementadas... pero es más una preferencia personal.
Yo me lo he pasado pipa con los Yooka-Laylee, y ninguna queja, pese a las críticas que se han llevado, tanto por el tipo de juego que son como por el motor elegido (hasta la prensa le criticó no haber usado Unreal).
Lo de los assets es lo de siempre: los que los conocen los critican, pero los que los van a jugar no tienen por qué conocerlos, y si tu juego lo haces solo, no vas a gastarte un dinero que no tienes. Puedo entender que empieces a coger assets sin criterio, y que no casen con el estilo de juego, pero no te suelen criticar por esa razón.
Además, la gran ventaja de Unity es que es fácil de usar para todos los perfiles de usuarios, ya seas programador, diseñador, grafista, o no tengas ni idea. Esa es la verdadera potencia del entorno. Siempre pongo el mismo ejemplo, pero en el Master, yo era el programador del grupo, y tenía que encargarme de programar el prota, programar los eventos, programar los objetos y encima, integrar todo lo que me mandaban las otras 4 personas (llegaba un grafista con un modelo de Maya, y yo tenía que importarlo, crear el prefab con sus cajas de colisiones, sus scripts, y extraer las animaciones y configurarlas, crear los eventos que las disparaban...). Para quitarme un poco de trabajo, como los demás querían que hubiera cámaras dinámicas según la sección del nivel, creé 5 prefabs de cámaras (cámara que sigue al prota, cámaras fijas, cámaras semifijas...) y se las di a los diseñadores para que ellos las pusieran y las configurasen, y así me quité varias horas de colocación, ajustes y demás: convertí una tarea de programación en una tarea de diseño.
Y así se puede hacer con todo. Y si tú no puedes hacerlo, alguien lo habrá hecho en la tienda por un par de "gluglús".
Tenía una GameEngine hasta la versión 2.8, pero dejó de mantenerse porque no tenía sentido gastar esfuerzos en que Blender siguiese ese camino: https://en.wikipedia.org/wiki/Blender_Game_Engine
Aún así hay gente que lo sigue intentando: https://upbge.org/#/
Lo que sí puedes hacer, por supuesto, es modelar las cosas en Blender e importarlas en cualquier otro engine sea Godot, Unity o lo que sea.
Blender hace muchas cosas aparte de modelar 3D. Por ejemplo, tiene un editor de vídeo no lineal decente, especialmente si ya conocer los atajos de teclado de blender. Puedes editar cualquier vídeo de tu gato hecho con el móvil, no hace falta que lo hayas modelado en 3D.
Además de modelar, puedes crear las animaciones y exportarlas también, y sus herramientas son bastante mejores que las de Unity. Luego las puedes retocar o usar el gestor de animaciones para programar cuándo lanzar cada animación.
A mi me desconcertó lo del Blender Game Engine, pero jamás aprendí a usarlo. Ya, lo del editor de vídeo ni sabía que existía.
Estopero
26/09/2023, 13:26
El nuevo modelo de negocio es abusivo pero lo más bestia nivel Tiranía Total era la retroactividad
Incluso juegos ya publicados entrarían en el nuevo modelo de tarifas, y no sería suficiente con despublicarlos de las plataformas porque las copias ya vendidas estarían generando instalaciones y cobros a los desarrolladores
Han dado marcha atrás en esto porque al menos en Europa les meterían un puro tremendo por atentar contra la competencia, ya se habían anunciado demandas, y finalmente solo entrará en el nuevo modelo de tarifas quién desarrolle con la nueva versión de Unity
Y ojo porque aun así un cambio tan drástico de tarifas puede tener recorrido legal, porque están haciendo abuso de posición dominante al extender su framework a precios asequibles para meter la estacada después con los desarrolladores ya secuestrados
Una pena porque Unity es un gran framework, con muchísimo contenido extra publicado tanto en forma de documentación, formación, tutoriales, contenido artístico o de desarrollo, pero yo solo seguiría utilizándolo si despidieran al CEO de forma fulminante, ya no sabes por donde te la pueden intentar colar
Esto ha sido un suicidio por parte de Unity
futu-block
26/09/2023, 20:25
editor de video e incluso de animaciones 2d (porque de 3d obvio) es mi asignatura pendiente, pero es tan completo blender...
josepzin
27/09/2023, 12:51
Justo vi esto: Alternativas a Unity: 5 engines para tener en cuenta
https://pressover.news/articulos/alternativas-a-unity-5-engines-para-tener-en-cuenta/
Extraño que 2 de esas alternativas sean argentinians (al menos de origen): Godot y Coco.
futu-block
27/09/2023, 23:06
Coco...
Justo vi esto: Alternativas a Unity: 5 engines para tener en cuenta
https://pressover.news/articulos/alternativas-a-unity-5-engines-para-tener-en-cuenta/
Extraño que 2 de esas alternativas sean argentinians (al menos de origen): Godot y Coco.
Bueno, extraño no, ya que el artículo lo escribe un argentino, y es normal que barra para casa. De hecho, él mismo dice que rompe sus propias reglas sólo para incluir Coco, ya que no es completamente código abierto, que era el tema del artículo.
Por cierto ¿Godot sólo pesa una treintena de MB? Juer, entre eso y que no hay que instalarlo, parece diseñado para mi :quepalmo:
Coco...
¿Algo que ver con las adorables criaturas que hay que rescatar en la última aventura del erizo azul? :lol:
futu-block
28/09/2023, 12:25
coco-lilo...
sacamuelasXD
josepzin
03/10/2023, 13:29
No es que me caiga muy bien pero tiene sentido todo lo que dice.
https://www.youtube.com/watch?v=vBR6IGEzGrI
Te puede caer mejor o peor, pero sin duda, te habla desde la experiencia, y eso nunca hay que subestimarlo.
Y además lleva 2000 años entre nosotros y murió por nuestros pecados... A ver, teniendo en cuenta su apariencia, que está rodeado de palomas y que en sus videos predica sobre lo que se debe de hacer y lo que no... es evidente que se trata de jesucristo de incognito.
futu-block
03/10/2023, 20:35
jijijiji
josepzin
03/10/2023, 20:52
Y además lleva 2000 años entre nosotros y murió por nuestros pecados... A ver, teniendo en cuenta su apariencia, que está rodeado de palomas y que en sus videos predica sobre lo que se debe de hacer y lo que no... es evidente que se trata de jesucristo de incognito.
Juasssss quizás sea por eso que no me cae bien, LA APARIENCIA.
¡Qué va! Si no tiene ni la mitad de carisma que el original.
Eso sí, ha conseguido que Guinxu se vaya pareciendo a él cada vez más :D No le llega porque a Gintxu no le crece el bigote ni aunque se afeite todos los días :D :D :D
Por cierto, ha subido un vídeo sobre cómo conseguir un efecto de nieve en Unity para cualquier modelos muy chulo.
fbustamante
04/10/2023, 18:23
Pon el enlace, cachoperro.
Como no tiene videos el gachó ese. :D
josepzin
04/10/2023, 18:45
No le llega porque a Gintxu no le crece el bigote ni aunque se afeite todos los días :D :D :D
Por algún motivo el Gintxu ese me cae mucho mejor, yo supongo que es una cuestión visual.
Pon el enlace, cachoperro.
Como no tiene videos el gachó ese. :D
Cachoperro tú, que es el cuarto empezando desde el último que ha puesto :D
https://www.youtube.com/watch?v=vOCPUapZ4C8
Además, que este hilo no va de eso :awesome:
Por algún motivo el Gintxu ese me cae mucho mejor, yo supongo que es una cuestión visual.
Y que el Ginxu le pone ganas, el Majo parece que va siempre al 85% de velocidad o está como si se acabara de levantar :P
fbustamante
05/10/2023, 06:59
¡Claro! Por eso no lo encontraba.
El video es del Guinxu ese, no del Majo.
Y cuando hablabas de simular nieve, yo pensaba en que nevaba, no en esa porquería. :D
Por cierto, me gusta ver a Majo porque parece que se acaba de fumar un porro todo el rato. XD
Vale, veo que no soy al único que el Majo no le parece tan majo xD no se, me da una sensación de que lo tiene subidito un tanto extraña, y luego las rarezas y pintan suyas no ayudan (que lo mismo es todo un personaje y es una bellisima persona)....
Sin embargo, Ginxu me cae hasta bien jejejeje, tiene una forma de explicar las cosas que me gusta, me pasa lo mismo con el MeletinitasDev, al final lo que me interesa de esos videos es conocer cómo funcionan las cosas y ver las soluciones que proponen.
Sí, lo de que se lo tiene muy creído también fue mi primera impresión, pero no, cuando ves un par de vídeos más, ves que te lo cuenta todo de una forma bastante imparcial, pero metiendo detalles de su propia experiencia. Como parece que no gesticula nada, y los detalles te los da de sus propios juegos, da la impresión de que tiene un ego bastante grande, pero luego te das cuenta de que, si no relata su propia experiencia ¿de quién te la va a dar? ¿De un juego del que no tiene el código fuente?
Lo que terminó de romper esa sensación fue un vídeo en el que él y Ginxu se enfrentan cara a cara a realizar una serie de tareas de programación, uno usando matemáticas, y el otro, alternativas sin matemáticas. A ver si tengo un enlace por aquí... (rebuscando en el bolsillo mágico que Drumpi le ha hackeado a Syto):
https://www.youtube.com/watch?v=lHGqig6h3ls
https://www.youtube.com/watch?v=rZV40Xeo2GA
Juer, he encontrado dos versiones del mismo vídeo. Podéis elegir entre el de Ginxu y el de Alva. Drumpi, te has pasado con el hackeo.
- ¿Quieres saber quién mató a Mr Kenedy?
- ¿Al presidente o al luchador?
- ¡A Ambos!
Bueno, también podéis ver que se han ido copiando el estilismo :D El estilo descuidado es el mejor para poder concentrar tu tiempo en cosas importantes, como aislarse socialmente haciendo chorradas en el ordenador que sólo te importan a ti y a una selecta colección de frikis.
Edit: ah, vale, uno es con las soluciones de Guinxu, y el otro con las de Alva, hay que ver los dos ^^U
futu-block
05/10/2023, 11:10
a ver haber, el Yisas es odiable 100% pero es que luego no dice cosas vanales, tiene mucha coherencia y mas con respecto a la pogramación, pero es lo mismo de siempre por lo que no veo sus vidrios, porque está enseñando el careto en vez de estar enseñando lo que está explicando...
se vé que ha sufrío mucho de chico, le daban laticasos o algo pa que sufriera y eso luego lo ha desarrollao en forma de carisma...
en cuanto los videos del reto, fabuloso, me encanta como se puede sacar casi el mismo resultado de una forma o de otra, da pa darle al coco
Es lo bonito de la programación, nunca hay una única solución, y siempre te la puedes traer a tu terreno. Por lo general suele haber tres muy básicas: usar mates, usar el cerebro, o apoyarte en las herramientas del lenguaje. A partir de ahí, combinaciones mil.
Vaya, me he encontrado este vídeo sobre primeras impresiones de Godot, y en el minuto 7 ha lanzado un disparo directo a mi punto más débil :D
https://www.youtube.com/watch?v=Uf18ajLlJYQ
josepzin
05/10/2023, 13:22
a ver haber, el Yisas es odiable 100%
Si, da un mal rollo en plan maniatico asesino serial o algo asi. Esa es mi impresión viendolo, pero los contenidos que hace son buenos.
Yo he visto bastantes videos de estos dos, y algunas charlas con otros dev hablando de como empezaron, hacen o hacian las cosas y lo que me pasaba por la cabeza era:
***** que chapuza, a ver si espabilas y haces algo de una **** vez.
Si, da un mal rollo en plan maniatico asesino serial o algo asi. Esa es mi impresión viendolo, pero los contenidos que hace son buenos.
Es que es justo eso, lo mismo es lo que digo, que es todo pura fachada y luego resulta un buen tipo, pero de entrada no me gusta ver sus videos, por ejemplo, del bigote que ha puesto Drumpi (findemor creo que se hace llamar), no me produce ese rechazo.
Pero le daré otra oportunidad al Yisus a ver si me puedo saltar sus excentricidades y videos de palomas y operaciones de uvas...
futu-block
05/10/2023, 20:03
ome, es que también se está perdiendo una paga ahí, eso de acoger palomas y gastarse una pasta en veterinarios y luego que se le caguen en la casa y se le mueran es de tener tara y PMA...
josepzin
05/10/2023, 20:14
Lo de las palomas no sabía nada, supongo que no es culpa suya, ya se sabe que Jesús siempre aparece rodeado de palomas, su padre en los cielos así lo dispuso.
futu-block
06/10/2023, 09:57
alguna será el que lo engendró, juas juas juas
Yo he visto bastantes videos de estos dos, y algunas charlas con otros dev hablando de como empezaron, hacen o hacian las cosas y lo que me pasaba por la cabeza era:
***** que chapuza, a ver si espabilas y haces algo de una **** vez.
¿Existe un meme equivalente a "PC Master Race" para los programadores? Hace años que me hace falta uno :D
Pero de todas formas, es que estos dos no son desarrolladores profesionales, ni expertos en Unity, siquiera. Son dos desarrolladores como los del foro, que hacen sus cositas, las suben, aprenden cosas nuevas, las comparten... la diferencia es que se han montado un buen canal en YT y han conseguido una buena cantidad de seguidores, y gracias a eso, uno se ha permitido el lujo de gastarse una pasta en un "juego" gratuito, contratando incluso a un grafista, y el otro ha creado un homenaje a Golden Sun que está vendiendo en Steam, y se ha ahorrado media campaña de márqueting :D
Aquí pasó que, en cuanto la gente pudo monetizar sus chorradas en la Play Store, hubo una huida masiva de gente en busca de fortuna y gloria :D
También está el canal de "Leyendas y videojuegos", que es más de análisis de videojuegos y su industria, pero desde hace un tiempo, Erik está subiendo vídeos del desarrollo de un juego de gestión de granja en el que se ha involucrado, por si queréis ver el desarrollo de un juego desde cero, y cómo evoluciona en tiempo real.
Por cierto, al hilo del vídeo de antes, me he visto este curso... y me lo he tragado enterito :D Godot suena interesantísimo. No me gusta la idea de usar GDScript, pero si para la depuración en tiempo real no me queda más remedio que acudir a él... aunque llevo años depurando "a la antigua" con BennuGD, tampoco debería ser un trauma :D Pero me gusta lo de poder modificar las variables desde el entorno en tiempo real.
https://www.youtube.com/watch?v=L3pFEk1HPCQ
Tengo un par de proyectos 3D basados en escenarios hechos con cubos que pueden ser interesantes para hacerlos con Godot... pero la falta de tiempo, y la pereza que me da tener que volver a empezar de cero con algo, me quita las ganas :llorosa:
futu-block
08/10/2023, 09:47
prueba godot con C+ o C++, yoquesé, es algo de C en vez de GdScript...
y Javo es bueno haciendo tutos, suscribete a Leedeo
C#. No tengo claro si lo diseñó M$ o si venía de antes, pero es una mezcla entre C++ y Java. Tampoco es lo más eficiente del mundo, pero poder usar listas con LinQ como si fueran BBDD (ordenar, obtener un rango de elementos, buscar en base a varios criterios...) es una bendición que no sabes la de tiempo que te ahorra.
Y ya puede ser bueno el tal Javo: fue el primer traductor oficial de Godot al español :D
Así aprendí yo DIV2, me leí entero el manual, casi función por función, por lo que cuando quise empezar, ya más o menos me conocía todas las funciones del lenguaje :D
Han despedido al anormal que quiso instaurar la runtime fee, el mismo anormal que echaron de EA por ser un pesetero de mierda. A ver en que compañía acaba, espero que en ninguna.
Han despedido al anormal que quiso instaurar la runtime fee, el mismo anormal que echaron de EA por ser un pesetero de mierda. A ver en que compañía acaba, espero que en ninguna.
Ese tarado dijo que un desarrollador que no pensara en micropagos mientras programaba era idiota.
https://www.lavanguardia.com/andro4all/juegos/el-ceo-de-unity-john-riccitiello-abandona-la-compania-con-efecto-inmediato
C#. No tengo claro si lo diseñó M$ o si venía de antes, pero es una mezcla entre C++ y Java. Tampoco es lo más eficiente del mundo, pero poder usar listas con LinQ como si fueran BBDD (ordenar, obtener un rango de elementos, buscar en base a varios criterios...) es una bendición que no sabes la de tiempo que te ahorra.
Y ya puede ser bueno el tal Javo: fue el primer traductor oficial de Godot al español :D
Así aprendí yo DIV2, me leí entero el manual, casi función por función, por lo que cuando quise empezar, ya más o menos me conocía todas las funciones del lenguaje :D
El C# fue la respuesta de microsoft a Java y por mi parte se lo pueden meter por lo oscuro, solo teniamos una aplicación en windows y heredo todos los problemas de versionado de visual basic.
-----Actualizado-----
Han despedido al anormal que quiso instaurar la runtime fee, el mismo anormal que echaron de EA por ser un pesetero de mierda. A ver en que compañía acaba, espero que en ninguna.
En Capcom que fueron los que iniciaron esta epoca de micropagos y dlcs de pago
El C# fue la respuesta de microsoft a Java y por mi parte se lo pueden meter por lo oscuro, solo teniamos una aplicación en windows y heredo todos los problemas de versionado de visual basic.
Como desarrollador que ha trabajado con Java, que mantiene un proyecto en VB6, y que actualmente trabaja en C#.NET y con proyectos de compañeros en VB.NET te digo que, actualmente, C# me parece una forma muy cómoda de trabajar. Podemos discutir si es más o menos eficiente, pero la sintaxis, mucho más simple que C++, el sistema de clases y el no tener que estar peleándome con punteros (algo que manejaba día a día con BennuGD, y que aún tengo pesadillas de mis tiempos de C) creo que es el mejor compromiso que he visto entre facilidad, eficiencia y lenguaje estricto... por mucho que me duela en el alma admitirlo.
Ahora bien, si quieres, lo discutimos como personas civilizadas. Total, yo no me considero un "master race" de programación (mientras no digas nada malo de Fénix o BennuGD :D).
masteries
11/10/2023, 10:26
C# me parece una forma muy cómoda de trabajar. Podemos discutir si es más o menos eficiente, pero la sintaxis, mucho más simple que C++, el sistema de clases y el no tener que estar peleándome con punteros (algo que manejaba día a día con BennuGD, y que aún tengo pesadillas de mis tiempos de C) creo que es el mejor compromiso que he visto entre facilidad, eficiencia y lenguaje estricto...
Jo, qué maravilla; los punteros son tu mejor amigo y el peor enemigo al mismo tiempo
Cuando te sales del mundo de los computadores de propósito general, ya sean PCs, Raspis... la cosa cambia mucho, y ya tienes suerte si existe compilador de C que funcione en condiciones;
hay entornos de compilación (comerciales) para determinadas arquitecturas que siguen usando compiladores del año 91 o 92, y para ello tienen una máquina virtual con DOS 5.0 por detrás...
no quieras saber lo mal que funciona todo eso, y la de problemas que dan esos compiladores, a veces intentan compilar los comentarios, y las muchas veces no reconocen bien determinadas estructuras de código (como un switch dentro de una claúsula else if) y generan código chungo cuando las encuentran xD
A mi el C# con .NET me parece lentorro, donde trabajaba estabamos haciendo una aplicacion y al mostrar una ventana habia un delay como de medio segundo, mientras que en una aplicacion parecida que hice en C++ con wxWidgets era instantaneo.
Nunca entendi las quejas con los punteros, pero vamos, si trabajas en C++ usas los std::shared_ptr y std::unique_ptr y asunto resuelto en caso de que seas un desastre y pierdas memoria.
Jo, qué maravilla; los punteros son tu mejor amigo y el peor enemigo al mismo tiempo
Cuando te sales del mundo de los computadores de propósito general, ya sean PCs, Raspis... la cosa cambia mucho, y ya tienes suerte si existe compilador de C que funcione en condiciones;
hay entornos de compilación (comerciales) para determinadas arquitecturas que siguen usando compiladores del año 91 o 92, y para ello tienen una máquina virtual con DOS 5.0 por detrás...
no quieras saber lo mal que funciona todo eso, y la de problemas que dan esos compiladores, a veces intentan compilar los comentarios, y las muchas veces no reconocen bien determinadas estructuras de código (como un switch dentro de una claúsula else if) y generan código chungo cuando las encuentran xD
+1 a lo resaltado en negrita. El programador que no sabe trabajar con punteros, está condenado. Por eso, el trabajar con clases es una bendición, porque ya lleva los punteros de forma implícita: cuando pasas una clase por parámetro, no pasas una copia, sino un puntero a dicha instancia; lo mismo si pasas una List o un Dictionary.
Para un sistema de pocos recursos, estoy de acuerdo que los punteros son "el camino", pero para una aplicación de escritorio ¿Para qué hacer una cola con punteros, si te pueden dar ya hecha una implementación de una List de tipo <object> o del tipo que quieras, y puedes meter en ella lo que te de la gana? Máxime si usas LinQ, que parece que trata ese espacio de memoria como una tabla relacional ¿se llamaba así? Como si fuera una BBDD, cuyos accesos son aún más rápidos que andar recorriendo una lista buscando elementos. ¿Sabes el tiempo que me ahorra algo como esto?
listaFiltrada = miLista.Where(x => (x.quantity > 0) && (x.date >= DateTime.Today));
Ya, sobre compiladores cruzados y demás, en eso me llevas mucha ventaja. Yo sólo he usado algunos, y ya estaban preparados para el sistema. Podemos discutir si eran más o menos cómodos, porque la mayoría que he usado eran para Linux, y en Windows tenía que ponerme a hacer instalaciones del MINGW o como se llamara la ventana de comandos con el cmake y demás herramientas portadas a Windows.
A mi el C# con .NET me parece lentorro, donde trabajaba estabamos haciendo una aplicacion y al mostrar una ventana habia un delay como de medio segundo, mientras que en una aplicacion parecida que hice en C++ con wxWidgets era instantaneo.
Nunca entendi las quejas con los punteros, pero vamos, si trabajas en C++ usas los std::shared_ptr y std::unique_ptr y asunto resuelto en caso de que seas un desastre y pierdas memoria.
¡Oh! ¡Dios mío! Un delay de medio segundo en una aplicación de escritorio... :D :D :D
Primero, el tío que usa la APP le da igual, porque de ordenadores sabe lo justo para pasar el día. Segundo, que no tiene más remedio que usar esa aplicación porque le viene impuesta (no veas las atrocidades que se hacen en diseño en favor de la "funcionalidad", o de entregar lo antes posible). Y tercero, cambiad de equipos porque esos equipos van lentísimos, en medio segundo me carga una página web hecha en .NET Core, contanto con el delay de carga de datos en red :D
A ver, que soy el primero que dice que .NET no es óptimo, y el primero que odia el exceso de recursos consumidos... pero compensa lo que acorta los tiempos de desarrollo, la depuración y la ampliación (yo venía de programar BennuGD en Notepad++ sin debuger, y en cuanto aprendí a usar VS, era el rey cazador de bichos, y un rayo programando).
En ese compromiso, me parece buena herramienta, a falta por conocer alternativas mejores. Y ojo, que con Java, que era parecido, no opinaba lo mismo: el entorno era lentísimo, y los resultados aún más.
Las quejas con los punteros son muy simples: si no los conoces, puedes hacer burradas, provocar un error, y tardar horas en encontrarlo si no sabes depurar. Se te cae el programa y no sabes por qué, hasta que te das cuenta que al borrar elementos de la lista, la estás recorriendo de principio a fin, y se te está saliendo el índice al final de la lista, o puede que hayas puesto un <= en lugar de < en otra parte del programa.
Son muy peliagudos, y el segundo reto del novato, después de instalar el entorno de desarrollo y hacer que funcione el "hola mundo". Son algo demasiado abstractos para el común de los mortales.
Es lo mismo que con los hilos: .NET tiene una herramienta que los simplifica, el "async-await", y después de 3 años trabajando con ello, aún hoy estoy descubriendo los problemas que pueden dar. Ayer encontré uno muy curioso con las funciones que gestionan los datos de retorno, dentro de un bucle. Menos mal que, de nuevo, acostumbrado a BennuGD y a pensar en procesos, pude averiguar la razón en un par de segundos tras analizar los valores del debugger.
Pero es lo que dice todo el mundo: la herramienta adecuada para cada problema (foto del Chuache).
¡Oh! ¡Dios mío! Un delay de medio segundo en una aplicación de escritorio... :D :D :D
Si, apenas es nada, pero si coges una aplicacion que cada vez que se muestra un nuevo dialogo, lo hace de forma instantanea, se te hace menos incomodo. Parece una tonteria pero cuando llevas un buen rato, se agradece la agilidad.
-----Actualizado-----
PD: la aplicacion en .NET la solia correr en un ordenador mas moderno, con mejor CPU y mas memoria que el mio, y a pesar de eso iba peor.
No, si eso lo entiendo. Está claro que cuanto más ágil sea el programa mejor. Sólo intento mostrar el punto de vista que, a lo mejor, ese "medio segundo" no compensa que el desarrollo pase de durar una semana a dos, especialmente si después, encontrar un fallo se tarda 6 horas en lugar de 3, especialmente si el que tiene que arreglarlo no es el que escribió el código en primer lugar.
Sobre el PD, ni idea.
Como desarrollador que ha trabajado con Java, que mantiene un proyecto en VB6, y que actualmente trabaja en C#.NET y con proyectos de compañeros en VB.NET te digo que, actualmente, C# me parece una forma muy cómoda de trabajar. Podemos discutir si es más o menos eficiente, pero la sintaxis, mucho más simple que C++, el sistema de clases y el no tener que estar peleándome con punteros (algo que manejaba día a día con BennuGD, y que aún tengo pesadillas de mis tiempos de C) creo que es el mejor compromiso que he visto entre facilidad, eficiencia y lenguaje estricto... por mucho que me duela en el alma admitirlo.
Ahora bien, si quieres, lo discutimos como personas civilizadas. Total, yo no me considero un "master race" de programación (mientras no digas nada malo de Fénix o BennuGD :D).
He trabajado con C y C++ y no solia tener problemas con los punteros pero quiza sea que llevo muchos años con el, con java y muchos problemas con la memoria y la lentitud (come maquinas para desayunar), con C# en windows y muchos problemas de compatibilidad con las versiones de los runtimes/librerias igualito que en visual basic y desplegar la maldita aplicación en un monton de puestos era una loteria, al final hubo que ponerla en un servidor remoto para evitar esos problemas a costa de pagar un pastizal por las licencias. Por eso C# lo mas lejos posible (aparte de ser un lenguaje propietario de Microsoft)
¿C# problemas de compatibilidad? Será que yo no he tocado el entorno de desarrollo en años, pero hasta ahora, ninguna máquina ha tenido pegas con lo que he programado. Vale que el 45% eran programas Xamarin destinados a móviles Android, otro 45 eran las WebApis que dan servicio a dichas APPs (WebApis desplegadas en sistemas en el que nosotros hemos hecho la instalación del IIS y de lo que necesita para funcionar), y apenas dos o tres proyectos han sido aplicaciones de escritorio para alguna utilidad concreta. Mis compañeros sí que se dedican a hacer addons en vb.NET para el ERC, y tampoco han tenido problemas.
Será que todos los equipos tienen el .net 4.5 instalado por nosotros, y el Windows Update se encarga de tenerlo al día.
Ya digo que el que ha trabajado con punteros, sabe de qué va la cosa y los errores más habituales. Yo no los he usado desde hace más de 5 años, y no hace mucho estuve ayudando a un novato en el foro de BennuGD a manejarlos. Pero eso no quitan para que sigan siendo un peligro, y créeme, con la cantidad de código y de operaciones que tienen los proyectos que estoy manejando, lo último que quiero es andar de pelea con ellos.
Pero bueno, ya he descargado Godot con soporte para C#... aunque en realidad, el soporte que tiene es de Mono, por aquello de hacer que funcione en Linux y esas cosas :D
Los punteros eran un mal necesario cuando los ordenadores no tenían apenas recursos y había que usarlos para acceder directamente a las posiciones de memoria en lugar de (por ejemplo) reservar más memoria para trabajar con un duplicado de esos datos. Pero a día de hoy son un **** atraso en el 99% de los casos.
masteries
14/10/2023, 14:04
Los punteros eran un mal necesario cuando los ordenadores no tenían apenas recursos y había que usarlos para acceder directamente a las posiciones de memoria en lugar de (por ejemplo) reservar más memoria para trabajar con un duplicado de esos datos. Pero a día de hoy son un **** atraso en el 99% de los casos.
Creo que esa es la razón por la que sólo haya compiladores de C para las arquitecturas embebidas, al final, casi todo lo que escribes o son drivers para hardware; que viene a ser mucho acceder a posiciones de memoria que son registros, o son operaciones intensivas sobre arrays o matrices, donde tomar punteros si presenta una ventaja a nivel de ahorrar ciclos de reloj.
Pero para pasar un único dato o un par de datos como argumento a una función, pues no notas diferencia ni aún midiendo el tiempo en ciclos de reloj.
Como se nota los que programáis para PCs o computadores de propósito general; podéis reservar memoria; en mi mundo usar un "malloc" es algo prohibido, aunque la función existe y está implementada, como no garantiza un retorno con éxito, no puedes utilizarla; y suerte tienes cuando dispones de 1 MB de RAM
Y los compiladores de C++ para esas arquitecturas, al final no acaban de estar plenamente soportados, tienen soporte parcial,
o las normas de codificación que tienes que seguir se pegan de frente con las características de C++
Para PC, lo más reciente que programé (y hace más de un año), fué un driver para un dispositivo USB personalizado;
y eso iba directo junto al kernel de Windows y cómo accedes al hardware del chipset USB del PC; pues C y punteros xD
¿Retraso? Si paso una imagen a una funcion que aplica un blur, lo normal es que le pase un puntero a la imagen y la funcion realice el blur sin hacer ningun tipo de copia. La solucion que propones es hacer una copia y pasarla a la funcion, despues si quiero machacar la imagen original con el resultado tengo que hacer otra copia... Muy lento.
En muchas arquitecturas el hardware esta mapeado a unas direcciones de memoria, si tienes que hacer un driver, ¿como voy a decirle a la tarjeta grafica, a la controladora del disco duro, o tarjeta de sonido que quiero activar a un determinado modo si no tengo un puntero que apunte a ese registro?
El problema de los punteros es que no se enseña a programacion de forma correcta, te dan un curso de python o java sin explicarte como funciona un ordenador, que las variables u objetos que creas parece que estan en el limbo y no importa si creas miles de ellos. He visto codigo para manejar matrices para graficos 3D (o sea matrices de 4x4 nada de matrices de cualquier tamaño) y crear los valores en el heap (usando new) en vez de crearlos en la pila.
fbustamante
14/10/2023, 18:07
Yo me crié con punteros y trabajar de otra forma me parece lo mismo que tirar comida porque tenemos mucha.
Así tenemos actualizaciones de 100 Gb y programas que no sabes dónde correrlos porque no van finos en ningún lado.
futu-block
14/10/2023, 23:31
ese es el problema, el de los transistores que aumentaba de tamaño cada dos año (o algo de eso)...
total, que cada vez tenemos mas memoria, mas capacidad de almacenaje, mas velocidad a la hora de hacer cálculos, mas etceteras que hacen que nuestro proyecto sea un almacén de 500 mil metros cuadrado con maquinarias de todas clases posibles y recursos ilimitados...
ya no optimizamos, aunque sea un poquito, las cosas las hacemos al pimponazo, da igual...
Los punteros eran un mal necesario cuando los ordenadores no tenían apenas recursos y había que usarlos para acceder directamente a las posiciones de memoria en lugar de (por ejemplo) reservar más memoria para trabajar con un duplicado de esos datos. Pero a día de hoy son un **** atraso en el 99% de los casos.
Y que te impide en C pedir memoria dinamica para duplicar los datos, aunque me parece que es una perdida de recursos duplicar los datos y no trabajar directamente con ellos. Atraso para mi es utilizar un lenguaje como python que es lo mas ineficiente que pueda existir o java para un backend o batch. Aunque a dia de hoy es raro utilizar C puro, es mas normal utilizar C++.
Volvemos a lo mismo: hay que usar la herramienta correcta para el problema concreto.
Yo he programado dispositivos embebidos en ASM. Cuando empezaron a salir los que se programaban en C me parecieron un atraso. Si Masteries lo ve bien es por una sola cosa: los sistemas lo soportan. La tecnología es mejor, la velocidad lo admite, los compiladores son eficientes, y el ahorro de tiempo es más que perceptible.
Lo mismo que hacer operaciones sobre una copia es perder el tiempo, hacerlo sobre los datos originales puede ser un peligro, o nada recomendable, porque pierdes los datos originales. Puede que los datos te hagan falta más adelante, y si los has modificado, tienes que volver a cargarlos. Mismos motivos por los que la gente trabaja con ficheros en copia local, y nunca desde un pendrive... o trabajaba.
Sí, hacer una copia de datos gasta memoria, pero copiar una matriz de 1024x1024x4 cuando tienes 16GB de espacio para trabajar, no me parece un malgasto de memoria. Diferente sería si estuviéramos con los 32MB de la Wiz.
Y no es que un malloc esté prohibido en un sistema embebido, es que la cantidad de memoria reservada para tal instrucción es extremadamente limitada, y se dice "prohibido" para que la gente se acostumbre a usar la cabeza. Al menos, cuando yo estudiaba, había siempre un bloque de memoria reservado para la pila, y otro para operaciones de memoria dinámica, pero si la memoria no me falla, por cada 8MB de memoria, eran 100KB como mucho.
EDIT: De hecho, siempre he visto un atraso los lenguajes interpretados, tipo Javascript: al final realizas una casi compilación cada vez que ejecutas el código, tienes que identificar las líneas, las palabras reservadas, los comandos, sus parámetros, una y otra vez, y todo en una ristra de caracteres. Eso, antes siguiera de pensar en ejecutar la acción. Y aparte, que cualquiera puede leer tu código, alterarlo, buscar vulnerabilidades... La de veces que habré guardado una imagen o un vídeo de una web que supuestamente lo tiene deshabilitado :D
Lo de las actualizaciones de 100GB creo que van por otros derroteros. Siempre me ha extrañado que un parche de código, que son los ficheros más pequeños de un proyecto, requieran descargar tantos datos en los juegos de hoy. Tanto espacio es indicativo de que se han modificado los gráficos y los sonidos, y si no hay nadie que se haya dado cuenta de ese detalle, o es que han cambiado datos no visibles (triggers en animaciones, metadatos...), o es que va todo encriptado, y el cambio de algunos bytes del ejecutable obliga a volver a encriptarlo todo por algún checksum o alguna verificación similar.
masteries
18/10/2023, 12:01
Y no es que un malloc esté prohibido en un sistema embebido,
Técnicamente prohibido no,
Pero si tu sistema embebido va para un ascensor, una grúa, un automóvil, un tren, un avión, una nave espacial o un satélite, o para un dispositivo médico.
Y son escenarios bastante comunes para los sistemas embebidos; incluso si es algo de IoT para un coche... como va para un coche y se tiene que homologar,
pues a seguir las reglas, así que lo recomendable es seguir bastante muchas de esas reglas en el día a día, así vas estando preparado llegado el caso
Entonces sí está prohibido; pero se debe a las normas de codificación muy estrictas que debes seguir, creo que nunca te has enfrentado a ellas y no las conoces; tales como MISRA C y las derivadas del IEC según sector. Se trata de evitar casos como el del Challenger, que se cree se debió a dos controladores cuyo código estaba compilado con dos compiladores diferentes, y el tipo de dato predeterminado en ambos no coincidía... ya tampoco se permite hacer uso del tipo de dato predeterminado del compilador, por ejemplo esto:
unsigned short variable;
/* Declarar variables al estilo antiguo, como en C89, nada de declarar variables entre medias del codigo */
/* Ni utilizar tildes en los comentarios, y solo este tipo de comentarios, los de C89 */
/* Se pueden utilizar variables sin inicializar, pero en su primer uso, ha de inicializarse */
...
...
variable = 0;
/* Esto no se permite, porque ese 0 puede ser un double, un uint32, un int32... segun le salga al compilador */
/* la norma MISRA señala que no puedes apoyarte en los tipos por defecto del compilador */
/* ni utilizar funciones que no puedan garantizar un 100% de retorno con exito en todas las ocasiones, como malloc, free... */
variable = (unsigned short)0; /* Asi es como debe ir todo el codigo, incluso cuando se hacen operaciones, es muy pesado si */
Editado: Imaginad el caso del Challenger, desde el controlador central se envía un valor de 100 como un entero sin signo de 32 bits;
y el controlador del motor interpreta ese 100 binario, como un double o un float... el controlador del motor vió de todo menos un 100;
y reventó.
Y que te impide en C pedir memoria dinamica para duplicar los datos, aunque me parece que es una perdida de recursos duplicar los datos y no trabajar directamente con ellos. Atraso para mi es utilizar un lenguaje como python que es lo mas ineficiente que pueda existir o java para un backend o batch. Aunque a dia de hoy es raro utilizar C puro, es mas normal utilizar C++.
Nada te impide trabajar con punteros, salvo el hecho de que estás jugueteando con las direcciones de memoria. Si no cometes ningún error están muy bien, pero los humanos somos dados a cometer errores y los errores cuando estas toqueteando la memoria pueden tener consecuencias muy aleatorias y una trazabilidad un tanto difícil. Por mencionar algo que recuerdo de mis tiempos de estudiante, cuando para ahorrarte duplicar un array pasas un puntero a dicho array y decides avanzar por él sumando posiciones al valor del puntero y te sales de él sin darte cuenta, o cuando retornas un puntero y en lugar de acceder al valor que hay en esa dirección de memoria, tomas la dirección del puntero como valor, etc, etc.
Técnicamente prohibido no,
Pero si tu sistema embebido va para un ascensor, una grúa, un automóvil, un tren, un avión, una nave espacial o un satélite, o para un dispositivo médico.
Y son escenarios bastante comunes para los sistemas embebidos; incluso si es algo de IoT para un coche... como va para un coche y se tiene que homologar,
pues a seguir las reglas, así que lo recomendable es seguir bastante muchas de esas reglas en el día a día, así vas estando preparado llegado el caso
Entonces sí está prohibido; pero se debe a las normas de codificación muy estrictas que debes seguir, creo que nunca te has enfrentado a ellas y no las conoces; tales como MISRA C y las derivadas del IEC según sector. Se trata de evitar casos como el del Challenger, que se cree se debió a dos controladores cuyo código estaba compilado con dos compiladores diferentes, y el tipo de dato predeterminado en ambos no coincidía... ya tampoco se permite hacer uso del tipo de dato predeterminado del compilador, por ejemplo esto:
unsigned short variable;
/* Declarar variables al estilo antiguo, como en C89, nada de declarar variables entre medias del codigo */
/* Ni utilizar tildes en los comentarios, y solo este tipo de comentarios, los de C89 */
/* Se pueden utilizar variables sin inicializar, pero en su primer uso, ha de inicializarse */
...
...
variable = 0;
/* Esto no se permite, porque ese 0 puede ser un double, un uint32, un int32... segun le salga al compilador */
/* la norma MISRA señala que no puedes apoyarte en los tipos por defecto del compilador */
/* ni utilizar funciones que no puedan garantizar un 100% de retorno con exito en todas las ocasiones, como malloc, free... */
variable = (unsigned short)0; /* Asi es como debe ir todo el codigo, incluso cuando se hacen operaciones, es muy pesado si */
Editado: Imaginad el caso del Challenger, desde el controlador central se envía un valor de 100 como un entero sin signo de 32 bits;
y el controlador del motor interpreta ese 100 binario, como un double o un float... el controlador del motor vió de todo menos un 100;
y reventó.
No, no conozco esas normas, porque por suerte no me he visto aún en la tesitura de tener que programar un sistema tan limitado, tan crítico, o de tiempo real.
De todas formas, lo entiendo. En un SO tienes la ventaja de que el sistema te reserva un espacio de memoria, y vigila que no te salgas de él. Eso no existe en sistemas embebidos... bueno, no existía, cada vez son más los que usan un kernel Linux, o un BIOS (y no me refiero al Sistema Básico de Entrada y Salida, sino al micro Sistema Operativo para estos cacharros, que no recuerdo cuál era el acrónimo ^^U). Como digo, yo aprendí microcontroladores en ASM, y los que iban dos cursos por detrás usaron C, y creo que ya andan usando Pyton.
En fin, que sí, lo del Challenger, según nos explicaron, a groso modo, fue que hubo un desbordamiento de una variable, por usar un byte en lugar de un int o algo parecido. Y por eso siempre he preferido los lenguajes fuertemente tipados, aunque sea un rollo el andar convirtiendo unidades, pero te obligan a declarar siempre el tipo de la variable.
De hecho, ayer mismo me tuve que pelear con Javascript, porque me estaba guardando un valor como string, y necesitaba que fuera un número... y era algo que ya había corregido anteriormente por otra cosa. Es más, la misma variable servía para guardar el valor tanto en string como en "numérico"... y la conversión la puede hacer automáticamente, en función de la operación que realices... tienes que tener un cuidado.
Nada te impide trabajar con punteros, salvo el hecho de que estás jugueteando con las direcciones de memoria. Si no cometes ningún error están muy bien, pero los humanos somos dados a cometer errores y los errores cuando estas toqueteando la memoria pueden tener consecuencias muy aleatorias y una trazabilidad un tanto difícil. Por mencionar algo que recuerdo de mis tiempos de estudiante, cuando para ahorrarte duplicar un array pasas un puntero a dicho array y decides avanzar por él sumando posiciones al valor del puntero y te sales de él sin darte cuenta, o cuando retornas un puntero y en lugar de acceder al valor que hay en esa dirección de memoria, tomas la dirección del puntero como valor, etc, etc.
Estaba preguntando que qué te impedía duplicar memoria usando punteros, igual que si pasas una variable por valor. Que no, nada te lo impide, pero es tontería, porque es esfuerzo doble.
A mi, lo que me traía de cabeza era tener que acordarme de recorrer el array al revés para ir borrando elementos, para evitar salirme de la lista con un bucle FOR. O peor, tener que ir con dos punteros para borrar un nodo, y reenlazar el nodo anterior con el siguiente. Un desastre cuando usabas listas doblemente enlazadas. Y ni mencionemos los punteros creadores y consumidores en sistemas asíncronos. El que haya visto algo de procesos y semáforos, sabe de qué hablo.
Pero puedes hacer cosas imposibles de otra forma, como un buffer circular, cuyo último valor es el anterior del primero, y que se usa mucho en el filtrado de señales.
Creo que hablais del cohete Ariane, el Challenger exploto por un problema con las juntas de los depositos o algo asi.
No, no conozco esas normas, porque por suerte no me he visto aún en la tesitura de tener que programar un sistema tan limitado, tan crítico, o de tiempo real.
De todas formas, lo entiendo. En un SO tienes la ventaja de que el sistema te reserva un espacio de memoria, y vigila que no te salgas de él. Eso no existe en sistemas embebidos... bueno, no existía, cada vez son más los que usan un kernel Linux, o un BIOS (y no me refiero al Sistema Básico de Entrada y Salida, sino al micro Sistema Operativo para estos cacharros, que no recuerdo cuál era el acrónimo ^^U). Como digo, yo aprendí microcontroladores en ASM, y los que iban dos cursos por detrás usaron C, y creo que ya andan usando Pyton.
En fin, que sí, lo del Challenger, según nos explicaron, a groso modo, fue que hubo un desbordamiento de una variable, por usar un byte en lugar de un int o algo parecido. Y por eso siempre he preferido los lenguajes fuertemente tipados, aunque sea un rollo el andar convirtiendo unidades, pero te obligan a declarar siempre el tipo de la variable.
De hecho, ayer mismo me tuve que pelear con Javascript, porque me estaba guardando un valor como string, y necesitaba que fuera un número... y era algo que ya había corregido anteriormente por otra cosa. Es más, la misma variable servía para guardar el valor tanto en string como en "numérico"... y la conversión la puede hacer automáticamente, en función de la operación que realices... tienes que tener un cuidado.
Estaba preguntando que qué te impedía duplicar memoria usando punteros, igual que si pasas una variable por valor. Que no, nada te lo impide, pero es tontería, porque es esfuerzo doble.
A mi, lo que me traía de cabeza era tener que acordarme de recorrer el array al revés para ir borrando elementos, para evitar salirme de la lista con un bucle FOR. O peor, tener que ir con dos punteros para borrar un nodo, y reenlazar el nodo anterior con el siguiente. Un desastre cuando usabas listas doblemente enlazadas. Y ni mencionemos los punteros creadores y consumidores en sistemas asíncronos. El que haya visto algo de procesos y semáforos, sabe de qué hablo.
Pero puedes hacer cosas imposibles de otra forma, como un buffer circular, cuyo último valor es el anterior del primero, y que se usa mucho en el filtrado de señales.
Efectivamente, pero una de las funcionalidades más usadas de los punteros, como es acceder a una variable de otra función o de otra parte del programa, se ha simplificado mucho con los años con las referencias anidadas (no se si ese es el nombre oficial, me refiero a la típica manera de codificar en visual studio de acceder a variables de otra función poniendo el nombre de la función, un punto y el nombre de la variable, en plan "funcion2.variable1"), por lo que una de las mayores justificaciónes que tenían en un principio, que es la de no duplicar datos en memoria, ya no es válida hoy en día. Otra cosa es que esas referencias anidadas sean internamente punteros, pero el caso es que con esa sintaxis ahorras muchos quebraderos de cabeza y errores accidentales.
josepzin
18/10/2023, 18:29
Creo que hablais del cohete Ariane, el Challenger exploto por un problema con las juntas de los depositos o algo asi.
Ya me parecía, porque de los dos transbordadores accidentados uno fue por unas juntas que se congelaron (creo) y el otro fue por unas placas termicas que se desprendieron.
Creo que hablais del cohete Ariane, el Challenger exploto por un problema con las juntas de los depositos o algo asi.
Lo siento, pero es que no nos presentaron formalmente, por lo que no se me quedó su nombre en la cabeza :D
Efectivamente, pero una de las funcionalidades más usadas de los punteros, como es acceder a una variable de otra función o de otra parte del programa, se ha simplificado mucho con los años con las referencias anidadas (no se si ese es el nombre oficial, me refiero a la típica manera de codificar en visual studio de acceder a variables de otra función poniendo el nombre de la función, un punto y el nombre de la variable, en plan "funcion2.variable1"), por lo que una de las mayores justificaciónes que tenían en un principio, que es la de no duplicar datos en memoria, ya no es válida hoy en día. Otra cosa es que esas referencias anidadas sean internamente punteros, pero el caso es que con esa sintaxis ahorras muchos quebraderos de cabeza y errores accidentales.
Que yo sepa, el mayor uso de los punteros es el de referenciar a una zona de memoria que hemos reservado, y que vamos pasando de una función a la siguiente como parámetro, para no tener que duplicarla. O el paso por referencia, en lugar de por valor.
No sé a qué te refieres con "acceder a variables de otra función" en lenguajes que no sean Orientados a Objetos o de ejecución procedural. En C yo aprendí que los datos entre funciones o métodos siempre se pasan por parámetro (de nuevo, por valor o referencia) o devolviendo un valor, por lo que siempre tendremos o una variable de tipo x, o un puntero a una zona de memoria. A lo mejor son cosas mucho más avanzadas de las que yo vi, pero el acceso a una zona de memoria, sin tener una referencia, nunca ha sido, por lo que yo aprendí, buenas prácticas.
Por eso se crearon las clases, para ir pasando instancias de clases, o referencias estáticas, y que su "zona de memoria" sean sus atributos, y su acceso esté más controlado, ya sea mediante sus métodos o por sus funciones de acceso (get/set).
También están los punteros a funciones, pero eso ya quedó fuera de lo que aprendí, y aunque alguna vez me pareció útil, al final nunca lo usé. Creo que tiraba de directivas del precompilador, que jamás llegué a usar y temas de cadenas a funciones que nunca me gustaron, sobre todo, porque usar una string como un valor absoluto siempre me pareció una fuente de errores muy grandes (esto lo llegué a usar en Java, y una simple tilde o una mayúscula o un carácter en una codificación diferente y ya no sabía dónde tenía que ir).
Lo siento, pero es que no nos presentaron formalmente, por lo que no se me quedó su nombre en la cabeza :D
Que yo sepa, el mayor uso de los punteros es el de referenciar a una zona de memoria que hemos reservado, y que vamos pasando de una función a la siguiente como parámetro, para no tener que duplicarla. O el paso por referencia, en lugar de por valor.
No sé a qué te refieres con "acceder a variables de otra función" en lenguajes que no sean Orientados a Objetos o de ejecución procedural. En C yo aprendí que los datos entre funciones o métodos siempre se pasan por parámetro (de nuevo, por valor o referencia) o devolviendo un valor, por lo que siempre tendremos o una variable de tipo x, o un puntero a una zona de memoria. A lo mejor son cosas mucho más avanzadas de las que yo vi, pero el acceso a una zona de memoria, sin tener una referencia, nunca ha sido, por lo que yo aprendí, buenas prácticas.
Por eso se crearon las clases, para ir pasando instancias de clases, o referencias estáticas, y que su "zona de memoria" sean sus atributos, y su acceso esté más controlado, ya sea mediante sus métodos o por sus funciones de acceso (get/set).
También están los punteros a funciones, pero eso ya quedó fuera de lo que aprendí, y aunque alguna vez me pareció útil, al final nunca lo usé. Creo que tiraba de directivas del precompilador, que jamás llegué a usar y temas de cadenas a funciones que nunca me gustaron, sobre todo, porque usar una string como un valor absoluto siempre me pareció una fuente de errores muy grandes (esto lo llegué a usar en Java, y una simple tilde o una mayúscula o un carácter en una codificación diferente y ya no sabía dónde tenía que ir).
Resumiendo, quería decir que una de las cosas que antes se hacía con punteros ahora se hace con referencias anidadas. Vamos, que en lugar de tener que andar pasando direcciones de memoria con los problemas que puede dar eso, ahora se hace de manera implícita accediendo directamente a variables de otras funciones poniendo el nombre de la función un punto y el de la variable. No se si me explico.
josepzin
18/10/2023, 23:44
Usar variables... pfff estos programadores modernos.
Resumiendo, quería decir que una de las cosas que antes se hacía con punteros ahora se hace con referencias anidadas. Vamos, que en lugar de tener que andar pasando direcciones de memoria con los problemas que puede dar eso, ahora se hace de manera implícita accediendo directamente a variables de otras funciones poniendo el nombre de la función un punto y el de la variable. No se si me explico.
Pues no, como no me pongas ejemplos de qué lenguajes estás hablando, yo pienso que hablas de C, y como no sean variables estáticas, una función, por sí sola, no tiene valores en sus variables, a no ser que sea una instancia, padre de la función que se está ejecutando en ese momento, y puede haber varias instancias (ejemplo: recursividad).
Como digo, en C# puedes hacer MiClase.campo1 siempre que campo1 sea estática, o bien instanciaMiClase.campo2, donde instanciaMiClase es de tipo MiClase, y campo2 es una variable public, internal o tenga implementada Get(). Y lo bueno de las clases es que puedes acceder a MiClase.campo3 que es private, siempre que lo hagas mediante un método public, que ya se encarga, por ejemplo, de verificar que los valores son válidos, que las condiciones lo permiten, o que se puede devolver su valor en el tipo que se necesite (por ejemplo, una string en el "culture" apropiado, es decir, con coma decimal en español, o con punto decimal en inglés).
Moderneces innecesarias para el programador de C de toda la vida, que ya sabe todo eso y toma sus propias medidas para evitar estos problemas :D Y en el caso del que usa ASM, ya ni te cuento ¿Cultures? Da gracias de que te devuelve una serie de chars ASCII por la consola de comandos, que alguien ya redirigirá a un log de texto al ejecutar el binario.
Ten en cuenta una cosa (y así me lo enseñaron): cada función de C tiene dos zonas de memoria reservadas, la parte de código, que es compartida por todas las instancias de dicha función, y que es de sólo lectura, para la ejecución de comandos, y la parte de las variables, de la que se crea una copia por instancia, ya que "int cont" no vale lo mismo en miFuncion padre que en miFunción hija, o miFuncion que se ejecuta en el segundo core. Por eso decir "un puntero a una variable de una función" es muy ambiguo, tienes que haber pasado el puntero por parámetro, y asegurarte de que dicha zona de memoria no se ha liberado, porque podría haber sido machacada por otra instancia. Es el tipo de errores que eran usados por hackers para acceder a zonas de memoria del sistema, antes de que los SO limitasen el acceso a las direcciones reservadas para esa ejecución del programa. Aunque claro, estoy hablando de una época donde W95 no era más que un proyecto :P
Ten en cuenta una cosa (y así me lo enseñaron): cada función de C tiene dos zonas de memoria reservadas, la parte de código, que es compartida por todas las instancias de dicha función, y que es de sólo lectura, para la ejecución de comandos, y la parte de las variables, de la que se crea una copia por instancia, ya que "int cont" no vale lo mismo en miFuncion padre que en miFunción hija, o miFuncion que se ejecuta en el segundo core.
Las variables locales de una funcion se meten en la pila.
Las variables locales de una funcion se meten en la pila.
Cierto, perdón por mi error.
Lo cual no quita para que, si no hay instancia, no hay memoria en la pila :P
Al final, es una cuestión de preferencias, si prefieres la simplicidad de los punteros, la seguridad de las clases, o si eres un Máster del código que prefiere ensuciarse las manos hasta los codos, y aprovechar el HW al máximo. Lo que no entiendo son las guerras que se forman en torno a cada lenguaje, y por qué el lenguaje de los demás es siempre una aberración... Excepto Java, Java es el demonio, ineficiente, y todas las alternativas son siempre mejores :lol:
josepzin
25/10/2023, 19:25
https://www.youtube.com/watch?v=u12e3Gyq6sQ
Sombras verdes? pfff prefiero Godot.
-----Actualizado-----
PD: el movil no va a 60fps, yo diria mas bien entre 15fps y 20fps
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.