Si quieres tener precalculados los vectores normalizados, y no tener que ir haciendo senos y cosenos sobe la marcha (aunque muchos procesadores ya guardan tablas precalculas de sin, cos), si que puedes utilizar unos angulos fijos.

Si quieres hacerlo más genérico, es dividir

Código [Seleccionar] Expand

base_rot = 2*PI / num_frags.
Luego

Código [Seleccionar] Expand

angle = base_rot*i + desviacion donde "i" es el numero del fragmento.

La desviación como dices un rango, yo la calcularia con un "random_float(min, max)" o la implementación que tengas echa (si no lo tienes todavia, yo me haria esa función, es muy, muy útil).

Con este angulo yo calcularia un vector normalizado, es decir

Código [Seleccionar] Expand

sinf( angle ), cosf( angle ). Y luego lo multiplicaria (cada componente x e y) por la velocidad inicial, que podrias calcularla como otro "random_float(min, max)".

Con todo esto quedaria un archivo de configuracion más o menos asi:

Código [Seleccionar] Expand


num_frags = 5
min_desv_ang = -0.01
max_desv_ang = +0.01
min_vel_ini = 2.0
max_vel_ini = 3.0
min_rot_ang = -0.05
max_rot_ang = +0.05


Si crees que hay demasiado trabajo de senos y cosenos durante la creación de la explosión puedes mirar de precalcularte los vectores iniciales para un minimo angulo en un array y luego seleccionar el que te convenga. Pero yo no creo que sea necesario.

Un saludo.

EDIT:
Otra cosa que igual veo más complicada, es que si los fragmentos son recortes de la imagen original de la burbuja, si se crean desde el centro del antiguo sprite (burbuja completa), igual la transición te queda un poco "extraña".
Puedes hacer que el "punto central" de los fragmentos esté en la posición relativa donde debiera estar el centro de la burbuja completa. Pero si utilizas este mismo punto como "pivot point" para escalar y rotar, las rotaciones te quedaran un poco raras (es decir, pivotando sobre un punto fuera del mismo sprite).

La otra solución es que apliques las posiciones relativas al centro del sprite completo, al crear los fragmentos. Pero tienes que "saber" (calcularlas en el programa que tengas de edición de imagen o dibujo) esas coordenadas, y aplicarlas a los fragmentos, con lo que se vuelve un poco más complicado el hacer código genérico y reusable.

Yo creo que con aplicar gravedad constante y aplicar las velocidades iniciales (emisor) correctamente ...

cada frame por particula actualizas:

Código [Seleccionar] Expand


vel = vel + acc*dt
pos = pos + vel*dt


más o menos, no?

Algo como lo que puse en este articulo, pero más sencillo y en 2D:
http://typhoeus-sdk.blogspot.com.es/2012/06/problemas-de-memoria-no-lo-se-no-me.html

La única pega que le veo si quieres que los fragmentos tengan rotacion en "profundidad". Si es rotacion 2D pura le puedes poner una pequeña velocidad angular sin aceleracion, y otro parámetro que tienes para modificar.

Al final lo bueno es que puedas cargar los parametros del sistema desde un archivo de configuración para poder recargarlo durante el juego, y ir haciendo pruebas para ver como queda, algo asi como un "editor improvisado" para salir del paso  0:-)

[1 -]

En la PS3 realmente puedes tener una textura o un cualquier otro buffer declarado en main ram, trabajar con ella y utilizar la direccion de mem directamente desde GPU (suponemos utilizar Gcm y no PSGL), sin "casi" latencia añadida (respecto en almacenar el buffer en la VRAM). Incluso puedes hacer "guarradillas" como parchear un shader desde la lógica que tengas implementada en una SPU.

Supongo que si es un avance, tiene sentido que las direcciones de la "RAM unificada" se puedan utilizar desde CPU y GPU indistintamente. Supongo que habrá algún tipo de mecanismo de "lock" de una zona de memoria para que no hayan errores de sincronizacion al escribir datos desde diferentes procesadores a la vez (al estilo como bloqueas por mutex o semaforos o lo que sea en una estrategia de threading típica de CPU).


A mi me choca más:

Single Chip Customer processor/ CPU AMD Jaguar x86-64bit 8 cores / GPU AMD Next Generation Radeon graphics engine capable of 1.84 TFOPS

