The Return Of The Space Coyote's dear diary - Page 1

http://rajah.atari.org/files/ BEEPBEEP_20060624.LNX (le jeu) et .ZIP (le source)

Touches pour l'intro :
- toutes : passage à l'ingame.

Touches pour l'ingame :
- A et B : sauter et se moquer.
- OPTION1 : changer le mode du Coyote
- OPTION2 : réinitialiser les positions et l'état du beepbeep
- CURSEUR : se déplacer

Livré avec sources en l'état, c'est en cours de dev, que je dois suspendre momentanément (car ya DGEM à finir), mais je veux continuer ce jeu. Il est interdit de faire ses sous avec, vous pouvez reprendre tout ou partie du code pour vos besoins. Les graphes ne sont pas à reprendre : proviennent du jeu de la version ST (prière de posséder les originaux, donc).

To do :
- intro : starfield horizontal, rasters (?), musique
- ingame : décors (soit je récupère ceux du désert de la VO, soit j'invente un truc dans l'espace) avec scrolling différentiel, bruitages, mode avec tombé de dynamite de l'hélico, déplacement des rochers (en atténuation sinusoïdale), système de points et d'affaiblissement si le beepbeep mange pas assez
- séquences d'animation (nommage en latin des créatures, tombé du coyote, etc)

Bon, maintenant, faut que je prépare la valise : VACANCES !!!

L'animation des vehicules lorsqu'ils se déplacent est trop fun, Les graphs de ce jeu sont ideal pour la lynx !
Par contre BeepBeep a vieillit, il n'est plus aussi veloce qu'avant..

Enfin un projet avec un peu d'humour ! BRAVO !



notelpmet

Voila un projet interessant. La version ST sur Lynx serait super.

Excellent boulot, juste (enfinc'est ptet que moi) quand les mines réapparaissent, elles sont quasi systématiquement au bord de l'écran...

Vraiment sympa ! Bravo !

C'est suffisament rapide et c'est jolie. Un p'tit fond d'écran ?

Bonne idée de la part de Marss, sur ST existe la version "Road Runner" qui bénéficie d'une défilement de décor.

Merci

Au cas où certains n'ont pas compris, les graphes sont rippés de la version ST. Pour le décor, je vais essayer de le tranposer, mais il va y avoir des problèmes de place en RAM (pour le scrolling, la Lynx fait ça très facilement)... un petit coup de Topaze ?

GT en vacances.

Rajah Lone :
un petit coup de Topaze ?

Oui, oui, oui GT en train de faire de la promotion de mon prog


On regarde cela en privé


GT

Bon, il y a une échéance : la Numerica, sinon c'est la *C2007, ou l'Alchimie 2007.

Return to the code, avec pour principal objectif : les décors... et ce programme de transfert .TTP vers la cartouche de Karri, si j'arrive à faire remarcher ce bouzin...

Tayooooo !!!

see you at AC07

Bon, j'ai rippé les décors... ils sont stockés entiers dans la RAM et chargés à chaque changement de niveau. Chaque image fait 3072*136 en 3 plans. Pas de construction extemporanée, c'est du transfert de block brut : donc pas applicable à la Lynx, il n'y a pas assez de RAM. Je dois donc utiliser une table et des éléments de décors (GT_en_attente, si on m'écoute).

Pour anecdote, le jeu original affiche plus de 16 couleurs : ils utilisent la même astuce que Dungeon Master c-a-d un changement de palette.

En attendant, je me concentre sur le fond : le scrolling est parallax. J'ai obtenu les fonds de décors (horizons), que j'ai pu 'rétrécir' en sprites spr 2 plans. Forcément, les couleurs sont mauvaises, mais il y a une astuce, dans le SCB.

struct scb {
	uchar b0;
	uchar b1;
	uchar b2;
	uint *next;
	uint *bitmap;
	int   x;
	int   y;
	int   sizex;
	int   sizey;
	uchar palette[8];
	};
...
struct scb background1;
struct scb background2;
...
background1.b0 = 0x40;
background1.b1 = 0x10;
background1.b2 = 0x20;
background1.next = &background2;
background1.bitmap = 0; // valeur allouée après chargement de la CART vers buffer
background1.x = -320;
background1.y = 0;
background1.sizex = 0x100;
background1.sizey = 0x100;
background1.palette[0] = 0x31;
background1.palette[1] = 0xbc;
background1.palette[2] = 0x00;
background1.palette[3] = 0x00;
background1.palette[4] = 0x00;
background1.palette[5] = 0x00;
background1.palette[6] = 0x00;
background1.palette[7] = 0x00;

