Posté le 24/11/2019 17:47
!
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 
)
Ajout des compteurs(pièces, score, vies, temps) fonctionnels.
Ajout des goombas, cadeaux et des briques fonctionnelles.
Image du 15/02/2020 (J'utilise l'émulateur, c'est plus propre maintenant non ? )
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) 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
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 239 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
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.
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 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
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
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
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
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
@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