Falta saber los tamaños de cache para hacer "especulaciones" sobre que cosas van a cambiar a partir del año que viene, pero yo tengo algunas "alocadas predicciones":

1 - Con 8 cores x86 se acaba con el uso del procesador matricial (CELL), y los Helper CPU (SPU en este caso).
Los cores de "Proposito General" se imponen sobre "procesadores especializados" en calculo intensivo. Y esto se queda relegado en exclusiva a la GPU, que en este caso queda integrada dentro del mismo chip.
Estrategia más acorde con los PC actuales, o con consolas como la XBOX, y más fácil de implementar, "portar" y depurar. Pero yo creo que cabe preguntarse hasta que punto se ha podido llegar a explotar la arquitectura CELL.

2 - Para mi sorpresa parece que Mike Acton no acertó en su suposición de que seguramente habria un procesador que ayudara especificamente con las fisicas. Insomniac tendrán que conformarse con tener su sistema de fisicas en CPU de propósito general o procesar alguna cosa con el pedazo de GPU que le han puesto. Parece que lo que insinuaba Acton se cumple, utilizar la GPGPU para fisicas y simulacion en general (seguro que molara para particulas GPU ^^)

3 - La GPU es Radeon. Joder que mareo, hoy NVIDIA, mañana Radeon, hoy GC, mañana HLSL, y sino hazte tu propio compilador de High Level Shaders.

4 - x86 significa menor penalización por branch code (en un principio). Si las caches también aumentan, quizás las "estrategias" de herencia y polimorfismo no penalicen tanto en el performance.
Aun así sigo pensando que las estrategias DOD (Data Oriented Design) seguirán siendo una buena estrategia en general.



En definitiva, parece que será una consola "más fácil" de programar y más parecida a un PC de sobremesa. Decisión que quizás este motivada por la "complicación" extra que presentaba la PS3, y muchos ports de juegos que han dado peor resultado en PS3 que en XBOX360 (aunque la primera sea más "potente", explotar sus caracteristicas requiere mayor conocimientos y más tiempo de desarrollo, normalmente).


Y las tres preguntas al aire por si alguien las quiere recoger:
¿no es esta el área que cubre Microsoft?
¿al final tendremos dos consolas nuevas "practicamente iguales"?
¿esto será bueno o malo ? (para desarrolladores por una parte, por el consumidor por otra)


Un saludo


EDIT: Vale he leido esto en el levante-emv:

Por su parte, la unidad de procesamiento gráfico (GPU) se ha mejorado, principalmente para permitir una utilización más fácil para la computación de propósito general (GPGPU) como la simulación física. La GPU contiene una matriz unificada de 18 unidades de cálculo, que en conjunto generan 1,84 Teraflops de potencia de procesamiento que se pueden aplicar libremente al apartado gráfico, tareas de simulación, o la combinación de los dos.

O sea que retiro lo de que no hay especialización en fisicas, o calculo intensivo, la GPGPU se encargaria de "shadearlo" (por decirlo de alguna manera) todo.

Yo hace mucho que no hago UMLs. Entre otras cosas, porque ahora intento diseñar orientado a datos, antes que orientado a objetos, y UML tira demasiado por el tema objetos.

Aun asi hay tipos de diagramas UML (clases, sequencia, etc) que a veces vienen muy bien para "plasmar" el tipo de interaccion o diseño que quieres para algo concreto. Pero como digo yo lo utilizo muy poco, y para cosas concretas, donde creo que se necesita una explicacion o diseño. Intentar diseñar todo un sistema entero con UML antes de comenzar a implementar nunca me ha dado buenos resultados.

Yo pienso que lo mejor son los free-forms y esquemas en general. Yo los hago con el inkScape, o en papel o el la whiteboard y luego tiro de foto con la camara digital, pero como he dicho antes es una ayuda para algunas cosas, no un "dogma".

Otra cosa que utilizo ahora, es mezclar el diseño, la documentacion y a gestión de tareas en un unico archivo .org (del org-mode de emacs). Esto viene bien en algunos casos. Por ejemplo, lo ultimo que he diseñado/"trackeado"/documentado asi es el "FileServer" para los assets.
El truco aqui es mezclar secciones de diseño (por ejemplo los goals e historias de usuario), con tareas (TODO list) que a su vez contienen algo de diseño y algo de doumentacion. En este caso, como se puede exportar el documento en formato HTML o PDF (entre otros) puedes utilizar el archivo final como documentacion.
Por ejemplo:

Código [Seleccionar] Expand


....

*** Commands [3/5]
**** DONE *quit-server* support
*USAGE:* "quit-server".
This command quits the server application.
This command returns a lson message:
#+begin_src lson
server_cmd_return = {
  isOk = // <bool>: is ok ?
}
#+end_src
...


El html que sale es mas bonito que esto, pero la idea es que sabiendo la documentacion final del usuario puedes hacerte una idea de lo que tienes que hacer y al marcar con (TODO/DONE/etc) puedes llevar el "tracking" de las tareas, con lo que te ahorras tener varios documentos, e informacion duplicada en ellos.
Que org soporte varios tipos de hipervinculos es lo que lo hace perfecto para poder añadir enlaces a las imagenes de los esquemas tambien, con lo que al final en un solo archivo de texto tienes tres documentos, y si lo organizas bien, queda todo bastante claro. Por supuesto, luego puedes separar las secciones, y generar un html solo con la documentacion (por ejemplo). Pero ya es mas trabajo, que es de lo que se trata de ahorrar con esto.

De todas formas, esto viene bien para "herramientas pequeñas separadas".
Estoy pensando en probar a utlizar un org por cada "sprint" que haga del "runtime" del engine.
Creo que puede ser útil para planificar los goals del sprint, juntar algo de documentacion de diseño, y  gestionar las tareas. Aunque en el caso de que la "documentación de usuario" sea sobre la interfaz de una libreria (como es el caso), creo que es mejor hacerla en doxygen directamente.

Un saludo.

Si, exactamente eso.

En el código del emisor de particulas, version C, del link que he puesto, esta implementado con arrays, lista de "elementos a borrar" y "swap-last", por si quieres cogerlo de ahi.

1) Si quieres hacerlo con OOP y stl utiliza un std::vector o un std::list para "sprites" o disparos.
2) Si la lista es de punteros debes crear y borrar los objetos con new y delete.
3) En tu caso la lista podria ser de objetos en vez de punteros ya que solo amacenas posicion y "direccion" (yo no pondria un entero, pero weno)
4) Acerca de OGL: no crees un lista de visualizacion para el ciruclo cada vez que lo dibujes. Precalcula la lista antes con listas precompiladas o, mucho mejor, con vertex buffers, y luego haces un draw call y listo.
5) No deberias actualizar y pintar los objetos en el mismo for NUNCA!!

Aqui lo importante es que machaques libros y ejemplos de C++ hasta que entiendas la diferencia entre "memoria estatica" y dinámica, variables y punteros, stack y heap dinamico.

La idea es que una clase o un struct realmente es una zona de memoria que ocupa, tanto como ocupen los campos de la misma.
Por ejemplo, tu clase disparo tiene 2 floats y 1 int. En el caso (normal) de que el compilador entienda un int como 32bits o 4 bytes (tb puede ser que algunos compiladores para algunas plataformas entiendan el int como 8 bytes), tendriamos 2 * 4 (cada float) + 1 * 4 (cada int) =  12 bytes. Que seria lo que devolveria el codigo: "sizeof(disparo)", te recomiendo que lo pruebes con un simple main tal que asi: "printf("Clase disparo ocupa: %d", sizeof(disparo) );", codigo que deberia escribir en la consola el tamaño de la clase.

Dicho esto entramos en el tema de la OPP. Los structs y las clases, ademas de datos tiene "metodos". Pero estos son simplemente funciones, y la forma de llamarlos depende de una cosa llamada "casting", que es la forma en que el compilador entiende que tipo de objeto esta manejando.
Esto supone en C++, que al final cualquier direccion de memoria se puede tratar como cualquier tipo de objeto, pero el contenido de esa zona de memoria no se conoce y puede encontrarse fuera de los limites de direccionamiento de tu programa, puediendo crear cualquier tipo de comportamiento inesperado. Esto hace de C++ un lenguaje tan "poderoso" como "peligroso".

Un caso especial es el polimorfismo. Una clase con polimorfismo (con metodos virtuales), ademas de los datos que declares en ella, tiene un puntero al principio, que es la direccion de la vtable que contiene las direcciones de memoria de los metodos virtuales de tu clase. Esto implica que una clase con polimorfismo tiene un "pequeño" trozo de información sobre su tipo, que le permite seleccionar en tiempo de ejecucion que funcion se ejecutará sobre el objeto.