Désolé pour l'écriture C, je suis pas très à l'aise avec le mélange ASM+C... J'espère que ça reste compréhensible. J'ai étudié ces trucs bizarres en fin de SCB, ces fameux 'pens'. Normalement, on a généralement :

background1.palette[0] = 0x01;
background1.palette[1] = 0x23;
background1.palette[2] = 0x45;
background1.palette[3] = 0x67;
background1.palette[4] = 0x89;
background1.palette[5] = 0xab;
background1.palette[6] = 0xcd;
background1.palette[7] = 0xef;

En fait, il s'agit d'une table de correspondance (un mappage). Pour lire celle juste au dessus, il faut dire la 1ère valeur indique la couleur 0, la seconde valeur la couleur 1, la troisième la couleur 2... En fait, la palette du sprite est celle de la lynx, donc il suffit d'avoir une table de 1 -> 1, 0 -> 0, 2 -> 2, etc.

Dans mon cas j'ai 0x31 et 0xbc... que 4 couleurs (uniquement 2 plans), donc seulement les 4 premières valeurs de cette table à renseigner.
La première couleur (noire dans degas Elite) sera dessinée avec la couleur 3 (bleue claire dans Degas).
La deuxième couleur du sprite sera peinte avec la couleur 1 de la palette en cours de la Lynx.
La troisième couleur du sprite sera affichée avec la couleur 11 de la palette Lynx.
La quatrième couleur du sprite sera peinte avec la couleur 12 de la palette Lynx.

Sinon, pour les plans, c'est codé dans le premier octet (bits 7 à 4), exemples :
background1.b0 = 0x40; -> 2 plans
background1.b0 = 0x80; -> 3 plans
background1.b0 = 0xc0; -> 4 plans
Dans cet octet est aussi codé, si c'est un background, s'il doit y avoir calcul de collisions, etc... voir la table en fin de page de ce lien (SPRCTL0).

Ze Beepbeep must run.

En direct de la Numerica...

Argllll... allocation d'un buffer statique de 3Ko : tout foire, alors que 1Ko, ça reste bon. Autrement dit, ya plus de RAM, je dois me passer des décors du jeu original pour faire quelque chose de plus dépouillé. Dans l'espace, donc... Et me concentrer sur les économies mémoire. J'ai l'impression que ma méthode de descripteurs de sprites consomment pas mal. Va falloir faire, pour ceux qui sont possible, à l'ancienne, via une déclaration assembleur.

Tu utilises des listes chainées de sprite avec l'astuce qui permet d'économiser plusieurs octets par déclaration de sprite ?

Et bonne Numerica à tous

@Fadest : non, je ne connais pas l'astuce... vais chercher. Merci

Les sprites peuvent être "compressés", c'est sans doute à ça que Fadest faisait allusion. La compression se résume à dire 3rouges 4 bleus un blanc au lieu de rouge rouge rouge bleu bleu bleu bleu blanc...

En fait, je pensais surtout au fait que quand on fait une liste chainée de sprites, le premier a une vraie déclaration (28 octets de mémoire), mais on peut dire que les suivants auront certaines infos identiques au premier (palette particulière par exemple). Bref, chaque sprite chainé (hormis le premier) ne prend que 11 octets au lieu de 28. Pas grand chose, mais sur une map 20x10 par exemple, ça fait 17*200=3400 octets économisé, pas si mal vu ce qu'on a de dispo (une quarantaine de kilos).
Ensuite, c'est sur que si tu chaines peu de sprites dans ton programme, ça ne va pas beaucoup te faire gagner...

Tu peux regarder l'exemple sprdemo4 de Mathias qui est normalement avec le kit BLL, c'ets là que j'ai découvert ce truc (c'est dingue à quel point Mathias, avec quelques autres, aura été utile aux communautés Lynx et Jag #respect#).

Je dois aussi avoir des exemples qui trainent quelque pas si tu as besoin, mais tu peux toujours jeté un oeil à cet article :
http://fadest.free.fr/spip/article.php?id_article=5 (et à la définition de SPRCTL1, c'est lui qui permet de dire que la palette est commune à toute la liste chainée).

Voilà, c'est bien ce que je cherchais, à savoir si on pouvait se passer de la table de "pen" à la fin... SPRCTL1 avec un 0x18 (use same palette)... j'ai cherché cet aprèm mais pas trouvé la soluce. Mes essais n'ont pas marché.

Par contre, j'ai ma map... hihi : suffit de prendre un sprite de map à quelques pixels et 1 plan, puis de le zoomer ça évite de faire une table de mappage Ça fait très pixel, mais comme c'est "in space now", je n'ai plus qu'à agrémenter avec quelques objets ça et là.

