... si algo he descubierto en esta industria es que el 70% de los programadores tienen mucho conocimiento de videojuegos en si, de como hacer las cosas, pero no escriben codigo robusto ni reutilizable ni nada.
...
Todos ellos muy buenos y para mi indispensables ya que sientan las bases de lo que yo creo que deberia ser un buen programador de videojuegos, que no es solo saber el algoritmo de A* o programar un QuadTree, sino muchas mas cosas.
...

???

¿Cuantos programadores de la "industria" conoces?

PS: un "int[64]" sigue siendo más rápido de compilar, y suele ser más eficiente asi como portable que un "vector<int>"

He estado echando una ojeada y he tenido mucho en mente lo que decíais sobre cargar una y otra vez los vertexbuffers, por aquello de que cuanto menos cpu haya de por medio mejor. Que os parece un vertex buffer general para toda la escena, y que cada poliedro utilice su propio index buffer. Claro que ésto solo funcionará para escenas pequeñas, no puedo guardar un vertexbuffer para una malla de terreno compleja en la gpu no??? o si?

En un prinicipio, tampoco pasa nada por tener unos cuantos vertex buffers.

Hay juegos (aunque más antiguos) que tenian toda le geometria del escenario en una malla, aunque solo se dibujará parte de la misma. Pero tambien tienes que tener en cuenta si quieres que haya "instancias" de una misma geometria.
Al final la geometria de la escena la deberias tener en memoria de gpu (aunque hay API y plataformas que te permiten tener buffers en memoria principal, y hay algunos dispositivos que tienen la memoria compartida CPU/GPU).

Otra cosa es que sea un "mundo" muy grande, con lo que tienes que tirar de "streamming", pero lo que visualizas lo tienes que "tener cargado", de eso nadie te salva.

Lo que tienes que tener en cuenta son los "draw-calls". Para dibujar con "un material diferente", debes de lanzar un draw-call por cada objeto, y entre ellos, cambiar el estado del renderer (o encolar un display list, dependiendo de la API).

No hay solución mágica, ni un camino fácil ... las APIs son tan "flexibles" a la vez que "complejas" para permitir hacer las "guarrerias" que hagan falta con tal de rascar 1ms más en cada frame.

Tienes más de un camino válido y eficiente, pero por desgracia, hay más de 100 "malos" e ineficientes. Mi consejo es que busques el equilibrio, y no te obsesiones con "generalizarlo" todo. Para mi las mejores soluciones son las soluciones especificas, si estuviera inventada ya la solución mágica para todo, sobrariamos los ingenieros.

Un saludo y suerte :)

Lo de "parsers" viene por que los primeros programas para la creacion de aventuras conversacionales se les llamaba asi, porque de algun modo "parseaban" la entrada del jugador, que era una frase normalmente, y le daban una semantica.

Creo que el llamar "parser" al Ags o al Wintermute, es más una cuestión de "herencia". Pero realmente ambos se podrian denominar "game engines", ya que, aunque son exclusivos de aventuras graficas (no digo que no se pueda hacer nada más, pero su "utilidad principal" es esa), corresponden con mi interpretación personal de "game engine".

Para mi un "game engine" se puede dividir en: runtime y tools.

- Las tools son programas que tienen la finalidad de crear, convertir y manejar el "content" o "asset resources" del juego, principalmente.
- El runtime es un ejecutable que "corre el juego".

Generalmente las "tools" se comparten entre juego y juego (aunque normalmente, siempre suelen actualizarse y mejorarse), y el "runtime" depende.

Unity3D por ejemplo tiene el mismo "runtime" para todos los juegos (claro está que cada versión lo actualizan más, pero para una misma version el runtime y el editor siempre son el mismo), lo que "diferencia" el juego es solamente el "Content", entre ellos están el código .NET compilado: los scripts que definen la lógica.

En cambio puede haber otro "motor" que tan solo provea de "librerias" al runtime, y cada "juego" sea una nueva "aplicación" que use dichas librerias.


Un saludo.


PS: Un "parser" propiamente dicho podria ser por ejemplo: Inform7

En mi opinión deberias utilizar un vertex buffer por una malla completa o incluso varias mallas o submallas.

