Ver la versión completa : ¿Programar en Android sin saber Java?
FlipFlopX
16/09/2015, 20:34
Hola gente, quiero desarrollar una app android para mostrar datos de un server, algo sencillo en principio, mostrar tal dato, 4 botones y poco más, que irá aumentando en complejidad. La cuestión es que en todos lados veo 1º Java, luego Android. No sé si con algún IDE tipo Android Studio se puede hacer algo con las plantillas que hay, o toca aprender Java (y si se puede pararelizar mientras se aprende Android). Pues eso, saludetes :D
Tienes C# con Xamarin, Javascript con React Native, C++ con cualquier motor de videojuegos, HTML5 con una página web móvil o Cordova, Go con gomobile, Kotlin o Groovy/Scala/Clojure como otras posibilidades. No es lo mismo que hacerlo con Java a pelo, pero si lo único que quieres es sacar un app son opciones. Programar vas a tener que programar con todos ellos.
Si lo que quieres es algo de drag & drop también hay un par de programas por ahí para hacerlo, pero es como el que quiere aprender a conducir usando un triciclo.
Y no sé hasta qué punto, incluso con Unity creo que puedes hacerlo: puedes programar con C# o Javascript, y hacer los interfaces casi con drag&drop (sólo tendrías que programar lo que hace cada botón, incluso se pueden animar los elementos de forma gráfica).
Aunque creo que con Java tardas menos, si sabes programar con él (y por lo que he visto, no es muy diferente de C#, a nivel básico). Android es una de mis tareas pendientes, lo dejé con el "hola mundo" usando XML :confused:
Si es una app chorra de las que hay a tropecientos, con Java C# o cuelquiera de esos lenguajes de pseudoprogramación te valen.
Si lo que quieres es hacer algo serio, C (ni siquiera C++), ensamblador y un lanzador Java.
De todas formas, C#, Java, Python, Ruby y todos esos lenguajes chorras se sustentaban en una ley que ya va para 10 años que no se cumple (la ley de Moore).
Para Java ya hay un calendario de extinción parcial (las grandes compañías limitaran su uso), para C# otro, y mono, la versión gratuita de C.NET, tiene el futuro mas negro que el de la propia España.
De todas formas, no te apures, los planes de extinción son a muy largo plazo, Java seguirá siendo un lenguaje para los negocios, al igual que C#, y C# será el lenguaje de scripting de referencia para hacer chorraditas en Windows.
La vuelta a C/C++ y ensamblador está cada vez mas cerca, tal y como predijo un doctor en ciencias de la computación en un artículo que ley hace tiempo creo que en la revista DrDobb's, si no recuerdo mal.
Ñuño Martínez
17/09/2015, 14:47
Smart Mobile Studio (http://smartmobilestudio.com/). Lo único malo, que es de pago. Prometieron una versión "community" del compilador/traductor, pero por lo que sé, todavía no lo han hecho.
La vuelta a C/C++ y ensamblador está cada vez mas cerca, tal y como predijo un doctor en ciencias de la computación en un artículo que ley hace tiempo creo que en la revista DrDobb's, si no recuerdo mal.
Ojalá fuera así.
^MiSaTo^
17/09/2015, 14:55
Si es una app chorra de las que hay a tropecientos, con Java C# o cuelquiera de esos lenguajes de pseudoprogramación te valen.
Si lo que quieres es hacer algo serio, C (ni siquiera C++), ensamblador y un lanzador Java.
De todas formas, C#, Java, Python, Ruby y todos esos lenguajes chorras se sustentaban en una ley que ya va para 10 años que no se cumple (la ley de Moore).
Para Java ya hay un calendario de extinción parcial (las grandes compañías limitaran su uso), para C# otro, y mono, la versión gratuita de C.NET, tiene el futuro mas negro que el de la propia España.
De todas formas, no te apures, los planes de extinción son a muy largo plazo, Java seguirá siendo un lenguaje para los negocios, al igual que C#, y C# será el lenguaje de scripting de referencia para hacer chorraditas en Windows.
La vuelta a C/C++ y ensamblador está cada vez mas cerca, tal y como predijo un doctor en ciencias de la computación en un artículo que ley hace tiempo creo que en la revista DrDobb's, si no recuerdo mal.
http://www.subeimagenes.com/img/cuentanos-mas-93739.jpg
Molondro
17/09/2015, 15:00
Mirate appinventor, creo que te puede servir
IMHO si quieres aprovechar el android tienes que programar en java, si usas cualquier librería/lenguaje puente no le vas a sacar todo el provecho y estarás a la espera de que actualicen la librería en caso de que saquen nuevas librerías en android.
Lo mismo que iOS/OS X, si quieres sacarle provecho aprende Objective-C.
_Seagal_
17/09/2015, 19:16
No te asustes con el java en android. Con la cantidad infinita de ejemplos que hay en internet no hace falta saber programar, solo cortar y pegar y adaptar (y entender lo que estas cortando y pegando, claro).
Si es una app chorra de las que hay a tropecientos, con Java C# o cuelquiera de esos lenguajes de pseudoprogramación te valen.
Si lo que quieres es hacer algo serio, C (ni siquiera C++), ensamblador y un lanzador Java.
De todas formas, C#, Java, Python, Ruby y todos esos lenguajes chorras se sustentaban en una ley que ya va para 10 años que no se cumple (la ley de Moore).
Para Java ya hay un calendario de extinción parcial (las grandes compañías limitaran su uso), para C# otro, y mono, la versión gratuita de C.NET, tiene el futuro mas negro que el de la propia España.
De todas formas, no te apures, los planes de extinción son a muy largo plazo, Java seguirá siendo un lenguaje para los negocios, al igual que C#, y C# será el lenguaje de scripting de referencia para hacer chorraditas en Windows.
La vuelta a C/C++ y ensamblador está cada vez mas cerca, tal y como predijo un doctor en ciencias de la computación en un artículo que ley hace tiempo creo que en la revista DrDobb's, si no recuerdo mal.
Duras y polémicas declaraciones. Tú lo insinúas, pero yo lo digo: Java es el nuevo COBOL, XD
josepzin
17/09/2015, 21:48
La vuelta a C/C++ y ensamblador está cada vez mas cerca, tal y como predijo un doctor en ciencias de la computación en un artículo que ley hace tiempo creo que en la revista DrDobb's, si no recuerdo mal.
Se debería poner por ley :P
¿El pache anda reactivando clones o qué? están frescos no, fresquísimos.
El día que se vuelva a C, C++ y/o ensamblador, va a haber un superhabit de empleos de programador bestial. No por nada, sino por los "malos hábitos" de los lenguajes de "alto nivel" que se les habrá pegado a más de un """programador""" (nótese las comillas triples).
También te digo que los tiempos de desarrollo se van a quintuplicar como poco :lol:
En el junglegungle que hay ahora se incluye el gamemaker de yoyo por 12$ con el modulo de android incluido (normalmente vale 299$)
ah! y tambien incluye varios juegos indie bastante decentes con codigo fuente
Aiken
FlipFlopX
18/09/2015, 21:28
Gracias por los consejos!
El día que se vuelva a C, C++ y/o ensamblador, va a haber un superhabit de empleos de programador bestial. No por nada, sino por los "malos hábitos" de los lenguajes de "alto nivel" que se les habrá pegado a más de un """programador""" (nótese las comillas triples).
También te digo que los tiempos de desarrollo se van a quintuplicar como poco :lol:
Yo estaría muuuuy feliz, que de POO poco, un curso exprés de Java del que no me acuerdo de casi nada y C++ lo que di en la universidad para hacer una interfaz de usuario básica
El problema es que para hacer algunas librerías o aplicaciones tienes que tirar de C/C++ si quieres rendimiento y si cada vez hay menos programadores.
Hace tiempo hicimos en el curro una aplicación con las librerias en C++ y la interface en .NET y no veas como bajaba el rendimiento respecto a una hecha entera en C++.
Por tocar los cojones, ¿qué opinais de Rust como alternativa a C++ en bajo nivel en PC? Corre sobre LLVM + clang, abstracciones útiles y baratas, sintaxis y paradigmas de este siglo, RAII por defecto, buen compilador, buen manejo de dependencias, librería base que no es el toperón de las STL + boost que no se puede usar en muchos sitios, diseñado para multihilo desde el principio.
Seguirá siendo más lento que C a pelo o C++ bien optimizado, pero con el borrow checker te quitas de la mayoría de los errores comunes.
Y para que no os ofendais, una lista de buenas prácticas en C++ https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
Ñuño Martínez
22/09/2015, 11:31
Por tocar los cojones, ¿qué opinais de Rust como alternativa a C++ en bajo nivel en PC? Corre sobre LLVM + clang, abstracciones útiles y baratas, sintaxis y paradigmas de este siglo, RAII por defecto, buen compilador, buen manejo de dependencias, librería base que no es el toperón de las STL + boost que no se puede usar en muchos sitios, diseñado para multihilo desde el principio. Jo#€r, qué viejo soy. NPI de lo que es Rust, LLVM, clang y RAII. Incluso lo del boost me suena a chino, porque me temo que la traducción que conozco no es a lo que te estás refiriendo. :lamer: Pero me da igual. Por lo que he visto, C++ sigue siendo el mismo excremento de siempre y la STL sigue liando la marrana cosa mala. El C de toda la vida (léase pre-99, que el C99 tampoco es que me haga mucha gracia) sigue siendo la mejor opción para programar en bajo nivel. :teacher:
Y para que no os ofendais, una lista de buenas prácticas en C++ https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md No me ofendo. Aun así, sigo pensando que la mejor práctica en C++ es no utilizarlo. :canon2:
Jo#€r, qué viejo soy. NPI de lo que es Rust, LLVM, clang y RAII. Incluso lo del boost me suena a chino, porque me temo que la traducción que conozco no es a lo que te estás refiriendo. Rust es un lenguaje de programación bastante reciente con énfasis en "memory safety" pero manteniendo las bases de C con clases. LLVM es (entre otras cosas) una especificación para "bytecode" que luego se compila contra la plataforma, como hace la JVM pero sólo en tiempo de compilación y orientado a bajo nivel tipo C/C++ o nuevos lenguajes como Rust. Clang es un compilador Lin/OSX/Win que produce "bytecode" para LLVM, y le ha ganado la cancha a GCC los últimos años porque reporta mejor los errores, anda a la par en rendimiento (?), y es más configurable porque deja ver los árboles sintácticos. RAII es un patrón de programación para llevar el tema de la gestión de punteros algo mejor y dejarlos caer cuando toca para evitar errores, es con lo que más se le llenala boca a los de C++ desde el 11. Boost es una de las colecciones de librerías más conocidas, tiene un porrón de años, y complementa las stl con cosas como manejo de fechas, regex y mil movidas más.
Pero si, aprender C correctamente aun te lleva a muchos sitios y eso no va a cambiar de hoy a mañana ^^ C multihilo sigue siendo un poco putada por lo que se, y eso echa para atrás a mucha gente.
C++ sigue siendo el mismo excremento de siempre y la STL sigue liando la marrana cosa mala.Si. Osea, han añadido cosas para que la gente deje la gramática de C con clases y empiece a tener un poco más en cuenta usar la memoria correctamente con inferencia de tipos, punteros con referencias contadas, o que no se puedan compartir, además de un nuevo tipo de paso de parámetros barato por "préstamo". Pero en el fondo siguen siendo un par de añitos sólo aprenderte todo lo que std te dejan hacer, y luego ya te metes con stl, boost y los sospechosos habituales de libPNG, etc.
Pero a ver, que yo me aclare ¿Tan mala es la POO de C++ como para deshecharlo completamente? Me parece una herramienta útil para encapsular la funcionalidad y mantener cierto orden en el código... o al menos así me parece en Java ¿Hay mucha diferencia entre ambos?
Porque C no tiene nada parecido, y recuerdo "imitar" el comportamiento teniendo una lista enlazada, pasándola por parámetros, y modificándola/consultándola sólo y exclusivamente desde las funciones creadas para manejarla.
Lo cierto es que tengo que ponerme y aprender C en serio, no lo que nos enseñaron en la facultad, que era hasta lo más básico de punteros ^^U
El problema de la POO en C++ es que tienes que ser un poco adivino porque para que funcione la vinculación dinamica tienes que declarar los métodos como virtual, si es una librería de la que no tienes el código y el método no es virtual y necesitas cambiarlo pues te jodes.
De todas formas es cuestion de acostumbrarse y si quieres tener rendimiento sigo pensando que es la mejor opción, lastima que aquí en españa parece que no se hacen aplicaciones serias en C++.
Ñuño Martínez
22/09/2015, 20:34
Pero a ver, que yo me aclare ¿Tan mala es la POO de C++ como para deshecharlo completamente? Yo el problema no lo tengo con la POO, sino con cómo funciona el lenguaje. Ha tomado de C muchas cosas "malas" (desde el punto de vista de un lenguaje de alto nivel, aunque son utilísimas para programación a bajo nivel) que hacen que haya cosas que sean un maldito infierno entenderlas.
Por ejemplo, la conversión automática de datos. Ya da problemas en C si no te andas con ojo, si encima añadimos los "constructores de conversión" (creo que se llamaban así) más sobrecarga de operadores (sobre todo los de asignación) unido a una STL deficiente (no he usado las últimas versiones, me han dicho que han mejorado mucho, pero también me juraron lo mismo de Joomla) pues ya tienes un lío de tres pares que deja en "tontería fácil de identificar" el tema de que PHP te convierta las cadenas de texto en enteros sin avisar, y viceversa.
Me parece una herramienta útil para encapsular la funcionalidad y mantener cierto orden en el código... o al menos así me parece en Java ¿Hay mucha diferencia entre ambos?
Java y C++ NO son iguales. Repito, porque parece que la peña no lo pilla. Java y C++ NO son iguales. Parecidos sí, iguales no.
Porque C no tiene nada parecido, y recuerdo "imitar" el comportamiento teniendo una lista enlazada, pasándola por parámetros, y modificándola/consultándola sólo y exclusivamente desde las funciones creadas para manejarla.
Lo cierto es que tengo que ponerme y aprender C en serio, no lo que nos enseñaron en la facultad, que era hasta lo más básico de punteros ^^U En C puedes hacer programación POO con todo: Encapsulación, sobrecarga y polimorfismo. Porque la POO son esas tres cosas, nada más. El resto son comeduras de tarro de gurús que quieren venderte un libro para pagarse el yate.
Y ya se me ha calmado la sangre un poco, así que paro.
Pero antes: ¡Pascal! Ale, ya lo he dicho. Talué.
Las STL no tienen nada de deficientes, otra cosa es que usases las STL que te traen los compiladores de micro$oft que se pasan los estándar por los huevos y falten cosas y tengas otras que no funcionen igual.
IIRC java no permite la herencia multiple, y la vinculación dinamica funciona siempre, es como si pusieras todos los métodos como virtual en C++.
Las conversiones automáticas en los contructores la puedes evitar usando "explicit" en la declaración. http://stackoverflow.com/questions/121162/what-does-the-explicit-keyword-in-c-mean
^MiSaTo^
22/09/2015, 21:19
En C puedes hacer programación POO con todo: Encapsulación, sobrecarga y polimorfismo. Porque la POO son esas tres cosas, nada más. El resto son comeduras de tarro de gurús que quieren venderte un libro para pagarse el yate.
Y ya se me ha calmado la sangre un poco, así que paro.
Pero antes: ¡Pascal! Ale, ya lo he dicho. Talué.
Yo entiendo que Programación Orientada a Objetos es también que tengas objetos y clases. Y no me digas que un struct es lo mismo que una clase/objeto... porque no. De hecho la manera de pensar y diseñar algo en POO o en Estructurada es muy diferente.
Lo mejor de c++ es que contiene c en su gran mayoria, con todo lo bueno(control casi absoluto a bajo nivel, rendimiento) y lo malo (garbage collector integrado, pa que?)
De todas formas(en mi humilde entender, aqui no soy yo el tuerto) C++ no deja de ser un parche sobre C para poder utilizar POO.
Y ojo, me gusta c++, fue el lenguaje con el que aprendi POO por mi cuenta para poder enseñarlo en una academia para alumnos de empresariales/informatica de sistemas (no es coña) de Deusto. La primera vez fue un calvario, pero cuando le pille el tranquillo, me parecio que POO es un paradigma viable, incluso la sobrecarga de operadores (bien hecha) es una MARAVILLA y las herencias, con los polimorfismos y demas, una idea cojonuda para ahorrar codigo y encapsular.
En otro orden de cosas, este verano me he acercado al c# con unity y me ha dado cancer de sida el no poder crear constructores heredando monobehauvior.
La cosa es: si me pongo con c# a secas, me seguira dando asco??? Unity me da asco???
Por ahora, seguire con el gamemaker que aunque parezca para crios y no tenga funciones per se, lo tengo cogido de los huevos...
-----Actualizado-----
Yo entiendo que Programación Orientada a Objetos es también que tengas objetos y clases. Y no me digas que un struct es lo mismo que una clase/objeto... porque no. De hecho la manera de pensar y diseñar algo en POO o en Estructurada es muy diferente.
Cuanta razon Misato, una clase es un struct que ademas de variables alberga funciones y tiene un sistema de privacidad.
De todas formas(en mi humilde entender, aqui no soy yo el tuerto) C++ no deja de ser un parche sobre C para poder utilizar POO.Hace 15 años alomejor. Lo que antes estaba yo llamando "C con clases". A día de de hoy es otra bestia, empezando con C++03 y desde C++11 ha habido cambios radicales (autos, nuevos punteros, lambdas, std::, constexp, nullpt, function objects, asserts, move...) y ahora escribir como si fuera C está estrictamente verboten. Usar new, malloc o delete es mal. Arrays ni tocarlas, std::vector. Los devs lo llaman "modern c++" en tutoriales y sitios de referencia para distinguirlo.
Si no lo tocas desde que echaban Dragon Ball en la tele alomejor no es mala idea el echarle un ojo: http://herbsutter.com/elements-of-modern-c-style/
New es mal!?????? NOOOO!!!!
Joopeta, me tengo que poner al dia
-----Actualizado-----
Por cierto, siguen echando Dragoi Bola en ETB, tanto Z como Kai
-----Actualizado-----
Ya le he hechado un vistazo Pako, y la verdad, es que parece que a c++ le han puesto cara nueva y tetas.
Nuevas features y facilidades como nullptr y los nuevos punteros con ownership: me gustan...
Las lambdas, solamente he oido hablar de ellas pero no las he tocado nunca, no se ni lo que son...
tipificado de datos auto, no se si me gusta o no, ya me habia acostumbrado a hacer #typedefs en cadena para crear un puntero a un array de punteros que apuntan a objetos.
C++11/14/17 me da miedo, me da la sensacion de que cualquier linea que escriba estara mal/obsoleta... Me he quedado roto con lo de usar llaves en vez de parentesis
Necesito un libro/tutorial/ejercicios nuevos de c++, a ser posible buenos y por la patilla.
Una lambda es como un puntero a función excepto que el método lo defines en el momento y existe sólo mientras exista el contexto al que se lo estás pasando. Por ejemplo, tienes un método "hacer" que recibe dos int y un puntero a función (o std::func) que recibe dos ints y retorna un int, y se lo aplica a los parámetros del método "hacer". Puedes llamar a ese método con 2, 2, y luego una lambda que sume los dos parámetros que reciba, o una lambda que los reste, o los divida, todo con el mismo método pero sólo cambiando la lambda. No tienes que escribir métodos de suma y resta y luego coger el puntero a ellos, lo haces en el momento.
Otro ejemplo, Lambda que suma 4 al parámetro que mandes:
#include <iostream>
#include <functional>
int main()
{
std::function<int(int)> func2 = [](int i) { return i + 4; };
std::cout << "func2: " << func2(6) << '\n';
}
Hay todo un paradigma de programación montado alrededor de ésto llamado "functional programming", lo mismo que está estructurado (C) o POO (Java). El lenguaje FP más típico es Haskell, pero el más conocido es Javascript (como originalmente se diseñó :P)
Sin querer con el movil he borrado el anterior mensaje... Las lambdas son una paja que se ha inventado el strousup para declarar funciones dentro del alcance de otra funcion porque al ser un puntero a una funcion no es estrictamente una funcion
Lambas son más viejas que C y C++, es más un concepto matemático que se lleva aplicando en otros lenguajes desde hace décadas. Para que veas lo poco novedosas que son, hasta Java las ha implementado en Java 8.
Otra vez borrado al intentar editar el msg... Gracias por citarme, estoy en lo cierto,no?
Un ejemplo de qué pasa cuando te vas con las lambdas a fuego:
int numbers[] = {0, 1, 2, 3}
for (int value: numbers){
if(number % 2 == 0){
std::cout << std::to_string(number);
}
}
se convierte en
Observable.Iterate(numbers)
.filter([](number){ number % 2 == 0 })
.map(std::to_string)
.forEach(std::cout)
Lo unico que no entiendo es... ¿Por que se usan [ ] al crear la lambda ? Es cosa de gramatica o tiene algun sentido que no pillo?
Lo unico que no entiendo es... ¿Por que se usan [ ] al crear la lambda ? Es cosa de gramatica o tiene algun sentido que no pillo?
Tiene un sentido que no pillas. Como esto es C++, si no te lees el manual no te enteras, de hecho yo lo acabo de descubrir. Si pones = o & o el nombre de una variable o campo en esos corchetes la lamba puede acceder a esos valores también, en vez de pasarlos como parámetros. Los "capturas" y no los sueltas hasta que la lamba muere, asi que hay que tener cuidado.
Un ejemplo de qué pasa cuando te vas con las lambdas a fuego:
int[] numbers = {0, 1, 2, 3}
for (int value: numbers){
if(number % 2 == 0){
std::cout << std::to_string(number);
}
}
se convierte en
Observable.Iterate(numbers)
.filter([](number){ number % 2 == 0; })
.map(std::to_string)
.forEach(std::cout)
Te has pasado con lo de string, que yo sepa cout te pinta los ints sin conversion... ;p
Te has pasado con lo de string, que yo sepa cout te pinta los ints sin conversion... ;p
Era por añadir el map al ejemplo porque es una de las funciones más típicas.
-----Actualizado-----
La ventaja de todo esto es que la forma en que te obligan a escribir las cosas, siendo todo métodos que reciben uno o varios valores, y retornan una única respuesta, hace que todo tu programa pueda hacerse multihilo sin mucha ceremonia.
Nada de sincronizar campos, andar con mutexes, tener tu mapa o tus listas preocupado por concurrencia y tal, porque todos tus datos sólo existen dentro de esa captura de la lambda que avanza en la cadena de operaciones.
No es muy distinto de estructurada, la ventaja es el abusar los punteros a función y usar funciones que actuan en otras funciones, y lo metes todo en una cadena de manera descriptiva, lo mismo que cuando usas bash con | y xargs.
Osea que los corchetes son paradecir que pasas datos por referencia en vez de por valor? Mindblowing
-----Actualizado-----
Era por añadir el map al ejemplo porque es una de las funciones más típicas.
-----Actualizado-----
La ventaja de todo esto es que la forma en que te obligan a escribir las cosas, siendo todo métodos que reciben uno o varios valores, y retornan una única respuesta, hace que todo tu programa pueda hacerse multihilo sin mucha ceremonia.
Nada de sincronizar campos, andar con mutexes, tener tu mapa o tus listas preocupado por concurrencia y tal, porque todos tus datos sólo existen dentro de esa captura de la lambda que avanza en la cadena de operaciones.
No es muy distinto de estructurada, la ventaja es el abusar los punteros a función y usar funciones que actuan en otras funciones, y lo metes todo en una cadena de manera descriptiva, lo mismo que cuando usas bash con | y xargs.
Vale, ahora entiendo por que se le han añadido. Pero no dejan de ser una paja.
Osea que los corchetes son paradecir que pasas datos por referencia en vez de por valor? Mindblowing
No, no, imaginate esto.
#include <iostream>
#include <functional>
int value = 5;
int main()
{
std::function<int(int)> func2 = [&value](int i) { return i + value + 4; };
std::cout << "func2: " << func2(6) << '\n';
}
Si no lo pones en el corchete, value no puede ser llamado desde la lambda. Fíjate que el método se sigue llamando con un sólo parámetro. Si pasaras la lambda a otras funciones ese valor seguiría existiendo hasta que la lambda caiga.
-----Actualizado-----
Vale, ahora entiendo por que se le han añadido. Pero no dejan de ser una paja.Es C++, no puedes decir que sea un lenguaje estructurado, POO o funcional puro porque puedes usar el estilo que quieras. El POO lo hace mejor que el estructurado, y el estructurado que el funcional, pero las opciones están ahí. Puedes escribir en C con clases como en 1990 y sigue siendo compatible. O darte al locurón del Template Metaprogramming.
Como me decía mi antiguo jefe, C++ te da suficiente cuerda como para dispararte en el pie xD
Entendido, era mi opcion b.
Ultima cosa antes de que me taches de ignorante:
int [ ] numbers = {0, 1, 2, 3} equivale a int numbers[ ] = {0, 1, 2, 3} ?????
Si, escribo a lo Java porque es lo que uso a diario, asi que no te fies de que mi gramática sea 100% correcta. Quédate con el concepto (www.youtube.com/watch?v=vcfKwK05oS4).
No, no, imaginate esto.
#include <iostream>
#include <functional>
int value = 5;
int main()
{
std::function<int(int)> func2 = [&value](int i) { return i + value + 4; };
std::cout << "func2: " << func2(6) << '\n';
}
Si no lo pones en el corchete, value no puede ser llamado desde la lambda. Fíjate que el método se sigue llamando con un sólo parámetro. Si pasaras la lambda a otras funciones ese valor seguiría existiendo hasta que la lambda caiga.
-----Actualizado-----
Es C++, no puedes decir que sea un lenguaje estructurado, POO o funcional puro porque puedes usar el estilo que quieras. El POO lo hace mejor que el estructurado, y el estructurado que el funcional, pero las opciones están ahí. Puedes escribir en C con clases como en 1990 y sigue siendo compatible. O darte al locurón del Template Metaprogramming.
Como me decía mi antiguo jefe, C++ te da suficiente cuerda como para dispararte en el pie xD
Multiparadigma que le dicen...
-----Actualizado-----
Si, escribo a lo Java porque es lo que uso a diario, asi que no te fies de que mi gramática sea 100% correcta. Quédate con el concepto (www.youtube.com/watch?v=vcfKwK05oS4).
Concepto pillado, gracias Pakoito
^MiSaTo^
23/09/2015, 08:54
Jur! Lambdas en C++!? Pues si se han puesto las pilas xD
Luego le echo un ojo a tu enlace, gracias pakoito. Que yo tb hace muchísimos años que no toco C++
The_Punisher
23/09/2015, 10:13
En el junglegungle que hay ahora se incluye el gamemaker de yoyo por 12$ con el modulo de android incluido (normalmente vale 299$)
ah! y tambien incluye varios juegos indie bastante decentes con codigo fuente
Aiken
Ummmm, mas info sobre ese gamemaker please :D
Ñuño Martínez
23/09/2015, 11:13
Yo entiendo que Programación Orientada a Objetos es también que tengas objetos y clases. Falso: No necesitas clases (Small-Talk, Squeak, JavaScript, Object Pascal...). Las "struct" son descripciones de objetos (y no lo digo yo, que lo dicen Kennet, Ritchie, Tanenbaum, Wirth...). Jaque mate. :cool:
[edito] La "programación orientada a objetos" es una forma de enfrentarse a un problema, no una característica que tenga un lenguaje de programación. Cualquier lenguaje que permita estructurar datos y ocultar datos y código permite usarlo.
^MiSaTo^
23/09/2015, 11:21
Perdón? Javascript no es POO. De hecho tiene Object pero no es ni de coña POO. Jaque mate para ti si los otros ejemplos son lo mismo que JS xD
La POO es un paradigma (https://es.wikipedia.org/wiki/Paradigma_de_programaci%C3%B3n) que viene estrechamente relacionado tb con la definición del lenguaje que usa ese paradigma.
Por favor dime cómo puedes hacer ciertos patrones de diseño de POO en Pascal o C.
platipus
23/09/2015, 12:04
Ummmm, mas info sobre ese gamemaker please :D
Rápidito que solo queda un día.
https://www.humblebundle.com/weekly
IronArthur
23/09/2015, 12:52
Ultimamente javascript ha llevado los lambda & cia a niveles curiosos (ES6), un test para Redux/React/Inmutables:
describe('store', () => {
it('is a Redux store configured with the correct reducer', () => {
const store = makeStore();
expect(store.getState()).to.equal(Map());
store.dispatch({
type: 'SET_ENTRIES',
entries: ['Trainspotting', '28 Days Later']
});
expect(store.getState()).to.equal(fromJS({
entries: ['Trainspotting', '28 Days Later']
}));
});
});
Salu2
Ñuño Martínez
28/09/2015, 12:38
Nos estamos saliendo mucho del tema. Pero mucho mucho.
Perdón? Javascript no es POO. De hecho tiene Object pero no es ni de coña POO. Jaque mate para ti si los otros ejemplos son lo mismo que JS xD
La POO es un paradigma (https://es.wikipedia.org/wiki/Paradigma_de_programaci%C3%B3n) que viene estrechamente relacionado tb con la definición del lenguaje que usa ese paradigma.
Por favor dime cómo puedes hacer ciertos patrones de diseño de POO en Pascal o C.
Puedes hacer POO incluso en ensamblador, de igual forma que puedes programar en espagueti con Java o con Small-Talk (que, por cierto, es uno de los pocos lenguajes que son auténticament OO según tu propio baremo). Y lo de los patrones, ¿ayudan? En ocasiones sí. ¿Son imprescindibles? En absoluto. ¿Pueden aplicarse en Pascal o C? Sin duda*. ¿Y en BASIC? Rotundamente no todos, pero seguro que más de los que pueda parecer*.
De todas formas, podemos tirarnos aquí la vida discutiendo sobre el sexo de los ángeles sin llegar a un consenso. Personalmente considero una soberana estupided cerrarse en que la POO sólo se puede hacer de esta forma y con este lenguaje y nada más, cuando en origen (y vuelvo a repetirlo) es una forma de enfrentarse a un problema presentando una forma de llevar el DIVIDE ET IMPERA un paso más allá de la programación estructurada.
Y volviendo al tema, puedes programar en Android incluso en BASIC.
* Nunca lo he hecho, pero apuesto a que se puede incluso usando las descripciones originales de los tres lenguajes (Wirth, K&R y K&K respectivamente), respectivamente).
Y ojo, me gusta c++, fue el lenguaje con el que aprendi POO por mi cuenta para poder enseñarlo en una academia para alumnos de empresariales/informatica de sistemas (no es coña) de Deusto. La primera vez fue un calvario, pero cuando le pille el tranquillo, me parecio que POO es un paradigma viable, incluso la sobrecarga de operadores (bien hecha) es una MARAVILLA y las herencias, con los polimorfismos y demas, una idea cojonuda para ahorrar codigo y encapsular.
En otro orden de cosas, este verano me he acercado al c# con unity y me ha dado cancer de sida el no poder crear constructores heredando monobehauvior.
La cosa es: si me pongo con c# a secas, me seguira dando asco??? Unity me da asco???
Por ahora, seguire con el gamemaker que aunque parezca para crios y no tenga funciones per se, lo tengo cogido de los huevos...
Según mi (poca) experiencia con Unity, C# y Unity son dos cosas diferentes.
A ver, sí, dispones de todas las herramientas de C# para trabajar, pero eso no significa que sea cómo se trabaja realmente en Unity.
Me pasó hace un par de semanas, tener que implementar una lista de "colliders" (elementos del juego con forma de cubo, que al chocar con nuestro objeto, disparan una llamada a un método llamado OnColliderEnter u OnTriggerEnter, según si son sólidos o no) que estamos tocando, y claro, como heredan de "MonoBehauvior", estos deben estar asignados por fuerza a un GameObject.
Como yo no usaba directamente los colliders, sino una estructura que contenía el collider e información extra que necesitaba, estos no podían estar ligados a un GameObject, porque hubiera sido un desperdicio de recursos innecesario.
Mi solución fue usar clases sin herencia alguna, y trabajar al estilo tradicional (con mi constructor, mi propio Add, Delete, Find, etc). ¿Problema? que el editor no me mostraba los elementos de la lista en tiempo de ejecución, por lo que encima tuve que depurarlo "a la vieja usanza": creando un método que mostrase los elementos de la lista al pulsar un botón.
Ignoro si existe una forma mejor, pero me funciona.
En teoría, en Unity, los scripts son eso, trocitos de código para cosas muy concretas, y para un elemento individual. Es una forma de pensar muy diferente... que me tiene comida la moral, porque yo soy muy de comprobar si existe un elemento antes de acceder a él, y eso, en lo que he leido, sobra, porque un GameObject, si necesita un componente que se lee de un script, lo va a tener porque el programador lo va a poner seguro :loco:
Es C++, no puedes decir que sea un lenguaje estructurado, POO o funcional puro porque puedes usar el estilo que quieras. El POO lo hace mejor que el estructurado, y el estructurado que el funcional, pero las opciones están ahí. Puedes escribir en C con clases como en 1990 y sigue siendo compatible. O darte al locurón del Template Metaprogramming.
Como me decía mi antiguo jefe, C++ te da suficiente cuerda como para dispararte en el pie xD
Os estoy leyendo y estoy flipando en colores. O sea, yo siempre he tenido en mente que C es un lenguaje con muchos años, y que si ha sufrido alguna modificación ha sido en el compilador o porque se ha encontrado un fallo grave con la sintaxis o algo así... y me decís de C++ con versiones "new" o algo así :confused:
Yo me planteaba aprender C++ porque me imaginaba C, con las clases de Java (bueno, con su propia sintaxis, claro), o sea, una estructura de datos, y las funciones que se podían usar exclusivamente para acceder a ella. Ordenadito, simple y sin posibilidad de error. ¿Pero admite el cambio de tipo automático? ¿recolector de basura? Con la de problemas de depuración que da eso, y de rendimiento ya ni te cuento: si eres programador, sabes qué has creado y es cosa tuya recoger las cosas antes de irte a jugar a la calle, porque la memoria es muy cara y... bueno que se me va la olla ^^U
Entiendo que cualquier lenguaje requiere años para dominar parte del mismo (especialmente algo como C, que nadie domina al 100%) y siempre es bueno que te dejen libertad para desarrollar tu estilo, o que te den herramientas para facilitar el trabajo (como Java) pero siempre sabiendo a qué te enfrentas: a un niño malcriado, que quiere que hagas las cosas a su manera, y que es tan tonto como para seguir lo que le dices al pie de la letra, y que a poco que le dejes un poco de cuerda va a hacer lo que le venga en gana.
Como yo no usaba directamente los colliders, sino una estructura que contenía el collider e información extra que necesitaba, estos no podían estar ligados a un GameObject, porque hubiera sido un desperdicio de recursos innecesario.
Si usas Unity deberias ceñirte a la forma de programar que te indican o terminaras escribiendo mas código del necesario, lo mismo con cualquier otra librería o framework.
Ñuño Martínez
30/09/2015, 21:09
(...) yo siempre he tenido en mente que C es un lenguaje con muchos años, y que si ha sufrido alguna modificación ha sido en el compilador o porque se ha encontrado un fallo grave con la sintaxis o algo así... Pues no. La última norma/redefinición de C es la C11, useasé que se publicó en 2011. Ya ves. Eso sí, yo me quedé en la versión ANSI (la de 1989), aunque alguno de los cambios realizados posteriormente los conozco.
Yo me planteaba aprender C++ porque me imaginaba C, con las clases de Java (bueno, con su propia sintaxis, claro), o sea, una estructura de datos, y las funciones que se podían usar exclusivamente para acceder a ella. Ordenadito, simple y sin posibilidad de error. ¿Pero admite el cambio de tipo automático? ¿recolector de basura? Con la de problemas de depuración que da eso, y de rendimiento ya ni te cuento: si eres programador, sabes qué has creado y es cosa tuya recoger las cosas antes de irte a jugar a la calle, porque la memoria es muy cara y... +1.000 a eso último.
Aun así, y salvo que lo hayan metido en el C++11, no tiene ni tipos automáticos ni recolector de basura. Al menos no como lenguaje, aunque puede que lo tenga en la biblioteca.
Os estoy leyendo y estoy flipando en colores. O sea, yo siempre he tenido en mente que C es un lenguaje con muchos años, y que si ha sufrido alguna modificación ha sido en el compilador o porque se ha encontrado un fallo grave con la sintaxis o algo así... y me decís de C++ con versiones "new" o algo así :confused:
Yo me planteaba aprender C++ porque me imaginaba C, con las clases de Java (bueno, con su propia sintaxis, claro), o sea, una estructura de datos, y las funciones que se podían usar exclusivamente para acceder a ella. Ordenadito, simple y sin posibilidad de error. ¿Pero admite el cambio de tipo automático? ¿recolector de basura? Con la de problemas de depuración que da eso, y de rendimiento ya ni te cuento: si eres programador, sabes qué has creado y es cosa tuya recoger las cosas antes de irte a jugar a la calle, porque la memoria es muy cara y... bueno que se me va la olla ^^U
Entiendo que cualquier lenguaje requiere años para dominar parte del mismo (especialmente algo como C, que nadie domina al 100%) y siempre es bueno que te dejen libertad para desarrollar tu estilo, o que te den herramientas para facilitar el trabajo (como Java) pero siempre sabiendo a qué te enfrentas: a un niño malcriado, que quiere que hagas las cosas a su manera, y que es tan tonto como para seguir lo que le dices al pie de la letra, y que a poco que le dejes un poco de cuerda va a hacer lo que le venga en gana.Puedes escribir C++ como si fuera Java o C#, pero no vas a usar las cosas buenas del lenguaje. Además hay bastantes asunciones que en C++ no funcionan: los métodos no son virtuales por defecto, acceder a un método virtual es caro, los generics son un lenguaje en si mismo, la eficiencia de según qué estructuras es distinta, el tiempo de vida de un objeto cambia, crear un nuevo objeto es mucho más caro, destruir o cerrar objetos puede volverse más complejo que dejárselo al recolector de basura.
Luego además de eso están todas las cosas que C++ puede hacer y los otros no, y que GCC/Clang son mucho más que compiladores, pueden hacer cosas con el preprocesador que en Java/C# se hacen con JIT, anotaciones o extensiones.
http://i.imgur.com/pbQFFew.png
Nathrezim
01/10/2015, 09:38
¿recolector de basura? Con la de problemas de depuración que da eso, y de rendimiento ya ni te cuento: si eres programador, sabes qué has creado y es cosa tuya recoger las cosas antes de irte a jugar a la calle, porque la memoria es muy cara
Si tienes una cantidad de tiempo infinito para desarrollar si es buen método de trabajo. El tiempo de máquina es bastante más caro que la memoria.
Si usas Unity deberias ceñirte a la forma de programar que te indican o terminaras escribiendo mas código del necesario, lo mismo con cualquier otra librería o framework.
Ya pero crear GameObjects para referenciar componentes que ya tienen GameObjects asignados, sólo para ahorrarme seis direccionamientos indirectos (que son los que tengo que hacer para consultar dicha información extra) no compensa.
Si hay algo que he aprendido, es que el coste de crear, destruir y mantener procesos/clases/objetos/GameObjects es muy alto, en según qué casos, más que leer un dato de una SD.
Si tienes una cantidad de tiempo infinito para desarrollar si es buen método de trabajo. El tiempo de máquina es bastante más caro que la memoria.
Eso díselo al Firefox de mi equipo de sobremesa :D
No hace falta tener un tiempo infinito de desarrollo para que, por ejemplo, si creas una lista enlazada, le dediques 4 minutos a hacer un buen destructor, en lugar de decir "que lo haga el recolector". Sé que hay casos muy complejos en los que no es posible, pero me consta que si a un programador no lo acostumbras desde el minuto 1 a tener controlado todo lo que crea, en poco tiempo se va a volver un vago: he visto casos de "como al cerrar Fenix se destruye todo, no voy a descargar los gráficos ni a destruir el scroll", o en Java de "no voy a crear el destructor, que el recolector de basura de cuenta de la lista", o incluso "yo siempre uso int, aunque sé que no va a pasar el valor de 32, total, mi PC tiene 2GB de RAM" (en aquel entonces, eso era muchísima RAM).
Ya digo que nos dan cosas que nos facilitan la vida, y el recolector es una de ellas, pero es mejor no depender de ellas. Usa el recolector por si se te olvida llamar al destructor, no para que haga el trabajo por ti.
Por ejemplo: Java me parece genial para crear pequeñas aplicaciones o cosas que no requieran un uso intensivo del PC, pero no me hagas un SO basado en él para juegos, sobre todo si el HW del usuario normal no está a la altura (actualizar el HW NUNCA es una solución).
Luego, cuando esté trabajando, toda esta filosofía de trabajo se va a la m*****, por supuesto :lol:
^MiSaTo^
01/10/2015, 16:17
AY my sweet summer child!
Yo solo diré que el día que pusieron @autoreleasepool y gdc y demás en iOS (vamos lo que viene siendo lo similar al gc) di palmas. Ya estoy yo mayor para gestionar la memoria a mano :P
Nathrezim
01/10/2015, 16:37
Por ejemplo: Java me parece genial para crear pequeñas aplicaciones o cosas que no requieran un uso intensivo del PC
Cosas pequeñitas, como el backbone de un banco. Que la parte gráfica de Java sea algo lenta no quiere decir que el resto del sistema lo sea, en cuestión de machacar números no llega al nivel de rendimiento de C puro, pero tampoco creas que se queda atrás.
El tiempo que esta el recolector de basura ejecutándose en una aplicación es irrisorio, cuando de verdad tienes que preocuparte por la memoria es cuando tienes que tener grandes cachés, porque el tiempo se te va en las transferencias de información (red, DDBB, ficheros...) entonces es donde tienes que llegar al compromiso de tiempo de ejecución / memoria y ver que tal escala el conjunto.
Ya estoy yo mayor para gestionar la memoria a mano :P
No es estar mayor, esque tienes el tiempo controladísimo, a mi me encantaría poder dedicarme a hacer profiling de las aplicaciones y optimizarlas hasta el límite, hay pocas cosas que me gusten más hacer trabajando, pero te pagan la hora para cubrir requerimientos lo mejor y más rápido posible.
^MiSaTo^
01/10/2015, 16:47
Cosas pequeñitas, como el backbone de un banco. Que la parte gráfica de Java sea algo lenta no quiere decir que el resto del sistema lo sea, en cuestión de machacar números no llega al nivel de rendimiento de C puro, pero tampoco creas que se queda atrás.
El tiempo que esta el recolector de basura ejecutándose en una aplicación es irrisorio, cuando de verdad tienes que preocuparte por la memoria es cuando tienes que tener grandes cachés, porque el tiempo se te va en las transferencias de información (red, DDBB, ficheros...) entonces es donde tienes que llegar al compromiso de tiempo de ejecución / memoria y ver que tal escala el conjunto.
No es estar mayor, esque tienes el tiempo controladísimo, a mi me encantaría poder dedicarme a hacer profiling de las aplicaciones y optimizarlas hasta el límite, hay pocas cosas que me gusten más hacer trabajando, pero te pagan la hora para cubrir requerimientos lo mejor y más rápido posible.
Bueno nosotros tenemos normalmente un par de semanas para hacer "consolidation" (no se como llamarlo en Español sin que suene mal xD) y en esa consolidation una de las cosas que hacemos es profiling.
Después de eso la aplicación pasa por otra empresa que la testea de arriba a abajo y otra segunda que le hace pen test.
Aún así, ya he tenido que manejar yo la memoria muchas veces y me es más cómod que me lo haga el sistema si es que lo hace bien (como es el caso de iOS normalmente).
nintiendo1
01/10/2015, 17:08
Por ejemplo: Java me parece genial para crear pequeñas aplicaciones o cosas que no requieran un uso intensivo del PC, pero no me hagas un SO basado en él para juegos, sobre todo si el HW del usuario normal no está a la altura (actualizar el HW NUNCA es una solución).
Pues Android es uno de los mejores sistemas para desarrollar juegos, más que nada porque tienes motores como Unity y Unreal Engine.
De que te sirve tener un SO propio para una consola si no hay motores para usarlos... porque que cada empresa cree su motor no es nada práctico, más que nada si quieres crear un juego 3D decente y no tienes un presupuesto muy grande.
Al final da igual como está hecho el SO, si lo tienen muchos usuarios lo vas a usar porque tienen muchos usuarios que van a comprarte la aplicación. Y los que hacen motores gráficos lo van a portar a esos SO porque le interesa que los desarrolladores usen su motor para hacer sus juegos y ganar dinero.
Saludos.
Pues Android es uno de los mejores sistemas para desarrollar juegos, más que nada porque tienes motores como Unity y Unreal Engine.
De que te sirve tener un SO propio para una consola si no hay motores para usarlos... porque que cada empresa cree su motor no es nada práctico, más que nada si quieres crear un juego 3D decente y no tienes un presupuesto muy grande.
Al final da igual como está hecho el SO, si lo tienen muchos usuarios lo vas a usar porque tienen muchos usuarios que van a comprarte la aplicación. Y los que hacen motores gráficos lo van a portar a esos SO porque le interesa que los desarrolladores usen su motor para hacer sus juegos y ganar dinero.
Saludos.
Android es lo que es, el windows de los moviles. Tiene un mercado brutal, y por eso estan Unity y Unreal para android, pero no por poder desarrollar juegos en Unity, o Unreal (o Gamemaker, o Bennu, o c++ con sdl, o haxeflixel, o construct2..) es mejor "sistema para desarrollar juegos". Como mucho sera un SO para el que valga l pena desarrollar porque tiene una numero de usuarios de millones.
Pero diseñar juegos en android/dalvik a pelo... no
****
Ademas que las storesde android/ios estan PETADISIMAS de apps... ahora los mercados que mas rinden por parque de hardware instalado seran seguramente PSVITA y alguna sobremesa como xbox o play
-----Actualizado-----
Sobre todo en PSVITA, el posicionamiento es mucho mas sencillo que en cualquier otra store, y por lo tanto, auqnue no se gane tanto dinero, es mas facil empezar a ganarlo
En Android no se saca pasta con apps, iOS en conjunto saca beneficios un orden de magnitud mayor. Y aun así el 90% de los beneficios se acumulan en un puñado de apps. Es ridículo. Muy bien si quieres portar tu motor porque corres sobre Linux con OGL, pero pocas ventajas más.
En Android no se saca pasta con apps, iOS en conjunto saca beneficios un orden de magnitud más. Y aun así el 90% de los beneficios se acumulan en un puñado de apps. Es ridículo Muy bien si quieres portar tu motor porque corres sobre Linux con OGL, pero pocas ventajas más.
Justo por eso digo que el mercado mas goloso en PSVITA: tiene un parque de consolas respetable, no demasiados juegos y ademas los usuarios estan ansiosos por novedades. No es como en la store de android donde empiezas el ultimo de una fila de millones, sino mas bien como una fila de centenares
Justo por eso digo que el mercado mas goloso en PSVITA: tiene un parque de consolas respetable, no demasiados juegos y ademas los usuarios estan ansiosos por novedades. No es como en la store de android donde empiezas el ultimo de una fila de millones, sino mas bien como una fila de centenares
A mi no me parece tan buena idea. La VITA se ha dejado para morir ya, no anuncian títulos grandes, y todo lo que anuncian y sale es indie. Aunque tengas algo más de mercado, es más de rebote que real. No puedes tener un exitazo, pero si lo que quieres es sacar para comer alomejor si.
nintiendo1
02/10/2015, 01:30
Pero Vita no tiene ni Unity (Sony lo quito de la store por lo del bug) ni Unreal Engine 4, por lo que ya pierde un importante mercado de videojuegos. Si un desarrollador/empresa pequeña, le sale más rentable usar Unity o Unreal, ya que, entre otras cosas, es fácil portarlo a varias plataformas, no puede portarlo a Vita ya que no tienes ninguno de los 2.
Es algo complejo, por ejemplo OUYA también tiene un parque de consolas respetable y ya no saca nada ni dios.
Saludos.
todavia gamemaker vale
-----Actualizado-----
ademas, segun tengo oido de primera mano (uno de los devs de baboon) el devkit de vita esta bastante guay
nintiendo1
02/10/2015, 13:56
todavia gamemaker vale
-----Actualizado-----
ademas, segun tengo oido de primera mano (uno de los devs de baboon) el devkit de vita esta bastante guay
Pero los desarrolladores siguen sacando pocas cosas.
Quizás el futuro pasa algo como el SteamOS, pero orientado a ARM.
Un fork de una distribución Linux (tipo Debian), open-source (como hacen SteamOS) y que cualquier fabricante pueda instalarlo en su hardware (siempre que tenga drivers, claro, como en SteamOS). Yo creo que este es el único futuro que puede haber si se quiere competir con Android en el espacio de los videojuegos en dispositivos con ARM. Sacar consolas cada una con su SO privado cada vez tiene menos sentido (mira el caso de PS Vita, han dicho que no van a sacar sucesora, o de las últimas consolas open-source como GCW0 o RetroVGS) y sacar consolas con Android tampoco ha tenido mucho éxito (mira el caso de OUYA, NVIDIA Shield, Gamestick, MOJO, JXD, GPD...) ya que Android está más pensada para juegos rápidos y con controles táctiles (aunque cada vez más hay juegos "más hardcore").
Steam nos ha señalado el futuro en x86, y creo que se debería crear algo similar en ARM, de hecho es más necesario en ARM que en x86.
Saludos.
Cosas pequeñitas, como el backbone de un banco. Que la parte gráfica de Java sea algo lenta no quiere decir que el resto del sistema lo sea, en cuestión de machacar números no llega al nivel de rendimiento de C puro, pero tampoco creas que se queda atrás.
El tiempo que esta el recolector de basura ejecutándose en una aplicación es irrisorio, cuando de verdad tienes que preocuparte por la memoria es cuando tienes que tener grandes cachés, porque el tiempo se te va en las transferencias de información (red, DDBB, ficheros...) entonces es donde tienes que llegar al compromiso de tiempo de ejecución / memoria y ver que tal escala el conjunto.
Hombre, cuando yo tardaba 7 minutos en realizar una consulta en el programa que estaba desarrollando, era desesperante. Vale que el 90% de la espera era por culpa del acceso a la BBDD (que era un desastre), pero aun así hay cosas que me dan escalofríos cuando las uso... como las listas, que cada vez que metía un dato pensaba que al meter el byte 512 ya me iba a reservar 1KB y nunca iba a necesitar más de 600 elementos (eso escálalo a MB).
Un programa de gestión, no hace un uso intensivo del PC... hasta donde yo sé: le pides algo, lo busca, y espera la siguiente orden. En un juego está constantemente recalculando en escenario 3D, las físicas de los elementos del entorno, la IA de los enemigos, comprobando qué acciones hace el jugador... hablamos de operaciones que se repiten a cada frame, entre 25 y 60 veces por segundo, desde que se arranca el juego hasta que se sale... ¡Y encima en dispositivos portátiles! ¿por qué necesito un Samsung Galaxy S3 para ejecutar un juego que corre sin problemas en un P3 con una gráfica modesta?
Lo he dicho, me gusta programar en Java porque facilita muchísimo el trabajo, hacer aplicaciones es hasta relajante. Pero para hacer un juego, perferiría tener que leer manuales de C+SDL, e implementar las clases que ya existen en Java.
Y ya tengo la "mala" experiencia de usar una "máquina virtual" en una portátil: Fenix en GP2X y BennuGD en Wiz (los resultados ya los valorais vosotros).
NOTA: "mala" porque me encanta programar en estos lenguajes, pero optimizarlos para que funcionen es otro cantar. Al menos tienes formas sencillas/manuales de controlar lo que pasa. Hay que llegar a cierto compromiso entre facilidad y eficiencia.
Pues Android es uno de los mejores sistemas para desarrollar juegos, más que nada porque tienes motores como Unity y Unreal Engine.
De que te sirve tener un SO propio para una consola si no hay motores para usarlos... porque que cada empresa cree su motor no es nada práctico, más que nada si quieres crear un juego 3D decente y no tienes un presupuesto muy grande.
Al final da igual como está hecho el SO, si lo tienen muchos usuarios lo vas a usar porque tienen muchos usuarios que van a comprarte la aplicación. Y los que hacen motores gráficos lo van a portar a esos SO porque le interesa que los desarrolladores usen su motor para hacer sus juegos y ganar dinero.
Saludos.
No.
Es como decir que una furgoneta es el mejor vehículo para las 24 horas de Le-Mans porque puedes cargar con todo el combustible que necesitas.
Motores hay cientos para PC (Game Maker, SCUMMVM, RPG Maker, Open BoR...) que te permiten hacer grandes juegos en tres patadas, y no hay la saturación que en Android. Y muchos de esos motores están portados a muchas plataformas a través del homebrew.
Además, los que crean un SO propio para consola acaban desarrollando una API o lo que sea... un conjunto de instrucciones que permiten usar el HW de forma rápida y sencilla (creo que el modo7 de GBA no necesitas ni usar ASM para configurar los registros ni hacer los cálculos de pintado en pantalla). Lo que no hay son equipos que se dediquen a adaptar el código a esa plataforma, que debería ser el futuro en la industria del videojuego: estarían los desarrolladores de juegos, los desarrolladores de motores y las empresas que adapten el código de bajo nivel a las plataformas, 3 capas en lugar de las dos actuales.
Yo mismo he usado herramientas de comunicación y sincronización entre CPU y GPU por HW (pilas, señales, mensajes... en pistas y chips de silicio), usando el mismo código C que se utiliza para la comunicación de procesos por SW, gracias a las librerías del fabricante.
Es cierto, Android se ha convertido en algo atractivo por todas las facilidades que te dan... ¿O no? Misato se ha quejado innumerables veces de los problemas de compatibilidad entre terminales, y estoy viendo centenares de quejas por las limitaciones para usar Yomvi, por ejemplo.
Además, en mi caso particular, para poder jugar tengo que comprar un móvil que ahora mismo me cuesta 300€ como mínimo (y no me digais de financiación o portabilidad, porque en un caso lo pagas y en otro es una estafa), y con ese dinero me compro antes una consola que tiene 5 veces más potencia y me cobra los juegos UNA vez (al menos, los que yo compro) o me actualizo el equipo con 7 veces más potencia y puedo hasta crear/usar juegos "aficionados".
nintiendo1
03/10/2015, 17:56
No.
Es como decir que una furgoneta es el mejor vehículo para las 24 horas de Le-Mans porque puedes cargar con todo el combustible que necesitas.
Motores hay cientos para PC (Game Maker, SCUMMVM, RPG Maker, Open BoR...) que te permiten hacer grandes juegos en tres patadas, y no hay la saturación que en Android. Y muchos de esos motores están portados a muchas plataformas a través del homebrew.
Además, los que crean un SO propio para consola acaban desarrollando una API o lo que sea... un conjunto de instrucciones que permiten usar el HW de forma rápida y sencilla (creo que el modo7 de GBA no necesitas ni usar ASM para configurar los registros ni hacer los cálculos de pintado en pantalla). Lo que no hay son equipos que se dediquen a adaptar el código a esa plataforma, que debería ser el futuro en la industria del videojuego: estarían los desarrolladores de juegos, los desarrolladores de motores y las empresas que adapten el código de bajo nivel a las plataformas, 3 capas en lugar de las dos actuales.
Yo mismo he usado herramientas de comunicación y sincronización entre CPU y GPU por HW (pilas, señales, mensajes... en pistas y chips de silicio), usando el mismo código C que se utiliza para la comunicación de procesos por SW, gracias a las librerías del fabricante.
Es cierto, Android se ha convertido en algo atractivo por todas las facilidades que te dan... ¿O no? Misato se ha quejado innumerables veces de los problemas de compatibilidad entre terminales, y estoy viendo centenares de quejas por las limitaciones para usar Yomvi, por ejemplo.
Además, en mi caso particular, para poder jugar tengo que comprar un móvil que ahora mismo me cuesta 300€ como mínimo (y no me digais de financiación o portabilidad, porque en un caso lo pagas y en otro es una estafa), y con ese dinero me compro antes una consola que tiene 5 veces más potencia y me cobra los juegos UNA vez (al menos, los que yo compro) o me actualizo el equipo con 7 veces más potencia y puedo hasta crear/usar juegos "aficionados".
Cuando me refiero a que es uno de los mejores sistemas para juegos me refiero por facilidades para programar (tienes casi todos los motores portados), una store donde es "fácil" publicar y un enorme parque de dispositivos/usuarios donde la gente la compra.
El "problema" de Android es que no está pensado tanto para controles físicos y videojuegos "hardcore", si no para juegos de móviles (aunque esto cada vez va cambiando más), además de chupar muchísimos recursos.
Por eso mi idea para competir con Android en videojuegos es lo que puse antes:
Pero los desarrolladores siguen sacando pocas cosas.
Quizás el futuro pasa algo como el SteamOS, pero orientado a ARM.
Un fork de una distribución Linux (tipo Debian), open-source (como hacen SteamOS) y que cualquier fabricante pueda instalarlo en su hardware (siempre que tenga drivers, claro, como en SteamOS). Yo creo que este es el único futuro que puede haber si se quiere competir con Android en el espacio de los videojuegos en dispositivos con ARM. Sacar consolas cada una con su SO privado cada vez tiene menos sentido (mira el caso de PS Vita, han dicho que no van a sacar sucesora, o de las últimas consolas open-source como GCW0 o RetroVGS) y sacar consolas con Android tampoco ha tenido mucho éxito (mira el caso de OUYA, NVIDIA Shield, Gamestick, MOJO, JXD, GPD...) ya que Android está más pensada para juegos rápidos y con controles táctiles (aunque cada vez más hay juegos "más hardcore").
Steam nos ha señalado el futuro en x86, y creo que se debería crear algo similar en ARM, de hecho es más necesario en ARM que en x86.
Saludos.
Lo que estas diciendo es una gp2x pero actualizada y sobremesa
nintiendo1
04/10/2015, 00:51
Lo que estas diciendo es una gp2x pero actualizada y sobremesa
No. La GP2X tenía un SO cerrado (aunque sea Linux) y solo para la GP2X.
Yo propongo un fork de un SO linux (como Debian), open-source, y que cualquiera pueda añadirle sus drivers y portarlo al hardware que quiera sin tener que recompilar todo. Vamos, lo que es SteamOS pero aplicado a ARM. Y da igual que sea sobremesa o portátil, las 2 son ARM, así que te sirve para sobremesa y portátil.
Saludos.
Vaya, casualidad, en openhandhelds no estan las fuentes del firmware de GP2x, pero si las de wiz y caanoo. Donde dije GP2x digo Wiz ...
POr otra parte, NO puedes portar al hardware que quieras sin recompilar el en el caso del SO. Para poder hacerlo tendriamos que partir de la premisa de que todos los hardwares (procesador, disco, pantalla, inputs...) se comportan de la misma manera, y todos los procesadores tienen el mismo conjunto de operaciones,misma velocidad de clock... Incluso dentro de la familia ARM, hay varios tipos distintos de procesadores (ARM6, ARM9...) por lo que la generalizacion "usemos ARM" no es valida.
Si ya nos ponemos en que tenemos un maquina con un ARM de generacion X a Y MHz, con un minimo de RAM de Z GBytes... Pues estariamos acotando mucho el hardware. En ese caso si seria factible un SO.
Por cierto, la palabra portar incluye el recompilado
nintiendo1
04/10/2015, 02:30
Vaya, casualidad, en openhandhelds no estan las fuentes del firmware de GP2x, pero si las de wiz y caanoo. Donde dije GP2x digo Wiz ...
POr otra parte, NO puedes portar al hardware que quieras sin recompilar el en el caso del SO. Para poder hacerlo tendriamos que partir de la premisa de que todos los hardwares (procesador, disco, pantalla, inputs...) se comportan de la misma manera, y todos los procesadores tienen el mismo conjunto de operaciones,misma velocidad de clock... Incluso dentro de la familia ARM, hay varios tipos distintos de procesadores (ARM6, ARM9...) por lo que la generalizacion "usemos ARM" no es valida.
Si ya nos ponemos en que tenemos un maquina con un ARM de generacion X a Y MHz, con un minimo de RAM de Z GBytes... Pues estariamos acotando mucho el hardware. En ese caso si seria factible un SO.
Por cierto, la palabra portar incluye el recompilado
¿Y como funciona Windows, Linux o lo que sea en x86? Me explico, en x86 hay un montón de procesadores distintos de generaciones distintas, a un montón de Mhz distintos, y no hace falta un Windows distinto ni un Linux distinto para cada procesador que sacan, ni hace falta compilar las aplicaciones para cada PC distinto. Con el cambio de 32 a 64 bits sí ocurrió eso, pero dentro de 32 bits y 64 bits, a pesar de ser procesadores de distintas generaciones, con distintos Mhz y distinta RAM, funciona el mismo SO y los mismo programas sin tener que portarlos ni recompilarlos.
Saludos.
Ya bueno, pero la arquitectura minima necesaria es comun en todos los procesadores x86, comparten instrucciones de procesador... Prodriamos decir que a nivel de hardware el ADN de cualquier configuracion de x86 es la misma en el 99.9% de los casos. De hecho los HDD SATA, aunque sean de fabricantes distintos, comparten el mismo protocolo de comunicacion. Y los IDE tiene otro, y los SCSI otro. Y es el SO quien sabe como son esos protocolo, no los programas.
El SO (Win, Linux, BSD, MacOS...) se encarga de encauzar las peticiones que hacen los programas (carga este fichero en la ram, guarda esta foto en el HDD...) hacia el hardware. Podriamos decir que el SO es un intermediario entre Hardware y programas.
Por lo tanto los programas solo se tienen que encargar de hacer las peticiones al SO, y como el formato de estas peticiones en windows ya esta standarizado... un mismo programa funciona en XP, vista o 10.
Luego sobre los procesadores de 64 bits... hay programas que pueden sacarles provecho al extra que tienen, y el SO tiene que estar preparado para ello. Por eso hay windows 7 de 32 y de 64 bits, para poder aprovechar mejor los nuevos procesadores. Ademas, si a un pc con un SO de 64 le pones la version de 32 bits de un programa, lo mas probable es que funcione sin problemas, porque ese programa no le pedira usar ese extra. Anda que no habre leido eso de "si no esta seguro, descarge la version de 32 bits"
nintiendo1
04/10/2015, 10:18
Ya bueno, pero la arquitectura minima necesaria es comun en todos los procesadores x86, comparten instrucciones de procesador... Prodriamos decir que a nivel de hardware el ADN de cualquier configuracion de x86 es la misma en el 99.9% de los casos. De hecho los HDD SATA, aunque sean de fabricantes distintos, comparten el mismo protocolo de comunicacion. Y los IDE tiene otro, y los SCSI otro. Y es el SO quien sabe como son esos protocolo, no los programas.
El SO (Win, Linux, BSD, MacOS...) se encarga de encauzar las peticiones que hacen los programas (carga este fichero en la ram, guarda esta foto en el HDD...) hacia el hardware. Podriamos decir que el SO es un intermediario entre Hardware y programas.
Por lo tanto los programas solo se tienen que encargar de hacer las peticiones al SO, y como el formato de estas peticiones en windows ya esta standarizado... un mismo programa funciona en XP, vista o 10.
Luego sobre los procesadores de 64 bits... hay programas que pueden sacarles provecho al extra que tienen, y el SO tiene que estar preparado para ello. Por eso hay windows 7 de 32 y de 64 bits, para poder aprovechar mejor los nuevos procesadores. Ademas, si a un pc con un SO de 64 le pones la version de 32 bits de un programa, lo mas probable es que funcione sin problemas, porque ese programa no le pedira usar ese extra. Anda que no habre leido eso de "si no esta seguro, descarge la version de 32 bits"
¿Y en ARM no ocurre lo mismo? Por ejemplo, cojo Debian de ARM, lo instalo en mi dispositivo ARM, y ya tengo Debian de ARM con todas las aplicaciones que ya haya portadas/compiladas en Debian de ARM sin tener que rehacer la rueda en cada dispositivo. Vamos, como ocurre en x86.
Saludos.
¿Y en ARM no ocurre lo mismo? Por ejemplo, cojo Debian de ARM, lo instalo en mi dispositivo ARM, y ya tengo Debian de ARM con todas las aplicaciones que ya haya portadas/compiladas en Debian de ARM sin tener que rehacer la rueda en cada dispositivo. Vamos, como ocurre en x86.
Saludos.
En x86 Intel hace sus propias CPUs, y AMD y VIA (antes Cyrix) llevan decadas haciendo CPUs para ser directamente compatibles con las de Intel.
El mercado ARM funciona diferente, hoy dia ARM Holdings solo diseña las CPU pero no las fabrica, vende licencias a terceros de las especificaciones de sus modelos de CPU, y cada fabricante partiendo de esa base diseña y fabrica sus propias CPUs: Apple, Samsung, Qualcomm, Mediatek, Broadcom,... son ARM porque se basan en esa arquitectura pero no siempre son directamente compatibles.
nintiendo1
04/10/2015, 16:58
En x86 Intel hace sus propias CPUs, y AMD y VIA (antes Cyrix) llevan decadas haciendo CPUs para ser directamente compatibles con las de Intel.
El mercado ARM funciona diferente, hoy dia ARM Holdings solo diseña las CPU pero no las fabrica, vende licencias a terceros de las especificaciones de sus modelos de CPU, y cada fabricante partiendo de esa base diseña y fabrica sus propias CPUs: Apple, Samsung, Qualcomm, Mediatek, Broadcom,... son ARM porque se basan en esa arquitectura pero no siempre son directamente compatibles.
He encontrado la siguiente información en la página de Debian para ARM:
2.1.2. Three different ARM ports
The ARM architecture has evolved over time and modern ARM processors provide features which are not available in older models. Debian therefore provides three ARM ports to give the best support for a very wide range of different machines:
Debian/armel targets older 32-bit ARM processors without support for a hardware floating point unit (FPU),
Debian/armhf works only on newer 32-bit ARM processors which implement at least the ARMv7 architecture with version 3 of the ARM vector floating point specification (VFPv3). It makes use of the extended features and performance enhancements available on these models.
Debian/arm64 works on 64-bit ARM processors which implement at least the ARMv8 architecture.
Muchas CPUs ARM también pueden funcionar en cualquier modo endian «little-endian» o «big-endian»). Sin embargo, la mayoría de las implementaciones de sistemas actuales usan el modo «little-endian». Debian sólo permite actualmente sistemas ARM «little-endian».
2.1.3. Variations in ARM CPU designs and support complexity
ARM systems are much more heterogeneous than those based on the i386/amd64-based PC architecture, so the support situation can be much more complicated.
The ARM architecture is used mainly in so-called “system-on-chip” (SoC) designs. These SoCs are designed by many different companies with vastly varying hardware components even for the very basic functionality required to bring the system up. System firmware interfaces have been increasingly standardised over time, but especially on older hardware firmware/boot interfaces vary a great deal, so on these systems the Linux kernel has to take care of many system-specific low-level issues which would be handled by the mainboard's BIOS in the PC world.
At the beginning of the ARM support in the Linux kernel, the hardware variety resulted in the requirement of having a separate kernel for each ARM system in contrast to the “one-fits-all” kernel for PC systems. As this approach does not scale to a large number of different systems, work was done to allow booting with a single ARM kernel that can run on different ARM systems. Support for newer ARM systems is now implemented in a way that allows the use of such a multiplatform kernel, but for several older systems a separate specific kernel is still required. Because of this, the standard Debian distribution only supports installation on a selected number of such older ARM systems, alongside the newer systems which are supported by the ARM multiplatform kernels (called “armmp”) in Debian/armhf.
Vamos, según entiendo yo de lo que he leido, eso ocurría con los modelos antiguos de ARM, pero ya con los nuevos no ocurre. Ya solo hay 32 bits y 64 bits como ocurre en x86.
Por tanto, ¿sería factible la idea que propongo?
Saludos.
Pero es que básicamente estás proponiendo Android, ¿no?
nintiendo1
04/10/2015, 17:24
Pero es que básicamente estás proponiendo Android, ¿no?
Pero de lo que os quejáis de Android es de las capas de Java, en este caso no hay esas capas, ¿no? Por lo que el rendimiento de los juegos/apps sería mayor que en Android.
Claro, sería similar a Android, pero sin las capas de Java que lastran el rendimiento, y orientado a usarse con controles y no con una pantalla táctil.
Saludos.
^MiSaTo^
04/10/2015, 19:12
Pero de lo que os quejáis de Android es de las capas de Java, en este caso no hay esas capas, ¿no? Por lo que el rendimiento de los juegos/apps sería mayor que en Android.
Claro, sería similar a Android, pero sin las capas de Java que lastran el rendimiento, y orientado a usarse con controles y no con una pantalla táctil.
Saludos.
Entonces lo que propones es Android con ART en vez de Dalvik? xD
Simplemente con usar C++ ya te estás saltando toda la capa de Java y Android porque corren contra el linux que mueve dalvik/art. Es lo que hacen casi todos los motores de juego, usar Android para conseguir una ventana/actividad/surface opengl y tirar a partir de ahí.
nintiendo1
04/10/2015, 19:42
Entonces lo que propones es Android con ART en vez de Dalvik? xD
Simplemente con usar C++ ya te estás saltando toda la capa de Java y Android porque corren contra el linux que mueve dalvik/art. Es lo que hacen casi todos los motores de juego, usar Android para conseguir una ventana/actividad/surface opengl y tirar a partir de ahí.
¿Entonces por qué os quejáis de Android?
Saludos.
¿Entonces por qué os quejáis de Android?
Saludos.
Porque no se saca pasta en el mercado.
nintiendo1
04/10/2015, 19:58
Porque no se saca pasta en el mercado.
Quiero decir que porque os quejáis de la pérdida de rendimiento al usar Android. Por ejemplo, en Linux en un x86 no os veo quejaros de eso.
Saludos.
Búscame un mensaje donde digamos eso. Los que se quejan son los que no lo usan. Hay una pérdida de rendimiento de C++ a Java, pero no es tan abismal como para descartar hacer juegos en él. Hay ya varios en Steam o la Play Store, y van igual o mejor que los de gamemaker, UE4, o Unity. Mientras se hagan las cosas bien, y los requisitos sean adecuados, llevamos bastantes años que la potencia suple ese variación en rendimiento, que alomejor son los años desde que la gente que se queja probaron a usar Java.
Si quieres Call of Duty 22 a 60fps 4k necesitas C++ y varios magos de OpenGL. Si quieres un juego hecho en casa tu sólo o entre varios, o un estudio pequeño, se podrían hacer en Java con libgdx (https://libgdx.badlogicgames.com/gallery.html) sin problema de rendimiento.
-----Actualizado-----
Si no hablamos de juegos, sino la interfaz, da igual si el programador percibe que va un 10% más lento que una escrita en QT. Hay billones de usuarios Android que no tienen mayor problema en usarlo en móvil, tableta o escritorio. De la misma manera que esas app de twitter son mucho mejores que la oficial y siguen teniendo una fracción de los usuarios.
Y yo sigo manteniendo que a pesar de todo lo que lo odie, sigue teniendo más éxito como sistema de ventanas que UbuntUnity, Gnome, o GTK.
^MiSaTo^
04/10/2015, 20:45
Búscame un mensaje donde digamos eso. Los que se quejan son los que no lo usan. Hay una pérdida de rendimiento de C++ a Java, pero no es tan abismal como para descartar hacer juegos en él. Hay ya varios en Steam o la Play Store, y van igual o mejor que los de gamemaker, UE4, o Unity. Mientras se hagan las cosas bien, y los requisitos sean adecuados, llevamos bastantes años que la potencia suple ese variación en rendimiento, que alomejor son los años desde que la gente que se queja probaron a usar Java.
Si quieres Call of Duty 22 a 60fps 4k necesitas C++ y varios magos de OpenGL. Si quieres un juego hecho en casa tu sólo o entre varios, o un estudio pequeño, se podrían hacer en Java con libgdx (https://libgdx.badlogicgames.com/gallery.html) sin problema de rendimiento.
-----Actualizado-----
Si no hablamos de juegos, sino la interfaz, da igual si el programador percibe que va un 10% más lento que una escrita en QT. Hay billones de usuarios Android que no tienen mayor problema en usarlo en móvil, tableta o escritorio. De la misma manera que esas app de twitter son mucho mejores que la oficial y siguen teniendo una fracción de los usuarios.
Y yo sigo manteniendo que a pesar de todo lo que lo odie, sigue teniendo más éxito como sistema de ventanas que UbuntUnity, Gnome, o GTK.
Hombre el éxito de Android es innegable y Google lo ha hecho muy bien para ser "el windows de los móviles" en el sentido de meter Android en todo. Les ha salido la jugada redonda y eso no se puede negar.
Ahora bien, yo lo siento pero no xD Lo mismo que no uso windows en mis ordenadores, no uso cosas con android. Pero eso ya es tema de gusto personal de cada uno.
Por otro lado en lo referente a juegos(esto va para nintiendo1) el problema ni es android ni es iOS ni es el SO en sí. El "problema" es que un movil es lo que es, los controles son los que son y los juegos no están pensados de la misma manera que un juego de una consola u ordenador. También el target de esos juegos es muy distinto. Lo mismo a mi madre (no es el caso, pero para un ejemplo) le encanta el Candy Crush pero yo sinceramente paso olímpicamente de jugar en el movil. Mi madre pasa de jugar en una consola/ordenador. Son dos mercados distintos y el de los móviles no es al que yo pertenezco (ni la mayoría de usuarios de este foro).
Hombre el éxito de Android es innegable y Google lo ha hecho muy bien para ser "el windows de los móviles" en el sentido de meter Android en todo. Les ha salido la jugada redonda y eso no se puede negar.
Ahora bien, yo lo siento pero no xD Lo mismo que no uso windows en mis ordenadores, no uso cosas con android. Pero eso ya es tema de gusto personal de cada uno.
Hablaba de mayorías. La mayoría de los desarrolladores de aquí también tiene un nexus y un mac, y yo tengo un xiaomi y un acer ¯\_(ツ)_/¯
Por otro lado en lo referente a juegos(esto va para @nintiendo1) el problema ni es android ni es iOS ni es el SO en sí. El "problema" es que un movil es lo que es, los controles son los que son y los juegos no están pensados de la misma manera que un juego de una consola u ordenador. También el target de esos juegos es muy distinto. Lo mismo a mi madre (no es el caso, pero para un ejemplo) le encanta el Candy Crush pero yo sinceramente paso olímpicamente de jugar en el movil. Mi madre pasa de jugar en una consola/ordenador. Son dos mercados distintos y el de los móviles no es al que yo pertenezco (ni la mayoría de usuarios de este foro).Para eso tienes los drivers para pads. Linux tampoco está pensado para ser controlado con un pad, y ahí tienes Big Picture de Valve. Todo es buscar el mercado o la solución. El mercado de juegos para móviles no tiene nada que ofrecerte a ti o a mi comparado con lo que hay en consola y pc, pero eso no significa que no se puedan hacer o portar, tipo el último Xcom o los Baldur's Gate.
nintiendo1
04/10/2015, 20:51
Hombre el éxito de Android es innegable y Google lo ha hecho muy bien para ser "el windows de los móviles" en el sentido de meter Android en todo. Les ha salido la jugada redonda y eso no se puede negar.
Ahora bien, yo lo siento pero no xD Lo mismo que no uso windows en mis ordenadores, no uso cosas con android. Pero eso ya es tema de gusto personal de cada uno.
Por otro lado en lo referente a juegos(esto va para nintiendo1) el problema ni es android ni es iOS ni es el SO en sí. El "problema" es que un movil es lo que es, los controles son los que son y los juegos no están pensados de la misma manera que un juego de una consola u ordenador. También el target de esos juegos es muy distinto. Lo mismo a mi madre (no es el caso, pero para un ejemplo) le encanta el Candy Crush pero yo sinceramente paso olímpicamente de jugar en el movil. Mi madre pasa de jugar en una consola/ordenador. Son dos mercados distintos y el de los móviles no es al que yo pertenezco (ni la mayoría de usuarios de este foro).
Vale, puedo coincidir contigo, pero, ¿y el fracaso de OUYA? En teoría estaba para usarla con un mando como una consola. Y seguían saliendo la misma "mierda" de juegos.
Por otro lado, vuelve a tener sentido crear un fork de una distribución Linux para ARM solo para videojuegos "hardcore" (vamos, que se puedan usar con un mando).
Saludos.
Vale, puedo coincidir contigo, pero, ¿y el fracaso de OUYA? En teoría estaba para usarla con un mando como una consola. Y seguían saliendo la misma "mierda" de juegos.
Por otro lado, vuelve a tener sentido crear un fork de una distribución Linux para ARM solo para videojuegos "hardcore" (vamos, que se puedan usar con un mando).
Saludos.
No había mercado. Cien o doscientas mil unidades no es una cantidad que pueda considerarse interesante. Tampoco se dijo en ningún momento que fuera a haber soporte de estudios importantes.
Más que OUYA, lo más parecido a un éxito ha sido la Nvidia Shield y sólo por tener a Nvidia detrás empujando para que los juegos de pc fueran jugables por streaming.
Por otro lado, vuelve a tener sentido crear un fork de una distribución Linux para ARM solo para videojuegos "hardcore" (vamos, que se puedan usar con un mando).
Los juegos para Linux siguen siendo un mercado muy pequeño, no tienes más que verlos stats de steam y gogcom. Hay mucho por escalar.
nintiendo1
04/10/2015, 21:06
No había mercado. Cien o doscientas mil unidades no es una cantidad que pueda considerarse interesante. Tampoco se dijo en ningún momento que fuera a haber soporte de estudios importantes.
Más que OUYA, lo más parecido a un éxito ha sido la Nvidia Shield y sólo por tener a Nvidia detrás empujando para que los juegos de pc fueran jugables por streaming.
Los juegos para Linux siguen siendo un mercado muy pequeño, no tienes más que verlos stats de steam y gogcom. Hay mucho por escalar.
Pero al usuario le da igual que sea Linux o el SO de Pepe. En x86 está Windows, que tiene casi toda la cuota de mercado de x86 en jugadores, pero en ARM, ¿quien tiene esa cuota de mercado de jugadores? Actualmente Android, y casi ni eso porque los usuarios hardcore pasan un poco bastante de Android.
Como ahora la cuota de jugadores de ARM no la tiene nadie, por eso sería interesante una distro Linux.
Saludos.
A los usuarios les da igual pero si los juegos no corren en linux de por si, pocos vas a mover. Muy pocos de ls antiguos y muy pocos de los nuevos. Un par de miles a lo sumo, y solo un puñado de los muy conocidos.
nintiendo1
04/10/2015, 21:26
A los usuarios les da igual pero si los juegos no corren en linux de por si, pocos vas a mover. Muy pocos de ls antiguos y muy pocos de los nuevos. Un par de miles a lo sumo, y solo un puñado de los muy conocidos.
Creo que no no estamos entendiendo...
En ARM no hay juegos en casi ninguna plataforma, excepto las cerradas tipo Sony o Nintendo, o el caso de Android, pero que apenas tiene juegos decentes.
A lo que me refiero es a crear esa plataforma para que los desarrolladores que quieran desarrollar en ARM lo hagan ahí y se consolide como la plataforma de juegos en ARM.
No sé si me he explicado bien.
Saludos.
Para salvar esas distancias existen los motores. Tu no te preocupas de dónde corre, sólo de hacer el juego contra las especificaciones del motor. No necesitas windows o linux, necesitas un Unity o UE4. Ahora mismo es relativamente simple hacer un juego en Unity y que corra en ARM, MIPS, ARM_64, x86 o lo que quieras, sin muchos bugs. Es lo que casi toda la industria menos las grandes empresas están haciendo.
El problema siguen siendo las ventas.
^MiSaTo^
04/10/2015, 21:50
Hablaba de mayorías. La mayoría de los desarrolladores de aquí también tiene un nexus y un mac, y yo tengo un xiaomi y un acer ¯\_(ツ)_/¯
Para eso tienes los drivers para pads. Linux tampoco está pensado para ser controlado con un pad, y ahí tienes Big Picture de Valve. Todo es buscar el mercado o la solución. El mercado de juegos para móviles no tiene nada que ofrecerte a ti o a mi comparado con lo que hay en consola y pc, pero eso no significa que no se puedan hacer o portar, tipo el último Xcom o los Baldur's Gate.
Vale, puedo coincidir contigo, pero, ¿y el fracaso de OUYA? En teoría estaba para usarla con un mando como una consola. Y seguían saliendo la misma "mierda" de juegos.
Por otro lado, vuelve a tener sentido crear un fork de una distribución Linux para ARM solo para videojuegos "hardcore" (vamos, que se puedan usar con un mando).
Saludos.
No es cuestión de que se pueda poner un mando o no. Es cuestión de lo que he dicho, que el target de ese mercado no somos nosotros. Es otro mercado que funciona de otra manera distinta independientemente que se pueda manejar con un mando tb.
No es cuestión de que se pueda poner un mando o no. Es cuestión de lo que he dicho, que el target de ese mercado no somos nosotros. Es otro mercado que funciona de otra manera distinta independientemente que se pueda manejar con un mando tb.
Nintiendo1 quiere a los core, tu dices los casual, supongo que ahí es donde no nos ponemos de acuerdo.
^MiSaTo^
04/10/2015, 21:57
Nintiendo1 quiere a los core, tu dices los casual, supongo que ahí es donde no nos ponemos de acuerdo.
Yo contestaba a por qué no se quiere jugar en Android.
Él habla de hacer una plataforma en ARM. En realidad la plataforma da igual siempre que consigas meter a las empresas grandes en ella y hacerla popular.
De momento los únicos que saben hacer eso son Valve con Steam y las consolas con sus exclusividades (que ya no son tantas como antiguamente).
nintiendo1
04/10/2015, 22:00
El problema siguen siendo las ventas.
Pero, ¿donde fallan las ventas?
Supongo que tu me dirás que hay mucha saturación de cosas. Vale, para un indie lo entiendo, pero para una empresa importante ni de lejos eso es un problema.
Por ejemplo, imagina que lanzan un Call of Duty potente, o un Project Cars decente, eso independientemente de la saturación sería lo suficientemente llamativo como para vender.
Pero no lo sacan porque supongo que saben que no va a vender.
¿Entonces es la pirateria el problema?
Yo contestaba a por qué no se quiere jugar en Android.
Él habla de hacer una plataforma en ARM. En realidad la plataforma da igual siempre que consigas meter a las empresas grandes en ella y hacerla popular.
De momento los únicos que saben hacer eso son Valve con Steam y las consolas con sus exclusividades (que ya no son tantas como antiguamente).
Pero, ¿donde fallan las ventas?
Supongo que tu me dirás que hay mucha saturación de cosas. Vale, para un indie lo entiendo, pero para una empresa importante ni de lejos eso es un problema.
Por ejemplo, imagina que lanzan un Call of Duty potente, o un Project Cars decente, eso independientemente de la saturación sería lo suficientemente llamativo como para vender.
Pero no lo sacan porque supongo que saben que no va a vender.
¿Entonces es la pirateria el problema?Lo que dice Misato. Los que ya venden, venden bien. Los que no se venden bien necesitan un golpe de suerte para salir adelante, independientemente de la plataforma. Puede que te salga el siguiente Candy Crush como que te estampes con tu primer juego.
En las partes altas hacer un AAA con el gameplay de un juego de SNES o PSX parece tarea imposible estos días, por el tiempo y gente que necesitas, y pensar que alomejor no le gusta a todo el mundo y novende bien. Por la parte media (Larian, Paradox, Double Fine) las cosas no han cambiado mucho, alomejor ahora tienen más posibilidades de trabajar sin un publisher grande pero poco más. Por la parte de abajo hay mucha saturación.
Y ninguno de los 3 se la puede jugar a todo o nada en una plataforma nueva. Los experimentos que ha habido hasta ahora han sido mediocres. El próximo es Oculus, GearVR (Android!), o Valve Vive, que ya veremos cómo se da.
-----Actualizado-----
https://www.reddit.com/r/Games/comments/3nhckb/psp_emulator_ppsspp_v11_has_been_released/
Support for ARM64 on Android, for improved performance on new devices. Has some new optimizations.
Support Android TV, like nVidia Shield TV
nintiendo1
05/10/2015, 00:28
Lo que dice Misato. Los que ya venden, venden bien. Los que no se venden bien necesitan un golpe de suerte para salir adelante, independientemente de la plataforma. Puede que te salga el siguiente Candy Crush como que te estampes con tu primer juego.
En las partes altas hacer un AAA con el gameplay de un juego de SNES o PSX parece tarea imposible estos días, por el tiempo y gente que necesitas, y pensar que alomejor no le gusta a todo el mundo y novende bien. Por la parte media (Larian, Paradox, Double Fine) las cosas no han cambiado mucho, alomejor ahora tienen más posibilidades de trabajar sin un publisher grande pero poco más. Por la parte de abajo hay mucha saturación.
Y ninguno de los 3 se la puede jugar a todo o nada en una plataforma nueva. Los experimentos que ha habido hasta ahora han sido mediocres. El próximo es Oculus, GearVR (Android!), o Valve Vive, que ya veremos cómo se da.
-----Actualizado-----
https://www.reddit.com/r/Games/comments/3nhckb/psp_emulator_ppsspp_v11_has_been_released/
¿Entonces lo que faltaría es un cliente tipo Steam para las plataformas ARM? Porque ahora mismo la Play Store es un descontrol, y con un cliente tipo Steam se podría controlar que se sube, solo aceptar cosas que utilicen un gamepad, poner logros, chat, perfiles, amigos, etc.
Saludos.
Ñuño Martínez
05/10/2015, 20:19
Joé, me despisto un rato y empezáis a escribir ahí, tl;nr y tal...
Yo me he quedado en la parte esa de Misato diciendo que es muy mayor ya para gestionar la memoria, e iba a decir que tampoco era para tanto, que basta con hacer un destructor por cada constructor y es casi automático cuando te acostumbras, y no tardas casi nada si copias el código del constructor y con mínima maña cambias los new por delete; claro que luego he caído que vosotros usáis la cosa esa del C++ y su curiosa sintaxis de constructor y claro, que no es lo mismo que con Object Pascal, que puedes hacerte un script que te convierta el constructor en destructor con la liberación de memoria y todo...
Peeero, luego he visto que me quedan tres páginas o más que leer y me digo, "paso, que no me estoy aburriendo tanto, y encima van a estar con eso de que Pascal no lo usa ni Bob Esponja, y que obsoleto y que C++ y que C# y que patrones y que qué tonto yo por usar un lenguaje sin ambigüedades con lo chulo que es que el compilador no avise cuando confundo una comparación con una asignación, que es la sal de la vida, y que tal", así que os ahorro el trabajo.
De buen rollito, eso sí, que no me cabreo. Si en realidad me gusta chincharos.
^MiSaTo^
05/10/2015, 21:16
Joé, me despisto un rato y empezáis a escribir ahí, tl;nr y tal...
Yo me he quedado en la parte esa de Misato diciendo que es muy mayor ya para gestionar la memoria, e iba a decir que tampoco era para tanto, que basta con hacer un destructor por cada constructor y es casi automático cuando te acostumbras, y no tardas casi nada si copias el código del constructor y con mínima maña cambias los new por delete; claro que luego he caído que vosotros usáis la cosa esa del C++ y su curiosa sintaxis de constructor y claro, que no es lo mismo que con Object Pascal, que puedes hacerte un script que te convierta el constructor en destructor con la liberación de memoria y todo...
Peeero, luego he visto que me quedan tres páginas o más que leer y me digo, "paso, que no me estoy aburriendo tanto, y encima van a estar con eso de que Pascal no lo usa ni Bob Esponja, y que obsoleto y que C++ y que C# y que patrones y que qué tonto yo por usar un lenguaje sin ambigüedades con lo chulo que es que el compilador no avise cuando confundo una comparación con una asignación, que es la sal de la vida, y que tal", así que os ahorro el trabajo.
De buen rollito, eso sí, que no me cabreo. Si en realidad me gusta chincharos.
¿En qué trabajas para usar Object Pascal?
Carlos24
05/10/2015, 22:47
El problema del desarrollo en soc de bajo consumo la única que sigue los estandares y saca unos drivers con buen apoyo es NVIDIA que eso siga pasando en el 2015 es para tirar un tirón en las orejas de la fragmentación de los socs mobiles.
Ver las herramientas de depuración que ofrece NVIDIA y sigue los estandares ayuda mucho al desarrollador hacen falta más fabricantes como NVIDIA en el sector móvil.
Y no las ventas muchas veces no es la culpable de hacer un port o adaptación de un juego es tener que crear 10 perfiles y configuraciones diferentes perder el tiempo y gastar mucho dinero porque no todas las GPU o fabricantes están en el mismo nivel de apoyo Opengl es 2.x/3.x
^MiSaTo^
05/10/2015, 23:29
El problema del desarrollo en soc de bajo consumo la única que sigue los estandares y saca unos drivers con buen apoyo es NVIDIA que eso siga pasando en el 2015 es para tirar un tirón en las orejas de la fragmentación de los socs mobiles.
Ver las herramientas de depuración que ofrece NVIDIA y sigue los estandares ayuda mucho al desarrollador hacen falta más fabricantes como NVIDIA en el sector móvil.
Y no las ventas muchas veces no es la culpable de hacer un port o adaptación de un juego es tener que crear 10 perfiles y configuraciones diferentes perder el tiempo y gastar mucho dinero porque no todas las GPU o fabricantes están en el mismo nivel de apoyo Opengl es 2.x/3.x
Si justo ese es el problema xD
Carlos24
06/10/2015, 00:37
Pues sí hasta sucede en PC bajo Opengl no tan sangrante pero sí como para ver que hay fragmentación por el Vendor ID no están a la altura este juego solo funciona en NVIDIA requeriendo unos drivers modernos 352.21 o superiores si no quieres tener problemas , con GPU AMD o Intel no funciona correctamente o puede no ejecutarse.
https://www.gamingonlinux.com/articles/looks-like-shadow-of-mordor-wont-support-amd-graphics-on-linux-at-release.5513
Mordor FAQ for Linux
Which graphics cards and driver versions are supported by Middle-earth: Shadow of Mordor?
Graphics cards
Middle-earth: Shadow of Mordor requires the following graphics card series or better:
Nvidia: 6xx series
AMD and Intel: AMD and Intel graphics cards are not currently supported by Middle-earth: Shadow of Mordor.
Graphics drivers
Every effort has been made to support the graphics drivers packaged with Ubuntu, as well as open-source drivers. However, as the game contains a number of advanced graphics options, some driver versions are not compatible with it.
The driver versions below have been tested, and these and newer versions will run the game without issues:
Nvidia: 346.35
You may be able to play using older drivers. However, it is possible that you will encounter performance and stability issues, and we do not currently offer support for older driver versions.
Open-source drivers
Open-source graphics drivers are not currently supported by Middle-earth: Shadow of Mordor. Unfortunately, the current open-source Nvidia drivers do not support a number of the graphical features used in the game.
En PC no hay tanto problema porque tu lo vas actualizando y llega algún punto que Intel o AMD llegan a soportar (Con retraso) las extensiones requeridas por el engine .
Pero en un móvil muchos fabricantes móviles no actualizan el último Blob o binario disponible que arreglan fixes o implementaciones extensiones GL_ARB soportadas por el Soc .
En movil muchos fabricantes construyen el cacharro, te lo venden y ahí te quedas, si no te va bien comparte un modelo superior.
Carlos24
06/10/2015, 01:10
En movil muchos fabricantes construyen el cacharro, te lo venden y ahí te quedas, si no te va bien comparte un modelo superior.
A eso me refiero En muchos móviles con mismo hardware en unos tienen problemas y en otros no.. y la mayoría de las veces reside en bug en la versión del driver gráfico que lleva esa rom.....
Otros desarrolladoras se curan en salud activando diferente el juego según la identificación del CPU/GPU según lo que devuelva se descarga unos archivos o otros.
Ñuño Martínez
07/10/2015, 21:11
¿En qué trabajas para usar Object Pascal?
Por ahora, aplicaciones a medida (bases de datos, principalmente), pero vamos a meternos en el tema videojueguil y llevo meses dándole caña al primer mierdijuego promocional.
Por ahora, aplicaciones a medida (bases de datos, principalmente), pero vamos a meternos en el tema videojueguil y llevo meses dándole caña al primer mierdijuego promocional.
¿Qué librerías o tecnologías tenéis pensado usar para videojuegos?
Ñuño Martínez
08/10/2015, 11:23
Depende. Para PC/Mac estoy con Allegro (http://allegro-pas.sf.net/) y un motor (2D) propio que desarrollo a la vez, aunque para un par de juegos 3D hay idea de usar el motor Throne (https://www.youtube.com/watch?v=O1GjnzAGvgk), o el Castle (https://www.youtube.com/channel/UCq9jJ5ivIXC5VEWiUAfxBxw/videos) si por alguna razón no se puede negociar. Para Android e iOS no vamos a sacar muchas cosas*, pero alguna vamos a hacer usando Smart Mobile Studio (http://smartmobilestudio.com/), salvo que para entonces ya sepa cómo generar ejecutables JVM con Free Pascal y pueda enlazarlos con Allegro 5 (si no entendí mal, Allegro 5.1 ya tiene algo de soporte para Android y el 5.2 debería tener soporte completo).
_____________________________________
* Ya, ya, es donde está el dinero, pero los juegos que haremos son más promocionales que otra cosa porque nuestro fuerte es el cómic y el diseño.
Ñuño Martínez
08/10/2015, 12:04
Encantado. ^_^)
No. La GP2X tenía un SO cerrado (aunque sea Linux) y solo para la GP2X.
Yo propongo un fork de un SO linux (como Debian), open-source, y que cualquiera pueda añadirle sus drivers y portarlo al hardware que quiera sin tener que recompilar todo. Vamos, lo que es SteamOS pero aplicado a ARM. Y da igual que sea sobremesa o portátil, las 2 son ARM, así que te sirve para sobremesa y portátil.
Saludos.
Leo esto y se me viene a la cabeza FirefoxOS.
Es lo que prometían: un SO abierto sobre Linux. De momento está teniendo éxito cero, pero mi ZTE Open tiene algo más de rendimiento que equipos similares con Android. Y digo "algo" porque no puedo probarlo con aplicaciones "tochas", porque el SO está tan verde (y este movil tiene una versión desarrollada exclusivamente para muvistar, o sea, que va con un año de retraso) que se me cuelga cualquier cosa más potente que el "2048".
Búscame un mensaje donde digamos eso. Los que se quejan son los que no lo usan. Hay una pérdida de rendimiento de C++ a Java, pero no es tan abismal como para descartar hacer juegos en él. Hay ya varios en Steam o la Play Store, y van igual o mejor que los de gamemaker, UE4, o Unity. Mientras se hagan las cosas bien, y los requisitos sean adecuados, llevamos bastantes años que la potencia suple ese variación en rendimiento, que alomejor son los años desde que la gente que se queja probaron a usar Java.
Si quieres Call of Duty 22 a 60fps 4k necesitas C++ y varios magos de OpenGL. Si quieres un juego hecho en casa tu sólo o entre varios, o un estudio pequeño, se podrían hacer en Java con libgdx (https://libgdx.badlogicgames.com/gallery.html) sin problema de rendimiento.
A ver, el problema viene porque cuando se creó Android se dijo que sería un SO que aunaría todo el HW del mercado para que los programadores sólo se preocupasen de desarrollar sus aplicaciones sin acceder a bajo nivel (básicamente porque traía su API estandar para todo el mundo, y se compilaba el SO para cada móvil con sus propios drivers y demás).
Pero luego se vio el bajo rendimiento y se empezó a bajar al kernel, a tirar de C++ y a usar librerías específicas de cada GPU, y ahora tenemos este lio de que cada móvil es un mundo.
Así que los que hacen las cosas "como se deben hacer" (Android a saco) tienen programas/juegos con rendimientos pobres. Mientras que los que se aventuran a mejorar el rendimiento, consiguen buenos resultados... para los tres o cuatro móviles más vendidos (en casa sólo nos funciona Yomvi en la 360 y en los PCs, en ninguno de los 2 smartphones o de las 3 tablets que tenemos va).
Y lo mismo es sólo una apreciación mía y estoy equivocado, pero es lo que veo y suelo leer.
A los usuarios les da igual pero si los juegos no corren en linux de por si, pocos vas a mover. Muy pocos de ls antiguos y muy pocos de los nuevos. Un par de miles a lo sumo, y solo un puñado de los muy conocidos.
Pero eso es porque Linux hay tropecientas versiones, cada uno con sus propias librerías, y hacer juegos para ese SO era una odisea (que había, y hay, que recompilar). Eso ya le dio mala fama entre desarrolladores y la mantiene hoy día.
Lo que dice Misato. Los que ya venden, venden bien. Los que no se venden bien necesitan un golpe de suerte para salir adelante, independientemente de la plataforma. Puede que te salga el siguiente Candy Crush como que te estampes con tu primer juego.
Es lo que pasó con Android: Angry Birds fue uno de los juegos que empujó el SO, así como muchos ports de juegos flash, y que era más sencillo (creo) que en el viejo J2ME o Symbian.
Un nuevo SO, una nueva plataforma o una nueva saga necesitan hoy de muchísima suerte para tener ese empujón inicial que lo saque de las sombras.
Joé, me despisto un rato y empezáis a escribir ahí, tl;nr y tal...
Yo me he quedado en la parte esa de Misato diciendo que es muy mayor ya para gestionar la memoria, e iba a decir que tampoco era para tanto, que basta con hacer un destructor por cada constructor y es casi automático cuando te acostumbras, y no tardas casi nada si copias el código del constructor y con mínima maña cambias los new por delete; claro que luego he caído que vosotros usáis la cosa esa del C++ y su curiosa sintaxis de constructor y claro, que no es lo mismo que con Object Pascal, que puedes hacerte un script que te convierta el constructor en destructor con la liberación de memoria y todo...
Peeero, luego he visto que me quedan tres páginas o más que leer y me digo, "paso, que no me estoy aburriendo tanto, y encima van a estar con eso de que Pascal no lo usa ni Bob Esponja, y que obsoleto y que C++ y que C# y que patrones y que qué tonto yo por usar un lenguaje sin ambigüedades con lo chulo que es que el compilador no avise cuando confundo una comparación con una asignación, que es la sal de la vida, y que tal", así que os ahorro el trabajo.
De buen rollito, eso sí, que no me cabreo. Si en realidad me gusta chincharos.
Yo iba a decir lo mismo, pero sé que en programación las cosas no siempre son tan sencillas.
Una de las primeras cosas que aprendí es que "cada cosa que abras, acuérdate de cerrarla", pero en ocasiones el código se puede liar de tal forma que te encuentres con 20 caminos diferentes para la ejecución y no puedas dejar las cosas tan limpias como quieres...
Tengo ideas encontradas: yo siempre pienso que sí, que es fácil, y que hay que ser organizado (y si no, es que haces las cosas mal). Pero a menudo leo tantas quejas de gente con más experiencia que yo que dudo de mi propia forma de pensar.
Ñuño Martínez
10/10/2015, 13:11
Tengo ideas encontradas: yo siempre pienso que sí, que es fácil, y que hay que ser organizado (y si no, es que haces las cosas mal). Pero a menudo leo tantas quejas de gente con más experiencia que yo que dudo de mi propia forma de pensar.Entonces como yo, pero ya llevo mucho tiempo callándome y estoy bastante hasta el moño.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.