Buenas!
hace bastante que no posteo por aqui y no se muy bien en que seccion del foro deberia ir este post, asi que si los admin estiman oportuno moverlo a la seccion adecuada sin problema! :D

Estoy trabajando en Frontier (http://www.frontier.co.uk/) y recientemente hemos abierto bastantes puestos de todos los perfiles (artistas, qa, programadores). Tenemos unas cuantas ips super chulas en desarrollo, como Elite Dangerous. Si quereis mas info, mandarme un mensaje y os contesto sin problemas! Ya somos unos cuantos espanioles en el estudio pero cuantos mas mejor :P

Un saludo,
Ruben

Hola,
totalmente de acuerdo con Nae, mi experiencia me dice lo mismo.

Un saludo,
Ruben

Hi,
efectivamente, en C++ si haces un typedef sobre una clase(estructura o enum) anonima el nombre del tipo sera el que le asignes en el typedef, toda la razon. :)

Ahora, en C++ no es estandar declarar estructuras anonimas, aunque en C si esta permitido. Por tanto: "struct{int bar;} Foo; Foo foo;" o el ejemplo que has puesto "struct { int r, b, g; } Color;" no deberian compilar en C++ estandar.

Un saludo,
Ruben

Hi,

Bueno, se sobreentendía lo que quería decir.

Precisamente, si has sobreentendido algo de ese comentario es que no has entendido cual era el fallo, porque la explicacion dada en ese comentario esta mal. Por muy explicito que hubiera sido, esa no es la razon a tu problema.

Estabas declarando una estructura sin nombre y compilandolo en C++ (a juzgar por el error de compilacion que te daba), pero no es que no estuviese encontrando el miembro MiEstructura dentro de la declaracion de MiEstructura (que como se ve en el ejemplo que te he puesto no tiene problemas en encontrolarlo). En C++ no puedes tener estructuras sin nombre(con las uniones si), a diferencia de C. Por lo que tu ejemplo compila en C pero no en C++. En C++ es obligatorio poner un nombre a la estructura. Tan sencillo como eso. En C++ usar el idiom del typedef es redundante.

Un saudo,
Ruben

Hi,

Simplemente que, en el primer modo, el compilador aún no sabe qué es eso de MiEstructura (el del puntero que pones en negrita) hasta que termina de procesar todo lo que hay entre llaves. En el segundo modo ya sabe algo de ese tipo desde el principio.

Se me olvidaba: nada te impide hacer el typedef delante de tu segunda alternativa.

creo que el anterior comentario no es muy acertado , por no decir que no ha dado pie con bola ^_^'

typedef struct
{
  string nombre;
  string apellidos;
  MiEstructura *siguiente;
}MiEstructura;

en principio no te compila porque no has puesto un nombre a la estructura (despues de "struct"), no porque no encuentre una declaracion de MiEstructura. Deberia de compilarte de esta forma:

Código [Seleccionar] Expand

typedef struct MiEstructura
{
  string nombre;
  string apellidos;
  MiEstructura *siguiente;
}MiEstructura;
Aunque tambien puedes poner:

Código [Seleccionar] Expand

typedef struct FooBar
{
  string nombre;
  string apellidos;
  FooBar*siguiente;
}MiEstructura;
y te seguiria compilando.

Estas mezclando C y C++. En C para declarar una variable de tipo struct, tenias que poner siempre struct, lo cual era un coñazo. Asi que haces un typedef y listo (lo que has hecho en tu ejemplo). En C++ es diferente y directamente puedes declarar una estructura y usar ese nombre como un nuevo tipo sin tener que poner struct todas las veces que quieras declarar una variable de ese tipo. Asi que el hacer el typedef es redundante en C++. Asi tu ejemplo quedaria:

Código [Seleccionar] Expand


#include <iostream>

using namespace std;
struct MiEstructura
{
string nombre;
string apellidos;
MiEstructura *siguiente;
};

