for(espacio = i; espacio <= i; espacio++)

Ummm... yo diría que ahí tienes un problema...
     

repuesta:

creo que no tienes muy claro el for.,..

jajaja, gracias por el chiste me has alegrado el dia  :D
Deberian haber más posts de estos, algo de humor para relajar nunca está de más  ^_^

Yo lo tengo desde hace años ya. Está bastante completo, y te da base matematica, interpretaciones geometricas y aplicaciones en "computacion" de casi todo.
Tambien llevaba código que puedes gastar como base para una libreria matematica, lo que no recuerdo era el "handeness" que utilizaba, o el sentido de la rotaciones.

Buena elección para la biblioteca de base. :)

Lo que no entiendo es ésto: (-1) ^index[j]

Es la codificación que utiliza el FBX. Cuando hay final de poligono el inidice es negativo, y el valor es el indice negativo menos 1. Por lo tanto la transformación a positivo seria multiplicar por 1 y restar 1. p.e: (-8) * (-1) - 1 = 8 -1 = 7. Utilizar el operador XOR es simplemente porque es más rápido, aunque si transformas los indices antes da igual que lo hagas multiplicando y restando no pasa nada.

Eso pasa la hacer clic.

403 - Forbidden

El enlace esta linkado en el puerto 81, prueba este que he modificado yo:http://s3.subirimagenes.com/otros/7441505subir.jpg


En cuanto al problema en si, como he dicho creo que seria mejor que utilizaras directamente el sdk de autodesk (te evitarias estos problemas), para CONVERTIR, y que no cargues FBX desde el "runtime" directamente.

El problema que tienes es por los indices negativos que te he dicho. Y porque creo que (como te he comentado antes) no estas pintando bien con indices. No tienes que usa glDrawArrays sino drawElements.

En cuanto a los indices negativos, hay que convertirlos! Por arte de magia no van a aparecer los inidices corectos. Tendrias que repasar la teoria de numeros negativos (complemento a1 y a2) y saber como se "auto-castean" los signed y unsigned ... porque los 16bits de un short = -4 NO SON 4(b0000000000000100)!!


En el caso del FBX, si no usas el sdk, tendrás que aplicar:

Código [Seleccionar] Expand

"uIndex[j] = (index[j] >= 0) ? index[j] : ( (-1) ^index[j] );"
Los códigos negativos indican el final de un poly, lo cual quiere decir que puede que haya polys de mas de 3 lados(no es tu caso si te fijas).
El sdk de fbx lo hace directamente, y si no recuerdo mal podias triangular la malla, si no lo estaba ya, con funciones del mismo.

He echo un "UnitTest" en mi SDK(compilando el render system como opengl) para demostrartelo. Pongo el código (obvia las funciones especificas del SDK, y centrate en la conversion de inidices y las llamadas a OpenGL):

Código [Seleccionar] Expand