Todo esto te puede parecer muy abstracto, pero trata de comprenderlo (sino con mi explicacion con otra que encuentres por ahi), si realmente quieres entrar en "C/C++".


Como he dicho, tu clase disparo es suficientemente pequeña (tipicamente 12 bytes) copiar sus datos no es problema. Asi que puede ser mucho más eficiente tener un array de objetos, en vez de punteros:

Código [Seleccionar] Expand


disparo dis[20];

... y al crear el disparo no hay new, solo copias la info (los dos floats y el int):

Código [Seleccionar] Expand


dis[num_d] = disparo(x,y,dir); // sin el new!!: ahora dis es un array de objetos no punteros

... ahora cambias el update:

Código [Seleccionar] Expand


disparo *d;
d = &(dis[i]); // el "&" es necesario para traducir la direccion de memoria a donde va a apuntar el puntero


... y al borrar el disparo NO tienes que hacer DELETE porque no has echo new (los datos no estan en el heap dinámico, son estaticos).
Pero tu principal problema aqui es que no necesitas el puntero al disparo, necesitas el indice del array.

La solucion es basica, tu metodo de mover NUNCA llama a borrar_disparo!!!!!!
Puedes hacer que devuelva un bool que sea false cuando el objeto deba ser destruido, pero como estas actualizando el array no puedes borrar el objeto dentro del for de actualizar.
Yo suelo hacerme una lista local en la funcion (un array de ints y un entero con el numero de ementos del array) y almacenar los indices del array a borrar. Eliminar los elementos del array se hace en el mismo metodo, pero despues, con otro for. Si utilizas "arrays contiguos" (ya sean con objetos o punteros) deberás mover los datos para rellenar el "hueco" del objeto que quieres eliminar. Lo puedes hacer conservando el orden o no, si no necesitas conservar el orden puedes utilizar la tecnica "swap-last" que es bastante rapida, y solo tienes que mover muy pocoes elementos del array.

Otra opcion si no quieres tener que rehacer el array al borrar, puedes utilizar std::vector o std::list en vez de array de C. Aunque por varias razones (sobretodo de eficiencia) yo prefiero los "arrays de toda la vida", aunque haya que borrar los elementos del array a mano.


Como he dicho, pegale caña a ejemplos de libros y ejercicios aunque no sean exclusivos de juegos, porque no tienes claros muchos conceptos básicos de C.

Un saludo, y suerte.

EDIT: Si quieres ejemplos, en mi firma esta el link a mi blog, y en el articulo que colgue sobre gestión de memoria (que te vendria muy bien leer, aunque creo que es un poco más vanzado para el nivel que tienes ahora), hay un ejemplo sobre un emisor de particulas (muy basico) en version "C++" con std::lists y otra version en "C" con arrays. El código tiene todo esto de lo que he hablado aqui, y esta puesto con licencia MIT asi que lo puedes bajar y utilizar si quieres. http://typhoeus-sdk.blogspot.com.es/2012/06/problemas-de-memoria-no-lo-se-no-me.html

En un "postmortem" que hay por ahi de un final fantasy usaban combinaciones de shaders.

La definición de los shaders en vez de con condicionales lo hacian con custom nodes del Hypershade de Maya. Cada nodo corresponde a un "chunck" de código del shader. Esto es parecido a hacerte un "preprocesador" para los shaders.

El rollo, es que dependiendo de las combinaciones de nodos que habian creado para los materiales se creaban solo los "shaders combinados" necesarios. Además tenian una "cache" con los shaders para reutilizar las combinaciones creadas. Pero al final ponia, que como siempre, mantener la complejidad de la "explosion combinatoria" es la muerte.


La aproximacion en mi SDK tambien es parecida al tema del uber shader. Yo utilizo preprocesado tambien, que ademas permite "compatibilizar" el codigo del shader entre OGL y OGL-ES, por ejemplo.

Yo creo que uno de los dilemas es cuando hacer el preprocesado del codigo del shader:

- Hacerlo durante la carga puede ser bueno o malo. Evita que tengas que tener todo el "texto" creado para los shaders (en OGL-ES hay que tener el codigo del shader en "source", no se puede precompilar nada). Pero hay que hacerlo en C++ porque estas en el engine, y además si tienes el tema de usar STL (std::string por ejemplo) y las reservas dinamicas de memoria, un poco restringido, es un peñazo.

- Si lo haces como un paso de "pregeneracion" de los recursos, lo puede hacer en cualquier lenguaje, como Python, Perl, Lua, etc. que son bastante buenos en esto de preprocesar texto (y lo haces en un pis-pas).

- Si usas un leguaje de script para generar el codigo de los shaders en "pregeneracion de recursos", tambien se puede generar código c++ por ejemplo (para linkar parametros o lo que sea), a partir de las definiciones de los shaders (este tipo de codigo se suele meter en headers). Luego recompilas el "motor" con los nuevos headers, y listo.


No sé, son algunas ideas, el tema este es demasiado amplio.

Un saludo

No sé si has sido tú (no te respondía a tí específicamente), pero he leido frases hablando de los "meseteros", y gente de Madrid, como si todo lo que viniera de allí fuera malo... Amos, si eso no es criticable... Y pretender que eso es culto y plural...

Y si has leido mi segundo post, hablando del video en concreto, no sé como no ves en esos párrafos que yo también lo considero cutre...

En fin.

Como he dicho, ni siquiera te has molestado en leer que y quien a puesto cada cosa.

Has leído por encima, te ha saltado el chip "ya estan los nacionalistas de los cojones dando por culo otra vez", y has salido, como la mayoria de gente, la respuesta típica: "hay pues en mi casa también estamos jodidos y no nos quejamos" ... pues ese es vuestro problema, yo no me meto con nadie sea de la raza que sea, viva donde viva o hable la lengua que hable.

Y como has dicho también lo típico tópico: "la gente dice que los andaluces somos unos vagos". Te responderé con una historia que deberias saber:

Hay pueblo que se llama Marinaleda, donde "los vagos de los andaluces" vivian sin trabajar, solo tres presonas durante apenas tres meses, y el resto del año a pasar hambre y penurias.
Pero un dia, les llamarán lo que les llamarán, tuvieron los c*j*nes de QUEJARSE y pelear por lo suyo.
Actualmente el pueblo de "los vagos de Marinaleda" tiene una cosa que en el resto de España no se conoce: PLENA OCUPACIÓN.
La gente trabaja seis horas y media al dia, y tiene un SALARIO DIGNO: 1.200 Euros al mes. Tiene una VIVIENDA DIGNA: 15 Euros al mes: 90 metros construidos y 100 metros de patio. Y como padres y madres (lo que tiene la plena ocupación) tiene que ir a currar, tienen una guarderia para los niños pequeños que cuesta la astronómica cifra de 13 Euros al mes por chiquillo.


Así que veas que es mejor, si pelear, o no pelear por lo tuyo ... tu verás lo que haces.

Un saludo.

En un par de post me habeis llamado nacionalista, fascista y que incito al odio hacia a otras "regiones", muy bien ... habeis demostrado que o no sabeis leer, o al menos no habeis leido nada de lo que he puesto en ningún post.

Se os hincha la boca al hablar de nacionalismos a la mínima que ois hablar de algo que no es "vuestro", eso en mi pueblo tiene un nombre: "xenofóbia" que para el que no lo entienda es un "pánico extremo a lo diferente".

Seguiré diciendo que esto es una "cutrez" y encima ha ofendido a mogollón de gente (si no no hubiesen retirado la campaña), que la mierda de la formula 1 es un robo, y que hacerles la "bola gorda" a esos tios por sacar cuatro duros sin ningún tipo de "ética" o al menos "vista comercial" es un suícido social.
Que todo ese dinero y todo el que nos han estado estafando durante tantos años pertenece al pueblo, a la gente que se lo ha ganado, la que ha trabajado y ha cotizado, y que es "injusto" que "cuatro enchufados" se dediquen a chupar del bote y a convertirnos en el "hazme-reir". Normal que nadie quiera invertir aqui, esto está lleno de "roba millones de guante blanco", y "listillos pelotas" que se arriman desesperados a ver si les cae limosna del bolsillo.

¿Que os quereis vender? Venderos, pero siempre habrá alguien que os recuerde lo que sois.

