Proyecto a elegir y Organización

[thepoi]

Tiene muy buena pinta, venga ánimo que ya os queda poco. Al proximo proyecto me apunto de cabeza xdd

[lucesita]

pues, seras bienvenido entonces thepoi.

Alex... magnifica la rotacion (no me deteni a leer el codigo ya que Argentina esta cada vez peor ajjaja)

ahora me muero por ver las mod e drincast xD

la pagina... que decir, perfecta, mañana creo que estare probando la version en varias maquinas disferentes.

emm... si, no se que decir hoy estoy ofuscado xD

masomenos, para que se den una idea, el unico bug que me esta ROMPIENDO LAS PELOTAS es que no se corresponde el mapa de colisiones con lo que se ve -.- y no encuentro donde se produce el problema :S

supongamos que tenemos en el area de juego esto
0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,2,2
0,0,0,0,0,0,0,0,2,2
0,0,0,0,0,0,0,0,1,1
0,0,0,0,0,0,0,0,1,1

y en el mapa de colisiones esto es lo que hay exactamente
0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,2,2,0
0,0,0,0,0,0,0,2,2,0
0,0,0,0,0,0,0,0,1,1
0,0,0,0,0,0,0,0,1,1

puse el 2 en vez de uno pa que se disferencie bien pero en realidad van 1 xD

esto sucede cuando una vez que toca la figura con otra, tenemos un tiempo para moverla para <- o -> lo raro es que no siempre pasa :S

y cuando pasa generalmente no se elimina una linea que se completa :S estoy verdaderamente mareado.

y con respecto a que no te gusta la figura I como quedo, estuve jugando otros tetris y el giro que hacen con la figura I masomenos es asi
1,1,1,1
0,0,0,0
0,0,0,0
0,0,0,0

para rotarlo asi...
0,1,0,0
0,1,0,0
0,1,0,0
0,1,0,0

pero ami no me disgusta tanto como esta ahora.

Saludos Lucas, otro dia con mas tiempo pongo algo mas interesante jajajaja.

[Juan Carlos]

Hola, primero, antes que nada, felicidades por haber sacado la version (aunque sea alfa) de LineCube. Aunque el juego sea simple, han logrado lo que muy pocos logran hacer: terminar un proyecto.

Con respecto a los optimizaciones, no entiendo muy bien por que es necesario un array de 200 posiciones para las figuras (principal.cpp). Creo que con dos figuras es suficiente para el juego; una figura que sea "la figura actual" (la que controla el usuario) y otra que sea "la figura siguiente" (la que se muestra en la esquina inferior derecha).

Otra cosa que observe es la gran cantidad de variables globales que son utilizadas. En general, las variables globales traen problemas (y muchos).

Desde un punto de vista conceptual (no desde el punto de vista de la optimizacion). Hay dos factores a mejorar:

Primero, y por citar un ejemplo, la funcion NuevaFigura() (principal.cpp) genera, como es de suponer, una figura nueva y aleatoria. Pero ademas chequea que haya un lugar libre para su colocacion y ademas modifica "la figura actual" y ademas se encarga de hacer todo lo anterior en caso de que sea la primer figura a crear.
El algoritmo funciona bien, pero la funcion esta sobrecargada. Realiza muchas operaciones y esto trae varias desventajas a la hora de depurar y de someter a prueba a la funcion.

Otro caso evidente es la funcion main() (principal.cpp). Aunque suene raro, la funcion main debe ser tratada como una funcion mas, y debe seguir las mismas reglas y evitar sobrecargar a la funcion.

La manera mas simple de descomprimir la sobrecarga es partiendo el problema a resolver en varios subproblemas y resolverlos a estos con funciones mas chicas y especificas (se centran en resolver un problema). La mitica frase "divide y venceras".

Lo anterior mencionado es aplicado tambien a los metodos de las clases e incluso a la clase misma. (El segundo factor a mencionar) Por ejemplo:

Si yo menciono la palabra "televisor" ustedes pensaran en un objeto electronico que permite ver imagenes y escuchar sonidos. Ustedes pueden prender o apagar una television, cambiar de canal o modificar el volumen, etc.
Ahora, tiene sentido pensar que el televisor me dice la temperatura de la habitacion en que se encuentra? La respuesta es no.
Las clases funcionan de igual manera. Por ejemplo:

La clase Figura puede moverse. Eso tiene sentido? Si, por supuesto. La misma clase puede dibujarse, eso tiene sentido? Si (*). Ahora, una figura puede borra una fila de un mapa? Tiene sentido? No

Esto sobrecarga a las clases con metodos que nos les pertenecen y luego dificultan la depuracion.

Es importante aclarar que los algoritmos funcionan bien por lo que, si ustedes desean modificar LineCube, no necesitan reescribir todo. Simplemente se necesita ordenarlo, separando una funcion grande en unas mas chicas y/o redefiniendo a las clases segun el sentido comun.

Un post muy largo y MUY critico. No se enojen conmigo

Saludos

Nota: (*) A un nivel mas abstracto, incluso se busca separar el "objeto que resuelve un problema" del "objeto que lo representa"(una imagen o un sonido). Para los proyectos simples como este, no es necesario ese nivel de abstraccion y es perfectamente legal crea un "objeto que resuelve el problema" y que ademas "se representa asi mismo" con una imagen o sonido.

[Alex_13_estu]

¡Hola! Bueno, esta semana acabo las clases, así que parece que en breve podré dedicarme de nuevo al proyecto con algo más de tiempo del que ahora mismo dispongo. No tengo nada nuevo que decir respecto a actualizaciones, así que me limitaré a comentar los últimos mensajes y, si surje algo, comentarlo también. ¡Ah, sí! He subido una noticia a SF.net que pensaba pegar en la página del proyecto cuando Drincast nos brinde su mini-guía. Echadle un vistazo si teneis tiempo.

Primero de todo, agradecer las felicitaciones de Thepoi e invitarle a que participe en próximos proyectos. Será un honor contar con él. Vamos ya al mensaje de Lucas. Gracias a ti también por las felicitaciones, y gracias también por lo del bug. Era algo que ya había detectado yo hace unos días pero que me había olvidado de comentar. Lo cierto es que no entiendo muy bien por qué pasa lo que dices... Hay que tener mucha precisión y, si lo intentáis, acabaréis consiguiendo lo que tú dices, que es que la figura se dibuje en el mapa de colisiones donde no está. ¿El por qué? Pues no lo sé, si no ya estaría resuelto... Aunque tengo una ligera idea. Si revisáis el archivo "principal.cpp" veréis que lo primero que se hace en el loop en el caso de que el juego esté activo es generar una nueva figura si no la hay. Luego se dibujan los datos en pantalla y luego se realiza el movimiento vertical del mapa. Ojo, este movimiento se realiza antes de comprobar la pulsación de las teclas y de sus consecuencias, lo que, si no me equivoco, hace que la figura se dibuje en el mapa y a continuación se mueva lateralmente por la pulsación de los cursores. Esto da un ciclo del loop después de que la figura se dibuje para moverla en con las flechas. O sea, 20 milisegundos. De ahí que haya que ser bastante preciso para detectar el error. Para corregirlo, supongo que bastaría con comprobar que la figura no se haya dibujado ya en el mapa o, en su defecto, invirtiendo el orden de las funciones (es decir, comprobando antes la pulsación de teclas y haciendo descender a la figura después). Esto es algo que se me ha ocurrido ahora mismo, a bote pronto mientras leía el mensaje, por lo que tendré que implementarlo y comprobar que esté en lo cierto. Se aceptan críticas y correcciones, pero creo que he argumentado bastante bien mi postura. Y en cuanto al giro de la "I"... Creo que por ahora podemos dejarlo como está, si eso en un futuro lo cambiamos y analizamos más detenidamente los pros y los contras.

