How to Be a Complete Gentleman

[valdivia]

Aquí va una pequeña actualización con un video del juego corriendo en un Spectrum +. En realidad las únicas novedades con lo que ya había están en los gráficos, con mejoras de los suelos y añadidos en las decoraciones en general. Aunque ya tengo bastantes más elementos decorativos en el programa, no están en la demo (si veis, todas las pantallas tienen la misma decoración).

Pronto estará lista una versión con todas las pantallas terminadas. Entonces sólo me quedará hacer un juego Es decir, meter los enemigos, las misiones ...

http://www.youtube.com/watch?v=h1Yy4_DgIXc

holaa buenas cuanto tiempo ktal estas figura?ya estoy acabando porfin los estudios me queda una para septiembre porfin jejej haber si la saco y asi ya porfin tendre tiempo para hacer la portada que prometi jeje me ha gustado mucho el video corriendo en una spectrum cuanto te va kdando del juego?ya hay ganas de probalro un saludo!!

[apenao]

Hola de nuevo

Pues está hecho todo el mapa y las decoraciones de las habitaciones. Ahora estoy probando varias rutinas para que se muevan los enemigos. Voy avanzando muy despacito porque apenas dispongo de una horilla por las noches para dedicarle a esto mientras veo alguna pelicula.

Ya contaré más progresos a medida que se vayan produciendo

Un saludo.

[Z80user]

Pues está hecho todo el mapa y las decoraciones de las habitaciones. Ahora estoy probando varias rutinas para que se muevan los enemigos. Voy avanzando muy despacito porque apenas dispongo de una horilla por las noches para dedicarle a esto mientras veo alguna pelicula.

Yo mientras no vienen nadie en la tienda, pienso alguna coseja, luego por las noches, segun la noche tambien hago lo que tu.

Yo ahora estoy con eso, hacer una rutina para que un objeto se mueva desde una coordenada a otra, pero que tenga en memoria que ruta tiene que seguir, y no tener que estar calculandola continuamente, basicamente es usar la rutina de dibujo de lineas, lo que no queria hacer es la division H/V para calcular cuantos pixels hay que moverlo en horizontal, para que se mueva 1 en vertical (o sus 8 subversiones), porque las rutinas de 16 son lentas para crear una division, y yo tengo que hacerla para que tome solo 12 bits.

La idea es, que un muñeco se mueva desde la coordenada 0:0 a la coordenada 128:64 en linea resta, pero no tener que calcular a cada frame los movimientos intermedios que tiene que realizar, porque si no, acabaria moviendose hasta llegar al punto 64:0 y luego desde hay en diagonal hasta el 128:64, pero por lo que estoy con la rutina voy a tener que hacer la division.
NOTA: la rutina para medir las distancias la he puesto en el foro de computeremuzone la raiz cuadrada es ((H+V)*3+[H-V])/4 sin usar 16 bits, no es esacta, pero es aproximada con 7/4 creo que era mejor, pero no podia usar numeros tan grandes.
esto esta en la parte visible de computeremuzone si no recuerdo mal, en la parte de programacion, y luego en como detectar colisiones. En mi Foro/FAQ aun no he puesto la rutina, ni otra que tengo para subir, aunque no hay mucho en ella, a lo mejor te resulta util alguna http://z80user.zobyhost.com/foro

P.D. sorry por la referencia externa, pero creo que es necesaria

Se me olvidaba, mira aver si en la camara de video, tienes algun ajuste, para que grabe a 25Hz o a menos los videos en los que enfoques a la TV (algunas pone tambien modo TV, pero mejor cuanto mas lento ), te quitaras las bandas que se ven en los videos, y supongo que en la camara los deberas notar al grabar.

[na_th_an]

Usa el algoritmo de Bresenham. Se basa en aritmética entera únicamente y puede irse calculando poco a poco.

Código: Seleccionar todo