TY_TEST( StratosQuestion, CommonOGL )
{
Matrix4f posMatrix;
F32 radAngle = 0.0f;

F32 clearColor [] = { 0.0f, 0.0f, 1.0f, 0.0f };

g_RenderSystem.set_backface_culling(false);

g_RenderSystem.set_projection_matrix( CameraPerspective().x );

short index[]={0,2,-4,8,1,-10,4,5,-8,10,6,-12,12,13,-15,15,16,-18,18,19,-21,21,22,-24,24,25,-27,27,28,-30,30,31,-33,33,34,-36};
float vertices[]={-0.5,-0.5,0,0.5,-0.5,0,-0.5,0.5,0,0.5,0.5,0,-0.5,-0.5,1,0.5,-0.5,1,-0.5,0.5,1,0.5,0.5,1,0.5,0.5,0,-0.5,-0.5,0,0.5
,0.5,1,-0.5,-0.5,1,-0.5,-0.5,0,0.5,-0.5,0,0.5,-0.5,1,0.5,-0.5,1,-0.5,-0.5,1,-0.5,-0.5,0,0.5,-0.5,0,0.5,0.5,0,0.5,0.5
,1,0.5,0.5,1,0.5,-0.5,1,0.5,-0.5,0,0.5,0.5,0,-0.5,0.5,0,-0.5,0.5,1,-0.5,0.5,1,0.5,0.5,1,0.5,0.5,0,-0.5,0.5,0,-0.5
,-0.5,0,-0.5,-0.5,1,-0.5,-0.5,1,-0.5,0.5,1,-0.5,0.5,0} ;
float normales[108]={0,0,-1,0,0,-1,0,0,-1,0,0,-1,0,0,1,0,0,1,0,0,1,0,0,1,0,0,-1,0,0,-1,0,0,1,0,0,1,0,-1,0,0,-1,0,0,-1,0,0,-1,0,0,-1
,0,0,-1,0,1,0,0,1,0,0,1,0,0,1,0,0,1,0,0,1,0,0,0,1,0,0,1,0,0,1,0,0,1,0,0,1,0,0,1,0,-1,0,0,-1,0,0,-1,0,0,-1,0,0
,-1,0,0,-1,0,0};

int indexSize = TY_STATIC_ARRAY_SIZE(index);
int vertexSize = TY_STATIC_ARRAY_SIZE(vertices);

unsigned short uIndex[1024]; // 2KB --> mas vale prevenir que currar!!
for (int j = 0; j < indexSize ; j++)
{
uIndex[j] = (index[j] >= 0) ? index[j] : ( (-1) ^index[j] );
}

for (int i = 0; i < 400; i++)
{
g_RenderSystem.clear(TYE_CLEAR_FLAG_BOTH, clearColor);

radAngle+=0.03f;


posMatrix = Matrix4f();
posMatrix.rotate(0.0f, radAngle, 0.0f);

glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_NORMAL_ARRAY);

glVertexPointer(3, GL_FLOAT, 12, vertices);
glNormalPointer(GL_FLOAT, 12, normales);


posMatrix.translate(+0.0f, 0.0f, -5.0f);
g_RenderSystem.set_position_matrix( posMatrix.x );
glDrawElements(GL_TRIANGLES, indexSize, GL_UNSIGNED_SHORT, uIndex);

glDisableClientState(GL_VERTEX_ARRAY);
glDisableClientState(GL_NORMAL_ARRAY);


// swap buffers
g_pMainDisplay->swap_buffers();

// sleep 10ms
g_pDisplayManager->update();
TY_SLEEP_MS(10);
}

}


TY_STATIC_ARRAY_SIZE, lo utilizo para saber cuantos elementos hay el array:

Código [Seleccionar] Expand

#define TY_STATIC_ARRAY_SIZE(x) (sizeof(x) / sizeof(x[0]))


Espero que te sirva, un saludo!

A bote pronto tengos dos preguntas sobre el código:

1) Porque pintas primero con gldrawArrays y luego con glBegin / End?
Creo que lo segundo sobra.

2) Si me fijo en drawArrays (que es la que utilizaria yo).
Tendrias que pasarle un stride de 12 bytes (4*3) a gl*Pointer, no?

No sé si sera eso, mi codigo quedaria asi:

Código [Seleccionar] Expand


glVertexPointer(3, GL_FLOAT, 12, vertices);
glNormalPointer(GL_FLOAT, 12, normales);

Aunque yo pondria posicion y normal en un mismo array (suele ser más eficiente).

Puedes comprobar tambien como tienes el configurado en face-culling (activa que pinte los dos lados para comprobarlo).
Para depurar prueba a hacer un plano o algo con menos vertices., y intenta que las coordenadas estén redeondeadas (crealo "numericamente" en el max y asegurate de que tenga de lado 1.0f o algo más facil de visualizar).

Siento no poder ayudarte más, pero asi a primera vista no veo nada más raro.