Voy ahora al mensaje de J. Carlos. Gracias por las felicitaciones a ti también, tenía ganas de conseguir acabar un proyecto porque es algo que motiva mucho y da fuerzas para continuar y, hasta ahora, no lo había logrado. En cuanto a lo del array de 200 figuras, es porque todas las figuras que estén en el mapa se mantienen dentro de este array, se estén o no controlando. Fíjate en que, cuando se dibujan en pantalla, se recorre el array entero, se comprueba que estén activas y se dibujan. Lo del número 200 es, básicamente, porque si tenemos un mapa de 20 X 10 y suponiendo un muy difícil caso de que todas las figuras que hay tengan un sólo bloque (porque los otros se han eliminado), tendremos 200 posiciones bloques en pantalla, uno de cada figura. Aunque creo que sería más correcto poner 201, porque hay que contar con la "siguiente figura". No sé si me he equivocado en algún razonamiento, así que, si lo hice, corrígeme, por favor. Y lo de las variables globales... He de reconocer que soy adicto a ellas, aún a sabiendas de lo peligrosas que son. Trataré de corregirlo y así de paso me voy olvidando de ellas. Lo que sí creo que es interesante dejar como globales son las constantes, ya que, al no ser modificadas, no suponen tanto problema. De nuevo, corrígeme si me equivoco. Y vamos ya con los dos puntos que diste...

Debo decir que no me enojaron, al contrario, me pareció una información interesantísima y muy bien sintetizada y estructurada. Debo darte las gracias por la ayuda que nos prestas. En cuanto a lo de las funciones sobrecargadas, he de decir que tenía pensado reestructurar un poco main(), ya que lo cierto es que actualmente es algo compleja (sobre todo en el caso de que el juego esté activo). Pero lo de las otras funciones no se me había planteado y, repasando un poco, me he dado cuenta de que tienes toda la razón, hay miles de cosas que no se corresponden con el objetivo principal de la función. Creo que trataré también de partir un poco más el código a partir de ahora. Es un vicio como otro cualquiera que tengo, pero, si ves mis programas, observarás que las funciones hacen más cosas de lo que tenían que hacer en principio. Como es un buen momento para cambiar eso, creo que me pondré a ello. Y en el tema de las clases... Debo decirte que no se me planteó reorganizar los métodos, pero, de nuevo, a base de repasar y repasar código, me he dado cuenta de las burradas que hay: funciones que devuelven direcciones de memoria de datos privados que pueden ser fácilmente modificados, funciones que no tienen nada que ver con las características del objeto... En fin, que he roto casi todos los conceptos básicos de POO . Ahora bien, no comparto contigo el ejemplo de borrar filas de un mapa. Si hay que borrar una fila del mapa de una figura, ¿desde dónde quieres hacerlo? Desde mi punto de vista, lo mejor es incluirlo como una función propia dentro de esa figura. Otra cosa distinta es borrar completamente una fila del mapa de colisiones. Eso actualmente se hace desde el propio objeto que es el mapa de colisiones, mediante una función que es la de BorrarFila(). Por lo tanto, desde mi punto de vista ambos métodos son correctos. Acepto tu opinión y, seguramente, por tu experiencia tengas más razón que yo, pero para convencerme me gustaría que me dieses más argumentos y me dijeses dónde y cómo colocarías tú el método que borra esa fila de la figura. Espero que no te haya ofendido, simplemente quiero asegurarme de qué opción es mejor y más correcta. De nuevo, mil gracias por tu ayuda.

Nada más. ¡Ah, sí! Creo que fue precisamente J. Carlos quien, en otro post de este foro, recomendó un libro sobre C++: "Thinking in C++" de Bruce Eckel. Debo agradecerte también este aporte porque llevo solamente dos capítulos y he aprendido muchísimo. Incluso creo que me ha metido el gusanillo por aprender polimorfismo y otras cosas que hasta ahora había dejado. Si lo buscáis en Google, incluso encontraréis traducciones del primer volumen. Es, simplemente, genial. No dejéis de echarle un vistazo. Ahora sí, nada más. Y perdón por el testamento que acabo de soltar...

Un saludo.

EDITO:

Por si el mensaje aún no fuera lo suficientemente largo, os voy a hacer leer algo más editando básicamente por culpa de una actualización que subí. Lo único que añade es el inicio del repaso del código y la reorganización. Ya puse todas las variables como locales (excepto las tres superficies de SDL, que no me convencí a ponerlas locales, pero si a alguien le apetece hacerlo o tiene una buena razón para ello, no creo que cambie nada ni que sea muy difícil) y creo que lo he hecho bastante bien, porque no da fallos. Puede ser que pasando la referencia a algún que otro puntero me haya equivocado, pero creo que, en general, no hay errores garrafales. Y luego comencé con la revisión de funciones para "descargarlas" un poco, como recomendó J. Carlos, pero sólo repasé las tres primeras (las de inicialización), así que no he descargado gran cosa... Más bien he añadido comprobaciones por si acaso hay fallos al cargar las superficies... ¡Ah! Y he añadido, a los prototipos de las funciones que quedan por revisar (a las de las clases también) lo siguiente: "/*REV*/". Básicamente lo hice para diferenciar esas funciones de las que ya están revisadas. Aunque "main()" no tiene ese distintivo (me olvidé), también está por revisar. Y creo que en cuanto a la actualización nada más...

Ahora ya para acabar, ¿creéis que podemos sacar ya una versión Beta?. Lo planteo porque, desde mi punto de vista, no vamos a añadir ninguna funcionalidad nueva a la versión 1.0 (lo de los niveles y eso, aunque no sea muy difícil tal como me lo planteó Lucas una vez, creo que es mejor dejarlo para futuras versiones). Y, obviamente, no vamos a lanzar la v. 1.0 sin pasar por la Beta, ya que por ahora aún hay bugs en el juego. O sea, que lo tenemos todo para sacar ya la beta. Bueno, todo no. Yo todavía quiero esperar una respuesta clara de alguien (y cuando digo alguien me refiero básicamente a Drincast, ya que él es nuestro Mesías en estos temas) para saber si se va a decidir a hacer un nuevo fondo, o vamos a dejar el que está. Ojo, no estoy pidiendo que hagas uno nuevo, Drincast. Simplemente te pido que nos confirmes tu decisión. Sería de gran ayuda para tomar esta decisión. Con que postees un mensaje en el que digas "Lo voy a intentar hacer / No lo voy a hacer" me llega. Así no pierdes mucho tiempo y nos sacas de dudas. A mí personalmente no me disgusta el fondo que hay ahora, pero creo que habría que quitarle la parte izquierda en la que está escrito todo eso del "soporte TCP/IP". Es un texto muy importante para aclarar la función de esa zona de pantalla, pero creo que no sería bueno sacar una versión Beta de un juego en la que aparece eso... Digamos que es poco elegante. Básicamente, eso era lo que quería decir. Espero respuesta.

Un saludo.

P.D.: Todavía no comprobé que el bug que dijo Lucas en su anterior mensaje se deba a lo que yo planteé en este, pero espero poder hacerlo pronto.

[lucesita]