En cuanto lo de "orientar a objetos" totalmente el motor. Si esto implica crear clases a nivel de poligono, etc. y comenzar a utilizar polimorfismo, etc a "bajo nivel", yo lo veo un GRAN ERROR. Lo intenté en el pasado (y se puede decir que lo logré, porque funcionar, funciona, claro, ... pero como funciona es otra cosa).

En mi opinión, clases para managers, y otras cosas de "alto nivel".

Struct y PODs, para todo aquello que vaya a bajo nivel. Es mejor diseñar Orientado a Datos que Orientado a Objetos. En otras cosas porque como dice Mike Acton (Insomiac Games): "donde hay uno hay más de uno".


Se que es una opinión, y que muchos estarán en contra, pero como dice un amigo (que aparte de amigo, es un crack): "C+" mola, ... el "C++" no tanto (demasiado "+" XD).


Bueno, recuerda que es solo mi opinión.

Un salduo.

Yo he estado "desconectado" de stratos unos dias y no habia visto los links, pero hay mucho material interesante  :D gracias

Es una pena, pero la verdad es que estoy muy "pez" en esto de la GI.

A ver si saco tiempo, y me puedo poner yo también a "experiementar" con cosicas de estas.


Siento no poder echarte una mano :(

Saludos

Hola, he estado my liado con prespuestos y otras historias y no habia podido contestar desde hace dos semanas ... soy un "malqueda" :S

A la pregunta de XÑA: de momento es todo forward. Para dispositivos con fixed pipeline se utiliza solo una "configuración de renderizado", para programmable pipeline se puede utilizar single-pass o multi-pass ligthing.

La idea es que los efectos, sombras, etc. hasta ahora se ponian "a mano" en C++ en la "funcion de render", para cada proyecto en concreto. Y el sistema de "layers" te permitia seleccionar "objetos" a los que aplicar unos u otros efectos (cast/project shadows, real-time reflections, etc).

Pero visto, lo visto, esto es un peñazo insalvable, a no ser que como KneDa tengas la ventaja de tener la "funcion de render" en un lenguaje de script dinámico.


Al final estoy pasando todo a "data-drive" en ficheros de configuración LSON, con lo que para crear los RT, dibujar quads para post-screen, etc, se hace todo leyendo el archivo de configuracion.
Le voy a hacer caso a KneDa y voy a separar los pasos de los surface shaders, se renderizarán en el orden que dicte el archivo de configuración.
El deferred-shading por ejemplo, tendria que poder configurarlo desde el LSON también, así como HDR, diferentes tipos de shadows, etc.

Ya iré viendo, porque ahora hay curro, y de momento el sistema de materiales se va a quedar así, a no ser que ocurra algo de "fuerza mayor", y tenga que ponerme a "actulizarlo todo".


En cuanto a la pregunta sobre Json en c++ de KneDa: yo utilizo un "parser propio" bastante sencillito. Principalmente porque la syntaxis que utilizo para LSON no es exactamente Json. Más bien esta basado en esto: http://bitsquid.blogspot.com.es/2009/10/simplified-json-notation.html

Si que estuve buscando una vez, y encontre algo interesante: http://stackoverflow.com/questions/245973/whats-the-best-c-json-parser y un pagina con una lista de parsers, que no he podido volver a encontrar :(


Y en cuanto a lo de normalizar el atributo de la posicion del vertice lo decia porque yo marco como normalizados la normal (valga la redundancia) y los valores de color, por ejemplo, porque siempre van de 0 a 1 (o al menos deberian). En cambio la posicion del vertice puede ser cualquier numero, positivo, o negativo, y no deberia de estar normalizada. Por tanto yo en normalized para la posicvion pongo false, eso es lo que me habia extrañado.


Bueno, ya pondré como funciona esto del "data-driving pipeline" y como lo acabo de integrar con los surface shaders que tengo ahora ... cuando le pueda volver a dedicar unos dias para acabarlo.

Un saludo.

He estado leyendo otra vez tu descripción de pipeline, y me parece que lo habia interpretado mal  ^_^'

Más que las "Layers" que utilizo yo parece pipelines de renderizado tipo Horde3D, algo asi:

Código [Seleccionar] Expand

<!-- Forward Shading Pipeline -->
<Pipeline>
<CommandQueue>
<Stage id="Geometry" link="pipelines/globalSettings.material.xml">
<ClearTarget depthBuf="true" colBuf0="true" />
<DrawGeometry context="AMBIENT" class="~Translucent" />
<DoForwardLightLoop class="~Translucent" />
<DrawGeometry context="TRANSLUCENT" class="Translucent" order="BACK_TO_FRONT" />
</Stage>
<Stage id="Overlays">
<DrawOverlays context="OVERLAY" />
</Stage>
</CommandQueue>
</Pipeline>

¿Es algo parecido a esto lo que te refieres con pipeline?

Gracias por la respuesta, esta muy bien explicado todo :D

Voy con los comentarios:

Primero: me mola mucho que utilices json, ... yo tambien :D ... bueno ... más o menos ... lo mio se llama LSON pero es una "copia barata" del SJSON de BitSquid, que esta basado en json, pero con una "syntaxis" más sencilla y parecida a Lua.
De todas formas, esto lo hago en el "development content", mientras utilizo el motor para desarrollo, luego lo paso por un compiler, y genera packs binarios con tablas de offsets y compresion opcional. Pero "durante el desarrollo" mola mucho utilizar este tipo de formato :D, aunque supongo que será lo típico para webGl, pero en fin ... mola :)