Le scrolling est différentiel, la map est une sorte de laby, avec un fond étoilé qui scrolle aussi. Assez bluffant : elle a des couilles, cette Lynx.

Heureux d'avoir pu être utile

>hihi : suffit de prendre un sprite de map à quelques pixels et 1 plan, puis de le zoomer
Pour ceux qui n'ont pas regardé les sources de la librairie BLL, quand on fait un DrawFBox, en fait, c'est un sprite 1x1pixel zoomé à la dimension qui va bien
C'est pour ça qu'il n'y a pas de DrawBox d'ailleurs?

J'espère que la Lynx ne t'impressionne pas que toi, mais qu'avec Cooper, vous lui faites cracher les tripes devant tous les PCistes

En ce moment, Coopy "peaufine" un de ses petits jeux sur STE

Il a apporté sa Lynx et sa Karri-cartouche, pour comparer avec mon kit. Résultat : ma karri-cartouche est HS. rien à faire, faudra que je la renvoye à Karri pour reflashage... dommage, je voulais bien coder le soft de transfert pour ST.

C'est quoi le problème, les 2 softs de flashages qui sont écrasés ?

Je sais pas. Sa cartouche à lui fonctionne capricieusement, mais elle marche comme attendu (suffit de la chauffer un peu). La mienne : rien à faire. Soit parce que je l'ai pas utilisé depuis très longtemps, soit parce que mon 1er test depuis longtemps s'est fait en la branchant sur mon port série de mon MegaST (pour coder le soft de transfert en TTP).

Oki, j'ai trouvé... Pour virer la table de correspondance dans le SCB (les "pen"), dans une liste chainée de sprites, il faut que :

- le 1er sprite possède la table et soit obligatoirement affiché (surtout ne pas mettre à 1 le bit 2 de SPRCTL1).
- les sprites suivants peuvent ne pas posséder la table, et il faut que le bit 3 du SPRCTL1 soit à 1 (une valeur de 0x18 par exemple).

Donc, dans la liste, j'ai mis mon 1er sprite affiché, mais hors écran avec un SCBDATA null, et le reste des SCB n'ont plus de table de pens.
Ça fait moins de code et de RAM consommée. Et apparemment, ça a l'air d'aller un chouillat plus vite à l'affichage.

Oui, c'est exactement ça (je n'ai pas mes sources sous la main, alors je parlais de mémoire) pour SPRCTL1 et pour la vitesse d'affichage.

char GetPixel(char x, char y);
Returns the colour index of the pixel at position x,y.

C'est sympa, merci, mais le test du pixel est fait sur le ScreenBuffer uniquement, pas sur le RenderBuffer... Autrement dit sur l'écran final, pas celui de travail. Ça aurait été pratique, dans l'écran de travail, par exemple entre l'affichage du background et l'affichage des sprites, pour savoir sur quelle case (pas encore occupé par un sprite) rouge ou rose ou verte, on risque de poser son beepbeep ou son skweek.

Qu'à cela ne tienne, suffit d'aller dans les sources du BLL, de mater, et de recopier dans votre projet, en changeant juste ScreenBuffer par RenderBuffer :

extern GetColor();

#asm

_GetColor:          ; dérive de GetPixel, mais pour le RenderBuffer
        jsr popax
        sta $fc52
        stz $fc53
        lda #80
        sta $fc54
        stz $fc55

        jsr popax
        lsr A
        php             ; save C => even/odd pixel
        tay             ; y = byte-position

	clc
        lda _RenderBuffer      ; certes ©
        adc $fc60
        sta ptr1
        lda _RenderBuffer+1  ; coucou mon capitaine
        adc $fc61
        sta ptr1+1

        ldx #0
        lda (ptr1),y
        plp
        bcc _GetColor1
        and #$f
        rts
_GetColor1:
        lsr A
        lsr A
        lsr A
        lsr A
        rts

#endasm

et ça marche, et je sais pas aligner une seule ligne d'assembleur. DANS C*L Monsieur BLL et la Lynx, coder est un plaisir

Bien vu !

http://rajah.atari.org/files/lynx/

bon, malgré mes "avancées", ça a pas trop l'air d'avancer... quoique... cf 1er post pour les touches. J'aimerais savoir comment ça tourne sur une vraie rom Lynx, n'ayant pas de Karri-card qui fonctionnne correctement.

Nouveautés :
- rasters pour l'intro (mes premières lignes d'assembleur, hihi)
- une map (qui est en fait un labyrinthe) et un scrolling différentiel
- affinage pour le comportement des éléments autres que beepbeep et coyote
- 'tention, ils peut tomber
- optimisations diverses (en rapidité et place mémoire)