int main(int argc, char** argv)
{
MiEstructura miEstructuraA;
miEstructuraA.nombre = "Foo A";
miEstructuraA.apellidos = "Aar";

MiEstructura miEstructuraB;
miEstructuraB.nombre = "Foo B";
miEstructuraB.apellidos = "Bar";
miEstructuraB.siguiente = 0;

miEstructuraA.siguiente = &miEstructuraB;

std::cout << "miEstructuraA.nombre = " << miEstructuraA.nombre.c_str() << std::endl
  << "miEstructuraA.apellidos = " << miEstructuraA.apellidos.c_str() << std::endl
  << "miEstructuraA.siguiente->nombre = " << miEstructuraA.siguiente->nombre.c_str() << std::endl
  << "miEstructuraA.siguiente->apellidos = " << miEstructuraA.siguiente->apellidos.c_str() << std::endl;
return 0;
}

La unica reseña es que, puedes declarar una estructura con el mismo nombre que con una no estructura (funcion, etc...) por razones historicas heredadas de C. Asi que para hacer la "desambiguacion" (dios me pille confesao, si no existe ese palabro! :P) puedes poner delante del nombre del tipo estructura, "struct". Ejemplo:

Código [Seleccionar] Expand


struct Foo {
// ...
};
void Foo(int bar);


Un saludo,
Ruben

Hi,
echale un ojo a http://www.redmine.org/

Un saludo,
Ruben

Hi,
en España es cierto, o por lo menos lo era hace poco, que, por lo general, te piden proyectos para entradas junior y no miran como algo indispensable el que tengas la carrera de informatica. Ahora, en UK, y puesto que el esta en Irlanda/UK tiene mas relevancia, para puestos de entrada por lo general, te van a pedir carrera, ademas de proyectos.

En el momento en el que haces un poco de networking y te pones a hablar con la gente rápidamente te das cuenta de que muchos no tienen titulación relacionada con la informática y lo primero que te preguntan son los trabajos que has realizado o en los que has participado... sin importar la titulación...

De ahi a decir que no te van a contratar porque ellos no tienen la carrera y tu si y que puede que te vaya a perjudicar en tu proyeccion laboral hay un trecho enorme  ^_^' Vamos, que en mi opinion es una burrada como la copa de un pino.  ^_^'

Un saludo,
Ruben

Yo no tengo gran experiencia en el tema de trabajar en empresas de videojuegos, por aquí si hay gente con experiencia en estos lares, pero te comento que lo poco que he visto siempre lo único que les interesa son los proyectos que has hecho o en los que has participado y lo que es la carrera o los masters les importa más bien poquito.

En general, no es correcto, por lo menos en Irlanda/UK. Normalmente, para un puesto de entrada como programador/desarrollador/ingeniero/etc... se necesita una carrera. Si hablamos de puestos seniors, normalmente te piden experiencia equivalente.

es más no les gusta porque la mayoría no tienen cursados estudios sobre la materia y lo ven un poco como intrusismo, vamos que puede incluso perjudicarte en la proyección en el trabajo, quizás no para encontrar un trabajo a bajo nivel pero sí para progresar...

Tampoco es correcto. Aunque cuecen habas en todos los sitios, no he oido practicamente a nadie que conozco que trabaja en la industria quejarse de esto.

Quizás me equivoque pero es la sensación que a mi me dio al observar un poco sobre el tema, así que yo sería cauto en como orientar todo eso si de verdad quieres trabajar en el tema y te gusta.

En mi humilde opinion, creo que estas equivocado. :)

Hi,
Mi opinion personal: si ya estas en Irlanda, no te vuelvas a España para hacer un master y luego tener que volver a irte... ;) Vamos, que para mi no seria una opcion.

