Re: [C/SDL/SGDK] Le bouzin du Kane

[Top l'âne]

Autre question. SDL me permet de créer une Surface *ecran, que je peux envoyer à mes fonctions pour ne pas avoir à surcharger le main. Y a t'il une approche similaire avec SGDK?

Euh la plus étrange de tes question , je vois pas en quoi le SGDK d'empeche de faire un pointeur et ou d'empeche de faire une fonction.

Je mets en avant mon syndrome de noobitude autodidacte. Pour l'instant plus souvent cerné par le doute que par les certitudes.^^
En définitive j'avais déjà ma petite idée sur la question et ta réponse à suffit à me conforter.
Je me suis sorti le doigt, j'ai farfouillé une petite heure, et j'ai trouvé la méthode. Merci.

De fait ma démo Space Invaders pour MD avance pas mal, je suis bien content.

[Top l'âne]

Autre question. SDL me permet de créer une Surface *ecran, que je peux envoyer à mes fonctions pour ne pas avoir à surcharger le main. Y a t'il une approche similaire avec SGDK?

Euh la plus étrange de tes question , je vois pas en quoi le SGDK d'empeche de faire un pointeur et ou d'empeche de faire une fonction.

Je mets en avant mon syndrome de noobitude autodidacte. Pour l'instant plus souvent cerné par le doute que par les certitudes.^^
En définitive j'avais déjà ma petite idée sur la question et ta réponse à suffit à me conforter.
Je me suis sorti le doigt, j'ai farfouillé une petite heure, et j'ai trouvé la méthode. Merci.

De fait ma démo Space Invaders pour MD avance pas mal, je suis bien content.

A bientôt pour d'autres questions étranges.^^

[Top l'âne]

Hop hop hop, énorme source de satisfaction ce 4 février.



Une démo impeccable.
Un écran titre, un game over (par touche ou par invasion), et enfin... Enfin... Un put'*n d'algo propre pour le pattern aliens.
La vague se déplace comme un seul homme que ça fait plaisir à voir.

D'aussi loin que je l'ai testé, pas un seul bug à l'horizon. Je n'avais pas encore atteint un tel niveau de réussite avec la SDL. Je code du Space Invaders depuis octobre, une certaine lassitude pointait du fait de mes demis-succès, et donc de mes demis-échecs... En définitive je suis d'autant plus ravi que cette réussite accompagne mes premiers pas sous SGDK.

A ceci j'ai ajouté l'affichage du score.
Me reste à me pencher sur l'accroissement de la difficulté/vitesse des aliens pour présenter un soft globalement complet... Et puis bon, y a la partie son (visite du topic SGDK dans 3 minutes).

[tetsuro]

Super travail, content que tu avances 

[Top l'âne]

Que oui!^^

Je t'avais dit que je laissais le problème d'algo de côté pour avancer, mais ça me tourmentait tellement  que j'ai fait fumer ma cafetière pour en venir à bout.

J'ai largement dépassé le seuil que je m'étais fixé pour cette prise en main de SGDK, great success!

A côté je cogite sur un autre petit jeu de tableau pas trop ambitieux qui me permettra d'appréhender d'autres fonctionnalités d'affichage d'animation et de collisions.

[tetsuro]

Je vois que tu es un obsessionnel, lol, on se ressemble. Je rentre sur Carcassonne mardi, on pourra parler de ton petit projet de plateau, ça m'intéresse.

[Top l'âne]

Oyez oyez!

J'ai l'immense satisfaction d'avoir mené à terme mon premier jeu. Clone de Space Invaders dont voici une courte démo:



Le bin tourne parfaitement sous émulateur.
Tetsuro m'a fait le plaisir de le lancer sur son everdrive, le résultat s'en trouve moins glorieux avec une succession de bugs dont un freeze rédhibitoire en cas de collision d'un alien. Impraticable en l'état donc.^^

Mais je profite de la commande groupée actuelle pour faire l'acquisition de mon propre Mega Everdrive, ce qui me permettra de suivre au mieux l'élaboration de mon prochain projet.

Cet essai de SGDK laisse quelques questions en suspend que je vais plutôt postées dans le topic dédié.

[Stef]

Felicitations :) C'est vraiment un beau projet surtout quand on considere que c'est ta premiere realisation sur Megadrive. Deja le fait d'arriver a la fin d'un projet comme celui-ci c'est deja un sacre accomplissement en soi
Helas il n'est pas etonnant de rencontrer des problemes en testant sur la vraie machine compare aux emulateurs, SGDK te protege un peu contre ca mais c'est toujours beaucoup plus sensible sur la vraie machine... un everdrive est primordial pour tester tout au long du dev !

[tetsuro]

Coucou Stef, oui effectivement, tu as raison, j'ai justement testé son Space Rush sur MegaEverdrive v1 et il y avait des bugs qui n'étaient pas présents sur émulateur. Même l'affichage différait légèrement comme un balayage sur l'animation du vaisseau du joueur par exemple.
En tous cas c'est vraiment super qu'il ait fini un projet, ça doit être une immense joie pour lui, j'ai hâte d'atteindre son niveau :)

[Invité]

Bravo pour ta première réalisation !!


C'est toujours gratifiant de concrétiser un premier projet sur une machine rétro.
Concernant ton problème sur Megadrive Physique, c'est la 2ème partie de ton projet si tu veux réaliser une petite sortie physique, le débuggage "à la main" avec un Everdrive d'un côté, et ton compilateur de l'autre !


Pour ma part, cela m'a occupé pendant prés d'un mois sur Papi Commando ...

[Top l'âne]

Merci les gars. 

L'aventure continue. 

[ichigobankai]

Tu utilises quoi comme Emu ?
Je pense que tu dois utiliser Gens ou Kega... 
Prend plutot Regen ou Exodus, ils sont bien plus proche du hard (et donc moins permissifs) que les 2 premiers.

[Top l'âne]

Effectivement c'est un Kega.
Je vais donc me pencher sur Regen et Exodus, merci du tuyau.

[tetsuro]

Merci ichigobankai pour cette info, effectivement je viens de tester Space Rush et Regen bug au même endroit que sur la vraie Megadrive.

[Top l'âne]

+1
J'ai pu contempler la bancalitude de mon soft avec Regen.

Tetsu m'avait mis sur une piste après les essais sous Everdrive.
Après une bidouille rapide j'ai mis le nez sur le bout de code incriminé:

 for(i = 0; i < 50; i ++)
        {
            if(collision(laser, alien) == 1)
               {
                
                    SND_startPlay_4PCM_ENV(explode_16k, 8196, SOUND_PCM_CH2, 0);

                   laser.posy = 0;
                   alien[i].vie = 0;
                   alien[i].posy = 240;
                   level++;
                   score += 10;

                    if(level == 50)
                    {
                        score += 200;
                        waitMs(500);
                        wave(continuer);
                        waveBack--;
                        continuer = 3;
                    }
               }
        }

[/i][/i]
En supprimant la ligne d'envoi du son d'explosion, le bin a été accepté sans défaut par Regen. Et youpi!
Je maintiens l'intégrité du soft en réduisant le len en second argument comme suit:

SND_startPlay_4PCM_ENV(explode_16k, 512, SOUND_PCM_CH2, 0);

Tetsu a recompilé dans la soirée, le projet sans ce son, et j'avais un texto au réveil pour me dire que l'essai en Everdrive était concluant. Et re-youpi!!

Je suis très surpris que le problème vienne de là tout simplement, je me serai attendu à devoir retoucher mon code plus en profondeur.
Ceci dit, je ne sais pas exactement en quoi consiste cet argument...[i]

[/i]

[Top l'âne]

Je poursuis mon petit bonhomme de chemin sous SGDK. Avant de me lancer à nouveau dans un projet complet j'ai l'idée de créer une petite succession de jeux sommaires visant à explorer les fonctionnement/contraintes/mises en place des canons de l'arcade de salon. Principalement un plateformer et un shmup. Ce qui devrait m'ouvrir les bases pour envisager tout et n'importe quoi par la suite.^^

J'ai attaqué ce dernier la semaine passée avec un petit sprites sheet:



Les contrôles du vaisseau sont réglés (mouvement/tir), ainsi qu'un premier pattern aliens. Ils arrivent par la droite et bouclent autour de l'écran. De quoi envisager rapidement une première séquence de jeu.

J'ai enfin vu comment accéder à l'intégralité de la palette couleur. Une bonne chose de faite.
Je prévois un premier pas dans l'animation avec des explosions.
Et bien entendu le gros morceau, l'acquisition des scrollings. J'ai déjà effectué un test relativement concluant, donc j'aborde cet exercice sereinement.
Autre nouveauté en perspective, la collision au pixel pour en finir avec les sprites outrancièrement rectangulaires.

Au final j'ambitionne une petite run de trois à cinq minutes tout au plus.

Evidemment un peu de son ça serait pas de refus. Je compte repomper ici ou là des mélodies existantes mais savez vous s'il est possible de mettre la main sur une banque de bruitages?
(tir, explosion, saut, ramasser un power-up, etc...)

[Top l'âne]

Hop, j'ai trouvé une petite banque de sfx, format mp3 ou wav ici:
http://www.universal-soundbank.com/jeux-videos.htm

J'ai passé la dernière huitaine à pondre une douzaine de patterns aliens ainsi que quelques patterns de tirs ennemis.(en ligne, en diagos, à tête chercheuse)

J'avais également effectué un color-swap pour une seconde tranche d'ennemis avec des patterns moins agressifs et qui devaient tirer justement.

Mais comme je ne sais pas encore optimiser mes ressources, j'ai eu la vilaine surprise de voir le jeu ramer ostensiblement lors de la mise en place des collisions.

A propos des collisions justement, suite à quelques lecture, j'ai laissé de côté l'idée du pixel près. Quelques bounding boxes devraient suffire à les ajuster.

Je suis donc en train de remettre le code à plat. Réduire le nombre de sprites, pour une meilleure fluidité. Ce que j'avais hier soir commençait à me plaire pas trop mal.

Comme je ne me suis pas encore penché sur le Sprite Engine de SGDK j'ai bidouillé une décrémentation de variable dans ma boucle principale pour caler les explosions et ça passe bien.

Pour finir, afin de me sortir la tête des rédactions de patterns, j'ai mis au point un système de loops avec augmentation relative des pv aliens.
Au final avec un système de scoring basé lui aussi sur les loops, j'aurai un petit jeu complet plus étoffé qu'une démo sur un unique run.
Pour l'occasion j'avais planché sur un concept de chain-kill qui ne trouvera pas vraiment sa place ici, puisque les vagues aliens sont lancées sans interruption.

Un petit screen déjà obsolète en fait, juste histoire d'égayer le post en conclusion.

" />

[Invité]

Mais comme je ne sais pas encore optimiser mes ressources, j'ai eu la vilaine surprise de voir le jeu ramer ostensiblement lors de la mise en place des collisions.

A propos des collisions justement, suite à quelques lecture, j'ai laissé de côté l'idée du pixel près. Quelques bounding boxes devraient suffire à les ajuster.

Les collisions au pixel près sur une console 16 bits chaud , a part faire des mask je ne pense pas qu'il y a une solution plus rapide que celle ci.
Les collisions c'est vraiment un domaine particulier , sur PC on peut se permettre de faire des 'erreurs' et faire du temps de calcul perdu , sur une vielle machine il faut vraiment faire attention.
On tout cas je te souhaite de continuer dans cette voie , tu choisi tes projets qui suit ton niveau et ton évolution , tu ne peux que t'améliorer

[Invité]

Tout comme Kannagi le dit, je te conseille de faire une détection de type "Box", au plus simple !
Pour Papi Commando, avec énormément de sprites en tout genre et des types de collisions ( Avec le décor, entre les unités, avec les projectiles, etc ... ) j'ai opté pour une détection toutes les 8 frames.
Cela se voit à peine, et ca m'a permis de rien perdre niveau vitesse.


On peut réfléchir en créeant une variable TimerHitBox.
TimerHitBox++ 'On l'incrémente.
Si TimerHitBox>=9 alors Appel SousProgrammeHitBox:TimerHitBox=0


Voila en gros.
Pour ma part, concernant la détection entre Sprite, je travaille avec leur coordonnées.
Je calcule la valeur absolue entre elles ABS(XA-XB) et ABS(YA-YB) et je défini l'intervalle qui détectera la détection, selon la taille de l'élément.

Bon courage ! :)

[dub]

Sympa les sprites et bravo pour tes progrès.

[Top l'âne]

Merci pour vos encouragements chers camarades.

@Vetea: j'ai accueilli ton intervention avec beaucoup d'intérêt.
Je me sens encore un peu flou vis à vis de la notion de "frames". J'entrerai plus en avant dans le sujet avec l'étude du Sprite Engine.
Pour l'instant j'utilise simplement la boucle principale comme valeur de référence. (mais de toute façon est il possible d'avoir plus d'une frame par boucle...?)

Je me suis précipité sur ce procédé de timerHitBox que tu me présentes.
Mais il ne me permet pas de sauter les tests de collisions plus d'une boucle sur deux.
Au delà le rendu m'a parut nettement désynchronisé.
Et finalement cette optimisation ne m'a pas permis  de produire davantage de sprites.

En l'état je tourne sans ralentissement avec
-11 sprites pour le vaisseau+tir.
-5 sprites aliens.
-5 à 7 sprites de tirs aliens.

Le tout en mouvement perpétuel et avec toutes les incidences de collisions nécessaires pour le jeu.

Si je me retourne un peu sur les shooters pro de l'époque j'ai l'impression de ne pas être si éloignés de ce qu'on pouvait y trouver.

Ma fonction de collision est tout simplement celle présentée généralement dans les tutos:

Code:

bool Collision(AABB box1,AABB box2)


Code:

{


Code:

   if((box2.x >= box1.x + box1.w)      // trop à droite


Code:

    || (box2.x + box2.w <= box1.x) // trop à gauche


Code:

    || (box2.y >= box1.y + box1.h) // trop en bas


Code:

    || (box2.y + box2.h <= box1.y))  // trop en haut


Code:

          return false;


Code:

   else


Code:

          return true;


Code:

}

Ca me semble raccord à ce que tu proposes.



Pour l'heure ma run est presque complète.
Me reste principalement à coder la phase du boss avant de m'atteler au décorum (scrolling, scoring, title, son, etc...).


Si j'ai le temps, une petite vidéo de WIP la prochaine fois.

[Invité]

La technique de Vetea pour les collisions est bonne a condition que les vitesses ne sont pas très élevé en gros de 1 pixel ou moins (sur une vitesse de 3 pixel , sur 3 frame pour update on a deja 9 pixel de décalage), pour ma part on ne dirait pas comme ça mais j'utilise des vitesse de 4 pixel par frame pour les dégâts qui est bien sur decrementer  (quand on tape un lapinou).
Pour ma part je l'utilise aussi mais pas pour les collisions (je pense que cela doit être précis pour ne pas avoir un impact niveau gameplay ou visuel).
En gros j'utilise un timer pour les palettes mais je compte l'utiliser pour encore pour deux choses :
-l'animation de BG (mais Vetea semble deja le faire sur son bomb in the pixel ).
-gérer les 64 ennemis max de la map (faudrait pas être très sain de gérer 64 ennemi sur la même frame) , je gérerais par groupe de 8 (donc 8 frames pour gérer le tout).
Dans ton cas tu devra peut être faire cela aussi si tu as beaucoup de vaisseau sur un level , bref pas faire 100/200 ou plus if par frame pour voir s'ils sont a l'écran et voir si tu vas activer leur IA/pattern ou pas

Pour les collisions la fonction que tu as faite ressemble a un point/rectangle et non un rectangle/rectangle , le point/rectangle il est possible de donner l'impression d'un AABB en faussant les valeurs.
Mais je pense que c'est une partie qui doit le mieux être fait en assembleur pour avoir la bonne optimisation.

[Top l'âne]

Merci pour les précisions Kannagi. En effet j'ai tendance à booster la vitesse de jeu pour avoir rapidement un visuel pendant la phase de Dev. A retenter.


Bé pour l'heure je profite d'une conjonction favorable, 8 jours de congés et un everdrive tout neuf sous le pied. Je m'offre donc un break bien mérité niveau prog.

Quelle plaisir immense de voir tourner mes petites créations sur mon cathodique.

J'ai juste pris le temps d'uploader un petit WIP de mon projet:





Reprise du bouzin la semaine prochaine. Quelques menues vagues aliens supplémentaires et un petit boss puis je pourrai m'atteler au scrolling.  :)

++

[Top l'âne]

Nouveau WIP en présentation:



Ajout du scrolling. Saccadé sur la vidéo, mais parfaitement fluide en test.
Enfin une musique in-game en plus des sound effects. Il y a un son pour les touches qui ne détruisent pas, mais inaudible, couvert par la musique (j'ai vu pourquoi). Désynchro du son explosion sur la vidéo.
15 vagues aliens plus un boss que voici:



Deux heures pour coder cette connerie qui m'aurait pris 15 minutes sous paint.^^
Il devient urgent de me pencher sur les utilitaires de création de ressources.

Système de loops augmentant l'endurance des aliens et le scoring.

Cette démo est quasiment complète aux vues de mes ambitions. Je vais bidouiller quelques trucs supplémentaires ici et là pour le fun et revoir quelques points d'apprentissage en détail. Notamment le scrolling.
A la base j'ai pris le tuto de Stef, j'ai donc un scroll simple affilié à chaque plan, mais en bidouillant un peu pour garder la première tuile fixe pour les infos de scoring, j'ai eu la surprise de constater un étrange phénomène.
Les grosses étoiles sont toutes placées sur le B_PLAN, mais comme vous pourrez le voir sur la vidéo, elles ne vont pas toutes à la même vitesse. En fait dans ce cas précis, le rendu est meilleur que voulu, mais je ne comprends pas pourquoi cela arrive.^^

[F.L]

bravo
ça n'est plus vraiment un "bouzin"
c'est rapide et ça a l'air de bien fonctionner tout ça
bon courage pour la suite

[Top l'âne]

Merci FL,

vi ça tourne bien. Je n'ai pas encore passé cette dernière version sur everdrive, mais à priori pas de bug.
J'avais pris le temps de tester et peaufiner la vitesse des divers éléments cette fois (merci les #define...^^).
Je suis très content d'avoir enfin accès à l'intégralité de la palette couleur et au scrolling, je m'éloigne de l'austérité de mon premier Space Invaders et je m'approche un peu plus d'un rendu in-game de l'époque.
D'ailleurs j'ai mes premiers résultats concluant pour l'affichage de bitmaps en backgrounds, j'y travaille encore, mais je suis content de le dire, car ça ne s'est pas fait sans douleur.^^
Bref, je compte pouvoir étoffer encore l'impact graphique de mes prochains bouzins. :)

[Top l'âne]

En attendant un ost original d'un tiers pour accompagner mon shmup et uploader une version finale, je commence à mettre le pied dans mon prochain exercice visant à explorer le plateformer.

Voici une première tentative d'animation de ce qui devrait être le sprite principal:



Je ne me suis pas trop pris la tête en négligeant ouvertement tout travail sur le haut du corps.
J'y suis allé un peu à l'arrache, je m'en rends compte après coup. Plutôt que de réaliser les frames les unes après les autres, j'aurai du découper mon labeur en clés et en intervalles comme pour la réa des animés. Mais bref.

Pour la mise en place globale, je vais m'inspirer principalement de deux titres MD, Ghouls n'Ghosts et Ghostbusters.

[Invité]

Eh ben on commence a etre plus ambitieux c'est bien
Mais bon un plate-former/shooter sur MD c'est loin d’être le plus simple ,bonne chance pour ton projet.

[Top l'âne]

Oui, je m'approche doucement de ce qui représente à mes yeux les fondements du jeu 16 bits.

Je planche sérieusement sur le sample_sprite distribué par Stef. Quand je l'avais ouvert il y a quelques mois, j'y entravais peau de zob, mais j'ai eu le plaisir cette fois, après une première lecture en diagonale, de constater que je comprenais globalement les mécanismes. Un bon point.

Je lisais d'ailleurs je ne sais plus où qu'il le trouvait relativement pauvre, mais de mon point de vue de débutant, c'est déjà pas mal fourni.^^

Beaucoup de nouveaux concepts à étudier en fait.
Outre l'utilisation du sprite_engine et l'exploitation de l'animation qui en découle, j'intègre petit à petit les process de camera ainsi que le défilement d'un tilemap.
C'est également un premier pas intéressant concernant la physique du sprite principal et la notion d'accélération là où je me contentais pour l'instant d'influer directement sur les positions x,y du sprite.


La petite vidéo test qui va bien avec le sprite qui se ballade sur 4 tilesets de 512 pix:






Affaire à suivre. :)

[Stef]

Ah c'est pas mal, tu arrives à bien gérer la caméra et le chargement de map à la volée, c'est déjà une bonne étape de franchie !
Pour le Sprite Engine, je dois reconnaitre que la prochaine version de SGDK apportera quelques modifications sur ce point (il faudra faire quelques modifs sur le code) mais en théorie ça sera un peu plus simple à utiliser =)

[Top l'âne]

Bon j'ai pas trop de mérite pour l'instant, la gestion de la caméra (et le code dans l'ensemble) reste un calque gentil de ton sample, mais effectivement j'ai tout de suite voulu faire l'effort de développer une petite map. C'est un élément de jeu qui me fait rêver depuis le début de mon périple.
J'entrevois donc enfin la possibilité de coder un univers à la mesure de l'imagination et ça c'est très stimulant.

J'ai repris le code de zéro hier soir, s'agit désormais de piger dans le détail et savoir le faire par moi même. Petites crises de nerf en perspective. :)

Tu penses bien que je vais suivre l'évolution de SGDK avec grand intérêt.