3) Muy buena idea, estoy de acuerdo con lo que has dicho, deberia haberlo decidido asi desde el principio y no rallarme.
Comprobaré el formato de la geometria contra la especificacion de entrada del "surface shader" solo al aplicar el material al objeto, y hago "saltar" un tipo de warning exception o lo que sea, y reemplazo el material "que no se puede bindar" por uno generico que funcione con el formato especificado. ¿Por ejemplo, no?

Aunque hay una cosa que no entiendo de tu descripcion:

Código [Seleccionar] Expand

{ "datatype":"SHORT", "datasize":3, "offset":0, "normalized":true, "bind":"position"},
¿la posición esta normalizada?


4) Perdón por la cuarta pregunta, creo que la he "liado" un poco, a veces no me sé explicar ^^
Preguntaba por como almacenar los datos de las "propiedades" (uniforms), pero no me he dado cuenta en en js no debe haber ese problema por la naturaleza "dinamica y no tipada" del mismo lenguaje.
En cuanto a los uniforms precalculados estoy de acuerdo, yo también hago eso, por eso decia que para almacenar "propiedades" del material solo gastaba scalares y vectores, pero no matrices porque todas son para "parametros precalculados" como el worldViewProj, la inversa de la vista, etc.
Mola la semantica que le das, es parecida como dices a RenderMonkey, y, en este sentido, bastante más "flexible" que la mia, ya que no "interpreto" diferentes nombres de uniforms para los "parametros precalculados", siempre el mismo.


5) Supongo que los "pipelines" que utilizas, seran algo parecido a los "layers" que utilizo yo.
Siguiendo tu consejo deberia "colectar" los "draw calls/pasos" de cada mesh por separado, y luego ordenarlos segun la especificación plataforma (ordenar por shader, front-back, back-front, etc), para enviarlos de tirón al back-end. ¿No?
Lo cual me parece una idea "fantastica", asi que voy a probar a hacer algo asi, ya tenia algún tipo de ordenación, pero los "multi-passes" se hacian seguidos, y igual no es una buena idea.


Gracias de nuevo por las respuestas.
Un saludo

Jope con las comparaciones con floats y doubles, es bastante mas complicado de lo que parece.

Como dicen los expertos: "No importa cuan complicada creas que es la matematica de punto flotante, siempre lo será más."

En fin ... que remedio, es lo que hay ^^

Gracias por tu explicación :)

Verás, tengo algunas dudas sobre lo que has planteado, voy a explicar mi interpretación, bastante parecida a la tuya, pero posiblemente con algunas modificaciones.

En primer lugar, supongo que lo de "materiales por partes o por poligonos", te refieres a tener un mesh con varios sub-materiales (sub-meshes). Esto en mi engine es "indispensable", y asi lo tengo implementado.

En mi aproximacion un "surface shader" es lo que podriamos decir un material, y un Material Instance, una instancia de ese material.

Cada "surface shader" define los shaders que renderizan (estos shaders no están "acabados", ya que se combina su resultado para dar diferentes tipo: normal, skinned, multi-pass light, single-pass light, etc), los tipos de "uniforms" que acepta: diffuse, emissive, etc.., la "Render Layer" o "Layers" sobre la que trabaja (Default, Shadows, etc). Además para evitar la "explosion combinatoria" de los shaders, define que tipo de combinaciones de shaders puede tener.