Un saludo

EDIT:
Otras cosas que no habia visto!

Vale, me autocontesto la primera: pintas tres cubos, el primero (con glDrawArrays que es el que a mi me mola) en (0,3,0) relativo a donde esta la matriz cuando entras a este trozo de código. Los otros dos estan pintados en (10,0,0) y (20,0,0) respectivamente. No?
El primero con indices, y el segundo si ellos, directamente recorriendo los vertices. (No puedo asegurar que estos dos loops te funcionen bien)

Veo otro problema con glDrawArrays, y es que no estas utilizando los indices en esta funcion. Si quieres inidices prueba con

Código [Seleccionar] Expand

glDrawElements(GL_TRIANGLES, 36, GL_UNSIGNED_SHORT, index);

Otro problemilla más, esta vez en los inidices:
No deberias tener indices negativos!!!!!!
Deberian ser unsigned, y todos desde 0!!!

Y por ultimo parece que el ultimo float de vertices es 0, y no parece haber ningun otro punto en z = 0, lo cual es un poco extraño.

Espero habe sido de ayuda al final  ^_^'

El gDebugger que tengo yo es como una especie de Trial de un año.
Creo que no me dejaba depurar las aplicaciones que compilaba con el "emulador" de Imagination(PowerVR).

Pero mi sdk compila con OpenGl normal (basciamente un subset y cuato extensiones) o con el ES del emulador, asi que lo utilizo solo cuando compilo con OGL "normal".

Si lo tienes en linux no te costaria mucho hacer algo parecido con el OGL/X11 supongo.

un saludo.

[* Calcular normales al vueldo:]

* Calcular normales al vueldo:
Las normales se pueden modificar desde el editor por una razon. Los grafistas pueden "jugar" con ellas. Por eso no tiene por que existir una normal "perfecta", hay una normal "por defecto", pero la idea es que se pueda poner la normal que se quiera (siempre normalizada, claro).
Al menos eso es lo que yo tenia entendido, por eso exporto las normales.

* Exportador:
Exportar a tu propio formato directamente desde el el paquete de modelado no lo recomiendo por varias razones.

Complicado o no depende de como lo hagas:
- En Maya/Max lo puedes hacer en c++, como un plug-in utilizando el sdk de cada uno.
- En maya ademas puedes hacer un plug-in en python.
- En max ademas con maxScript puede acceder a la informacion de todos los vertices.
- En blender ni idea, pero supongo que "python rules".

Problemas que veo al exportar desde el modelador, que no tienes al leer un FBX/Collada:
- Un exportador por paquete de modelado.
- Diferentes SDKs/lenguajes para cada paquete.
- Seguramente tendras que triangular (aunque generalmente hay un comando en todos los paquetes para hacerlo)


Mi posición:
Sigo pensando que lo más rapido para ver resultados es convertir desde FBX o Collada. Y si en un futuro quieres saltarte el paso de exportar a collada desde el programa de modelado, lee directamente el binario .max o .mb.
Otra solución para saltarte la exportacion es uitlizar scripts de maya o max e invocar estos progrmas para que exporten a tu formato intermedio, como hace Unity3d.

Pienso que es mucho más comodo procesar las mayas y convertirlas a tu formato desde una aplicacion de consola que desde un "exportador".
Las razones principales son que no necesitas el programa de modelado en la maquina que esta compilando los "assets" o "recursos".
Y que lo puedes poner en un server a modo de "farm", comprobando cuando hay subidos cambios en el content repository, y de ahi vas compilando los recursos que hagan falta.
Y demás tonterias que se me ocurren.

Pero igual la que te importa es que creo que acabarias antes:
1) instalandote un exportador de collada en tu programa de modelado
2) bajando el Horde3d
3) cogiendo la aplicacion "colladaConverter" de Horde y modificando el metodo "exportGeometry" de la clase converter para exportar a tu propio formato
4) aprovechando el tiempo que te has ahorrado para hacerte una cerveza con tus amigos :)

