[C/gint] SuperCasioBros v0.5
Posté le 24/11/2019 17:47
Bonjour à tous
Voici mon nouveau projet de programmation :
"Super Casio Bros"
Présentation
Cet addin est un remake de
Super Mario Bros. pour les calculatrices monochromes. J'ai commencé à créer ce jeu en raison l'absence de ce titre mythique dans la liste des programmes et le voici, il est encore en beta, mais plus des trois quarts des mécaniques de base sont présentes.
Timeline
Voici ci-joint des images et des explications concernant l'avancement du projet. N'hésitez pas a faire des remarques
!
RdP 169
Cliquez pour recouvrir
RdP 169 (commentaires)
Cliquez pour recouvrir
Ici j'ai ajouté le fond des niveaux, la texture de la roche, et la possibilité de mettre en pause le jeu (mais ça vous ne le voyez pas
)
image du 30 novembre 2019
Cliquez pour recouvrir
Ajout des compteurs(pièces, score, vies, temps) fonctionnels.
Image du 4 décembre 2019
Cliquez pour recouvrir
Ajout des goombas, cadeaux et des briques fonctionnelles.
Image du 12 janvier 2020
Cliquer pour enrouler
Image du 12 janvier 2020. (RdP 173)
J'ai également affiné les spécifications techniques :
Le jeu devrait comprendre 5 mondes, dont 4 de 8 niveaux et un de 5 niveaux. Il y aura un système de sauvegarde, et les mondes se débloqueront un par un : Pour déverrouiller le monde suivant il faudra réussir à finir le monde d'une traite. En plus de ce mode, vous pourrez explorer indépendamment chaque niveau afin de les "travailler" pour ensuite déverrouiller le monde suivant.
Image du 15/02/2020 (J'utilise l'émulateur, c'est plus propre maintenant non ?
)
+Changements mineurs dans la version temps réel :
scrolling de la caméra plus fluide,
ajout des plateformes a mouvement horizontal
correction du bug du "wall jump" découvert par Kikoodx (le grand mario pouvait grimper les murs)
Tester la bêta du jeu
N'hésitez pas à tester la bêta pour contribuer à l'avancement du gameplay Voici les différentes versions disponibles
versions fixées (la dernière de préférence)
version temps réel (repo git), mais cette version peut être instable
Crédits
Le script de conversion de niveaux (image->code) est écrit en python
Le moteur de jeu est codé en C sous atom et est compilé avec gcc
Les graphismes ont été réalisés sous gimp.
Merci à
Lephenixnoir pour le travail énorme fait sur le
fxsdk et
gint
Merci également à GoldenKoble pour une partie des graphismes.
Citer : Posté le 18/02/2020 12:10 | #
Waait, this is not a memory leak
There is always a state when a copy is done and this time, it did not work because the second allocation was impossible. However, this is the first time it happens, and it will remain very rare.
If I'm right, the sh3 have less ram than the sh4 ones. Then this bug is only for sh3 models, which are very short in terms of ram margin.
Citer : Posté le 18/02/2020 12:14 | #
Waait, this is not a memory leak
There is always a state when a copy is done and this time, it did not work because the second allocation was impossible. However, this is the first time it happens, and it will remain very rare.
If I'm right, the sh3 have less ram than the sh4 ones. Then this bug is only for sh3 models, which are very short in terms of ram margin.
Now this is interesting. If this emulator is SH3, then how come the OS version is 2.09? I remember this version is only for SH4A.
Citer : Posté le 18/02/2020 12:16 | #
I had this error by playing a bunch on an older build, if you didn't fixed it there is a memory leak. Critor got one too.
https://tiplanet.org/forum/viewtopic.php?f=51&t=23491&start=10
Citer : Posté le 18/02/2020 12:16 | #
Wait, which model are you emulating and whith which software ?
Is this the SDK, or the manager plus ?
I thought it was the sdk ?
Ajouté le 18/02/2020 à 12:18 :
In fact, regarding to the log, this is not a memory leak, but a lack of ram. Maybe I could optimize that
Invité
Citer : Posté le 18/02/2020 12:22 | #
malloc 12080 FAILED means that when the program tried to allocate 12K of RAM, it did not work because there wasn't enough space available, so it logged that the malloc failed and then it stopped
I had the same message twice. I also had a question : is it normal that when you are in "mode course" and that Mario is "big" in the previous game he still is in the next game?
Citer : Posté le 18/02/2020 12:50 | #
I also had a question : is it normal that when you are in "mode course" and that Mario is "big" in the previous game he still is in the next game?
Actually the "mode course" is a game mode which is near to hte original game: you have to win all the levels of a world with a limited number of lifes. Then, when you earn a bonus, it is conserved level after level.
malloc 12080 FAILED means that when the program tried to allocate 12K of RAM, it did not work because there wasn't enough space available, so it logged that the malloc failed and then it stopped
I had the same message twice.
I will fix it as soon as possible, then. It seems to be quite easy to reproduce.
Citer : Posté le 18/02/2020 12:52 | #
This is pretty strange. I can only guess that interrupt and exception management on the emulator is not as true to the hardware as it could be. Although I can somewhat understand for exceptions, but the sleep functions should definitely work. They work on the same basis as the getkey() waiting and everything else... :o
This is not correct. SH3 and SH4 both have 48k of heap available for malloc(). The Graph 35+E II has 90k but it's the only exception.
What you are referring to is probably the fixed region for the data segments, which is 8k on SH3 and 32k on SH4. This region has nothing to do with malloc().
You are definitely using an SH4 emulator.
Citer : Posté le 18/02/2020 13:08 | #
I think I fixed the bug. (I cannot confirm, I did not find it myself )
Now the game uses less ram, there is only one 12K area allocated at a time.
https://gitea.planet-casio.com/Milang/supercasiobros
Ajouté le 18/02/2020 à 14:24 :
J'ai ajouté le mouvement manuel de la caméra avec les flèches haut et bas. C'est plus intuitif maintenant
Citer : Posté le 20/02/2020 12:10 | #
This bug is disappered in the newest version. (Actually during writing this comment, I let it run alone and no problem occurs.)
But I encountered another bug about timer. If you keep pressing right key all the time during gameplay, the timer suddenly run so fast.
https://imgur.com/PWxYtOg
And another bug which I think it is not your add-in's fault. When you press space key in keyboard in emulator, suddenly the game runs extremely slow. And key input from keyboard doesn't work at all. I have to quit the game and re-enter (by opening other elements in Main Menu as I said before) using mouse to solve this problem.
Citer : Posté le 20/02/2020 15:51 | #
Well, I found the bug. It was not exactly due to the right key, but it was due to a wrong value set in the image counter. You found it with the RIGHT key because it was a specific case that caused it at each game.
It is now fixed
For the second bug, in the emulator, which key/action is assigned to space ? Maybe it is a feature of the emulator which needs more perfs
Citer : Posté le 20/02/2020 15:53 | #
No, I didn't see any button on the calculator blinking, so it does nothing but it affect your game for unknown reason.
Ajouté le 20/02/2020 à 17:11 :
Ah, the timer bug appears again, but this time not just keep pressing RIGHT key...
https://linx.breizh.pm/hyk55s9o.mp4
Citer : Posté le 20/02/2020 18:33 | #
Oops, I just noticed that Thank you for the bug reporting !
In theory, it should happen once in 8 tries, but on the video it seemed to be a little harder
This is now completely fixed : https://gitea.planet-casio.com/Milang/supercasiobros
Citer : Posté le 21/02/2020 08:25 | #
Still exists
https://imgur.com/aKWMGul
(In 0:13-0:14, when I hit the mushroom, the timer just counted down to 392, but it was immediately changed back to 393 for unknown reason.)
Ajouté le 21/02/2020 à 09:29 :
This bug is weird...
https://imgur.com/usB2jGg
Citer : Posté le 21/02/2020 12:51 | #
That's very strange , I don't have any idea, the only instruction which affects the counter is time_left--
Are you sure that you are using the version from the last commit, and not from a fixed version ?
Citer : Posté le 21/02/2020 12:54 | #
You might want to inspect the behavior of gint's timers in the emulator using the gintctl add-in which is made precisely for that purpose (I can give you a build file later today if you don't want to compile it yourselves). Since Super Casio Bros runs, this add-in should run as well, and it has a timer menu where you can observe running timers. It might help detect if the issue is in gint.
Citer : Posté le 21/02/2020 16:25 | #
That's very strange , I don't have any idea, the only instruction which affects the counter is time_left--
Are you sure that you are using the version from the last commit, and not from a fixed version ?
Yes, even in the newest build.
Ajouté le 21/02/2020 à 16:26 :
Btw, did you recognize the second bug? (Which cause "Data is protected" error for unknown reason)
Citer : Posté le 21/02/2020 17:39 | #
That is very strange
On the last version this is a variable which is only affected by 1 instruction: decrementation
I don't know why it should be incremented
For the second bug, I don't have any idea, I am not using BFile yet. Maybe that comes from gint
This big seems to be specific to the emulator
Citer : Posté le 21/02/2020 19:18 | #
On the last version this is a variable which is only affected by 1 instruction: decrementation
I don't know why it should be incremented
Do you ever make copies of it, or save the VRAM to restore it later, or something like that which could lead you to draw an out-of-date value on-screen?
Citer : Posté le 21/02/2020 21:52 | #
No ...
I just decrement, then I call sprintf and I display it, that's as simple as that
I will check that again, but that's very strange
Ajouté le 22/02/2020 à 18:09 :
I tried to fix it for the last time, I didn't found any solution. I passed the variable as static, but that's the last thing I can do
The variable time_left is used twice: Here's the part of the code using it (https://gitea.planet-casio.com/Milang/supercasiobros/src/branch/master/src/score.c)
static int time_left=0;
void levelNew()
{
finish_level=0;
time_left=400;
time_id=0;
}
[...]
void scoreDisplay()
{
char str[10];
[...]
if (mario_dead==0 && finish_level==0)
{
time_id++;
if (0==time_id%8)
{
time_left--;
time_spent++;
}
}
sprintf(str, "%d", time_left);
int i=0;
while (str[i]) i++;
dtext(127-6*i, 1, str, C_BLACK, C_WHITE);
[...]
if (time_left==0)
{
[...] // time over animation
}
}
Je ne comprends vraiment pas, ce sont les seuls endroits où cette variable est modifiée et elle arrive encore à être incrémentée (Je n'ai pas de warning de toute façon et je n'envoie pas d'alias de cette variable nulle part donc je ne vois pas comment elle pourrait être modifiée)
@Calcloverhk, here is the last build https://gitea.planet-casio.com/Milang/supercasiobros/src/tag/0.5.3
It should be fixed, but I still don't understand why the bug still remains
Citer : Posté le 22/02/2020 18:20 | #
À quelle vitesse est-ce que le compteur est supposé descendre ?
Citer : Posté le 22/02/2020 19:37 | #
Le compteur time_id est incrémenté 20 fois par seconde et le compteur descend une fois tous les 8 ticks