function line(x0, x1, y0, y1)
     boolean steep := abs(y1 - y0) > abs(x1 - x0)
     if steep then
         swap(x0, y0)
         swap(x1, y1)
     if x0 > x1 then
         swap(x0, x1)
         swap(y0, y1)
     int deltax := x1 - x0
     int deltay := abs(y1 - y0)
     int error := deltax / 2
     int ystep
     int y := y0
     if y0 < y1 then ystep := 1 else ystep := -1
     for x from x0 to x1
         if steep then plot(y,x) else plot(x,y)
         error := error - deltay
         if error < 0 then
             y := y + ystep
             error := error + deltax

[apenao]

Gracias por los consejos. Lo que tenía hasta ahora era mucho más simple: Un bicho que va rebotando en las paredes y cada X pasos cambia de dirección aleatoriamente. Tenía previsto implementar 3 o 4 tipos de movimientos de enemigos (lo típico, el enemigo con movimiento lineal tontuelo, el semi-autista, etc) pero me he encontrado con un problemilla que ha derivado en otro.
En primer problema es el hecho de tener que meter un juego ahí dentro. Hasta ahora todo lo que he hecho han sido juegos para el "crap games compo", así que hacía unos gráficos que se movieran con qaop y a correr. Ahora me veo moviendo la chistera por la mansión y me gusta porque lo he hecho yo y los gráficos no están mal (al menos para lo que venían siendo mis estándares), pero no me imagino a una persona ajena al proyecto (es decir, a otra persona que no sea yo) divirtiéndose con esto. Tenía la intención de hacerlo en plan videoaventura pura y dura, pero con tantas habitaciones (tiene 224 si no recuerdo mal) va a ser bastante coñazo. Así que he pensado en hacer un arcade-aventura y aquí llegan las complicaciones: El motor de sprites que uso es demasiado lento para mover más de 2-3 sprites en la pantalla. Al principio era bastante reacio a cambiarlo pero dadas las circunstancias no voy a tener más remedio (y no me está viniendo mal hacerlo porque ya tenía abandonado el assembler y así voy repasando). Todavía no tengo decidido si hacer un buffer intermedio donde pintar los sprites rotados e imprimirlos luego directamente sobre la pantalla o liarme la manta a la cabeza y hacer uso de una buffer de la superficie de juego entera. Probaré ambas cosas y decidiré.
Tambien está el tema de la memoria. Al meter todos los gráficos (y todavía faltan los enemigos y otras cosillas) me estoy quedando corto. El principal problema es que para general el mapa lo hago con una matriz en la que, en aras de una mayor claridad del código una vez esté terminado y publicado, uso bytes enteros como flags en vez de hacerlo con bits (o grupos de bits cuando sea necesario).De manera que ahora me encuentro por un lado teniendo que optimizar el código en ensamblador para que sea más rápido y por otro lado sopesando hasta que punto puedo "estirar" las rutinas gráficas para que me quepan junto con el resto del juego en 48k. Lo bueno de esto es que me encanta hacerlo, porque voy practicando en ensamblador y al ver el resultado en el juego me da un subidón de autoestima Lo malo es que voy a tardar más de lo que esperaba. Además estoy con otro proyecto para el concurso de Radastán que ese sí tiene un plazo, así que hasta fin de año probablemente le dedicaré menos tiempo incluso que hasta ahora (aunque antes terminaré la adaptación del motor de sprites ya que estoy en ello).

Bueno, veo que me he ido por las ramas como acostumbro. En cualquier caso, cuando tenga listo el motor de sprites pediré un voluntario para beta-testear el juego porque necesito opiniones externas sobre algunos aspectos de la jugabilidad y creo que es mejor no sacar más "demos" públicas porque al final todos los posibles usuarios finales van a conocer el juego de memoria y va a perder el "factor sorpresa".

Un saludo a todos y gracias de nuevo por los comentarios.

[Boriel]

Lo primero de todo, he estado MUY perdido últimamente (cambios a babor, en la vida de uno). Pero de vez en cuando os leo.

Usa el algoritmo de Bresenham. Se basa en aritmética entera únicamente y puede irse calculando poco a poco.

Lo segundo: creo que apenao sigue usando el compilador ZXBASIC (proyecto que sigue vivo). El compilador no emplea la rutina DRAW de la ROM del Spectrum, sino la suya propia, y usa el algoritmo de Bresenham (creo que lo comenté en el interminable hilo del compilador que hay en este foro), tanto para líneas como para circunferencias. Fueron programadas en ensamblador, y especialmente la versión para circunferencias tiene una velocidad espectacular.