Además creo que si te lo montas bien puedes hacer tu exportador cada vez menos dependiente del ColladaConverter de Horde, y acabar con una libreria de exportación propia (pasito a pasito claro).

Un saludo

[EDIT]
No habia visto el EDIT de que ya tienes lo de FBX, ups  ^_^'

El ASCII de FBX viene bien para ver el contenido. Pero quizás te interese utilizar el SDK de FBX que hay en la pagina de Autodesk.
Hay que aprender, pero te puede ahorrar esfuerzo, y ademas podras leer FBX binarios tambien :)

Creo que nadie calcula las normales "al vuelo" al cargar el modelo.
Si quieres "compresion" al menos guarda las coordenadas polares.

Por lo que veo tardarias menos utilizando un formato binario propio.
Nada complicado. Una cabecera con el tipo de datos (tipo de vertices, tipo de indices, attributos de los vertices), el tamaño de los buffers(vertices e indices).

Con un par de structs y un par de funciones lo tienes.

El exportador es otra cosa. Si no quieres hacerte uno propio exporta desde el paquete de modelado a Collada o FBX. Luego con una aplicacion de linea de comandos lo conviertes a tu formato. Existe open collada y el sdk de fbx para facilitarte la vida (aunque a veces parece en que te la hacen imposible). Tambien puedes mirar el source de Horde3d, el "ColladaConverter" tiene su propio "lector de Collada", es bastante "lightweight" y es OpenSource.

Como ultima opcion (que suele ser la bomba), es crearte tu exportador que lea directamente de los archivo Maya o 3dsmax. Pero eso es ya mas curro, y Collada y FBX los puedes exportar desde practicamente cualquier paquete de modelado.


Como ultima opcion (que a mi no me agrada demasiado) esta el formato .x (si es que aun existe) de DX.
Y seguro que alguno más habrá por ahi.


Espero haber sido de alguna ayuda. :)

No se, me tiene intigrao... encima Dell los patrocina.

El tipet (CEO de la empresa) se llama Dell de apellido.
Nada que ver con que los patrocine Dell.

Cada vez preguntas una cosa, yo creo que no lo tienes claro, pero weno ...

Suponemos que tienes un struct de este tipo:

Código [Seleccionar] Expand


struct Rect
{
    int x;
    int y;
    int w;
    int h;
}:

Y suponiendo que el eje de coordenadas esta ariba a la izquierda:
El algoritmo para calcular la interseccion:

Código [Seleccionar] Expand


bool TamanyoInterseccion(const Rect &a, const Rect &b, int &w, int &h)
{
    int maxL = (a.x > b.x) ? a.x : b.x;
    int minR = ( (a.x+a.w) < (b.x+b.w) ) ? (a.x+a.w) :  (b.x+b.w);

    int maxT = (a.y > b.y) ? a.y : b.y;
    int minB = ( (a.y+a.h) < ( b.y+b.h) ) ? (a.y+a.h) : (b.y+b.h);

    w = minR - maxL;
    h = minB - maxT;

    return (w > 0 && h > 0);
}


Si w y h "vuelven" negativases que no hay interseccion.

Era eso lo que querias??


EDIT: de todas formas sigo pensando que no te servirá ...
Necesitas que entre en juego la velocidad del personaje, y tratar de forma distinta las colisiones con el escenario y con los enemigos, como se te ha ido repitiendo todo el rato.

Emmm... si quieres desarrollar para Nintendo, te vas a su web de desarrolladores y rellenas un bonito formulario en inglés, donde te pedirán información de la empresa (si no tienes empresa, olvídate). Si aceptan tu solicitud, podrás comprar sus kits y te darán acceso a la cuenta. ...

