Error al subir el archivo \'FROGGER_20111207.bmp\': Usted necesidad de utilizar extensiones de archivo permitidas (para imágenes: jpg, jpeg, gif, png y otros archivos: txt, rtf, pdf, zip, tar.gz, tgz, tar.bz2).
Ostia Bubu eres un hachá tio... la verdad que graficamente está super bien... y más aún programandolo en emsamblador, quizás si puedo rascar tiempo me meta...
Por cierto porque no le hechas un vistazo al Czz80,aunque la sintaxis es C, no es C, es lo muy similar al Basic que utilizo, y creo que puedes avanzar mucho más deprisa... no sé...
Respecto a tu ofrecimiento de ASM, por supuesto que lo acepto, no tengo ni la más remota idea de escribir una sola linea de código... gracias Bubu de antemano...
Memoria para troncos = (7 + 9 + 13) * 2 * 8 * 8 = 3712 bytes
Memora para tortugas = 5 * 3 * 2 * 8 * 8 = 1920 bytes
Total = 3712 + 1920 = 5.5KB
Soy un ignorante del Spectrum, así que seguramente esto que voy a decir es un disparate, pero por si acaso lo suelto. El caso es que más de una vez he oído comentar que el Spectrum tenía 8 colores, pero tiene un bit de brillo que permite pintar esos 8 colores más brillantes y así tener 16. La pregunta es: ¿No se podría usar eso para tener 2 tonos de rojo distintos, uno para el tronco y otro para las tortugas?
En cuanto al tema de optimización y C vs lenguaje de ensamble, a día de hoy lo más recomendable es escribir en C el grueso de los programas y optimizar únicamente en lenguaje de ensamble las rutinas que más tiempo de CPU consumen. Por ejemplo, no tiene mucho sentido invertir el tiempo extra que requiere programar los menús en lenguaje de ensamble, ya que no habrá diferencias apreciables de rendimiento y además los menús son un elemento en los que no pasaremos casi tiempo.
Por otro lado, como decía el gurú de la optimización Michael Abrash en su libro \"Zen of Code Optimization: The Ultimate Guide to Writing Software That Pushes PCs to the Limit\", más importante que programar en lenguaje de ensamble es diseñar (o re-diseñar) inteligentemente los algoritmos. Michael Abrash afirma que mientras que pasar una rutina de C a lenguaje de ensamble puede conseguir factores de mejora como mucho de 10 (lo cuál está muy bien), un rediseño inteligente de un algoritmo puede conseguir mejoras en un factor de 100 o más. Un ejemplo perfecto es lo que comentas Bubu de cómo vas a hacer el scroll al pixel de los troncos, evitando andar trasteando con desplazamientos y más instrucciones. Rediseñando de manera inteligente el algoritmo (independientemente de en qué lenguaje programes) has logrado una mejora que seguro es mayor que si pasases de C a ASM una rutina con desplazamientos.
Después de este tocho, en cualquier caso, el proyecto es relativamente sencillo, lo suficiente como para hacerlo por entero en ASM, así que si el tiempo no es un factor que te escasee, pues tampoco hay problema en hacerlo en este lenguaje.
Pero cuando la rana se suba a un tronco, tendré un sprite sobre otro, y por tanto van a parpadear (murrápido).
Por eso quiero probar (por probar) otro algoritmo aunque sólo sea para el río, el de ir shifteando online.
(...) pueden convertirse en 255 colores por sofware, ya que si pones píxeles 1 y 0 muy cercanos entre sí, y los 1 los colores con rojo p.ej. y los 0 con amarillo, obtienes un naranja virtual.
Voy a intentar hacer así los troncos a ver si consigo un color marrón más o menos guay.
; Repositorio de gráficos
void: incbin \\"includes\\void.bin\\"
tronco0: incbin \\"includes\\tronco0.bin\\"
tronco1: incbin \\"includes\\tronco1.bin\\"
tronco3: incbin \\"includes\\tronco2.bin\\"
tortug0:
tortug1:
tortug2:
tortug3:
tortug4:
cocodr0:
cocodr1:
; Propiedades de pantallas
scr0:
DEFB -1, 5, 0, scr0_row0, can0
DEFB +1, 5, 0, scr0_row1, can1
DEFB +1, 5, 0, scr0_row2, can2
DEFB -1, 5, 0, scr0_row3, can3
DEFB +1, 5, 0, scr0_row4, can4
;scr1:
;DEFB -1, 3, 0, scr1_row0, can0
;DEFB +1, 3, 0, scr1_row1, can1
;DEFB +1, 3, 0, scr1_row2, can2
;DEFB -1, 3, 0, scr1_row3, can3
;DEFB +1, 3, 0, scr1_row4, can4
; Objetos de filas
scr0_row0:
DEFW
tortuga0, tortuga0, tortuga0, void,
tortuga0, tortuga0, tortuga0, void,
tortuga3, tortuga3, tortuga3, void,
tortuga0, tortuga0, tortuga0, void
scr0_row1:
DEFW
tronco0, void, void, void,
tronco0, void, void, void,
tronco0, void, void, void
scr0_row0:
DEFW void, void, void, cocodr0, void, void, void, void, void, cocodr0, void, void, 0
scr0_row1:
DEFW void, void, void, void, void, void, void, void, tortug0, tortug0, void, void, tortug0, tortug0, void, void, 0
scr0_row2:
DEFW void, tronco2, void, void, tronco2, void, 0
scr0_row3:
DEFW tronco0, void, void, void, tronco0, void, void, void, tronco0, void, 0
scr0_row4:
DEFW void, void, tortug1, tortug1, tortug1, void, void, tortug1, tortug1, tortug1, void, void, tortug1, tortug1, tortug1, void, 0
Quizás lo que tenga que hacer es ejecutar los RR(HL) directamente sobre la VRAM, pero recuerdo cuando era chico y pogramaba en C/M que leía siempre que era mejor no escribir direstamente sobre la VRAM puesto que si se hacía seguramente parpadearían los gráficos...
; Convierte un número de 16 bits en ASCII (5 caracteres)
; IN: hl = número
; de = puntero a memoria donde almacenar el array ASCII
num2ascii:
ld bc,-10000
call kk1
ld bc,-1000
call kk1
ld bc,-100
call kk1
ld c,-10
call kk1
ld c,-1
kk1: ld a,\'0\'-1
kk2: inc a
add hl,bc
jr c,kk2
sbc hl,bc
ld (de), a
inc de
ret
¿Llegaste a probar lo de escribir directamente en la memoria de video? ¿Mejoró algo el tema?
Si te vas a plantear desplazar los bits de 2 en 2, yo te sugeriría que mejor lo hagas de 4 en 4, usando la instrucción RLD/RRD
do_collision:
; Detecta si en un momento determinado existe colisión
; entre la rana y un coche
ld ix, sprites_01_road
ld hl, (pos)
call calc_vram ; Calcula en de la dir. VRAM de la rana
do_collision_01:
ld a, (ix)
inc a
ret z ; Si el objeto es 0xFF, no hay más
ld b, (ix + 11) ; Captura el ancho del objeto
ld l, (ix + 12) ; Captura la dirección VRAM
ld h, (ix + 13) ; del coche
sbc hl, de ; Comprueba si coinciden
ld a, h
or l
jr z, do_collision_02 ; Si coinciden, se sale del bucle
ld bc, 16 ; Si no coinciden
add ix, bc ; selecciona el siguiente coche
jr do_collision_01
do_collision_02:
ld (time4), a
ret
Una pregunta que hago para z80 assembler experts:
si defino una rutina de mover los sprites 1 píxel, y la llamo como interrupción enmascarable, por mucho que sobrecargue la ejecución principal, los sprites siempre se moverán igual de rápidos, ¿verdad? Lo digo porque creo que las interrupciones se ejecutan siempre cada N milisegundos, y siempre cada N milisegundos, sea lo pesado que sea el main, ¿nor?
Tiene ud. toda la razón, sr. Raiders, ¡¡así se va a quedar!! El amarillo le da un toque de... destacamiento, por decirlo de alguna manera, jiji.
Pues nada, como regalito de hoy, un vidrio del Yutube ese en todo su esplendor (sin sonido, que no tenía ganas de activárselo, jiji)::
http://www.youtube.com/watch?v=THlOjLZx3o4
¡¡Hasta maña!!
¡¡CROACA!!
- Cuando la rana llegue a la orilla del río, hacer scroll hacia abajo de la carretera para mostrar el río
- Cuando la rana muera en el río (por tiempo, por ahogamiento...), hacer scroll hacia arriba del río para mostrar la carretera
ok, pues eso voy a catar. Voy a intentar un scroll de 8 en 8. Lo que nu sé es si desplazar también el marcador (las 2 líneas de arriba ) o dejarlo donde está y poner entre dicho marcador y las casetas un espacio azul, Creo que lo voy a dejar arriba del todo, y así tendríamos el marcador de arriba y la barra del tiempo de abajo siempre en las mismas posiciones, y sólo se movería la parte central que es el escenario del juego donde se desarrolla la acción, jiji.
Qué desesperante es el río, pero qué desesperante... jiji
Ríete tú de los que peregrinan a la virgen de rodillas. ¡Programando en assembler querría verles yo!
Hombre, si haces como en las versiones de spectrum de colocar solo 3 lineas de coches y troncos, te cabria todo en la misma pantalla, no??? Si vas a hacer dos pantallas, estoy de acuerdo que la transicion se haga lo mas rapido posible, aunque si una vez cruzada la carretera, no vas a poder volver atras, entonces en vez de cinco lineas, haz seis o siete para que sea mas dificil.
Ademas, en el cambio de pantalla, que pasaria con la serpiente que sale en la mitad del recorrido??
Bubu, que sepas que estaré atento a ese huevo de pascua en la versión terminada, reconociendo la inestimable colaboración, los sabios consejos y el apoyo incondicional que tanto mi mujer como yo te hemos brindado en este viaje a la retromadrid para que lleves a buen término tu versión del frogger (AKA \"La puta rana que no salta\")
Como anda el desarrollo bubu, que hace mucho que no veo actualizaciones... (que sepas que tengo en mente la portada, pero voy realmente liao...), Non ti preocupare... que aquí tengo los archivos \"Madre\" :trollface:
Estimados compañeros y amigos, voy a salir aquí y ahora del armario y os voy a contar la dura realidad... sobre el Zx Frogger.
Resulta que hace 2 meses empecé la jornada de sólo mañana y podía tener tiempo para meterle mano al Zx Frogger. Pues al poco de eso resulta que va Murphy y me hace petar el ordeñador, vamos, que salió ardiendo la placa.
No passsa nada, que no panda el cúnico. Saqué rápidamente el disco duro donde entre otras millones de cosas y proyestos tenía el Zx Frogger, lo enchufé en otro ordeñador y.... ¡¡¡NO FUNCIONABA!!!
¡¡¡aJaJaJaJAJAJaJAJAJajAJja!!!
No había forma. Tras mucho probar, me fijé en que una de las patillas del conector IDE del disco duro está rota, así que simplemente, el disco duro no funciona.
Me dio una bajona muy fuerte, y como ya se me está empezando a quitar, me gustaría preguntaros si creéis que esto tiene arreglo. ¿Las tiendas de infosmática arreglan cosas así?
(http://www.maximumpc.com/files/u69/frogger_game_over.jpg)
Ala, ahora ya no tienes excusa para no seguir con el Frogger ;)
AJAJajjAjAJAA, lo que no me pase a mí...
Bueno, logaran, un karmapoint para ti, que aunque sé que prefieres unas cervecitas, me cae lejillos, jiji.
La verdad lo he pensado un par de minutos, y mucho me temo que no se me ocurre ninguna solución mejor que la del cuadrado.
1.- Hacer la rana del color del río.
2.- Cuando la rana \"colisiona\" con un elemento (tortuga, tronco, cocodrilo), enmascarar con lo que hay debajo, usando una máscara con la forma de la rana rodeada de 1 pixel con el color de lo que haya debajo.
Por cierto que me ha llamado la atención un tronco que tiene un anillo amarillo :mog:
copy fro0_0.BIN + fro0_1.BIN + fro0_2.BIN + fro0_3.BIN + fro0_4.BIN + fro0_5.BIN + fro0_6.BIN + fro0_7.BIN fro0.BIN /B
¡¡Hola, torpedos!!
(el tronco debería haber salido magenta, pero sale amarillo, ya investigaré purcuá)
IF (a + b >= h) AND (h >= a)
ld a, d
cp e
jr XXXX
LD A, Y
CP X
JP P, DIRECION
LD A, MAYOR
SUB MENOR
JP P, DIRECCION_MAYOR_IGUAL
LD A, MAYOR
CP MENOR
JP P, DIRECCION_MAYOR_IGUAL
JP M, DIRECCION_MENOR
LD A, X
CP Y
JR NC, X_MAYOR_O_IGUAL_A_Y
; Sigue ejecutando por aquí si Y > X
[...]
X_MAYOR_O_IGUAL_A_Y:
; Sigue ejecutando por aquí si X >= Y
[...] LD A, Y
CP X
JR C, X_MAYOR_QUE_Y
; Sigue ejecutando por aquí si X <= Y
[...]
X_MAYOR_QUE_Y:
; Sigue ejecutando por aquí si X > Y
[...]
ld b, N
otro: call haz_cosas_con_b
djnz otro
ld b, N
otro: call haz_cosas_con_b
djnz otro
call haz_cosas_con_b
ld b, N
otro: call haz_cosas_con_b
dec b
jr nc, otro
La instrucción DEC no afecta al flag de acarreo, así que tu última proposición me temo que no funciona tal cuál la has puesto (podría valer cambiando el DEC por un SUB).
If the ULA is about to access the RAM and it detects either A14 or A15 (ie the CPU is also about to access the RAM) the ULA inhibits the CPU clock temporarily halting the CPU memory transaction until its own transaction is completed.
If you run a program in the lower 16K of RAM, or read or write in that memory, the processor is halted sometimes, as the ULA needs to access the video memory to keep the TV updated; the electron beam can\'t be interrupted, so the ULA is given a higher priority to access the contended memory. This part of memory is therefore somewhat slower than the upper 32K block.
El enlace que me has pasado, en efecto dice que el problema está al leer de esos 16 kIB, pero a mí que alguien me explique cómo puede la ULA leer un dato de los 16kIB de memoria \"baja\" a la vez que la CPU lee un dato de los 32 kiB de memoria \"alta\" siendo el bus de datos compartido. Es como decir que por una carretera de un único carril, pueden pasar por el mismo sitio 2 coches en sentidos opuestos. ¿Tenía Sir Clive Sinclair una varita mágica para conseguir esto? Pues que la pase, porque podría haber ahorrado dinero a todos los que para solucionar este problema utilizan memorias de doble puerto.
Así que aunque yo no entiendo cómo, ¡si lo dice WoS va a misa!
EDITO: En tu ejemplo de la carretera y los coches, sería como si en un sentido hubiera una rampa que subes, pero en el otro sentido la rampa te coge a la inversa, así que no pués subirla, jiji. ¡¡y la carretera es la pispa!!
Bueno, como el diagrama ese que puse no me aclaraba las cosas, he buscado un esquema real (http://k1.dyndns.org/Vintage/Sinclair/82/Sinclair%20ZX%20Spectrum/Circuit%20Diagrams/ZX%20Spectrum%20Issue%202%20-%20Schaltbild.gif) a ver dónde están esas resistencias que me dices... y ahora lo veo claro.
Las cosas que mas nos simplifican la vida en realidad son chapuzas. El sistema de refrigeracion de un frederico, en si es una chapuza, pero anda que no salen buenos de ahi los botellines!!!
Y yo que pensaba que habias dado con la solucion para que \"la puta rana que no salta\" no se resbalara de los troncos encebados.
Hazlo multicarga ya!!!!!
Jeje, es duro intentar frikear siendo padre, sobretodo si tienes la molesta costumbre de intentar dormir alguna que otra horilla por las noches.
Ánimo, que ya te va faltando menos. Eso sí, igual en el curro te van a empezar a mirar raro :forever:
Bueno, bueno, bueeeeno, ¡¡ya estoy instalando aquí el tema que te quema!!
Ponte a trabajar, que es lo que tienes que hacer, y dejar ya la mierda de las maquinitas!!!! :D
Buena idea Bubu, asi seguro que el proyecto recibe un empujón ;)
Por cierto atento a mi blog...:-D
Bubu una preguntilla cuanto llevas con el desarrollo de la rana?¿... en global, no me refiero ni parones ni nada, si no desde cuando generaste el primer fuente...
Pero ya sabes como terminar el juego o aun sigues dandole vueltas al ese problema que tenias con la rana??
Lo vas a hacer todo en la misma pantalla o vas a hacer scroll???
Que tal llevas lo de la serpiente??
Y lo de que no se caiga de los troncos??
Seria un puntazo que pudieras presentar el juego en el retromadrid que viene.
¡¡Este batuex, musicólogo y direstor de la orquesta filarmónica de Froggerlandia, qué grande!!
btw, ¿Alguien ve el vidrio que he puesto?
Tienes cuenta aun en Speccy.org en los foros o en zonadepruebas? Te puedo mandar un privado por ahi :)
Hombre yo compraria la cinta original por supuesto (La tapa anda por aquí ;))... Yo siempre he pensado que si sacará algo para máquinas de 8 bits o quizas en 16 bits lo sacaría al equivalente a 875 pts, por eso de no perder las buenas costumbres... :P , pero bueno eso cada cual... Yo he visto en ebay, pilas duracell por 1.000.000 de Euros :woohoo: , o sea que eso es cosa del desarrollador... :brindar:
¡Hey, el sr. art designer! Tengo que hablar contigo para ir cerrando el tema que quema, jejeje. Respecto al precio, 875 pesetas era cuando una cinta costaba 100 pesetas, jAjajAja, ahora una cinta virgen vale eso, 875 pesetas. El precio lo pone el fabricante, que no creo que exceda los 10 pavos, ya iré viendo...
se pondrá a la venta en formato físico (cinta con su carátula) para goce, disfrute y coleccionismo de todos, ya que este Frogger será el primero de una colección ;-)¿¿ BUBUSOFT ?? ;)
¿¿ BUBUSOFT ?? ;)
Ostia bubu, pues rápido y que suave va el juego, te está quedando o te ha qedaó de lujo...
Ya me dirás... lo de la tapa... que creo que lo debo de tener?¿ :o la question es dónde... Espero no haberlo tronchao.
IvanZx, se me ha ocurrido acuñar un nuevo palabro: SLOWARE, jiji. Y ahí si estaría catalogado este Frogger.
ld a, A
sub B
jp p, (si A>=B)
jp m, (si A<B)
LD A, H
SUB D
JP M, (si HL<DE. Se acabó el proceso)
JP Z, (si H = D. Hay que comparar L con E)
(aquí HL>DE. Se acabó el proceso)
SBC HL, DE
; Comprobación HL > DE
CCF
SBC HL, DE
JP P, (si hl >= de)
JP M, (si hl < de)
cp16bits:
; Subrutina que compara 2 números de 16 bits
; Entrada:
; HL: número1
; DE: número2
; Salida:
; flag NC si HL>=DE
; flag C si HL< DE
; flag Z si HL= DE
ld a, h
cp d
ret nz
ld a, l
cp e
ret
CCF
SBC HL, DE
Pues nu sé... el ejemplo que me hice no me funcionaba. Hacía algo tal que así:Código: [Seleccionar]CCF
SBC HL, DE
uséase, primero limpio el carry flag con CCF, y aluego hago la resta. Y pa números grandes se comportaba al contrario que pa números pequeños.
SCF
CCF
SBC HL, DEAND A
SBC HL, DETorpedos, una pregunta que me tiene janderizado (MetalBrain, si estás por aqui esto es para ti): ¿cómo se pué ampliar un sprite dibujado con SevenuP?
Al iniciar un sprite, le tengo que decir el tamaño, p.ej. 32x16. Me pongo a dibujarlo. Y mientras dibujo, me doy cuén de que me hace falta ampliarlo, 8 píxeles más de ancho. ¡¡Pues nu sé hacerlo!! Tengo que tirar el dibujo y volver a hacerlo...
Nah...
Si la memoria no me falla eran 3.
Bueno, antes de que llegué el ZX Frogger iré practicando con este aparatito :P
ajAJAjaJajAjAjajaA, ¡¡acabo de empezar a pogramar el Frogger de nuevo, desde CERO!!
Ay, lo que puede un par de pelotazos...
jajaja Bubu , ¿ pero no estaba casi terminado ? xDD
IN A, (0xFE)
XOR A
IN A, (0xFE)
Vaya repaso y avance le has pegado , tio !!
A este paso lo veremos pronto jejeje los troncos negros a mi no me convencen, pero es una apreciación personal. Que igual luego es la mejor opción, pero quizás al estar acostumbrado a otro color en el arcade me pasa eso.
Pues sí que es puñetero , sí... Sale siempre ese recuadro , ¿no?
¿ Ves más viable dejar la rana del mismo color que los troncos quizás ? o mejor sacrificar eso a favor de que la rana se vea verde?
Por cierto, en rojo quedan más chulos que en negro a mi entender.
En la otra version que tenias hecha quedaba mejor. Por que el recuadro alrededor de la rana es tan grande?? Supongo que no podras hacerlo mas pequeño porque si no ya lo hubieras hecho, pero seria lo suyo.
Ese cuadrado es ENORME, y se ve horroroso, sea del color que sea.
Yo pondría los troncos del ancho de un carácter y eliminaría la hilera de coches que se ve abajo para poder ensanchar el río.
A una malas, que sea la rana la que adopte el color de allá donde este.
Sí, ya me he dado cuenta de que da igual el color xD. Pues como has dicho, puedes ensanchar los troncos, aunque creo que eso perdería la esencia del juego. Opto porque la tortuga coja el color de donde esté, al menos así no se jode la estética del juego.
Y esa rana rosa que hace ahi?? Sigo viendo el cuadrado enorme, pero pintado de azul se disimula bastante y no queda tan mal.Según entendí, con el juego en funcionamiento, el cuadrado no se verá, ya que la rana estará en un frame si y en otro no. De ese modo, la ilusión óptica hará desaparecer el cuadrado aunque deje en su lugar un sutil parpadeo. ¿No era así, bubu?
Y esa rana rosa que hace ahi??
Según entendí, con el juego en funcionamiento, el cuadrado no se verá, ya que la rana estará en un frame si y en otro no. De ese modo, la ilusión óptica hará desaparecer el cuadrado aunque deje en su lugar un sutil parpadeo. ¿No era así, bubu?
Y esa rana rosa que hace ahi??
Es el player 2 xD
¿Se sabe exactamente si es hembra, primo o hermana?
Pero mu triste porque... ¡¡mi rana se muere!! ¡¡Bwwaaaahhhhh!! ¡¡Pobretica!! Ay, que se me ahoga...