Lo comento por apenao: si sigues usando el compilador (espero que si ) y ya usas DRAW, creo que no vas a obtener aceleración. Te echaría una mano en lo que se pudiera optimizar, pero creo que no voy a estar muy libre hasta el 2015 Bueno, vale, quizá hasta dentro de un par de meses.

[Z80user]

La idea es crear una trayectoria, en la que el punto de origen, va cambiando de posicion, segun nos acercamos al destino, que tambien se mueve, en un entorno abierto, libre de obstaculos.

Si uso el algoritmo de la diferencai de distancias entre 2 puntos, que usa una division, esta es extremadamente lenta, pero luego calcular los pasos posteriores, es muy rapida, salvo en diagonales.
El algoritmo de Bresenham, es extremadamente rapido en crear los valores iniciales, pero es bastante lento, al calcular los pasos posteriores.

error = X/Y
10 for n=1 to 8
20 A=A+error
30 IF a>1 THEN a=a-1
40 NEXT n
Convirtiendo esto a ensamblador es rapidisimo
1-. Sumar al registro A, el valor de C
2-. Mover hacia la izquierda el registro B, metiendo el bit del acumulador
3-. repetir los pasos anteriores (desenrollandolo mas rapido)

Con Bresenham, las operaciones para calcular la resta son algo mas complejas
1-. Restar al registro A, el valor de C
3-. si es menor de 0. Mover hacia la izquierda el registro B, metiendo el bit del acumulador
3-. si es menor de 0. Incrementar el registro A, con el registro D

Con lo que en principio es una operacion muy simple, y que en principio, usar una division parece muy costoso, a la hora de la verdad, trabajar con punto decimal fijo, es mas rapido, aunque en distancias grandes puede que se pierda precision.
El algoritomo de la division, para distancias grandes es mas optimo que el de Bresenham, que sale mas optimo para calcular distancias cortas.

Si haces algo asi, para lo de los zombis, tienes medio consegido lo de que piensen lento, sin tener que calcular hacia que direccion deben de moverse. (son zombies)
aunque claro, yo estoy pensando en ASM y tu en basic compilado. Al menos que tengas alguna idea mas para el juego.

[na_th_an]

Lo primero de todo, he estado MUY perdido últimamente (cambios a babor, en la vida de uno). Pero de vez en cuando os leo.

Usa el algoritmo de Bresenham. Se basa en aritmética entera únicamente y puede irse calculando poco a poco.

Lo segundo: creo que apenao sigue usando el compilador ZXBASIC (proyecto que sigue vivo). El compilador no emplea la rutina DRAW de la ROM del Spectrum, sino la suya propia, y usa el algoritmo de Bresenham (creo que lo comenté en el interminable hilo del compilador que hay en este foro), tanto para líneas como para circunferencias. Fueron programadas en ensamblador, y especialmente la versión para circunferencias tiene una velocidad espectacular.

Lo comento por apenao: si sigues usando el compilador (espero que si ) y ya usas DRAW, creo que no vas a obtener aceleración. Te echaría una mano en lo que se pudiera optimizar, pero creo que no voy a estar muy libre hasta el 2015 Bueno, vale, quizá hasta dentro de un par de meses.

Lo que necesitaba (o al menos eso entendí) es una forma de calcular trayectorias lineales. Se trataba de usar el algoritmo para conseguir DX y DY en cada paso de una trayectoria, no para dibujar lineas

@Z80User: Tenía entendido que el algoritmo de Bresenham es el más rápidos para calcular una linea en el caso general. De hecho no tiene ninguna división, y no estás acarreando un error que se acumula con cada iteración. Supongo que cada caso tendrá su óptimo, por supuesto,

[apenao]

Hola Boriel

Ya me imaginé que estarías de vacaciones o muy liado. Claro que sigo usando el compilador, pero ahora estoy retocando el mapeado y los gráficos para hacer hueco (estaba regular de memoria) y no "programando" en sentido estricto.