Y incito al odio hacia otros, porque como he dicho los responsables de hacer dicha "campaña" son valencianos. Por tanto estoy "atacando a otras regiones", ¿no?


Increible vuestras respuestas, vuestros comentarios, vuestras opiniones, ... pensaba que todavia habia una España culta y plural, pero ya veo que estamos como el 1965.


Un saludo.

Vergüenza de verdad da esto y mira, todo sigue igual:
http://www.lasexta.com/lasextaon/salvados/completos/salvados__cuando_eramos_ricos/508553/1
http://www.lasexta.com/lasextaon/salvados/completos/salvados__cuando_eramos_cultos/591033/1

Tranqui que ya lo vi en su dia y estoy totalmente de acuerdo.

En cuanto a lo de Madrid, yo ya he dicho que no se trata de formentar el odio, ni acusar a nadie, simplemente de exigir respeto.

PS: Por cierto, esto también da mucha vergüenza, http://www.youtube.com/watch?feature=player_embedded&v=mIkZvSihIZM (tranquilos, que hay botón de subtítulos).

el que no sepa aguantar una broma que se vaya del pueblo... joer...

lo siento ... estoy en mi pueblo

¿que has tu la App? pues aguanta y traga todo lo que te tienen que decir los que no estén de acuerdo

Espera, ¿esto ha costado dinero público?

Este en concreto supongo que no (si no cuentas la "fotraca de millons" que nos sablan cada año por la formula 1).

Pero la "empresa en cuestión" que hace estas "maravillas" tiene adjudicaciones públicas por valor de nueve millones y medio de euros.

..., me preocupa mas el no tener trabajo que el hecho de que unos moñas pongan una app que no me dice nada.

Entonces coincidirás conmigo en que adjudicarles 9 millones y medio de euros públicos (de la Generalitat) a estos "cutres" (PubliPS) por decirlo de una manera suave, en vez de estar "potenciando" la industria "profesinal y de verdad" y todo el potencial que tenemos aqui (no nos engañemos, vayamos donde vayamos nos dicen que somos una mafia, que hay muchos "game developers" valencianos, y me refiero a todo el territorio no solo a la "provincia", repartidos por todo el mundo) es como mínimo una "irresponsabilidad".

Yo por mi parte, aunque se me acuse de tirar piedras contra mi propio tejado, quitaria las subvenciones, ayudas, y "fugas" de capital público a empresas, ya que he podido comprobar que todo esto al final se trata de "nepotismo, enchufismo, etc.", y no se hace para nada siguiendo críterios de profesionalidad o proyección.
Nosotros seguiriamos igual de jodidos, pero por lo menos habria dinero para pagar los medicamentos a las farmacias, arreglar el tema de los "barracones" en los colegios, o poner una jodida estufa por aula (ya que la calefacción central se ve que es un privilegio para los colegios privados).


Yo personalmente no me considero gran cosa, pero si 40 veces más "profesional" que estos "parásitos".
Para mi al menos, vosotros también lo sois (profesionales), permitirme la pregunta: ¿cuantos millones os ha dado (a vosotros o a la empresa en la que hayais trabajado) la Generalitat?
A mi ni un puto duro, ni lo quiero tampoco. Pero que no me tomen el pelo por lo menos.

Un saludo.

Hans: no me lo creo, tendrás todo el humor del mundo que quieras, pero no cuela (cuando te enfadas aunque sea por messenger me das miedo :P , por cierto, al final no quisistes ni quedar para hacerte un cortado conmigo y hablar de lo que pasó con "mr. Terrazas", ...)

Eskema: perfecto que no te consideres valenciano también, ... pero por desgracia ...

¿Era ésto? http://www.elmundo.es/elmundo/2012/06/20/valencia/1340186282.html

Si es eso me parece una chorrada retirarlo o criticarlo, es sólo una broma sin importancia. Es como si los vascos nos quejáramos de que nos tachan de bastos en cada esquina.

Si es eso.

A ti te parece una broma porque oirás a mucha gente por València (cápital) hablando en castellano y soltando "Nano, nano, nano" como únicas palabras en valenciano. Pero si a alguien se le ocurriera la barbaridad de cruzarse contigo por la calle y comenzar a decir idioteces como "eskaralakakatua" o alguna cosa que denigrase la lengua própia de tu tierra, le partirias la cara a las primeras de cambio (cosa que me parece normal).

Agur