A faire pour les prochaines fois que je m'y torche :
- améliorer l'intro
- du son
- compteurs pour le nombre de seed (paquets de graines) à bouffer
- sortie de la map
- décorer (chuis un fana du minimalisme et un farouche opposant au baroque, mais ça va pas plaire à tous)
- optimiser encore plus : je me suis aperçu que le compilo cc65 mettait en branle tout un tas de manips, juste pour un incrément. Par ailleurs, la place explose de plus en plus si on rajoute des if-then. Pour les courageux qui matteront les sources, je fais des gotos dans mes switch, quelle horreur, mais fo-ce-ki-fo.


Par ailleurs, optimisations dans Gotballs, sur les vectors balls (suffisait de calculer que la moitié des coords, et puis routine de tri plus efficace pour l'affichage en Z).

Même si coder sur Lynx est trop trop bien, il faut que je retourne à mon premier amour : le GEM et GFA. Avec le Troll à torcher et "Litchi", un client ftp à coder pour virer de aFTP qui m'énerve de plus en plus.

Sympa d' utiliser les fonctions hard de la console !
Le jeu devrait être un peu plus rapide.
Mmmm... vectorsballs, rasters, zoom, scroll diff... finalement tu fais de la demo !

Yop, petit rapport en direct live.
Je compare on real Lynx et sur Handy en parallèle.

Intro :
les rasters sont invisibles sur Lynx (fond gris uni), mais peut être que ma Lynx fatigue aussi
Le scoll texte semble plus fluide sur Lynx, mais il y a aussi le saut quand "The return" arrive en haut (on a l'impression que ça saute plus de pixel d'un seul coup. Ca le fait aussi sous Handy

Jeu :
C'est un gros défaut de la Lynx en vrai (de la mienne en tous cas), sur fond noir, on voit des bandes verticales. Du coup, avant de bouger, j'ai 3 parties verticales : noires, grise (qui correspond à la barre horizontale de la map), noire. Note, ça le fait un peu aussi avec les lettres du scroll text.
Ca fait un peu la même chose que la map, si il y a un chemin vertical, il sera plus clair que les perties horizontales.

Passons au jeu, je le trouve plus agréable sur Lynx, non pas que ce soit plus rapide (j'ai essayé de comparer, c'est identique), mais l'utilisation du pad est flus facile vu que tu ne gères pas les diagonales. Ca me gène un peu sur le PC (un portable en plus) et pas du tout sur la Lynx.

J'ai testé sur la Lynx 1, même symptome pour l'intro, et rien à l'écran en lançant le jeu...

@Fadest : Oki, merci tout plein pour les tests
Ça sera difficile de ne pas faire des fonds unis, ou alors peut-être avec un tramage, ça irait...
Visiblement, je crois que je vais virer les rasters et mettre autre chose, ça fout la zone sur Lynx 1 après l'intro.

@Tempi : je tape que dans le hard
Démo ? bof bof, c'est le genre de truc que je voulais faire sur ST en GFA, mais il y avait pas de copros, donc c'était trop lent.

>ça fout la zone sur Lynx 1 après l'intro.
Je ne sais pas si c'est ça...
Ton intro, c'est dans ton prog principal en C, ou un programme assembleur qui appelle le jeu ensuite ?
Et dans le second cas, combien fait le .o du jeu en question ?
Je me demande si la Lynx 1 n'a pas un peu de ram en moins que la 2, une fois tout initialisé ?

Et pour le fond, c'est surtout qu'il faut éviter trop de contraste je dirais, et les fonds noirs (car l'effet que je décrit est beaucoup plus marqué sur fond noir). Maintenant, le space coyotte, c'est sur que c'est dans l'espace...

Il ne peut pas y avoir de .O, vu que je fais des chargements de "fichiers" à la volée. Les programmes sont donc en mémoire : intro et ingame. Les sources sont dispos dans les archives à côté.
Le .O de la compil commence à faire pas mal... d'ailleurs, je suis limite niveau mémoire : un buffer de 3K en plus et c'est la zone totale. Mais j'ai parfois vu une différence quand j'augmentais la taille du code : l'intro passait et l'ingame plantait.

On connait toutes les différences entre Lynx 1 et 2 ? Je croyais que la partie "soft" était la même...

Pour le fond, au lieu de prendre du noir, peut-être qu'un bleu très foncé irait... Mais bon, ça c'est du détail dans les finitions. Faut surtout que je me concentre sur le code et la réduction en RAM, et me décidé à alerter le Karri-SAV.