A análise à versão beta do jogo está online.
Antes do mais, com os devidos agradecimentos ao Mark Doney para review, devo dizer que o que ele analisou foi a primeira versão jogável do jogo. Ali as bugs eram abundantes, e ele deu com algumas na review.
Entretanto já tudo foi polido, e muita coisa foi mesmo melhorada, e até acrescentada.
Segui também o conselho dele e acrescentei nomes intermédios. Assim não só teremos nome como FUTEBOL CLUBE DO PORTO, e FCP, como também F.C.PORTO.
Esta alteração foi um problema para mim, e apesar de a perceber como relevante pois é como ele diz, a sigla de 3 letras, mais usada, torna-se confusa, a realidade é que isto estourou-me com o plafond de memória que tinha para corrigir bugs. 🙂
Penso que o jogo corre mesmo assim sem problemas, mas… terei de ver melhor.
A realidade é que creio que as bugs estão agora todas debeladas, mas neste momento não tenho memória para mexer no código, motivo pelo qual vou adiar o beta test que ia fazer aqui com dois elitores, solicitando a sua compreensão, mas a realidade é que tenho de arranjar uns bytes para poder proceder a eventuais correções que sejam necessárias.
Fiquem com o vídeo de review.
Para quem o quer jogar, o lançamento já está para breve, sendo que o Carlos Eduardo Santos, e o Bruno irão ter primazia assim que lhes enviar uma cópia para me ajudarem a remover eventuais bugs restantes.
Ahaha já este fds tinha estado a ver num site da Spectrum alguns prints dessa obra prima
Andei a mexer no código pois fiz uma alteração que me está a impedir de corrigir bugs pois gastei a memória toda. E consegui uma coisa que nunca tinha conseguido. Agora consigo carregar dados para a memória superior, sem os ter de meter primeiro usáveis na RAM principal.
Isto foi um avanço do caraças, dado que o Z80 apenas vê 64 Kb, e eu já consigo endereçar os 128K sem problemas.
Assim que tiver ram livre, dou-te o jogo e ao Carlos, para mo testarem. 🙂
Entendo pouco ou quase nada de programação 😅 .mas entendo a mensagem , quando estiver pronto é só falar
Ora bem, parece-me que já tenho uma margem para poder fazer alguma coisa…
Queria confirmar contigo e com o Carlos que os e-mails usados aqui estão válidos e podem receber mensagens.
Aguardo a resposta dos dois.
Sim
Carlos… E o teu?
Recentemente vi um vídeo de alguém a fazer um pequeno jogo para o Z81, ao fim de umas 20 linhas já não tinha memória nem para editar o jogo, eu nem sabia que ao chegar ao limite de memória já nem se podia editar o código. Uma das optimizações que ele fez foi curiosa, em vez de usar números, como o 1 que se repetia várias vezes, usou uma variável, do género, let x = 1, depois em todos os lados que usava o 1 substituiu por algo como, if a < x then … e em alguns lugares onde usava, por exemplo o 3, ele fazia x+x+x, não me lembro quanto poupava em ram ou se será o mesmo no basic do spectrum 128, mas achei muito curioso.
Também andei à procura de formas de passar o basic de um ficheiro .tap (ou semelhante) para poder editar num editor moderno e depois voltar a passar o código para o spectrum. Consegui extrair o código com a ferramenta tzxtools e o comando tzxcat –basic <ficheiro.tzx>
O problema foi fazer o inverso, passar o código para um ficheiro .tap. Testei as ferramentas zmakebas e bas2tap, mas ambos deram-me problemas em alguns caracteres ascii. Seja como for, ficam essas ferramentas se por acaso te sejam de alguma utilidade.
Eu usei o zmakebas, dado que programo no Notepad, para converter o txt em tap.
Concateno os .tap usando um copy /b 1.tap+2.tap+3.tap 4.tap no ms-dos. O /b indica que estamos a trabalhar com ficheiros em binário.
E sim, quando não tens RAM, nem editar o codigo podes. A máquina fica basicamente impedida de aceitar seja o que for.
Pior ainda, podes criar danos ao código se tentares sequer gravar.
Quanto ao que referes, basicamente estás a trocar memória por processamento. Um número gasta 5 bytes de ram, pois os números são armazenados como sendo de vírgula flutuante. E sempre que usas um número, gastas mais 5 bytes. Meter numa variável guarda o valor apenas uma vez, ao passo que usar X apenas gasta 2 bytes.
Assim, 1+1+1 gasta 15 bytes mais 2 bytes da operação, ou seja, 17 bytes. x+x+x gasta 8 bytes a contar com as operações. É menos de metade.
Isto é um show, mas o código torna-se ilegível, e por isso é uma solução de último, último recurso. Nunca ponderei recorrer a isso.
A unica coisa que não percebo é porque substituir 3 por x+x+x. 3 gasta 5 bytes, e o resto 8. Das duas uma, ou há algo mais que eu não sei, ou ele está errado aí.
Agora o que faço muito é subrotinas em tudo o que se repita.
Seja como for, no ZX 81 com 1 KB de RAM, tudo é relevante.
Mas uma subrotina, apesar de ser a prática ideal de programação, também gasta bytes pois fica à espera do return. Nesse sentido, apesar de menos elegante, podes usar GOTOs, apesar que se torna um problema retornar ao ponto de origem se quiseres usar o código ali presente várias vezes, tendo de se recorrer a gatilhos que se ativam em if then.
Prefiro também não usar.
Uma coisa engraçada que fiz. Uso valores em milhões para representar o dinheiro no jogo. Mas fica feio aparecer 50000000. Para perceberes o valor, tens de andar a contar zeros.
O ideal era aparecer como 50.000.000. Infelizmente o Spectrum não tem como representar isso, pelo que resolvi o problema passando os valores a uma variável Alfa numérica. Depois imprimo-a no ecrã letra a letra a contar do fim, para o princípio, sendo que a cada 3 impressões, meto o ponto.
Tens de ser criativo… :-p
Sobre o TZXTOOLS que não conheço, eu não acedo a código de terceiros. Há uma ética que eu sempre tive, em que respeito a propriedade intelectual dos outros, assim como espero que respeitem a minha. Para além do mais, isso pode dar chatices sérias.
Tenho zero interesse em aceder a código de terceiros, apenas estou a tentar ver o código de um jogo que fiz na altura. Deixo aqui uma captura por se há dúvidas
Lembro-me na altura de ter feito outro jogo de futebol, inspirado no Striker, mas infelizmente não o consegui encontrar. Este futebol 5 é muito básico, escolhes a tática e e rezas para ganhar o jogo hehe. O inspirado no Striker que lhe chamei de Campeonato, dava para rematar à baliza, mecânica semelhante ao Striker. Fiz outros joguitos, nenhum publicado, nem saberia como o fazer na altura, mas infelizmente o único que encontrei foi mesmo o Futebol 5.
Wow… Mas já tinhas grafismo definido por ti. Nada mau,
Obrigado! Cada equipa tinha o seu próprio equipamento.
O que me lembro ter feito na altura, foi substituir alguns caracteres ascii e usá-los para os equipamentos.
Isto são UDGs associados a caracteres, criados como uso de pokes e data bins. E vejo que tiveste o cuidado de dar espaço para caber o quadrado com a cor. Muito porreiro.
Eu pensei em fazer isso, mas isso engordava-me os bonecos, pelo que desisti.
A notícia do jogo já se espalhou.
https://planetasinclair.blogspot.com/2025/02/manager-de-futebol.html?m=1
Muito bom, parabéns!
Num comentário anterior, relacionado com as subrotinas e os GOTOs, mencionas problemas em retornar ao ponto de origem. Não poderias usar o GOSUB? Este deveria de retornar à linha seguinte ao GOSUB que chama a subrotina, mas talvez tenha percebido mal o problema!
O que eu disse é que um GO SUB, RETURN gasta mais memória que um mero GO TO. Nesse sentido se pudéssemos usar sempre o GO Tão era preferível. Mas o problema deste último é o regresso ao ponto de origem que obrigaria a gatilhos IF para retornar ao sitio certo.
Acho que a coisa mais divertida que fiz programando, foi caracteres especiais asc2 de várias formas caindo em cascata, e tendo fade-time igual no filme Matrix durante a faculdade.
Usei C# e deu mais de 1000 linhas. Projetei para 1080P e tinham layers sobre layers de cascatas criando um belo efeito 3D. Porque adicionei uma rotação sagital de uns 15 graus.
Fiz disso ser minha proteção de tela no Windows na época. Gastava poucos recursos.
Mas o do filme Matrix tem alguns caracteres especiais a mais que são diferentes e não os encontrei.
Ficou faltando essa parte.
Aqui tens 16 páginas… cerca de 5000 ou 6000 linhas de código. Mix de Basic e Assembler, apesar que estou a conseguir já bons resultados apenas com o Basic em muitas coisas. Infelizmente para reproduzir audio em 3 canais o Basic não dá mesmo, e aí preciso de algo cerca de centenas de vezes mais rápido pelo que o Assembler é indispensável.
Só para se ter uma ideia, um ciclo for next de 1 a 1000 gasta cerca de 0,5s no Basic, mas é apenas 2 ms no assembler.
Com assembler você consegue até alocar variáveis registradoras até diretamente no CPU de qualquer máquina. Na memoria mais rápida que existe as cache.
Sistemas de tempo real usam muito isso. Como o ABS dos veículos.
O Z80 não tem caches, apesar que tem 14 registos de 8 bits que podem ser usados.
Por exemplo o comando assembler LD A, (HL) lê da RAM, mas posso optimizar ainda mais usando LD A, B que usa os registos e faz a copia, não passando pela RAM.
Felizmente nunca precisei de mais velocidade. O meu código está maioritariamente na linguagem base do Spectrum, que é o Basic. Meter isso tudo em assembler é algo que me daria mais RAM e performance, mas algo para esquecer. Não me vou meter nessa num jogo que vai ser grátis.
Para já, quando o lançar vou tirar um tempinho off, mas depois tenho um conceito baseado no universo da Battlestar Galáctica que quem sabe não meterei em jogo.
Que bacana, Mário! Só não sabia que seu nome era um “trava-línguas” em inglês! Parabéns pelo Remake 35 anos depois!
😉
Parabéns pelo jogo, Mário! Ficou excelente!
Vindo de ti, Tio Hildo, que deves ter sido a pessoa que mais contacto teve com o jogo, pois foste recebendo as betas todas, e uma pessoa que admiro pelo seu trabalho de programação no seu software reconhecido de contagem de FPS, frame Times e resolução, tenho de tomar isso como um elogio que me deixa deveras de peito cheio. 😀