Coincidirás conmigo Mars, en que la "educacion" de desarrolladores para consolas es un problema. Ya que como bien has dicho, tienes que ser empresa para que se te licencie como desarrollador oficial y poder acceder a los kits, compiladores y documentación.
Además se suele exigir tener desarrolladores con experiencia en la industria para obtener dicha licencia, y si es una empresa pequeña, suele ser la pescadilla que se muerde la cola.

Además las restricciones respecto a la difusion (o que salga algo del estudio) en cuanto a kits, documentacion, etc es muy rigurosa, y altamente penada.

En conclusión poder contratar a desarrolladores con experiencia en estas es muy, muy dificil.

Yo personalmente he tenido problemas serios con gente inexperta, que se "emperran" en no seguir las politicas de gestion de memoria, o adaptarse a las limitaciones de cada dispositivo, quejandose continuamente: "Pues vaya mierda de consola!".

Y cuanto más avanza la tecnologia (con los nuevos procesadores de varios nucleos, y los procesadores matriciales), más tiempo de formación se necesita.

Por eso yo a veces confio en que la "desventaja" para las ventas de los custom firmwares y las "modificaciones" de consolas que permiten cargar homebrew, puede formar a gente en dispositivos tan cerrados.
Al menos fue mi caso, que me formé "minimamente" en algunas consolas (GBA,NDS,PSP,...) mediante el hombrew, antes de comenzar a trabajar con el kit oficial. Aunque reconozco, que siempre es más "comodo" trabajar con el oficial, y los devkits te suelen facilitar mucho la vida.

Por desgracia, como he dicho antes, cada vez menos gente de las "scenes" de las consolas intereasada en aprender a programar, y muchos más chavalines "pirateando" la consola, y haciendo más loaders (como si no hubieran suficientes!)


Aun asi, siempre que sea para aprender, el Homebrew, me sigue pareciendo un buen punto de arranque. Nunca para acabar un juego comercial, pero si para formarte.

Un saludo.


EDIT:
Como tambien dije en la reunion de Empresas que organizo Nae el año pasado en el Esat, creo que es necesario, al menos en estas academias o en escuelas de algun tipo, se adquieran licencias de educacion (que haberlas, las hay) para poder formar a la gente (además de tener profesores con experiencia en la industria).
Pero yo siempre he sido de los que le tiran más horas en casa ;)

La libreria e informacion aqui: http://kennethxu.blogspot.com/2009/05/strong-typed-high-performance_18.html

He estado investigando los links y hay info muy curiosa para emitir codigo IL.
No lo voy a utilizar para la llamada al metodo del "grandparent", pero ya tengo en mente alguna aplicacion para esto  :D

Gracias blau  ;)

Me parece que tienes que mirar en la seccion de loover:
http://www.stratos-ad.com/forums/index.php?board=40.0