Un material, en un principio, tiene una referencia a su "surface shader", una lista de uniforms, y estados de render (Alpha, Cull, Depth, etc). Los materiales se crean a partir de la funcion " MaterialManager::create_material( SurfaceShader::Handle shaderHandle )" con lo que se crea un "Material Instance" con los uniforms especificos del surface shader, además se copian los estados por defecto (Alpha, Cull, ...).


Y ahora mis preguntas:

1) ¿Vale la pena tener los estados de render (Alpha, Cull, etc) en cada "Material Instance" o los quito y dejo solo los de los "Surface Shader"? (De entrada pienso que me ahorraria cambios de estado al construir las "Display List" para el "render back-end")

2) La selección del tipo de shader (Skinned, Rigid, Lights , etc) me queda un poco "branchy code". ¿Alguien ha encontrado una buena solución para esto?

3) Los atributos dependen del tipo de mesh (por ejemplo pueden tener color en los vertices o no), lo que me lleva a una nueva selección del "shader program". ¿Alguna otra solución?

4) Yo guardo los "uniforms" como arrays estaticos. Divido en dos tipos de parametros en "escalares" (floats simples), y "vectoriales" (Vector4, aunque puedes coger los dos primeros floats, por ejemplo, para un vector2), ya que gasto no matrices (estos uniforms, como worldViewProj por ejemplo, los cambio desde el renderer-back-end, no desde el material), con lo que tengo que almacenar tambien las keys para obtener el parametros por nombre (U32 con el Crc32 de un string), y los indices de uniform del parametro en cuestion en el shader.
¿Alguna otra aproximacion?


5) Para utilizar varios "passes" los defines como varios materiales para el mismo modelo. Yo habia pensado en cambio de que el "surface shader" tuviera "la lista de pasos" especifica, luego hay unos "pass" especiales para acumulacion de depth, etc. que se realizan en otras "layers" del renderer.
¿Es mejor realizar los "todos los passes especificos del material del tiron", o dibujar todos los objetos por cada pass por separado como hago con los "passes especiales"?
En un principio, a mi me parece que puede depender de la arquitectura, pero no estoy seguro ¿Que pensais vosotros?


La verdad es que es un poco "trallada de olla" el sistema, pero no he encontrado demasiadas referencias, y esto me parece suficientemente flexible, aunque tengo alguna duda sobre la eficiencia de algunas cosas.


Un saludo, y gracias de nuevo

Voy a "reabrir" esto, para hacer una pregunta.

Estoy rehaciendo el sistema que tengo de materiales y surfaces shaders (que supongo que es algo parecido a lo que comentaba Gallo del GP7), y me preguntaba a que solución habias llegado tú al final, KneDa, que habias decidido, o si habias encontrado algun link más sobre el tema.

La verdad es que estoy un poco confuso también con algunas cosas, y no me gustaria tener que volver a reprogramar todo el subsistema otra vez porque algo no me" cuadre" luego, como me ha pasado ahora.

Un saludo y gracias.

Para liarte con más links, el ShadowGun que esta echo con Unity:
http://blogs.unity3d.com/wp-content/uploads/2011/09/Shadowgun_Unite2011.pdf
http://video.unity3d.com/video/3709506/unite-11-shadowgun-rendering

Video y pdf ^^

Guardan lightprobes como Spherical Harmonics, la gracia en particular es que se samplea la iluminacion de los SH por vertice, y luego se interpola y modula por pixel.

Y para resolver el "problema de los brillos" con las especulares tienen un par de trucos en personajes y escenarios, miratelo si estas interesado.

Las optimizaciones, eso si, las han echo para dispositivos moviles, depende del ordenador que cargue la app de webgl, pero creo que tendrás menos problemas, en fillrate por ejemplo.


Un saludo

Te remito al articulo que te he puesto antes, la "tecnica" original en la que esta basado tu algoritmo (el de los enteros como lo llamas) es de Dawson y el lo explica muy bien, pero repito lo dicho:

No hay una formula mágica!!!!

Si lo que necesitas es una funcion que "resuelva todo" y que encima este "optimizada" (como la optimizacion del pdf que pones) es muy dificil, por no decir imposible (ya que es lo que dicen los que saben del tema del IEEE, no yo ^^).

