Archivos de Categoría: Entornos de Desarrollo

Desactivar el Sistema de Control de Versiones en PHPStom

Se puede activar el Sistema de Control de Versiones en PHPStorm desde el menú VCS pero ¿Cómo se desactiva?

PHPStorm VCS

No encontré ninguna opción pero esta es la solución: Eliminar el ficher .idea/vcs.xml y reiniciar PHPStorm.

Ref: How to disable version control in phpstorm?

Usar el Simulador de Xcode con un plug-in para iOS en Unity 3

Como ya se vio en “Crear una applicación Unity 3 con Plugin de código nativo para iOS” podemos crear un plug in the código nativo para iOS en Unity 3. El problema es que por defecto no se pueden probar las llamadas a código nativo en el Simulador de Xcode. Probablemente no tenga mucho sentido probar una aplicación Unity 3 en el simulador ya que el rendimiento 3D puede variar mucho con el del dispositivo real, pero si todavía no tienes un dispositivo iOS puede servirte.

Dentro del proyecto Xcode en el fichero “Libraries/RegisterMonoModules.cpp” se puede ver como las funciones definidas dentro del “extern” están dentro de un bloque que solo se procesa cuando el target NO ES el Simulator (#if !(TARGET_IPHONE_SIMULATOR)). Tenemos que sacar de esos bloques tanto la definición de la función que registra las funciones (mono_dl_register_symbol) como nuestras funciones propiamente dichas. Fijarse en las líneas marcadas en negrita a continuación:

#include "RegisterMonoModules.h"

extern bool gEnableGyroscope;

extern "C"
{
	typedef void* gpointer;
	typedef int gboolean;
#if !(TARGET_IPHONE_SIMULATOR)
	const char*			UnityIPhoneRuntimeVersion = "3.5.0f5";

	extern int 			mono_ficall_flag;
	void				mono_aot_register_module(gpointer *aot_info);
	extern gboolean		mono_aot_only;
	extern gpointer*	mono_aot_module_Assembly_CSharp_firstpass_info; // Assembly-CSharp-firstpass.dll
	extern gpointer*	mono_aot_module_UnityEngine_info; // UnityEngine.dll
	extern gpointer*	mono_aot_module_mscorlib_info; // mscorlib.dll
#endif // !(TARGET_IPHONE_SIMULATOR)
	void				mono_dl_register_symbol (const char* name, void *addr);
	void	_PassStructFromObjCToUnity();
	void	_Test();
}
void RegisterMonoModules()
{
    gEnableGyroscope = false;
#if !(TARGET_IPHONE_SIMULATOR)
	mono_aot_only = true;
	mono_ficall_flag = false;
	mono_aot_register_module(mono_aot_module_Assembly_CSharp_firstpass_info);
	mono_aot_register_module(mono_aot_module_UnityEngine_info);
	mono_aot_register_module(mono_aot_module_mscorlib_info);


#endif // !(TARGET_IPHONE_SIMULATOR)
	mono_dl_register_symbol("_PassStructFromObjCToUnity", (void*)&_PassStructFromObjCToUnity);
	mono_dl_register_symbol("_HaveObjCDoSomething", (void*)&_HaveObjCDoSomething);
}

Podemos modificar el scriptPostprocessBuildPlayer” para no tener que hacer estos cambios a mano cada vez que generemos el proyecto Xcode. Un poco de awk hace la magia (no es muy bonito el código pero funciona…):

#!/bin/bash
cp -fR ./iOS Build/Libraries ~/Documents/Xcode/my-project/
cp -fR ./iOS Build/Data ~/Documents/Xcode/my-project/
rm file.tmp
awk '
{
  if ($0 == "#if !(TARGET_IPHONE_SIMULATOR)" && NR == 9) {
    getline var1;
    getline var2;
    printf "%sn%sn%sn", var2, $0, var1 >> "file.tmp"
  } else if (NR == 32) {
     printf "#endif // !(TARGET_IPHONE_SIMULATOR)" >> "file.tmp"
     printf "n%sn", $0 >> "file.tmp"
  } else if ($0 == "#endif // !(TARGET_IPHONE_SIMULATOR)" && NR > 32) {
  } else {
    print $0 >> "file.tmp"
  }
}' ~/Documents/Xcode/my-project/Libraries/RegisterMonoModules.cpp
mv file.tmp ~/Documents/Xcode/my-project/Libraries/RegisterMonoModules.cpp

Probablemente sea una buena idea desactivar la opción “Dead Code Stripping” del proyecto Xcode (dentro de “Linking” en “Build Settings”) ya que Xcode puede pensar que las funciones definidas como externas no serán nunca llamadas desde Xcode ya que son llamadas desde Unity.

Fuente: http://answers.unity3d.com/questions/49945/gamekit-linker-failure.html?sort=oldest

Crear una aplicación Unity 3 con Plugin de código nativo para iOS

Crear un nuevo proyecto en Unity3D. Ir a “File->Build Settings”, seleccionar la plataforma iOS y luego “Player Settings…”. En “Other Settings” dentro de “Identification” configurar el “Bundle Identifier” por ejemplo con “com.YourCompanyName.YourProductName”

Si no se hace esto dará este error al hacer el “Build”.

NOTA: Si se va a ejecutar en el simulador de Xcode hay que configurar la opción “SDK Version” a una versión de simulador (“iOS Simulator Latest” por ejemplo o la versión de iOS deseada), ya que en caso contrario (si se elige una para dispositivo como por ejemplo “iOS Latest” u otra versión concreta) aparecerán errores acerca de que no están definidas cientos de funciones para la arquitectura i386 al compilar el proyecto de Xcode. Si este paso se hace mal habrá que volver a hacer “Build” en Unity y volver a copiar las carpetas “Libraries” y “Data” a nuestro proyecto Xcode como se va a explicar a continuación.

Una vez configurados el “Bundle Identifier” y la “SDK Version” salvar la escena y el proyecto donde se quiera. Al ejecutar “Build And Run” y se creará un nuevo proyecto de Xcode (llamado “Unity-iPhone”) dentro de la carpeta de nuestro proyecto de Unity con el nombre que nosotros queramos, por ejemplo “iOS Build”. Hay que copiar TODA esa carpeta a otra parte, por ejemplo donde residen tus proyectos de Xcode.

Cuando hagamos algún cambio en nuestro proyecto de Unity y hagamos otra vez “Build” nos pedirá donde guardar el proyecto de Xcode que genera, pero podemos sobreescribir el original (el que se crea dentro de la carpeta de nuestro proyecto Unity) sin problemas. Lo que si habrá que hacer es copiar TODOS los ficheros de las carpetas “Data” y “Libraries” del proyecto Xcode que ha vuelto a crear Unity cuando hace el “Build” a las correspondientes en el proyecto de Xcode que hemos copiado nosotros la primera vez. Se puede usar un script similar a este y ejecutarlo a mano después de hacer “Build”:

#!/bin/bash
cp -Rf ./iOS Build/Data ~/Documents/Xcode/my-project/
cp -Rf ./iOS Build/Libraries ~/Documents/Xcode/my-project/

De todas maneras la mejor opción para conseguir el mismo efecto es crear un script PostprocessBuildPlayer (ojo que el fichero tenga permisos de ejecución) dentro de “Assets/Editor” (por lo que habrá que crear una carpeta llamada Editor dentro de la vista de “Project” y copiar ahí es script) con el mismo contenido que el anterior para que los ficheros se copien automaticamente a nuestro proyecto de Xcode cada vez que hagamos “Build” en Unity. Los scripts PostprocessBuildPlayer pueden ser shell script o Perl script.

Abrir nuestro proyecto de Xcode y cambiar el nombre del fichero “iPhone_target2AppDelegate.m” (puede tener un nombre diferente según la versión de Unity pero la cuestión es hacerlo en el fichero “AppDelegate”, por tanto será cuestión de ver qué fichero tiene al final puesto precisamente “AppDelegate”) a “iPhone_target2AppDelegate.mm” (es decir 2 emes al final en vez de solo 1). Esto sirve para que Xcode lo compile como código Objetive-C++.

En ese fichero justo encima de “@implementation ...” poner lo siguiente:

static iPhone_target2AppDelegate *delegateObject;

Dentro del método “applicationDidFinishLaunching” añadir la siguiente línea que aparece en negrita como primera instrución a ejecutar:

- (void)applicationDidFinishLaunching:(UIApplication *)application {
    delegateObject = self;
    ...
}

Al final del “AppDelegate” (es decir el fichero “iPhone_target2AppDelegate.mm”), pero antes de la claúsula @end, poner el siguiente código que crea 2 métodos que pueden ser llamados desde el exterior. Uno de ellos acepta como parámetro una estructura por referencia a la que se modifican sus valores (los métodos usados para obtener el nuevo valor no están creados ya que solo es un ejemplo) y el otro que sin más ejecuta un método del “AppDelegate” que nosotros debemos crear.

NSString* CreateNSString (const char* string) {
    return [NSString stringWithUTF8String: string ? string : ""];
}

char* MakeStringCopy (const char* string) {
    if (string == NULL) return NULL;
    char* res = (char*)malloc(strlen(string) + 1);
    strcpy(res, string);
    return res;
}

struct MyStruct {
    char* stringValue;
    int intValue;
};

extern "C" {    
    void _PassStructFromObjCToUnity ( struct MyStruct *myStruct ) {
    	NSLog(@"_PassStructFromObjCToUnity");

    	myStruct->stringValue = MakeStringCopy([delegateObject.someStringProperty UTF8String]);
    	myStruct->intValue = [delegateObject.someNSNumberProperty intValue];

    	printf("-> myStruct->stringValue %sn", myStruct->stringValue);
    	printf("-> myStruct->intValue %in", myStruct->intValue);
    	NSLog(@"-> complete.");
    }

    void _HaveObjCDoSomething () {
    	NSLog(@"_HaveObjCDoSomething");
    	[delegateObject doSomething];
    	NSLog(@"-> complete.");
    }	
}

Ahora volvemos a nuestro proyecto de Unity y dentro de una clase C# en Assets/Plugins/ podríamos poner algo similar a esto, que sería quien se encargaría de llamar a nuestros métodos definidos dentro de “extern "C"”.

using UnityEngine;
using System.Runtime.InteropServices;

public struct MyStruct
{
    public string stringValue;
    public int intValue;
}

public class OBJCPlugin 
{
    [DllImport ("__Internal")]
    private static extern void _PassStructFromObjCToUnity ( ref MyStruct myStruct );

    public static MyStruct PassStructFromObjCToUnity ()
    {
    	Debug.Log("OBJCPlugin.PassStructFromObjCToUnity");
    	MyStruct data = new MyStruct();
    	if ( Application.platform == RuntimePlatform.IPhonePlayer )
    	{
    		_PassStructFromObjCToUnity( ref data );
    	}
    	return data;
    }	

    [DllImport ("__Internal")]
    private static extern void _HaveObjCDoSomething ();

    public static void HaveObjCDoSomething ()
    {
    	Debug.Log("OBJCPlugin.HaveObjCDoSomething");
    	if ( Application.platform == RuntimePlatform.IPhonePlayer )
    	{
    		_HaveObjCDoSomething();
    	}
    }
}

Como hemos modificado el proyecto de Unity para que llame a las funciones en código nativo de iOS hay que volver a hacer el “Build” y copiar las carpetas “Libraries” y “Data” a nuestro proyecto Xcode (aunque si hemos creado el script PostprocessBuildPlayer las carpetas se copian automáticamente. De esta manera ya se juntan tanto las llamadas hechas desde C# en Unity como el código nativo escrito en nuestro proyecto Xcode.

Si quieres poder ejecutar este proyecto Xcode en el simulador lee el post “Usar el Simulador de Xcode con un plug-in para iOS en Unity 3“.

Fuentes: http://answers.unity3d.com/questions/10110/specific-steps-to-set-up-a-plugin-for-iphone-in-xc.html
http://www.tinytimgames.com/2010/01/10/the-unityobjective-c-divide/

Usar OpenCV en Eclipse CDT

Instalar OpenCV (ver los post de cómo hacerlo en Ubuntu 10.10, Ubuntu 11.10, Ubuntu 12.04 y OpenCV 2.4 en Ubuntu 12.04).

Instalar Eclipse CDT:

sudo apt-get install eclipse-cdt

Abrir Eclipse CDT y seleccionar un workspace (no es más que una ruta donde poder guardar varios proyectos juntos). Crear un nuevo proyecto “C++ Project”, darle un nombre y seleccionar “Empty Project” para “Project type” y “Linux GCC” para “Toolchains”.

Hacer click con el botón derecho del ratón sobre la carpeta del proyecto y seleccionar “Properties”. Ir a “C/C++ Build->Settings”. Ahí, dentro de la pestaña de “Tool Settings”, ir a “GCC C++ Compiler->Includes” y rellenar la opción “Include paths (-l)” con la ruta donde estén instalados los includes de OpenCV. Si instalaste OpenCV desde el código fuente lo más probable es que la ruta sea “/usr/local/include/opencv2” (o la ruta indicada en CMAKE_INSTALL_PREFIX al configurar con CMake), pero si lo instalaste desde los repositorios la ruta debería ser “/usr/include/opencv2“.

Ahora ir a “GCC C++ Linker->Libraries” y rellenar el campo “Libraries (-l)” con (al menos) estas librerías de OpenCV:

opencv_core
opencv_highgui

La opción “Library search paths (-L)” debe tener la ruta donde se encuentren los binarios de las librerías de OpenCV. Como antes, si instalaste OpenCV desde el código fuente la ruta debería ser “/usr/local/lib” (pasa lo mismo que antes aquí con la opción CMAKE_INSTALL_PREFIX) y si lo instalaste desde los repositorios “/usr/lib“.

Ya es hora de programar un poco. Ir a “File->New->Source file” y crear un nuevo fichero llamada “main.cpp“. Rellenarlo con lo siguiente:

#include "opencv.hpp"

int main(int argc, char* argv[])  {

	IplImage* img = cvCreateImage( cvSize( 640, 480 ), IPL_DEPTH_8U, 3 );

	cvCircle( img, cvPoint( 320, 240 ), 100, cvScalar( 255, 0, 0 ), 5 );

	cvNamedWindow( "OpenCV Window", CV_WINDOW_NORMAL );
	cvShowImage( "OpenCV Window", img );

	cvWaitKey(0);

	cvDestroyWindow( "OpenCV Window" );
	cvReleaseImage( &img );

	return 0;
}

Este código tan solo mostrará una ventana negra con un círculo azul en el centro y esperará a que pulses una tecla para salir. No es demasiado elaborado pero solo queremos comprobar que todo funciona bien.

Eclise CDT viene con la opción de construir automáticamente la aplicación, pero yo siempre lo deshabilito desmarcando “Project->Build Automatically”. Construir la aplicación pulsando Control+B o mediante la opción “Project->Build All”. Antes de debugger/ejecutar nuestra aplicación tenemos que configurar un entorno de debug/ejecución. Ir a “Run->Debug Configurations…” y hacer doble click en “C/C++ Application”. Se creará una configuración de entorno de debug nuevo, pero el parámetro “C/C++ Application” puede que no se rellene automáticamente (al menos a mi me pasó esto), así que haz click en el botón “Browse…” para elegir un “Project”, seleccionar tu proyecto, y ahora (si el binario de tu aplicación existía al haber construido antes correctamente todo) todo debería estar bien y el botón de “Debug” debería poder pulsarse.

Ahora ya tu aplicación debería poder ejecutarse sin problemas. Usar cualquier otra librería dentro de Eclipse CDT es más o menos parecido.