Estando ya en Irlanda/UK y teniendo un videojuego como proyecto de fin de carrera tienes el camino practicamente hecho! :). No te hace falta un master en España para tener contactos ni para acercarte al mundo profesional: busca puestos de becario/junior en empresas de videojuegos en Irlanda/UK, mira el igda de tu region, ve a todas las conferencias que puedas sobre videojuegos y temas relacionados en Irlanda/UK (hay muchas), pregunta a tus profesores sobre el tema o al que te lleva el proyecto, etc...

No te hace falta ningun master en España teniendo en cuenta lo que cuentas, de hecho creo que seria contraproducente volverte a España en tu situacion, porque luego salir es mucho mas jodido.

Tampoco te hace falta tener en tus proyectos assets de calidad. Eres un programador, no un artista. Las empresas esperan ver "arte" de programador en los proyectos que les entregues junto con tu cv. No te preocupes por eso. Preocupate por demostrar toneladas de ilusion y pasion, por demostrar que te gusta aprender cosas nuevas y que acabar proyectos lo mejor pulidos que puedas (atencion al detalle).

Resumiendo, lo que yo haria en tu caso:
- Me dejaria de preocupar por los assets de mis proyectos.
- Acabaria el proyecto lo mas pulido posible. Es mejor tener poco pero bien, que mucho pero mal. Sobre todo cuida la manera en que lo presentas.
- Me pondria las pilas en el networking (conferencias, profesores, igda, foros, etc...). Si tienes dudas sobre este tema te puedo orientar a rasgos generales.
- Me haria un listado con todas los estudios de videojuegos de Irlanda/UK, buscaria cuales ofrecen becas/puestos junior y mandaria mi cv con proyectos a cada una de ellas.

Si aun asi, ves que un master te conviene mas, ni se te ocurra hacerlo en España estando ya en Irlanda/UK. Buscatelo en Inglaterra.

En fin, espero que te haya ayudado. Con cualquier duda no dudes en preguntar.

Un saludo,
Ruben

Hi,
viendo esta oferta de trabajo http://www.stratos-ad.com/detail.php?vtipo=1&vfecha=2010-03-03&vhora=16:47:24 en la que piden un programador 3d con 2 años de experiencia por 17k€ a 20€k, me he puesto a pensar si es que han bajado los sueldos en España tanto. Hace poco, unos 5 años, cuando la gente terminaba la carrera superior de ingenieria informatica se colocaba normalmente sin experiencia cobrando unos 18k€-19k€ en Madrid. Con 2 años de experiencia en graficos en España  esperaria algo entre 29k€-32k€.

¿Alquien tiene alguna opinion sobre esto?

Mi opinion:
- Ver este tipo de ofertas con el sueldo ayuda a filtrar mejor cuales son las que te pueden interesar, asi no pierde el tiempo nadie.[/li][/list]
- Algo de desconcierto porque no es la primera vez que veo una oferta con un sueldo tan bajo con respecto al perfil que piden. Lo cual me lleva a preguntarme: ¿Hay gente que realmente con esa experiencia acepte esos sueldos?¿Esta tan mal el mercado en España que se permiten lanzar ofertas pidiendo un perfil claramente "infrapagado" (no se si existe el palabro! :P)?

Por mi experiencia, es bastante dificil encontrar a alguien con experiencia en graficos en España. Por lo que me asombra bastante que se ofrezca tan poco a un perfil que es dificil de encontrar.

Un saludo,
Ruben

Hi,
este motor http://visualizationlibrary.com/documentation/pagkeyfeatures.html no usa un super arbol de escena sino en cada caso la estructura de datos que mas convenga (segun ellos, que no lo he usado nunca :P).

Un saludo,
Ruben

Hi,
pues lo dicho, el Cormen es el libro de referencia para eso mismo. En la segunda edicion, que es la que tengo yo, tiene: la III parte dedicada a estructuras de datos basicas (las que tu has citado) y la V a estructuras de datos mas avanzadas (fibonacci heaps, binomial heaps, etc...). Luego, tambien tiene la parte VI, dedicada a algoritmos de grafos. Los ejemplos que ponen estan en pseudo codigo, no en C++. Aunque no es muy complicado implementarlos en C++ sin hacer muchas florituras. Por lo que he visto van ya por la tercera edicion. http://mitpress.mit.edu/algorithms/

