Test de mi gameEngine en C++

[Hokuto7]

Entonces si que habia problemas con el letMeAlone().

He estado probando una segunda forma de hacer un constructor y por las pruebas que he hecho me han resultado satisfactorias y tambien he probado el quitar los corchetes a los "case" y funciona bien,te pongo una clase con estas cosas haber que te parece.
[Codebox=cpp file=Untitled.cpp]
class Objeto: public sprite{
private:
int estado = 0;
public:
//constructor
Objeto(float posicionX,float posicionY){
this->x = posicionX;
this->y = posicionY;
}
//frame
void frame(){
switch(estado){
case 0:
graph = imagen[0];
visible = true;
//x = 320;
//y = 32;
estado = 10;
break;
case 10:
if(key(KEY_C)){
letMeAlone();
}
break;

}//fin switch estado de clase objeto

}//fin frame de clase objeto

};//fin clase objeto
[/Codebox]

Tengo que probar una tercera forma que no me gusta mucho porque hay que crearlo fuera de la clase pero lo probare solo por curiosidad.

[erkosone]

Si tio, hay muchas formas de hacerlo jeje, es lo bueno de este lenguaje, es bastante versatil pero es un poco feo de escribir en general..

Bueno, actualizada la libreria, procedo a montar un nuevo tutorial sobre animaciones y señales.. y el siguiente ya un juego, así aprobecho y documento el tema de signal() y letMeAlone() que no veas el jaleo que tiene jeje...
Pero ya funciona bien desde un proceso protegido, desde un proceso desprotegido y desde el main.. en todos los casos respetando el funcionamiento principal de dejar vivo al proceso que lo llama y si se llama desde el codigo principal los mata a todos.

También funciona el que si llamas a letMeAlone() desde un proceso como "disparo()" pues para ese frame se va a ejecutar tantas veces como "disparos" hayan.. y eso esta mal.. solo deberia ejecutarse una vez por frame por que si no matará a todos los procesos siempre.. ya que es llamado desde todos ellos y es que llamado desde A mataria a B, pero luego llamado desde B mataria también a A.. así que ya funciona todo correctamente.. tenia mas miga de lo que yo pensaba.. esto en java es super facil.. en C++ es una locura XD..

La descarga del entorno actualizado ya esta disponible
En nada cuelgo el nuevo tutorial..

[Hokuto7]

No veo la descarga del entorno actualizada,ponla en la pagina principal donde cuelgas los videos para tenerlo mas claro y tambien le podrias poner distintos numeros para saber que la vas actualizando.

Tengo una pregunta por curiosidad,he visto que hay un fork de raylib para lua y otro para go.Si tu quisieras hacer una libreria de gamelibzero en c# para raylib,tendrias que hacer primero un fork en c# de raylib o podrias hacer la libreria de c# para la version de c directamente,es solo por curiosidad.

[erkosone]

nunca me ha gustado C#, no tengo idea.. se que C# es un lenguaje que da muchisimos problemas de portabilidad, lo usan conocidos mios en el trabajo y me dicen que es horrible, nunca he trabajado con c# la verdad..

[CicTec]

nunca me ha gustado C#, no tengo idea.. se que C# es un lenguaje que da muchisimos problemas de portabilidad, lo usan conocidos mios en el trabajo y me dicen que es horrible, nunca he trabajado con c# la verdad..

La portabilidad es horrible porque C# es un lenguaje creado por Microsoft por su framework .NET y como todos los productos de Microsoft la portabilidad es nula o casi.

Aunque hoy en dia es un lenguaje standardizado, se trata de un languaje managed, el codigo es compilado en una forma intermedia y ejecutado por el CRL que es el Runtime Environment, practicamente es una maquina virtual que ejecuta el codigo interpretado o lo traduce en nativo en runtime con un compilador JIT, lo cual requiere que la maquina de destino tenga una implementacion del CRL para ejecutar un programa C#, ademas de este hay el framework .NET que es una coleccion enorme de librerias y portarla a otra plataforma (SO) es muy costosa, ademas su espacio requerido en el disco es muy grande y el program, siendo managed aunque tenga compilacion nativa en runtime es mas lenta y ocupa mas memoria de un programa C o C++.

C# es util para la creacion de programas complejos porque es mas facil respecto a C++, pero para trabajar a bajo nivel (construccion de engines) C y C++ son un "must be".

[erkosone]

Pues mira.. no sabia exactamente por que me decian que era tan doloroso el port de aplicaciones entre sistemas y ahora ya lo se, gracias por la info CicTec.
Que es de microsoft lo sabia, pero que era similar a java no tenia idea.

[erkosone]

Actualizado con un nuevo video explicando como realizar animaciones, y el uso de señales como letMeAlone() y signal();

La descarga esta actualizada al inicio del post, con el entorno y la libreria actualizados

[Hokuto7]

Ya he visto el video y me ha gustado mucho,esta muy bien explicado y paso a paso.

Ahora comentar un par de cosas,he realizado algunas pruebas complementarias para ver si todo esta correcto.No he podido utilizar el signal() en una clase para matar a otro objeto,esto es lo que me dice.
[Codebox=cpp file=Untitled.cpp]
error: 'objeto' was not declared in this scope
[/Codebox]
Esta claro que no detecta la variable de la clase,me tiene que decir como hacer esto.

Ahora te comento algo que no te va a gustar,en el void draw() tienes el letMeAlone() y funciona bien pero si utilizas dos signal() para matar a los dos objetos el programa me peta.
[Codebox=cpp file=Untitled.cpp]
if(key(KEY_V)){
signal(objeto1,s_kill);
signal(objeto2,s_kill);
}
[/Codebox]

Resumiendo,letMeAlone()-> perfecto,un signal()-> perfecto,dos signal()-> hasta luegos lucas.

[erkosone]

Gracias por las pruebas Hokuto, lo reviso en cuanto tenga un ratito, merci por probarlo.
El siguiente video es ya un juego de naves jeje.. te gustara

[erkosone]

Arreglado, voy a verificarlo mas profundamente pero ya esta arreglado y bastante mas eficientemente que antes.. ha megorado mucho el rendimiento de las señales..

Antes lo que hacia en signal() internamente era recorrer el array de sprites/procesos y al localizar al sprite en cuestión y matarlo.. esto me provocaba un error en el iterador supongo que por no utilizarlo yo correctamente.. bueno es igual.. el caso es que ahora signal() solo marca al sprite en concreto y luego se hace una pasada de sprites al final del frame para eliminar de una pasada a todos los marcados.. con esto me ahorro todas las pasadas independientes al array de sprites..
Mejorando así el rendimiento de la eliminación de procesos/sprites..

Ahora al letMeAlone() voy a hacerle lo mismo marcandolos todos.. y despues de probarlo a fondo publico el nuevo update

Con este cambio ahora llamar a signal() apenas tiene impacto en el rendimiento por muchos sprites que esten coexistiendo en el programa