[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 15/02/2020 17:00 | #
Pour l'instant les niveaux font 13 ou 14 tiles de haut, soit au maximum 112 pixels de haut. Mais j'envisage de (pourquoi pas après tout) tester des niveaux en forme de tour, donc qui seraient beaucoup plus verticaux
Si j'ai le temps ce soir, je fais un article pour la rdp de demain J'ai pas mal de petits changements à annoncer
Invité
Citer : Posté le 17/02/2020 21:03 | #
Bonjour, j'ai essayer le jeu mais impossible d'arriver au niveau 4. Le niveau 3 est comme impossible. Une explication ?
Merci d'avance
Citer : Posté le 17/02/2020 21:31 | #
En fait, le jeu est encore en développement, et donc seuls les deux premiers niveaux sont complets. Le troisième est une ébauche, et les autres n'ont pas encore été faits
Merci beaucoup d'avoir testé en tout cas, et n'hésite surtout pas à poster un retour ou proposer des améliorations
Citer : Posté le 18/02/2020 09:18 | #
Salut, j'ai testé la nouvelle version c'est beaucoup plus fluide !
La rémanence est beaucoup moins "lourde" qu'avant, sûrement grâce à la caméra et l'interface moins présente.
Comme l'a noté Lephé' on se retrouve de temps en temps dans des situations où le sol est hors vision (niveau 2), une des solutions au problème serait de déplacer la caméra en maintenant haut ou bas (temporairement).
Citer : Posté le 18/02/2020 09:25 | #
Merci pour ton test
Maintenant que j'ai complètement désactivé les touches haut et bas, je vais peut être les assigner, peut-être avec un raccourci particulier, à la caméra
Je ne sais pas encore trop exactement comment le présenter au joueur, mais c'est dans les cartons
Dans l'idée, la pression seule de la touche haut pourrait faire monter la caméra, de même avec bas. Comme ça ce serait un peu comme Gravity Duck dans l'idée
Citer : Posté le 18/02/2020 09:45 | #
Ça me paraît pas mal, surtout qu'on avance souvent à droite et taper Droite+Haut ou Droite+Bas est faisable sans s'arrêter de bouger.
Invité
Citer : Posté le 18/02/2020 10:09 | #
En fait, le jeu est encore en développement, et donc seuls les deux premiers niveaux sont complets. Le troisième est une ébauche, et les autres n'ont pas encore été faits
Merci beaucoup d'avoir testé en tout cas, et n'hésite surtout pas à poster un retour ou proposer des améliorations
Merci, ça me semblé bizarre d'avoir un niveau impossible. Il y a aussi un petit problème, à la fin des niveaux le drapeau qui devrait être sur le bloc flotte 1 bloc plus loin que la fin donc qd Mario arrive il ne touche pas le drapeau il y a un vide entre les deux.
Bon développement
Citer : Posté le 18/02/2020 11:08 | #
Hello! Thank you for developing this cool add-in game. This is almost stable IMO.
In fx-9860GII emulator, its speed is fair. But in Graph 35+EII emulator, it runs just like the real game! Almost three times faster than fx-9860GII one! (And so the timer is also 3 times faster) But the startup screen and level screen skips immediately (like 0.1 sec) in fx-9860GII one unlike Graph 35+EII.
Also I found a bug that you cannot re-enter the game once you quit by pressing [MENU], [EXIT], or even in-game exit button. You have to load any element other than itself in Main Menu to solve this bug.
Citer : Posté le 18/02/2020 11:19 | #
Once you leave an add-in that terminated its main() function, you can normally not reenter, whatever the add-in.
Usually you use GetKey(), which allows you to press MENU and go back to the menu in a non-terminating way (so you can come back). This is a missing feature in gint's getkey() function, but we already know how to do this (it's a matter of time).
Citer : Posté le 18/02/2020 11:28 | #
In fx-9860GII emulator, its speed is fair. But in Graph 35+EII emulator, it runs just like the real game! Almost three times faster than fx-9860GII one! (And so the timer is also 3 times faster) But the startup screen and level screen skips immediately (like 0.1 sec) in fx-9860GII one unlike Graph 35+EII.
I guess that when you talk about the fx-9860GII emulator, you talk about the ont which is included in the SDK. Unfortunately, the bugs presents in the SDK, especially about speed, are (i think) due to a special behavior of the emulator which is not supported by gint, so I can't fix them
But if you did test it on the Graph 35+EII emulator, which is a true copy of the current model, you could test in real conditions this game
Also I found a bug that you cannot re-enter the game once you quit by pressing [MENU], [EXIT], or even in-game exit button. You have to load any element other than itself in Main Menu to solve this bug.
This is a standard addin behavior, when you exit it, you cannot relaunch it immediately again, you have to run another app before.
However, Lephenixnoir is making in gint an enhanced getkey function, designed to pause the addin when [MENU] is pressed (like in other addins like C.BASIC). When it will be developed I will use it
Thank you very much for testing, and also thanks to Lephe, for all the work about gint, which is very efficient and stable.
Citer : Posté le 18/02/2020 11:30 | #
I should mention that gint's timers are set according to the actual clock frequency so they should really be the same time on all platforms. Do you know more about that emulator special behavior Milang ?
Citer : Posté le 18/02/2020 11:39 | #
In fx-9860GII emulator, its speed is fair. But in Graph 35+EII emulator, it runs just like the real game! Almost three times faster than fx-9860GII one! (And so the timer is also 3 times faster) But the startup screen and level screen skips immediately (like 0.1 sec) in fx-9860GII one unlike Graph 35+EII.
I guess that when you talk about the fx-9860GII emulator, you talk about the ont which is included in the SDK. Unfortunately, the bugs presents in the SDK, especially about speed, are (i think) due to a special behavior of the emulator which is not supported by gint, so I can't fix them
But if you did test it on the Graph 35+EII emulator, which is a true copy of the current model, you could test in real conditions this game
Citer : Posté le 18/02/2020 11:43 | #
First, I noticed that sleep_ms and even sleep functions does not work :
The splash screen, level screens etc are displayed, but without any pause.
Because of that, when I run the game on the SDK, even if the timer speed is fine, the (virtual) cpu never pauses, and this leads to a quite high (real) cpu consumption for this kind of emulator. (This is subjective, but I think its quite heavy to use 50-80% of a single core at 2.8GHz, even in wine)
There is a second specific behavior, but I don't think that we can change anything about it:
There is no gint_panic function called when an exception occurs: The sdk comes first and shutdowns the emulator, and displays a message like this An exception occurred ! Illegal read access at 0xFFFFFFFF for example. This slows down debug, so, ironically, when I have to find the cause of a crash, I have to try it on the calculator
Citer : Posté le 18/02/2020 11:43 | #
Wait, why did I get this picture in fx-9860GII emulator (this time in actual machine), saying "RAM full"?
Did you design it, Milang?
And I can't even press any key there.
Citer : Posté le 18/02/2020 11:46 | #
Oh, maybe you found a memory leak
Can you press the L key and send a screenshot of a few log lines ?
(The key with an arrow, you don't need alpha)
Yes, I designed it, It's a custom error msg
Citer : Posté le 18/02/2020 11:49 | #
This is the latest log.
Citer : Posté le 18/02/2020 11:50 | #
Oo
This is not expected at all
Ajouté le 18/02/2020 à 11:52 :
There is a log hidden in the addin, based on liblog
At any time you can open it by pressing the [→] key, and also in the configuration menu
you should have seen something like
[std] free called
[std] number of zones
1
[std] malloc 280 OK
[std] number of zones 2
Ajouté le 18/02/2020 à 11:55 :
Ouch...
I confirm that this is a memory leak.
It seems that it allocated twice a level without freeing the previous
I will try to reproduce it and fix it
Citer : Posté le 18/02/2020 11:55 | #
Oo
This is not expected at all
Ajouté le 18/02/2020 à 11:52 :
There is a log hidden in the addin, based on liblog
At any time you can open it by pressing the [→] key, and also in the configuration menu
you should have seen something like
[std] free called
[std] number of zones
1
[std] malloc 280 OK
[std] number of zones 2
Yes, I've found out, but what "malloc 12080 FAILED" means?
Citer : Posté le 18/02/2020 11:57 | #
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
Citer : Posté le 18/02/2020 12:08 | #
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
Well, I think I can reproduce the memory leak now. Just load the level 1, don't press any key and wait until this error pops out.
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.