Espero que te haya ayudado.  :)

Un saludo,
Ruben

Hi,
Busqueda rapida en amazon: "data structures" http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=data+structures&x=0&y=0  y te saldran tropotocientos de c++. Ahora la biblia de estructuras de datos y algoritmos es "Introduction to algorithms" del MIT de Cormen. http://www.amazon.com/Introduction-Algorithms-Third-Thomas-Cormen/dp/0262033844/ Te recomiendo encarecidamente que compres ese libro si estas estudiando estructuras de datos y algoritmos. Luego, si lo que quieres es tener ejemplos de estructuras de datos en c++ y tu nivel en c++ es alto, puedes mirarte el codigo de boost. De todas formas, si nos explicas para que lo quieres, pues te podremos aconsejar mejor.

Estructuras de datos me suena demasiado viejo, si te refieres a cómo estructurar los datos en tu aplicación, yo creo que con saber bien sobre Programación Orientada a Objetos tienes ya casi todo resuelto, luego si es en C pues te miras tutoriales de las STL y finalmente algun tutorial sobre patrones de diseño.

Creo que estas confundiendo y mezclando conceptos. Una cosa es como almacenar y gestionar los datos de tu aplicacion (estructuras de datos y algoritmos, entre otros) y otra totalmente diferente es como diseñar tu aplicacion (tipo de lenguaje, patrones, entre otros). La programacion orientada a objetos esta igual de relacionada con estructuras de datos que cualquier otro tipo de programacion.  Los patrones de diseño y las estructuras de datos, pues no tienen nada que ver. STL es de C++. Y que te suene a viejo, no  aporta absolutamente nada.

Un saludo,
Ruben

Hi,
mas o menos, por lo que puedo intuir de tu caso, yo lo que haria seria trabajar en un tipo de angulo en mi "core" y pasaria (lo antes posible) todas las entradas/salidas de angulos que lleguen/salgan a/de mi "core". Por ejemplo, supongamos que mi core trabaja en radianes. Si el usuario trabaja en grados de 0..400 justo despues de recoger la entrada del usuario y validarla, la convertiria a radianes, para despues procesarla en mi core. Con Opengl igual, justo cuando vayas a necesitar llamar a Opengl, lo conviertes a grados.

Yo no creo que merezca la pena meter mas tipos en este caso.

Un saludo,
Ruben

Hi,
typedef crea un alias pero no define nuevos tipos. El compilador se queja porque, efectivamente, has definido dos metodos con mismas declaraciones. Vamos, que el compilador se encuentra con un acimut_t en una y, al ser un alias de un float, para el compilador es un float. Lo mismo pasa con radianes_t. Asi que, el compilador ve dos metodos iguales.

Por mi experiencia, normalmente no se diferencia explicitamente en codigo que tipo de angulos usas. Normalmente, se menciona en la documentacion y los argumentos se pasan en floats. Por ejemplo, para que te hagas una idea, en directx la funcion de creacion de una matriz vista pide radianes? (nunca me acuerdo! :P) para el fovy y en glu se usa el contrario (grados? :P), pero ambos esperan un float. Luego, con que te definas un par de constantes de conversion, vas listo.

Ahora, yo lo que haria (por tu propia salud mental! :D) es homogeneizar el tipo de angulos que usa tu codigo. Es decir, decides que tu codigo usa radianes y luego ya vas convirtiendo como prefieras (wrappers, cambios in-situ, etc...) de los tipos de las librerias al tuyo.

Espero que te haya servido.

Un saludo,
Ruben

EDITADO: corregidas algunas faltas y errores....  ::)