Lo que he puesto yo no es lo más rapido del mundo ni de lejos, ya que estas haciendo el fabs y la resta, con lo que la solucion podria parecer "redudante" con el algoritmo que tenias.

Lo que te ofrece respecto a la comparacion con un delta "float", es más precisión "relativa". Pero si quieres velocidad no es la solución, simplemente separa comparaciones cerca y lejos de cero. Con dos funciones por ejemplo.

Un saludo


EDIT: copio esto del articulo que no paro de mencionar porque me parece muy interesante y explicativo:

There is no silver bullet. You have to choose wisely.

+ If you are comparing against zero, then relative epsilons and ULPs based comparisons are usually meaningless. You'll need to use an absolute epsilon, whose value might be some small multiple of FLT_EPSILON and the inputs to your calculation. Maybe.

+ If you are comparing against a non-zero number then relative epsilons or ULPs based comparisons are probably what you want. You'll probably want some small multiple of FLT_EPSILON for your relative epsilon, or some small number of ULPs. An absolute epsilon could be used if you knew exactly what number you were comparing against.

+ If you are comparing two arbitrary numbers that could be zero or non-zero then you need the kitchen sink. Good luck and God speed.

EDIT2: Estaba repasando el algoritmo que he puesto para ver si podia elimnar el "branch code", y he encontrado que tenia una cast mal y no funcionaba con negativos ... sorry ^^. El cambio es esta linea:

Código [Seleccionar] Expand

I32 sign = (((I32)(ai ^ bi)) >> 31) - 1; // Parece que bien, pero NOOOO!!
por esta otra:

Código [Seleccionar] Expand

I32 sign = (((U32)(ai ^ bi)) >> 31) - 1; // Esta si :D

ups! ... chorrada pero importante

Hola, voy a contestar pero no me hagas mucho caso porque no piloto mucho de IEEE 754 ^^

Con lo poco que entiendo del tema, lo de restar y compara con cero: NOOOOOO! (mira "Infernal zero" y "Catastrophic cancellation" en el artículo que pongo más abajo).

Creo que el problema lo tienes en el mismo algoritmo. Con flotantes de simple precision no te deberia funcionar tampoco cerca de cero.

La razón es que es una "optimización" de la propuesta de Bruce Dawson (Valve Software) para comparar flotantes basandose en la ULP (Unit in the Last Position). Que no tendria que ver en mi opinión con epsilon, como pones de constante. (aunque realmente no se que vale esa epsilon).

El mismo Bruce Dawson expone los problemas de su tan "conocida" tecnica o aproximación: http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/.
Aunque yo te recomiendo que te leas todos sus articulos sobre flotantes si estas indagando sobre ello.

Mi "corrección" con unos unittest comparandolo con el "original" esta en floats:

Código [Seleccionar] Expand


#define FLT_EPSILON_REDEF     1.192092896e-07F        /* smallest such that 1.0+FLT_EPSILON != 1.0 */

// Dawson "optimizado"
static bool is_near_equal_float(float a, float b, I32 maxDiff = 1)
{
I32 ai = *((I32*)(&a));
I32 bi = *((I32*)(&b));
I32 sign = (((I32)(ai ^ bi)) >> 31) - 1;

TY_ASSERT( (sign == 0) || (sign == 0xffffffffffffffff) );

I32 diff = (((0x80000000 - ai) & (~sign)) | (ai & sign)) - bi;
I32 v1 = maxDiff - diff;
I32 v2 = maxDiff + diff;

return (v1 | v2) >= 0;
}

// Nuevo Dawson, no tan "optimizado", pero funciona cerca de cero
static bool is_near_equal_float_new_dawson(float a, float b, I32 maxUlpsDiff = 1, float maxRelDiff = FLT_EPSILON_REDEF )
{
// Check if the numbers are really close -- needed
// when comparing numbers near zero.
float absDiff = fabs(a - b);
if (absDiff <= maxRelDiff)
return true;

I32 ai = *((I32*)(&a));
I32 bi = *((I32*)(&b));
I32 sign = (((I32)(ai ^ bi)) >> 31) - 1;

TY_ASSERT( (sign == 0) || (sign == 0xffffffffffffffff) );

I32 diff = (((0x80000000 - ai) & (~sign)) | (ai & sign)) - bi;
I32 v1 = maxUlpsDiff - diff;
I32 v2 = maxUlpsDiff + diff;

return (v1 | v2) >= 0;
}