Por cierto, la última versión que colgaste me daba el mismo fallo que te dicen en tu foro (el de pos.bas), pero vamos que ahora mismo da igual porque no iba a usar todavía las opciones nuevas.

En cuanto al algoritmo de Bresenham, pues es como dice Nathan. Iba a usarlo para calcular la trayectoria de un sprite no para dibujar una linea. Y es cierto que el compilador es rapidísimo trazando lineas. De hecho mi primera idea era hacer los fondos con tiles, pero cuando vi lo rápido que era me apeteció más hacerlo con draws Me gusta que se vea como se dibuja la pantalla al entrar en ella (siempre que sea lo suficientemente rápido, y en este caso lo es).

Bueno, ya te iré contando cuando haya más avances.

Un saludo y de nuevo gracias a todos por el interés.

[na_th_an]

Una cosa, que dices que andas corto de memoria... ¿Cómo almacenas las pantallas dibujadas con DRAW? ¿Tienes en el programa la rista de PLOTs y DRAWs a pelo? Podrías ahorrar mucha memoria si codificaras todo esto en una lista de números interpretable.

Por ejemplo, y sin optimizar nada, podrías emplear 3 bytes por instrucción:

Código: Seleccionar todo

PLOT -> 0 x y
DRAW -> 1 x y
END -> 9 0 0

En el primer caso, (x, y) representan dónde se pone el punto, y en el segundo, hasta donde llega la linea. De ese modo, esto pinta un cuadrado:

Código: Seleccionar todo

Dim command As uByte
Dim cx As uByte
Dim cy As uByte
Dim x As Byte
Dim y As Byte
Dim pointer as uInteger

x = 0
y = 0

datos:
Asm
   defb 0, 50, 50, 1, 100, 50, 1, 100, 100, 1, 50, 100, 1, 50, 50, 9, 0, 0
End Asm

pointer = @datos

Do
   command = Peek (pointer)
   cx = Peek (pointer + 1)
   cy = Peek (pointer + 2)
   pointer = pointer + 3

   If command = 0 Then
      Plot cx, cy
      x = cx
      y = cy
   Else If command = 1 Then
      Draw cx - x, cy - y
      x = cx
      y = cy
   End If
Loop while command <> 9

(Sin probar, pero debería funcionar o tener muy pocos fallos ) De este modo cada pantalla te la almacenas en unos cuantos bytes que, además, podrían comprimirse de mil formas (por ejemplo, con ristras de draws sin tener que repetir el comando "draw").

[apenao]

Pues sí, entre otras cosas chapuceras tambien está la ristra de plots y draws. Ya tenía pensado hacer algo así, aunque con tu ejemplo lo veo más claro que como se me había ocurrido a mí.

Es lo que pasa cuando programas anárquicamente, sin un esquema. Se me van ocurriendo cosas sobre la marcha y las hago, luego me doy cuenta de que ocupa mucha memoria, o es muy lento...

Pero bueno grandes obras maestras se han hecho sin guión, como Casablanca o Uchi-Mata (bueno, Uchi-Mata si que lleva guión). En fin.

[apenao]

Pues he estado mirando el código y tengo un buen montón de plots y draws. Como iba haciéndolos uno a uno en un fichero aparte, no me di cuenta de lo que iba "engordando" el programa. De manera que lo primero que voy a hacer es una rutina como la que dice Nathan y probablemente gane bastante espacio.

¡Gracias por el consejo!

[na_th_an]

Seguro que te ahorras un montón Suerte.

[valdivia]

weno apenao era para decirte buenas noticias ,ya como he acabado los estudios empezare a hacer la portada del jeugo como prometi ,diseñare varios dibujos para ver cual te convence mas

[apenao]

weno apenao era para decirte buenas noticias ,ya como he acabado los estudios empezare a hacer la portada del jeugo como prometi ,diseñare varios dibujos para ver cual te convence mas

Gracias, pero no tengas prisa. Ahora estoy con un proyecto supersecreto que tiene fecha de entrega (además de que estoy un poco enviciado con el NBA 2k11), así que seguramente lo dejaré en el horno hasta después de navidad.