#419 Buah, pues según ese benchmark la diferencia es sustancial. Lo que no entiendo el porque xdd
#420 lo se, pero es para dar un ejemplo xD
#421 sustancial, igualmente 10k++ de bunnys no son "sustanciales". si lo comparas con c# comparalo con c++ y lloras
GDScript (Release) 18560
C#/Mono 27555
GDScript (Release) 20540
C#/Mono 36720
GDScript (Release) 17639
C#/Mono 37455llamame loco, pero de sustancial poco.
#422 Con sustancial me refería a que es una diferencia notable. Y me refería a la diferencia entre GDScript y C# Ya si nos vamos a C++ es que dobla el rendimiento de GDScript.
Pero sigo sin entender el porque :S
EDIT: Me he ido a stackoverflow academy y he encontrado esto: https://stackoverflow.com/questions/29903320/why-is-my-computation-so-much-faster-in-c-sharp-than-python
Que tal vez aplica a mi duda sobre rendimiento entre Mono C# y GDscript
#423 El rendimiento se te va cuando el código ha de ser interpretado, ejecutado por una VM o código que "corre por si solo".
A nivel de rendimiento, un código interpretado (gdscript, python, etc...) es de lo más lento. Luego tienes códigos que corren en diferentes VMs, como por ejemplo java o C# (un mismo source de java o C# podría ser multiplataforma si se ejecuta en otra VM). Y finalmente tienes código que tras ser compilado, sus instrucciones son ejecutadas por la CPU, sin intervención de eun intérprete o VM. Por ejemplo ASM, C, C++, etc...
Una instrucción en python tiene que ser interpretada por la VM y luego traducida a instrucciones que la propia CPU pueda ejecutar. Eso es lento de cojones.
Un código en C se compila y sus instrucciones pueden ser ejecutadas por la CPU directamente (no es exactamente así, pero no quiero enrollarme mucho...). Eso es rápido de cojones.
A más bajo nivel, más eficiencia obtienes. Por eso la peña puede hacer demos de 90kb en ASM y generar un videojuego en 3d, con multiples texturas y sonidos.
#424 Si, lo de que a más bajo nivel mejor rendimiento es de cajón. Mi duda era entre GDScript y C# y por lo visto según he leído en el link que he puesto arriba es por lo del Just in Time compiler.
#427 https://godotengine.org/article/dlscript-here
Me lo miraré por los loles. Pero es que me gusta tanto python a nivel de sintaxis que por el momento no me planteo cambiar.
Y menos si hacemos (al menos yo) juegos de mierda que podrían correr igual de bien bajo una macro dentro de un Powerpoint xd.
Por si alguno no está en el grupo de Godot, está ya la alpha 3, https://godotengine.org/article/dev-snapshot-godot-3-2-alpha-3
¿qué estructura de directorio usáis?
En la GodotCon propusieron la siguiente, pero me parece poco específica y poco ordenada:
root
--_ assets
-----_ art
-----_ fonts
--_ src
-----_ autoload
-----_ hud
--_ todo lo demás
pensando en mejorarla, pero nunca sé si colocar escena + script juntos, o los scripts en otra parte... quizás necesito consejo
¿separais escenas de scripts? ¿directorios para items, enemigos, edificios...?
#435 A mí me mola incrustar los scripts en las escenas pero con eso olvídate de herencia 
En cuanto a cómo suelo organizarlo, depende, pero suele ser algo tipo lo que has puesto pero separando también mapas
#435 yo siempre pongo los scripts en la carpeta scripts, las escenas en la carpeta scenes, y en assets los assets xD
Tengo una scene Player me gustaría hacer dos jugadores cambiando el color de la camiseta, se me ocurren dos opciones:
- Hago una variable tipo (left o right) depende de para donde mire y en base a condicionales le digo si mira a un lado o a otro, si usa unas teclas u otras y si usa una animación con la ropa de un color u otro.
- Hago dos clases Player diferentes con las cosas que comentaba antes.
#439 Yo lo que haría sería un mismo Player y hacer animaciones diferentes. Si usas un spritesheet, con un animation player podrías usar animaciones diferentes e incluso dándole un valor de este es el player tal o cual, usar diferentes input del teclado
#440 Al final lo hago con valores fijos pudiendo seleccionarlos desde el panel del elemento:
export(String, "right", "left") var type
func _ready():
$AnimatedSprite.animation = typeEs más. pensandolo ahora según escribo esto creo que lo haré con constantes.
Edit: meh, no admite variables en el export range
A ver si me podeis echar un cable porque me he atascado con una cosa.
Tengo una serie de CollisionShape para suelo, techo y paredes.
Además al hacer click en un botón mando una señal para instanciar una Ball, depende del turno que sea en una posición u otra.
¿Como puedo detectar que colisiona con el suelo? Con el resto de elementos me da igual.
#443 Tus players son kinematic, no? ¿Cómo los mueves?
Edit:
Si es con move and slide usa esto:
int get_slide_count ( ) const
KinematicCollision get_slide_collision ( int slide_idx )
Si es con move and collide usa lo que te devuelve la función, creo que le tienes que hacer un get_collider()
#445 para que muestras el player?
Si lo que quieres es que un kinematic detecte el suelo, existe la funcion is_on_floor()
#445 Vale, con get_slide_count te da el número de colisiones. Iteras sobre las colisiones que haya, que bien pueden ser 0, y miras a ver si es el objeto que te interesa y haces lo que quieras con él. Una forma fácil de separar funcionalidades es usando grupos. Por ejemplo, en _ready de la pelota le dices:
add_to_group("pelota")
Y cuando estás viendo las colisiones compruebas si está en el grupo pelota y si no pues no haces nada 
¿Como puedo detectar que colisiona con el suelo?
Ay lmao, creía que querías comprobar cuando pega a la pelota!!!
#449 Hmmmm, los rigids tienen una propiedad para decir cuántas colisiones a la vez puedes detectar. Está en el editor, igual la tienes a 0, que creo que por defecto está a 0. No significa que no colisione, pero no hace el trigger del evento.