TY_TEST( StratosFloatQuestion, GlobalTest )
{
// El mismo numero
TY_CHECK( is_near_equal_float(0.1f,0.1f) );
TY_CHECK( is_near_equal_float_new_dawson(0.1f,0.1f) );

// Lejos de cero .. no hay problema
TY_CHECK( is_near_equal_float(0.1f,0.100000000001f) );
TY_CHECK( is_near_equal_float_new_dawson(0.1f,0.100000000001f) );

// Más de lo mismo, mumeros más grandes, menos precision, ... pero sigue funcionando
TY_CHECK( is_near_equal_float(10000.1f,10000.100000001f) );
TY_CHECK( is_near_equal_float_new_dawson(10000.1f,10000.100000001f) );

// mmm ... cerca de cero ... si implementas algo de Dawson ... haz caso a Dawson
TY_CHECK( is_near_equal_float(0.000000000011f,0.00000000001f) == false );
TY_CHECK( is_near_equal_float_new_dawson(0.000000000011f,0.00000000001f) == true );

// Y con cero ya ni te cuento ^^ ... viva Dawson!!!!
TY_CHECK( is_near_equal_float(0.0f,0.00000000001f) == false );
TY_CHECK( is_near_equal_float_new_dawson(0.0f,0.00000000001f) == true );
}


Como ves he "tocado" algunas cosas para que fuera en mi framework, pero el trabajo de vuelta lo veo sencillo.
Podrias pasarlo a doubles y hacer las comparaciones haber si es el problema.

El problema aqui es el fabs y el if, si lo que quieres es eliminar branchy code no parece una buena solución, pero sabiendo que el 0x80000000  debiera ser una mascara para el signo igual se puede hacer otro tipo de "optimización".
De todas formas creo que tambien depende de si la arquitectura en la que estas trabajando tiene que realizar cambios de registros de flotantes a enteros, ... en fin que no me preguntes de como iria más rápido, tendria que probarlo en varias maquinas.


Lo que me lleva a mi pregunta: ¿para que utilizas comparaciones "optimizadas"? ¿lo necesitas en tiempo real? ¿es para preprocesar algo?

Bueno, en realidad son tres, lo siento ^^

Si es para runtime, prueba a utilizar el Dawson "original", pero ten cuidado con los numeros cerca de cero, de todas formas yo que tu me miraria el articulo. Como dice Dawson en él: "There is no silver bullet. You have to choose wisely."


Espero haberte ayudado, un saludo.


EDIT: despues del "tostón" de post he encontrado la repsuesta corta ^^:

Código [Seleccionar] Expand

// Check if the numbers are really close -- needed
// when comparing numbers near zero.
float absDiff = fabs(a - b);
if (absDiff <= maxRelDiff)
return true;


esto es lo que he cmabiado   ^_^'

Conozco el precio de esas licencias y no flipo en colores porque se lo caro que es el desarrollo en una consola "grande".  A mi me toca las bolas mucho el hecho de tener que pagar por la base para optar a la licencia ios. ¿Entonces que clase de licencias separadas tienen si al final tienes que pasar por caja por algo que igual ni usas?, para eso no marees la perdiz y vendelo todo junto y dejate de pamplinas

Siento, "ocupar" el hilo, y no "hablar directamente de cosas para el Wave", pero tengo mi opinión sobre lo que dice Eskema.

Creo que lo importante del precio no es lo "caro del desarrollo", sino el "provecho" que se le puede sacar. En un principio no deberia importar si haces un juego de PC con la "Pro" o uno de iOS con la "indie", pero en la realidad, creo que se le puede sacar más provecho a iOS, por una menor "implantación" de la pirateria (por ejemplo).

Se que puedes estar en desacuerdo conmigo, y puedes tener razon, pero también entiendo que 2300€ por este tipo de tecnologia, está bastante bien (aunque yo desarrolle la mia propia ahora, con anterioridad lo he gastado en diferentes proyectos, en diferentes plataformas, con gastos muy superiores).

Que no aprovechas la version "Pro" de PC, que podias tener una versión "más barata" solo con una "Indie" de iOS, cierto también, pero has de reconocer que les ha salido una "buena estrategia comercial de enganche", y están "copando" el mercado Indie.


En fin no quisiera que pensanses que creo que no tienes razón, que la tienes, solo intento dar otro punto de vista ^^
Un saludo