En mi opinion (y esperemos que nadie me lo tenga en cuenta  ^_^'), el Homebrew (o XNA, o Net Yaroze en su epoca) es un gran punto de partida si lo que quieres es hacer es conocer las consola.

Depende mucho de lo animados que esten los "hackers" que modifiquen la toolchain(gcc generalmente) de compilacion, a facilitar el desarrollo "extraoficial", y no simplemente a crear un loader para piratear juegos (ultimamente me llevo mas decepciones con esto :( )
La "scene" que hay detras de cada dispositivo determina generalmente la cantidad de herramientas de "depuracion", etc que hay disponibles. En ocasiones (y seguramente debido a filtraciones de informacion) los SDK no oficiales, incluso ponen nombres muy pareciados a las funciones del SDK oficial, con lo que luego pasar a compilar con un SDK oficial puede no ser tan tedioso.
Hay un ejemplo que recuerde (al menos) de un juego de naves, que se programo con el SDK no oficial de la PSP, y luego salio como juego comercial de la misma consola.

Tambien creo (sobretodo en epocas de recruitment) que a la hora de encontrar gente para un proyecto que sepa programar, puedes encontrar, pero gente que este acostumbrada a las "limitaciones" de las consolas es mas dificil. Con lo que tienes que asumir un tiempo de formacion extra y esperar que se adapte, porque hay gente que es muy cabezona (y yo reconozco ser el primero  0:-) )


Pero por otra parte, comprendo enormente las reticencias de las compañias creadoras de las consolas a exponer publicamente muchos datos de las mismas, más con los ultimos "hackeos" que realmente estan perjudicando gravemente sus intereses, y de rebote a otras que se dedican a desarrollar, y a cruzar los dedos cuando sale la gold.


Asi que estoy entre dos vertientes que me afectan de manera "mas o menos" directa.
Pero mi consejo es que si quieres conocer las consolas tires de informacion de GDCs y informacion publica de Sony, Nintendo, o Microsoft.
Si quieres compilar y probar algo, deberas conseguir una consola que pueda cargar hombrew, y el sdk no oficial.
Pero: NO MAS LOADERS, POR FAVOR!!!


Un saludo.

El problema que tengo es que, con el código que tengo ahora, con el ejemplo anterior me indica que hay colisión por dos lados [abajo y derecha], pero me interesa saber el amaño del rectángulo que se crea ya que, si la X es mayor que la Y, quiere decir que la colisión es por abajo. No sé, es que más creo que ya no puedo explicarme :/

Yo creo que te entiendo, si sabes que el personaje colisiona por abajo con el enemigo es que lo estas pisando.
El codigo que te he puesto SOLO DEBE FUNCIONAR con los rects del escenario (que dices que son mas grandes que el rect dle personaje), si los enemigos son mas pequeños que el player no tiene porque funcionar.

Como te he dicho antes:

En cuanto a las colisiones entre "sprites" (personaje, enemigos, items, oloquequieras) no entiendo para que quieres saber la direccion.
Si lo que quieres es saber si estas pisando a un enemigo rollo salto mario es facil (suponiendo que el eje de coordenadas este en el borde superior izquierdo):
personaje.y < enemigo.y && personaje.isJump

Con lo que el rollo seria para la colision de personaje y enemigo:

Código [Seleccionar] Expand

if (HayColision(player.rect, enemigo.rect)
{
    if (personaje.rect.bottom < enemigo.rect.bottom && personaje.isJump && personaje.vel.y > 0) //por ejemplo
    {
        // Pisas enemigo: algo parecido a enemigo.Kill()
    }
    else
    {
        // El enemigo te mata:  personaje.Die()
    }
}
Como he dicho antes suponiendo el eje de coordenadas en el borde superior izquierdo de la pantalla

La comprobaciones pueden variar dependiendo del resto de la implementacion, si no tienes velocidad puedes hacer:

Código [Seleccionar] Expand

if (personaje.rect.bottom < (enemigo.rect.top + (enemigo.rect.w/2)) )...
o simplemente (mi preferida)

Código [Seleccionar] Expand

if (personaje.rect.bottom < enemigo.rect.bottom)...
O cosas asi, el rollo es que tu decides que condiciones quieres para que "mario" mate o, "pise" al enemigo. Por supuesto debes comprobar las excepciones que se pueden dar, y ver si te interesa que pase en esa situacion, pero yo me decanto por una comprobacion sencilla.
Es el tipo de comprobacion que he visto y mas tarde implementado en todos los plataformas 2D en los que he participado (que tampoco son mas de 2, pero bueno han funcionado bien).
Ademas este "tipo de comprobacion" tambien se encontrba en alguno de los plataformas de estos que hacia Hammer Tech. como demos del DIV, en auqella maravillosa epoca donde el 2D "dominaba el mundo"  0:-)
Y la verdad es que funcionaba ...


Bueno, espero haberte ayudado, pero en mi opinion estas intentando hacer algo un poco extraño con las intersecciones, que igual te pueden ofrecer menos informacion de la que necesitas para desarrollar tus ideas, pero weno...

Un saludo