Mensajes

mmm, porque tiene que ser fake...
Puede ser real, ya todo puede pasar en estos tiempos.

Es verdad tampoco es una imagen tan rara, peores se han visto en el campo, si estuvieran en pelotas manoseandose las partes sería más sospechosa de ser fake, o mejor dicho fucke(quiero decir, ya de ponerse con el photoshop pos haces algo más escandaloso, no?)

OpenGL es el estándar 3d usado en casi todo, luego también tienes el Direct3D pero sólo en Windows. OpenGL es multiplataforma y está a la última de las capacidades gráficas. Tutoriales? hay muchos, luego tienes los libros de colores.
Mira este, que además te adentra en motores más complejos(opengl sólo se dedica de dibujar cosas en 3D, raramente se necesita sólo eso, luego tienes motores basados en opengl con funciones más complejas de uso común y orientados a objetos por ejemplo):
http://black-byte.com/tutoriales/

Es un saludo esquimal... entre amigos... sólo que lo que se frotan no son las puntas de las narices... son las puntas de....

OpenGL?

desde que existe el foro creo que sólo han salido groovy, scala y go

clojure tiene gancho y también es para jvm

No se puede determinar, tiene que venir indicado, sólo puedes deducir cual es su base mínima(la del mayor dígito-1)

No entendéis, el problema no es juntar 2 imágenes, sino encajarlas como si fuera un puzzle. Juntarlas es demasiado fácil. El caso es ir comparando bordes para ver por donde continúa, ejemplo:
foto1             foto 2
++++++1    0######
++++++2    1######
++++++3    2######
fotos unidas
++++++1######
++++++2######
El problema es que en una foto no se puede comparar exactamente, porque aunque sea digital viene del mundo analógico. Necesitarás algo así como una función de cercanía.

Tienes algunas cosas mal en f_palindroma(el resto no lo he analizado mucho):
= no compara, asigna
2 bucles anidados? mirar si una palabra es palíndroma se hace en una pasada, o 2, pero no en n^2
comprobar si algo es palíndromo depende de que muchas comprobaciones se cumplan, no? tu sólo te quedas con la última(asignas a flag true o false, en vez de componer un resultado basado en todas las comparaciones)
y si ya tienes size para que chequeas fin de cadena('\0')? no hace falta
Otro consejo, ya lo comenté antes a otro, pero *(puntero+entero) == puntero[entero]
Solución:
Teniendo la longitud de la cadena es muy fácil, sólo tienes que comparar la mitad de la palabra, o sea, divides la palabra en 2 trozos y comparas el uno con el otro sólo que uno ascendente y el otro descendente.

Código (c) [Seleccionar] Expandir


for(p=cadena, q=cadena+size-1;p<=q;p++,q--)
      if(*p != *q )
            return 0;
return 1;

Básicamente es un flag = flag && *p == *q, lo que pasa que hago cortocircuito para acabar primero(en una conjunción con que uno sea falso anula toda la fórmula). Si te fijas un puntero va de principio a fin y el otro al revés
Creo que eso debería de funcionarte, o sino está muy cerca

Puedes seguir usándolo, pero ten en cuenta que en C++ cambia principalmente eso. Aunque es más una ayuda sobretodo para una principiante. (Aunque los cast implícitos siguen ahí)
Creo que de MinGW hay una versión portable, incluye el compilador de gcc para windows

chicos y si en lugar de un float mi vector es de letras es decir un char?
seria asi?
char *cad=(char *)(malloc(sizeof(char)*longi));
en resumen siempre se sigue la misma estructura en malloc? no tiene nada que ver que mi longi sea de tipo int no?

Sí, siempre es así x = <cast al puntero del tipo>malloc(sizeof(tipo) * <numero elementos>)
Es porque malloc es genérico: devuelve void * y reserva bytes por eso necesitamos saber cuantos bytes ocupa nuestro tipo y multiplicarlo
El free se hace sin nada especial

He leído que en C no es necesario convertir un "void *" al tipo correcto.

Por lo que me extraña de tu compilador.

¿Qué compilador usas?

En C++ creo que sí es obligatorio, pues tiene chequeo más fuerte de tipos(en tiempo de compilación)