jjoo que decir, juan, muy buenas apreciaciones, como alex no es que no entiendo POR QUE NO HACER QUE SE BORRE FILA DE LA FIGURA, si no es que no se me ocurre como hacer para que se borre desde otro lado. con respecto a lo demas, si estoy de acuerdo.

con respecto a lo de sacar la beta. si primero creo que tenemos que ver lo del bug ajaja, y con respecto al texto que esta sobre la izquierda, es como jugar al Lineage y decir... en la proxima version hay un skill que mata a todos. jajajaj es un chiste, no puede aparecer eso ni en una Beta jajaja

bueno, me bajo el update ultimo Abrazo a TO2

[Alex_13_estu]

Bueno, me paso por aquí con noticias sobre otra actualización más, ya véis que lo de acabar las clases me afectó bastante, porque estoy yendo a ritmo de actualización por día, cosa que antes me era imposible.

Como supondréis, esta actualización es, otra vez, de temas de optimización nada más. Dejo un resumen rápido y luego voy comentando punto por punto:

* Revisión de "CompruebaEventos()".
* Revisión de "NuevaFigura()".
* Como consecuencia de la revisión anterior, añado "BuscaHuecoFiguras()".
* Simplificación de la comprobación de colisiones.
* Cambio del "GetMapa()" de Figures para no dar direcciones de memoria de datos privados (hay que hacerlo con Cuadricula también).

