Oldschool is beautiful !

Diverses choses pour ce billet : On va déja commencer par un petit point d'avancé sur les différents projets en cours. - Dungeon and trolls (Coleco) : Le jeu semble pleinement débuggé, la documentation est écrite. Reste du réglage de jouabilité, musique et son à faire ainsi que des écrans d'intro, de gameOver et de fin de jeu. Bref, une 12 aines d'heure et c'est terminé, reste à trouver le temps :) - Bomb Jack (Coleco)  : Je suis en train de recoder le système de collision avec le décor (pour la 3ème fois !!) pour qu'il soit plus précis. Pour cela, je ne lit plus en mémoire vidéo les caractères, mais je crée en RAM une "image" des zones de collision du niveau. La lecture en ram étant plus rapide, je vais pouvoir lire plus de points de collision et être plus précis. J'ai déja implémenté la chose pour les ennemis et ainsi supprimer pas mal de ralentissements ! Cette méthode occupe par contre 96 octets en mémoire (pour ...

J'ai repris l'ancienne formule de OIB, et je l'ai mixé avec les lives sessions. Résultat, 3 tests préparés, mais présentés en "live" pour essayer de rendre la chose plus dynamique ... Je ne sais pas si c'est réussit, ça sera à vous d'en juger !

Chose promise chose due, voici mon tout premier essai de scrolling multilayer sur Dreamcast. Le scrolling le plus lent avance de 12 pixels secondes, le plus rapide à 72 pxs. Bien entendu on peut faire plus rapide sans soucis. Le soucis c'est qu'il m'à fallu pas loin de 45 minutes pour paramétrer ce tout petit scrolling ... Il va falloir soit que je trouve un outil pour m'aider ? (Game maker ?) ou que j'en développe un spécifique pour gagner du temps. En effet je n'utilise pas des tiles carrées ou rectangulaires mais des objets tous de tailles différentes. Il faut donc que je les positionnes en position x ou y dans l'univers virtuel. Et avec un logiciel de dessin, on est vite limité ... Voilou !! Je tente de trouver un outil et ensuite je teste certainement musiques et bruitages sur DC, ou alors les tirs du joueurs ... A voir :)

Dans le dernier post je vous montrais les différentes positions du joueurs selon son mouvement. Le passage d'un mouvement à un autre était très haché, forcément on passait d'une position à l'autre en 1 image ... J'ai donc mis à profit la routine de rotation pour fluidifier le changement de position, et ce sans utiliser d'image intermédaire. Je translate et fait tourner les différentes parties du sprite de manière programmé pour atteindre leur nouvelle position. Voici ce que cela donne en vidéo.

Et oui, je n'arrive pas à m'arrêter .. J'ai fait l'assemblage des sprites et l'animation ... Voici en vidéo l'avancée : Et j'ai également améliorer ma librairie pour gérer rotation par le centre, et le zoom (pas encore par le centre) : Dernière info, vous pouvez dès à présent télécharger le kit de dev Dreamcast ainsi que ma librairie graphique (+ un exemple) sur  http://bfglesite.site90.com/ rubrique "Tutoriaux" puis "Dreamcast" !! Bon coding !! (N'oubliez pas de dégager le Dynarec sous NullDC pour vos tests sous peine de crise de nerfs !!) :) :) Voilou !!

Il est bien possible que le "bug" soit corrigé ... Et qu'en fait le bug en soit, n'existait pas ... mais qu'il y en avait un autre gros comme une baraque à frite (mais qui ne faisait pas planter la chose). D'abord je tiens à remercier PatBier (Dynamite Dreams) ainsi que Johannes Graf (Duranik) pour leurs tests ainsi que leurs corrections. Leur tests ont donnée des résultats différents, mais après analyse, ce sont les même problème qui sont apparu. Pour afficher un "sprite" il faut mapper une image sur des polygones. Ces polygones on des coordonnées x,y en 2D, mais comme on est sur DC on à la 3ème dimension qui rentre en compte, la z. Or, mes sprites avaient tous une priorité Z = 1. Ce qui veut dire que tout les sprites sont sur le même plan. Ceci marche sur l'émulateur mais pas sur la vrai console. D'ou PatBier au premier test de ma rom pensait que le programme plantait depuis le début car le fond de l'image écrasait tout les sprite...

Suite des aventures du bug maudit !!! J'ai 2 pointures du coding Dreamcast qui m'aident sur le sujet. Il semble que mon programme soit tout à fait correct (ouf, je ne suis pas si mauvais que ça :) ) mais qu'on se tourne vers soit un problème de l'émulateur sur lequel je teste (leurs avis), soit éventuellement un problème de ma toolchain de programmation (mon intuition) voire les 2. Pourquoi la toolchain ? Je suis repartit de la base et j'ai compilé le programme de démo qui affiche une simple image. Lancé sur nullDC et la vrai Dreamcast, je vois apparaître quelques pixels roses parasites. J'ai envoyé ce programme à patBier de la DynamiteDream Team qui lui l'à recompilé et ne voit pas les pixels roses. J'ai repris son .elf (exécutable sortit du cul du compilo) et transformé pour le faire avaler par nullDC. Je vois les pixels roses !! Il va me falloir donc trouver un système pour injecter directement le .elf à la Dreamcast et vérifier que ce n'...