Bueno, los dos primeros puntos no tienen mucho que aclarar, simplemente revisé esas dos funciones e hice los cambios pertinentes (por ejemplo, "CompruebaEventos()" ya no devuelve la pulsación de los cursores porque no es necesario). En cuanto a la función "BuscaHuecoFiguras()", decir que es muy simple: lo único que hace es buscar un hueco del array de figuras que esté libre, para ser ocupado por una nueva figura. Era algo que hacía bastante a menudo en la función "NuevaFigura()" y que no se me había ocurrido modificar. Pero como fue uno de los ejemplos que J. Carlos puso en su anterior mensaje y me pareció buena la idea de separar esa función, pues lo hice. Vamos ahora con la comprobación de colisiones. El método "Colision()" de la clase cuadrícula se encargaba de comprobar si una figura colisionaba contra los bordes o contra tras figuras que estuviesen paradas. Para ello había que indicarle la dirección de la figura, cosa que a mi no me gustaba mucho. Y cuando algo no me gusta, no suele durar mucho en un código... Así que lo simplifiqué muchísimo (se quedó en un tercio de lo que era) y me olvidé de hacia dónde iba la figura. Ahora la manera de comprobar las colisiones es pasando como parámetros las coordenadas donde quedaría la figura tras el movimiento y, si ocupa alguna casilla que está ya ocupada, te avisa de que hay colisión mediante el valor de retorno y ya te encargas tú de no aplicar el movimiento correspondiente. De esta forma pude "reutilizar" esta función en "NuevaFigura()" para comprobar si la figura siguiente ocupaba una posición ilegal y finalizar así el juego. O sea, que maté dos pájaros de un tiro. Y en cuanto a lo de la función "GetMapa()" de Figures, digamos que la modifiqué por "daños colaterales" (necesité la modificación para poder pasar el mapa de la figura como parámetro a "Colision()" desde la función "NuevaFigura()", pero así de paso me di cuenta de un error garrafla que había en esa clase y en la clase Cuadricula. La función "GetMapa()" de ambas clases devolvía la dirección de memoria del array del mapa, lo que permitía que un dato privado de una clase fuese accesible desde fuera de ella (o sea, una animalada si usas POO). Para solucionarlo, hice que a esa función se le pase un array como parámetro en el que se copia el mapa, de forma que se protejan esos datos. Sólo lo hice en la clase Figures, así que no busquéis la modificación en Cuadricula (al menos no todavía). Sé que soy algo vago, pero es que cambiar esa función de Cuadricula me supondría modificar bastantes líneas de código, y prefiero dejarlo para cuando tenga algo más de tiempo. En cuanto a la actualización, nada más.

Sólo me queda decir que esperaré hasta que J. Carlos explique lo que le pedí en mi anterior mensaje sobre lo que comentó de la eliminación de filas para tomar una decisión respecto a la optimización de esa parte. ¡Ah! Y a que Drincast nos diga si va a hacer el fondo para decidir lo de la Beta. Aunque no hagas uno nuevo, Drincast, te agradecería muchísimo que le sacases las letras de la izquierda al que hay ahora mismo. como dijo Lucas, eso no puede ir en una Beta...

Un saludo.

EDITO:

Bueno, acabo de mirar el mail y tenía algo muy muy interesante, que hace que merezca la pena que edite el mensaje: Drincast acababa de enviar la guía de cómo actualizar la web. Como tenía muchas ganas de ella, me he puesto manos a la obra y en media hora escasa he contribuído un poco al desarrollo de nuestra página. Creé la página de descargas para, obviamente, descargar el juego (no le puse enlace en el menú superior porque ya está el botón de la izquierda), subí un nuevo screenshot de la pantalla de juego (aunque esté la parrafada de la derecha supongo que un screenshot para recordar este momento en el futuro no quedará mal) y puse dos nuevas noticias. Una de esas noticias era para avisar de la subida de la versión Alfa y la otra para comentar la creación de la nueva página de descargas. ¡Ah! Y en cuanto a lo de las descargas, a ver si alguien que tenga Linux compila el proyecto y me manda el ejecutable para subirlo y crear así la categoría de Linux y dejar de tener sólo Windows.

Nada más, que tengo algo de prisa.

Un saludo.

P.D.: ¡¡Nooooo!! Acabo de subir la página y no me deja el WinSCP. Y no tengo ni idea de por qué es... Me pone algo como "No puedo crear el archivo remoto...". Así que, drincast, te voy a mandar el archivo ".rar" de la página y si eso lo subes tú, porque a mi me es imposible. Echa un vistazo al correo cuando puedas. Ahora sí, me despido.

Un saludo.

[Juan Carlos]

Hola, con respecto al tema del metodo BorrarFila quiero decir que cometi un error. La declaracion del metodo en el archivo figura.h pide como parametro una Cuadricula. Por lo que pense que dicho metodo borraba una fila del mapa de la Cuadricula (lo cual esta mal). En vez de eso, el metodo borra una fila de su propio mapa (lo cual esta bien).
No obstante, dicho metodo llama a otro, BorraMapa() (figura.h), que pide un puntero a una matriz (un puntero al mapa de la cuadricula) y luego modifica dicha matriz violando la privacidad del objeto Cuadricula. En este caso, si hay un error conceptual. En vez de eso, el objeto Figura deberia pedirle "por favor" al objeto Cuadricula que borre una fila o borre su figura.

Con respecto a las nuevas modificaciones ya me baje el codigo y ... No puedo jugar Al parecer hay una referencia colgada y me produce un Segmentation Fault asi que mi Linux no me deja jugar.
Hasta lo que pude rastrear, el programa explota cuando se ejecuta la funcion Dibujar (principal.cpp linea 168). Al parecer el array figura que se pasa como parametro no esta inicializado (eso es lo que me marco el depurador).

Saludos

[Alex_13_estu]

¡Hola! Como ya viene siendo costumbre, paso por aquí para resumir los cambios y comentarlos:

* Revisión de "ResetGame()".
- Como consecuencia, se crea en "Cuadricula" la función "ResetMap()" para poner a 0 el mapa.
* Revisión de "Dibujar()".
* Revisión de"AumentarPuntaje()".
* Revisión de "Finaliza()".
* Revisión de "BorraFila()".
- Bug encontrado en el código (y me llevará días encontrar la solución).
* Revisión de "main()".
- Añado un nombre a la ventana de la aplicación medidiante el WM (todavía no le puse icono).

---

* Revisión del constructor de "Block".
* Revisión de "Block::CargarIMG()".
* Revisión de "Block::Dibujar()".
- Como consecuencia, reviso "Figures::Dibujar()" porque no era corrcta la implementación.
* Revisión del destructor de "Block".

Veréis que son bastantes, pero es que la mayoría de las funciones eran muy simples y no había que tocar nada. En cuanto a "ResetMap()", lo que hice fue que el mapa se reseteara desde el propio objeto y no desde fuera, ya que es más correcto. Lo del bug lo dejo para más adelante porque dará que hablar, así que sigo con lo del nombre de la ventana... Qué decir, simplemente usé el control del Window Manager de SDL para ponerle de nombre a la ventana LineCube. Y en cuanto a lo de la función "Block::Dibujar()", la cambié porque no me gustaba lo que hacía. En vez de dibujar sólo el bloque, se le pasaba el mapa de una figura y desde ahí iba calculando las posiciones de los bloques y dibujándolos. Esto, en términos de POO, no creo que sea muy correcto, más que nada porque no tiene nada que ver el bloque con la figura... En tal caso la figura tiene que ver con el bloque, ya que se compone de ellos. Así que ahora, desde la función "Figures::Dibujar()" se le pasan las posiciones de los bloques y se dibujan desde "Bloque::Dibujar()" de uno en uno, como debería ser. Y voy ya con lo del bug (lo que va a hacer que escriba un mensaje larguísimo). Si os fijáis en cómo funciona el método para dibujar, una vez borrada la fila del mapa y las filas de las figuras afectadas, se recorre el mapa hacia arriba, pasando las filas de 1 en 1 desde la que se eliminó y, si hay una figura que tenga su "InicioY()" en esa fila, se le ordena "Bajar()". Pues bien, eso no es correcto del todo. Suponed un mapa de colisiones como el siguiente (sólo pongo una parte y cada figura tiene un nº distinto):

..........
0000000040
0000003340
5500033440
5511112222

Como véis, la última fila está completa, lo que supone que haya que eliminarla. Fijaos en las figuras a las que les puse los números 3 y 4. ¿Cuál de ellas tiene el "InicioY()" primero? La número 3, ya que la número 4 tiene un bloque más arriba. Pero claro, si le ordenamos "Bajar()" a esa figura, no lo hará, ya que la casilla inferior está ocupada. A continuación se le ordenará "Bajar()" a la figura 4 y ésta sí que lo hará, ya que la fila inferior fue eliminada, dejándonos un mapa así (con la figura 3 "colgada" de ninguna parte):

..........
0000000040
0000003340
0000033040
5500000440

Con lo cual, de la reflexión anterior deducimos que lo importante no es el "InicioY()", si no más bien el "FinY()" (o sea, la última casilla ocupada por un bloque). Si en vez de comprobar el "InicioY()" comprobamos el "FinY()", ¿arreglaríamos algo? Pues no mucho, la verdad, porque, en el ejemplo anterior, el "FinY()" de las dos figuras es el mismo. Lo que nos lleva a que a veces funcionará y a veces no. ¿Cuando funcionará? Pues cuando la figura 4 tenga una posición en el array de figuras inferior a la de la figura 3 (porque el array se recorre de abajo a arriba y, al tener una posición más baja la figura 4, se bajaría primero de manera que la figura 3 no tendría ningún obstáculo al bajar). Pero, ¿qué pasa si la figura 3 tiene una posición inferior a la 4? Pues que tenemos de nuevo el mismo problema, y la figura vuelve a quedar "colgada". ¿Solución? No la sé. O bueno, mejor dicho, sí tengo una. Pero, desde mi punto de vista, es muy poco eficiente, y estoy seguro de que tiene que haber una mejor. Sólo hace falta pensar. De todas formas, explico lo que se me ha ocurrido. Es bastante simple, así que no será difícil de entender. Si en vez de recorrer una sólo vez el array de figuras, lo recorremos dos veces, tenemos el problema solucionado. Así de simple. Las figuras que ya bajaron no volverán a bajar, y las que quedaron "suspendidas" sin bajar lo harán ahora. Incluso, por si acaso, podríamos guardar en un array las posiciones de las figuras que quedan sin bajar y hacerlas bajar en la segunda vuelta. Y si todavía quedan figuras sin bajar, pues le damos otra vuelta más hasta que el array de figuras por bajar quede totalmente a 0. Podéis comprobar que funciona a la perfección, ahora bien, el coste debe ser altísimo, porque pasamos de recorrer el array de figuras una vez a recorrerlo dos o más. Por lo tanto, quiero ideas para solucionarlo. Y si no tenéis ideas, pues leed la mía y criticadla todo lo posible para que acabe siendo un buen método. Ahí lo dejo.

¡Por fin he acabado de explicar lo del bug! Voy ahora a por el mensaje de J. Carlos. En cuanto a lo de "Figures::BorraMapa()", he de decir que, como bien dices, es totalmente incorrecto. Ya lo había notado y, si repasas el código, encontrarás funciones en las que también se hace eso. Lo que pasa es que, para solucionarlo, tendría que rehacer el método "Cuadricula::GetCuadricula()" para que devolviera una copia del mapa en vez de la dirección de memoria (si te fijas, ya he hecho eso en "Figures::GetMapa()") y eso afectaría a bastantes cachos de código, por lo que quiero hacerlo un día que tenga bastante tiempo y pueda asegurarme de no volver a cometer esos errores. En breve espero solucionarlo.

Y en cuanto al Segmentation Fault... Pues no tengo ni idea del por qué. Ya sabéis que no tengo Linux y no lo puedo probar, pero lo cierto es que ni repasando el código he logrado ver dónde podría estar el fallo. Más que nada porque ese array de figuras que dices que podría ser el problema ya se pasa como parámetro anteriormente a "NuevaFigura()" y supongo que ahí no te da error. A ver si puedes rastrear un poco más y nos sacas de dudas, porque lo cierto es que estoy en blanco, y aún encima no puedo probar en Linux el juego... De estas cosas se pueden sacar dos cosas: o Linux es muy tocapelotas o Windows es una auténtica basura. Y creo que opto por lo segundo, así que no sé por qué sigo con Windows... En fin, creo que voy a dejar de escribir ya porque llevo un mensaje que supongo que tardaréis varios días en leer.

Lo dicho, ya acabé con lo principal del mensaje... Pero aún me queda recordar dos cosas a Drincast. La primera, que le mandé la web porque soy incapaz de subirla a SF.net (y sospecho que es por los permisos que le puso a los archivos que subió), así que a ver si él lo logra. Y lo segundo, también a Drincast, aunque aquí puede participar el que quiera, que sigo esperando una respuesta en cuanto a lo del fondo. Ya dije que no quiero un sí ni mucho menos, sólo quiero saber tu opinión ppara tomar una decisión sobre lo de sacar una hipotética versión Beta. Ahora sí, nada más.

Un saludo.

[drincast]

Hola losersdevelopers, bueno ayer probé el juego un rato a ver que fallas le encontraba, juegue y realice como 13000 de puntaje pero vi dos errores bueno no se si errores o soy yo, hay veces que no se elimina una fila, seda muy remotamente pero parece que no se calcula bien, creo que es cuando, hay espacios debajo de la fila a borrar pero es muy rara vez que pasa.

Otro error bueno no se si error, es que cerca a los 2200 de puntaje, me aparecieron como una 7 T de seguido y Lugo en 12000 de puntaje paso lo mismo pero esta vez fueron puras S (no se si es error de código pero esto le da una buena dificultad de juego), creo que más importante es el error que mencione arribe, jueguen 8na partida mas o menos larga y coloquen mucha atención cuando se valla a borrar una fila.

Otra cosa creo que le faltaba al juego para su versión beta y medí cuenta, es que estaba probando el juego mas o menos a la hora de almuerzo y cuando me disponía a ir a almorzar, pues no se puede pausar el juego, pues es una pequeña funcionalidad que codifique son mas o menos cuatro líneas de código y solo van en el archivo principal.cpp.

Aquí va una pregunta, realice las modificaciones en mi copia del repositorio (echan con darcs get) y al crear el parche con darcs send –o este ya no me dejo crearlo como antes así que yo le envió a Alex un correo con el archivo principal.cpp y el fondo del juego para que lo actualice.

Ahora lo de la optimización de código, no se esta es una opinión no mas, creo que todas las constantes del juego deberían ir en un archivo aparte del principal.cpp, podría ser uno nombrado constantes.h el cual se debería incluir en cada archivo de código, pues creo que es mejor así ya que en cualquier archivo se debería acceder a variables como el tamaño de pantalla, la resolución etc, y esto ayuda a mermar las líneas de código que hay en el archivo principal.cpp, es solo una opinión.

No siendo más por el momento me despido, felicitando a todos los que han aportado su granito o granote de arena para que alfil podamos sacar la versión beta de nuestro primer videojuego.

Saludos.

[Juan Carlos]

Hola, bueno con la idea de Drincast de agrupar todas las constantes en un archivo, quiero hacer una aclaracion.

Si las constantes son las constantes del preprocesador (las que se declaran con #define), la idea de Drincast es valida. Pero si se refieren a las otras constantes (usando el atributo const), estas variables (constantes) tiene un ambito global-parcial. Son visibles en todo el archivo (pero no en todos los archivos del programa como una variable global de verdad). Para ello es necesario usar la palabra clave extern:

Constantes.h:
extern int const MAX_FIGURAS = 2; //Declaracion y definicion

Otro_archivo.h:
extern int const MAX_FIGURAS; //Declaracion

Pruebenlo por que no estoy seguro del todo, y puede que me equivoque.

Con respecto a la solucion del bug encontrado por Alex, tal vez se puede simplificar la situacion.
Segun lo que he entendido, cuando una figura llega a colisionar, el usuario ya no puede controlarla (lo que es obvio) pero la figura sigue "viva". Por lo tanto, el usuario controla una figura a la vez, pero existen muchas mas que ya han estacionado. De aqui se entiende la existencia de un array de figuras (de dimension 200 o 201).
Hasta aqui, esto es correcto? (supondre que si, pero no he revisado el codigo)
Para reducir el espacio en memoria (y para solucionar el bug) se me ocurrio lo siguiente. Una vez que la figura llega a colisionar, esta deja una "huella" en la cuadricula de esta manera:

00000
00220
02200 (colisionó la figura s)

El numero a escribir depende del color del bloque. Una vez dejada la huella, la figura muere. La cuadricula deberia ser capaz de leerse asi misma (leer su matriz) e interpretar cada numero y dibujarse. Con esto solo se necesitarian 2 figuras (una que controla el jugador y otra que se muestra como la "figura siguiente").
Ademas, la eliminacion de una fila completa de la cuadricula se simplifica ya que no se necesita pedirle a cada figura que baje. El codigo de la eliminacion es:

Código: Seleccionar todo

int i=A;
for (; i>0; i--) {
     for (int j=0; j<columnas; j++) {
           matriz[i][j]=matriz[i-1][j];
      }
      if (filaVacia(i) {
            break;
      }
}
if(i==0){
     for (int j=0; j<columnas; j++) {
           matriz[i][j]=0;
      }
}


Donde A es el numero de la fila a borrar; y el metodo "filaVacia(int)" recibe el numero de una fila y determina si esta llena de ceros (return true) o no (false)

Ejemplo:

(Fila 0) 0000 0000
(Fila 1) 0000 0000
matriz original --> (Fila 2) 1000 ---->colisiona otra figura ---> 1022
(Fila 3) 1100 1122

La fila 3 esta completa entonces tomo la fila 2 y la copio en la fila 3

0000 Fila 0
0000 Fila 1
1022 Fila 2
1022 Fila 3

La fila 3 NO es vacia, entonces repito el procedimiento (copio en la fila 2 el contenido de la fila 1)

0000 Fila 0
0000 Fila 1
0000 Fila 2
1022 Fila 3

La fila 2 ESTA vacia, por lo que deduzco que las filas superiores tambien lo estan y no es necesario seguir copiando ceros y ceros.

Con respecto al lo de windows/linux, Si, "Windows es una auténtica basura". Cuando tenga un poco mas de tiempo, intentare debugear el codigo para encontrar la causa del segmentation fault.

Saludos

[Alex_13_estu]

¡Hola! Bueno, me paso hoy muy rápido porque voy muy justo de tiempo, así que, por una vez, no tendréis que dejaros los ojos leyendo el mensaje.

Lo primero, que acabo de subir unos cambios. Básicamente lo que hice fue organizar las constantes en otro archivo como sugirió drincast ("constantes.h"), poner el nuevo fondo que ya no tiene el texto a la izquierda e implementar el "pause" que me mandó por mail drincast con algunos cambios. O sea, actualización 100% drincast, xD. En cuanto a lo de las constantes, decir que no hubo problema, o sea, que no hizo falta lo del "extern". No preguntéis el por qué, pero funcionó. Y los cambios que le hice al pause fueron porque no me gustaba mucho el sistema. Tal como lo había hecho drincast, el juego se metía en un bucle que sólo acabab cuando se pulsaba "p" de nuevo, por lo que, si tú cerrabas la ventana o le dabas a ESC, el juego no respondía. Lo que hice ahora fue poner en una variable "bool pause" la información de si el juego estaba parado y, so lo está, no se reciben pulsaciones de teclas ni se mueven las figuras ni nada. Sólo se controlan algunos eventos de finalización. Eso es todo en cuanto a cambios.

El tema que comentó drincast de la repetición de muchas figuras iguales seguidas no tienen nada que ver con la puntuación. Juega otra partida larga y las posibilidades de que te ocurra lo mismo son casi nulas, ya que las figuras se generan de forma pseudo-aleatoria con "rand()". Y luego lo que comentó J. Carlos sobre el bug... Bien, debo decir que llevaba tiempo temiéndome que tendríamos que hacer ésto, así que considero que lo que has propuesto es lo mejor que podemos hacer ahora. Hace algunos días que me di cuenta que la manera en que estábamos llevando ciertas cosas nos iba a limitar mucho, y la principal era la bajada de las figuras. Empecé a imaginarme que tendríamos que hacer bajar el mapa todo de golpe, y no las figuras una por una como hacíamos ahora... Pero no lo hice. ¿Por qué? Pues porque me daba pereza modificar el planteamiento del juego (si hacemos los cambios, estamos modificando mucho ese planteamiento, ya que dejamos de lado gran parte de la idea que teníamos sobre las figuras y la mayor responsabilidad pasa al mapa de colisiones) y porque, en el fondo, esperaba encontrar una buena solución dejando las cosas como estaban. Pero eso es mucho más difícil de lo que parece (además de ser muy poco eficiente, como ya dije), así que lo mejor es adoptar el nuevo planteamiento. En cuanto tenga una hora o así para dedicarla al proyecto, realizaré los cambios.

No puedo comentar nada más porque voy justo de tiempo. Sólo decir que en breve subiré la versión Beta y haré esos cambios que dije. ¡La versión 1.0 está a la vuelta de la esquina, así que, ánimo!

Un saludo.

[lucesita]

me lei todo en 10 minutos... jajajaj realmente dan ganas de leer estas cosas, ahora me surgio una duda, haciendo pruebas y pruebas... encontre un gran problema bueno... gran gran... no se

PERO RENDERIZAR (no se si esta bien dicho, quiza lo corrcto sea, BLITEAR) el BackGround nos lleva entre 30 y 38 Milisegundos!!!!!!!!!!!!!!!!!!!!!!!!!!! todo el Resto se ejecuta en menos de 1 MS y hablo de blitar TODAS LAS FIGURAS, los puntajes, y calcular las coliciones asi que evidentemente tenemos algo mal (creo) por eso vine a pedir consejo de sabios

por que creen que tarde tanto en blitear el BackGround? yo lo primero que me supuse... claro.. esta en formato ".png" es por eso que tarda.... PERO NO!!!!!! lo puse en BMP y tarda lo mismo a lo que dije... claro!!!! Tiene demaciados colores para blitear, PERO NO!!!! hice un fondo solo de color negro y se demora los 30 Ms

y si se demora todo eso... a 20 Fps no llegamos ni soñandolo... asi que, si nos hechan un cable... agredecidisimos, si no tambien

Saludos Lucesita.

[Alex_13_estu]

¡Hola! Como ya es costumbre, voy a comenzar por hablar de actualizaciones. Básicamente he hecho ya lo más básico de lo que propuso J. Carlos: ahora lo que baja es el mapa y no las figuras. O sea, que ,si no me equivoco, se acabaron los problemas y los bugs de que había figuras que no bajaban y todo eso. Además, ya no hay un array de 200 figuras, si no que sólo hay dos variables del tipo "Figures": la actual y la siguiente. Las demás se guardan en el mapa por números según su tipo, y lo que se imprime en pantalla es el mapa, junto con la figura actual y la siguiente. Por lo tanto, he hecho también otro cambio, que es el de eliminar del código las líneas que se encargaban de crear el archivo "datos.txt". O sea, que ya no existe ese archivo. Básicamente lo eliminé porque ya no tenía utilidad alguna, es decir, si lo que baja es el mapa completo, no hay posibilidades de error... O eso creo.

Ahora bien, las actualizaciones dejaron serios cambios en las clases, por lo que a partir de ahora, y durante un par de días, trataré de estudiar a fondo las clases "Figures" y "Cuadricula" para eliminar todo lo que está obsoleto y mejorar los nuevos métodos. Creo que eso es todo en cuanto a las actualizaciones. Descargaos el repo y probadlo todo lo posible, porque es probable que se me hayan escapado cosas al retocar el código y no está exento de fallos...

Bien, voy ahora a hablar de lo que comentó Lucas de la velocidad de impresión en pantalla. Creo recordar que hace tiempo os dije que, probando el juego en mi portátil, me iba extremadamente lento. Pues bien, he estado midiendo exactamente cuánto de lento y... ¡Un ciclo del loop le lleva entre 75 y 80 milisegundos! Ya sé que es muy difícil conseguir que en un ordenador viejo como mi portátil corra a 50 FPS, pero de ahí a andar a 10 FPS hay una gran diferencia... Y lo peor de todo es que realizar todas las operaciones del loop, sin contar la impresión en pantalla, le lleva entre 1 y 5 milisegundos... ¡O sea, que la función "Dibujar()" se como los otros 70-75 milisegundos! Y para darle todavía más la razón a Lucas y asombraros un poco más, os diré que, dentro de esa función, imprimir las figuras y el texto le lleva entre 2 y 5 milisegundos... Con lo cual, nos quedan todavía entre 60 y 70 milisegundos que, ¿a que no sabéis quién se los "come"? Pues sí, la función "SDL_BlitSurface(background_game, NULL, pantalla, &rectangulo);". Bueno, realmente no todos esos milisegundos se los come esa función, si no que la función "SDL_Flip(pantalla);" también se lleva algunos, pero muy muy pocos (entre 2 y 7 milisegundos). Pero lo importante es que imprimir el background siempre le lleva algo más de 60 milisegundos, al menos en mi portátil. Y eso es muy grave. Todo esto me hace preguntarme, ¿qué harán los programadores profesionales de juegos para lograr que juegos en 3D funcionen a 50 FPS? Deben de tener unos trucos impresionantes, visto lo visto...

Para solucionar esto, voy a empezar a hacer pruebas, como "clipear" el background para que sólo se impriman unas zonas o cosas así, pero no creo que mejore espectacularmente los resultados... Aunque por probar no se pierde nada. Si descubro algo os lo comento. Nada más. Probad el repo para ver si le véis fallos y, si alguien conoce alguna solución al problema del blitting del background, por favor, que lo comente. Por muy pequeño que sea, seguro que será interesante.

Un saludo.

EDITO:

Dicho y hecho. Me he pasado como una media hora con todas las funciones que conozco de SDL que puedan afectar al "blitting" y al final he logrado encontrar una manera de acelerar de una manera impresionante el renderizado del background. Se trata de la función "SDL_DisplayFormat()" que, si os fijáis, ya utilizamos dentro de la clase "Block" en la función "CargarIMG()". Parece ser que lo "único" que hace esta función es convertir la superficie al formato de pantalla... Pues bien, con eso es más que suficiente para acelerar el "blitting". Sólo con cambiar un poco la función "InicializaSprites()" de forma que las superficies se carguen usando el "DisplayFormat()" he pasado de una velocidad de 12 FPS en mi portátil a una de 43 FPS. Y sobra decir que en un ordenador aceptable y mínimamente actual llega sin problemas a los 50 FPS que queríamos conseguir en un principio. De hecho, en mi ordenador de sobremesa (que es de doble núcleo con dos procesadores de 2.4 GHz, o sea, bastante bueno) sólo le lleva realizar el loop completo unos 8 ó 9 milisegundos. Aunque esos 8 o 9 milisegundos siguen siendo de la función "Dibujar()" (cosa que a mi personalmente me da mala espina), al menos ya no nos podemos quejar... Hemos logrado lo que queríamos, ¿no? Y, por supuesto, ahora mismo he subido los cambios al repo. Aparte de ese cambio, he solucionado un bug que había en la función "Figures::Girar()" y que se había producido como consecuecia de mi anterior cambio (el de hacer que sea el mapa lo que baje y no las figuras). Pero bueno, era una tontería, así que no tengo que explayarme en la explicación. Sólo decir que lo que hacía para comprobar que la figura no colisionara al girar era mirar si las casillas del mapa eran "iguales a 1". Pero ahora, con los nuevos cambios, eso no vale, ya que hay figuras que se representan con 1, otras con 2, 3, 4, 5, 6 y 7. O sea, que ahora lo que hace es comprobar que sean "distintas a 0" y no "iguales a 1". Una tontería.

Sólo me queda deciros que, vistos los avances, es posible que en breve suba la versión Beta para Windows (a ver si alguien con Linux se anima a enviarme los achivos necesarios para subir la versión para este S.O.). ¡Ah! Y que, aunque hayamos solucionado ya lo de la velocidad del loop, no estaría mal que, si sabéis algo, lo digáis, porque sigo sin entender cómo un juego como nuestro Tetris anda a 50 FPS con dificultad en algunos ordenadres y, sin embargo, hay juegos bastante más complejos y en 3D que sí me funcionan a los 40 FPS necesarios... Si alguien sabe algún truco útil, por favor, que nos lo transmita.

Un saludo.

[lucesita]

no voy a especificar mucho ya que se mas bien poco y nada, pero lo del Segmentation Fault, lo solucione poniendo el directorio COMPLETO de las imagenes en el codgio... que problema nos trae esto.... QUE SOLO FUNCIONA EN MI MAQUINA, pero aca no queda todo, Cuando genera la "figura proxima" ahi si que se caga todo, y no tira Segmentation Fautl... tira un monton de lineas que valla a saber dios o alguien que entienda mas que yo que significa... claro esta en Linux tengo ese problema.

esto va a modo de ejemplo, supongamos que ahora tenemos:
sur_img = IMG_Load("recursos/img/BackGrounT.png");

para que me funcione en linux tuve que hacer

sur_img = IMG_Load("/home/lucesita/programacion/proyectos/csdl/linecube/recursos/img/BackGrounT.png");

vuelvo a repetir, se me soluciono lo de segmentation fault pero ahora me tira NO SE QUE... alguien que entienda de linux que heche un cable.

y alex... yo lo solucione de la misma forma lo de los FPS xD, despues viendo en un proyecto, usaban SDL y se pasaron a OpenGL ya que renderizando con SDL conseguian como mucho 50 FPS y con OpenGL consiguen 300 FPS, me abstengo de dar una opinion del tipo el SDL es malo o es bueno, ni mucho menos quiero traer a colacion una discucion de SDL vs OpenGL, pero para proyectos grandes se deberia tener en cuenta jajaja


Saludos Lucesita.

[thepoi]

Hola

Menuda optimizacion, de varias decenas de milisegundos a unos pocos.
Por cierto, como medis el tiempo que necesita cada funcion? usais algun tipo de debugger/profiler? o con chivatos en el codigo?

[lucesita]

Honestamente no se como lo mide alex, yo uso la funcion "SDL_Ticks" de SDL

ej:

Código: Seleccionar todo

unsigned int t1, t2;
t1 = 0;
t2 = 0;
...
...
//suponiendo que desde aca quiero medir hago esto
t1 = SDL_GetTicks();
..
...
...
...
//y suponiendo que aca es donde quiero ver el tiempo

t2 = SDL_GetTicks();
tiempo = t2 - t1 // EN MILISEGUNDOS



PD: No desvirtuemos jajaja, si queres mas detalle abrite un nuevo Thread

[Alex_13_estu]

¡Hola! Me paso rápidamente porque voy algo justo de tiempo a solucionar dudas que hayan surgido, plantear lo que nos queda por hacer y comentar nuevas actualizaciones (aunque esta vez no son mías, si no de J. Carlos). Bueno, comienzo por las actualizaciones. Básicamente, he actualizado el repo con un parche que me mandó J. Carlos y que se encarga de actualizar el "Makefile" de Linux y solucionar algunas tonterías que había en el código (del tipo de las funciones "SetX()" y "SetY()", que, no sé muy bien por qué, les puse "int" de valor de retorno cuando no deberían retornar nada). Si tenéis dudas acerca de estos cambios, mejor será que se las preguntéis a él, porque yo me limité a aplicarlos.

Voy ahora con los mensajes anteriores... En primer lugar, la lucha entre Lucas y su Linux... Siento decirte que no puedo hacer nada por ayudarte, ya sabes que estoy cojo (y de las dos piernas) en temas de Linux... Así que creo que lo mejor será que lo consultes con J. Carlos, que domina bastante esos temas. Y lo de cambiarse a OpenGL, no tenía ni idea de que fuera más rápido, pero me suponía que algo así tendrían que hacer los desarrolladores de grandes juegos para lograr que programas 3D anduviesen a 50 FPS sin problemas. De momento nosotros vamos bien con SDL, así que creo que no es algo que tengamos que plantearnos en un futuro próximo. Y en cuanto a la duda de Thepoi de cómo controlamos los FPS, yo directamente uso el timer del Game Loop:

Código: Seleccionar todo

fps_tim.GetCurrentTime();

Inserto esa función en las partes de loop que quiero controlar y me dice los milisegundos que van desde que comenzó el loop. Luego compruebo el archivo "stdout.txt" y ya está... Simplemente eso. Espero haberte solucionado la duda, pero, si sigues queriendo saber más, abre otro topic como te pidó Lucas, que si no vamos a liar este muchísimo con cosas que no son del proyecto.

Y ya para acabar voy a comentar lo que tengo pensado hacer en un futuro inmediato. Lo primero será subir la versión Beta, puesto que ya tenemos un juego que funciona a un nivel bastante bueno y no creo que hagamos muchas mejoras de aquí a la versión definitiva. Y a partir de ahí, habrá que seguir retocando el código hasta tenerlo bastante limpio para presentar una versión 1.0. Se me ocurrió que podríamos meter un menú principal (muy muy simple) porque me gustaría agregar una funcionalidad que te permitiera escoger entre un fondo de color azul o rojo para la partida... Sé que es una tontería, pero me hace ilusión y es una buena manera de hacer pruebas para un futuro menú principal en toda regla. Espro que deis vuestra opinión para decidir lo que vamos a hacer.

Un saludo.

[drincast]

Hola Losersdevelopers, le escribo solo para avisar que acabo de subir de nuevo la pagina, con las modificaciones de Alex, y ya le di los permisos respectivos a todos los archivos para que todos la puedan manipular.

Quiero hacer una aclaración, cuando vayan a colocar un vinculo en la pagina por favor utilicen el atributo class=”link_stile1”,ya que los vínculos normales se dan en color azul y esto no se ven bien por los colores de la pagina, seria algo así

<a class="link_stile1" href="… ">Link 2</a>

Por otro lado no he tenido tiempo de leer todo lo que han escrito, ahora me guardo las paginas y por la noche las leo en mi casa.

Eso si prueben a ver si le di los permisos adecuados a los archivos,
Hasta la próxima que espero sea pronto

[Alex_13_estu]

Bueno LosersDevelopers, creo que ya tenemos la versión Beta en la red. Acabo de subir a la página de descargas de SF.net tanto la versión ejecutable para Windows como el código fuente. Espero que podáis solucionar pronto los problemas que tenéis con los "Segmentation Fault" y consigáis enviarme el ejecutable y el código para Linux, porque creo que sería bueno que ofreciésemos cuanto antes una versión para este sistema. Creo que respecto a la subida nada más.

En cuanto al último mensaje de Drincast, agradecerle que haya subido la página, y decir que creo que colocó los permisos correctamente. Ahora añadiré la noticia de que hay nueva versión y lo comprobaré al intentar subir nuevamente la Web. Muchas gracias por tu ayuda. ¡Ah! Y tendremos en cuenta lo de los links, la verdad es que cuando hice la página me parecían bastante feos en azul, pero como no controlo de HTML más que lo básico no supe cambiarlos... Muchas gracias también por eso.

Un saludo.

P.D. : Tanto para subir esta versión como para subir la Alfa, tuve que hacer miles de pruebas en SF.net porque soy todavía bastante novato en lo de subir versiones, así que siento deciros que si visitáis, dentro de nuestro proyecto, la página "Admin -> File Releases" estará totalmente mal estructurada, porque añadí paquetes que eran innecearios. Si queréis hacer algo en ella, por favor, hablado conmigo que os explico lo que es importante y lo que es "basura".

EDITO:

Bueno, como nadie escribió aquí desde mi último mensaje, tendré que editar... Lo primero, decir algo respecto a mi último mensaje: sigo sin conseguir subir los cambios de la web a SF. Me sigue dando problemas, así que, nuevamente, le envié por mail a Drincast los cambios para que los suba él. Eso en primer lugar.

Y luego, hablar también de la última actualización que acabo de subir. Básicamente, lo único que hice fue acabar con el primer repaso del código. y cambié bastante la clase "Texto", porque me parece muy interesante que se puda reutilizar en el futuro y, tal como estaba ahora, eso era muy difícil. Le he añadido algunas opciones para lograrlo, pero poca cosa. Echadle un vistazo. Lo que sí agradecería es que alguno de vosotros que tenga ganas le dé un repaso de nuevo al código, porque seguro que se me ha escapado algo. Porque si lo vuelvo a repasar yo, seguro que vuelvo a cometer los mismos errores, así que mejor que lo haga otro.

Y en cuanto a qué nos queda por hacer... Pues poca cosa. Simplemente implementar cualquier tontería que se nos ocurra para la versión 1.0 . Yo ya dije que me interesa lo de hacer un menú muy simple, pero espero que vosotros aportéis ideas para saber qué podríamos hacer que tuviera algo de interés.

Espero vuestras respuestas.

Un saludo.

[drincast]

Hola losersdevelopers, buen solo para felicitarles por el gran trabajo que se ha realizado, es algo importante para nuestro grupo que apenas comienza sacar una versión beta de nuestro linecube, un gran trabajo por parte de todos, aunque si nos faltaducho camino por recorrer.

Listo, decirle Alex que relámete lo siento no se si es que he echo algo malo a la hora de dar los permisos a los archivos de la pagina web, voy a tratar de ver cual es el problema, de todas formas ya subí las modificaciones que me enviaste al correo, y decirle a los demás que le echen un vistazo y se ven que algo falta pues le echen mano, y lo adicionen, noticias y de mas, claro respecto al juego o algrupo.

Yo este fin de semana intento darle un repasón al código fuente a ver que cosas veo por hay raras.

Saludos .

[Juan Carlos]

Hola, bueno ya me he bajado la nueva version y la verdad es que siento que el juego esta mucho mas fluido. Es notorio el cambio de los FPS utilizando la funcion Display de SDL.Muy bueno!
Despues de las modificaciones (los ultimos parches), no solo el juego es mas fluido sino que se ha arreglado el tema del Segmentation fault. Lo he estado probando por mas de 20 minutos y no he tenido ningun error.

Supongo que para la siguiente version hay que agregarle (en mi opinion):

-un menu
-un registro de los mejores puntajes
-un "Player 1 vs Player 2"
-un aumento de la velocidad de las figuras en funcion del puntaje, aumentando asi su dificultad.

Pero creo que hay algo mas importante y es el analizar que cosas resultaron bien durante el proyecto, y por supuesto que cosas salieron mal. Esto podria ser de ayuda para proyectos siguientes.

Felicitaciones.

[lucesita]

con respecto a lo que dices de Que salio bien y que salio mal... es algo que quedo pendiente con alex... quedamos en que abririamos un post para que opinen ustedes, ya que en claro, se nota que juan tiene experiencia sobrada, eh aqui el tema alex esta de vacaciones, asi que cuando vuelva, abrimos el post

por sobre todas las cosas, lo que quiero destacar es... EL DARCS (ese monstruo que cuando queremos actualizar 3 lineas, tenemos que subir a SF 3 Mb de inf)

otra de las cosas que quiero tratar es, "las buenas costubres"

y algo que me parece importante es Ponernos de acuerdo en la forma de trabajar, como ser "nombres de variables" cuando usemos indices referirnos atravez de una letra, como ser... la "n" o la "i". cuando recorramos indices de coordenadas, primero el Y despues el X o viceversa.

Creo que va a ser lo primordial ponernos de acuerdo en estas cosas, para un siguiente proyecto.

Saludos Lucesita

[drincast]

Hola LosersDevelopers, hace rato que no hay actividad, bueno eso es lo que me parece a mi, han sigo desarrollando o ya no se están comunicando, espero hayan descansado, y quisiera saber si vamos a seguir con el grupo.

Bueno espero no molestarlos y Saludos a todos

[Dokan]

Parece que esto se quedó trabado. A ver si los que saben de programación en C++ se animan a seguirlo. Yo por mi parte empezaría de cero pero esta vez con python/pygame que se me hace más factible.

[Juan Carlos]

Creo que el tetris quedo terminado. Faltan algunos detalles como un menu y otras cosas. Pero el juego es jugable.

Por ahora no me he podido bajar el codigo para probarlo, si alguno se interesa, el link para bajarlo con darcs esta en los primeros mensajes de este post.

Yo seguire intentado bajarlo.

Saludos

[carlostex]

Hola espero que alguien siga viendo este tema, que veo que casi a esta fecha no tiene actividad, propongo iniciar otro proyecto, hacer un juego diferente, tal ves el de las naves con scrolling, o algun otro que se les ocurra, espero que esten interesados, espero sus respuestas

[Dokan]

Haz la propuesta en un tema nuevo y a ver si la gente se anima. Personalmente no tengo tiempo para tanto, ya estamos dedicando los ratos libres al proyecto Asadetris que está siendo desarrollado en Python y Pygame. Además si fuera en C++ acabaría por abandonar como me pasó con éste porque no tengo ni idea (y de python poquita).
En conclusión, proponlo en un tema nuevo y quien quiera acabará apuntandose. Aunque se apunte poca gente te animo a que de todos modos, siguiendo los pasos de otros proyectos vayais poco a poco avanzando, con el tiempo seguro que más gente se interesa.

[carlostex]

Ok, cuando este listo convocare, pero tengo una duda,para antes de realizar un proyecto en el que participan varias personas, y es sobre el control de verciones, ya aprendi a usar el darcs, pero como hacen para enviarse los parches, y donde alojan el repositorio para que este disponible a actualizacion y descarga. quiziera que alguien me oriente, los que an participado en proyectos, como se las arreglan con eso del repositorio?

[Geo]

Normalmente se crea un espacio en algún servidor de proyectos de software abierto, como Sourceforge o Google Code, el proceso de registro es sencillo y, una vez aceptado, se tiene acceso a los recursos que proveen, como los repositorios de código (en Sourceforge se usa CVS y Subversion), el proyecto Asadetris está en Google Code y usa Mercurial.

[carlostex]

Muchas gracias Geo, aunque antes de leer tu respuesta ya avia investigado que host podia usar, sucedio que no podia quedarme con la duda y precisamente fui al repositorio de asadetris y me mando a code de google, luego cree mi cuenta y ya hize pruevas con mis programas, aunque no savia que tambien Sourceforge alojaba repositorios asi que gracias lo tendre en cuenta

[Dokan]

Carlos, no quiero parecer pesado ni cansino, pero una norma básica en casi cualquier foro es que eso que has hecho después de preguntar lo hagas antes, y si no das con la solución a tu problema preguntes lo que sea necesario que estaremos encantados de ayudarte.