Re: [SMS] Rick Dangerous

[Joe Akira]

pour les maps/tiles, j'utilise la base dispo sur http://www.rickdangerous.co.uk/rickmaps.htm
je refais les maps à la "main" (c'est pas bien compliqué), c'est grosso modo par tranche de 64px de haut.
La grosse diff c'est que je n'utilise pas de metatiles pour gagner en place donc moins de répétition sur l'agencement des tiles de décor.
Après je modifie les tiles & cie pour à la fois que ca colle avec la palette SMS (ca y'a pas trop le choix) et aussi pour rendre ca un peu plus joli que le jeu d'origine (enfin plus "à mon goût")

voilà pour un aperçu Atari ST vs SMS :


pour la méthode, y'a pas grand chose :
- Codé à l'origine en C via SDCC (mais lib proprio/non dispo publiquement qui est un mix SDCC et WLA-DX)
- de l'ASM z80 pour optimiser un peu le tout
- Photoshop pour la partie graphique (+code perso pour générer les palettes SMS/Photoshop)
- Tiled pour les tilemaps avec aussi script d'export maison

Après comme déjà dit c'est codé au feeling (gravité, déplacement etc) et non en décortiquant un code déjà fait (genre x-rick)

Merci pour ton éclaircissement

codé au feeling, tout ça... j'en suis loin, très loin ^^, mais on sait pas ce que l'avenir nous réserve... en tous les cas depuis gamin c'est mon rêve, faire un jeu (ou créer une partie du jeu), créer l'IA, etc... Je suis en reconversion, je vais peut-être partir là-dedans

Pour revenir à nos moutons, ta version SMS est très réussi.
Les couleurs sont un peu trop agressives (flashi), surtout le vert (et peut-être même qu'il y a trop de blanc aussi).
Belle créativités au niveau du décors en tout cas !

La version ST est plus "so(m)bre" et je préfère ce thème là malgré tout... mais bon je chipote un peu quand même

J'ai hate de voir les sprites et notre ami "Rick" !

[ichigobankai]

Bon j'ai fait un petit calcul ± rapide, le jeu/rom devrait faire entre 256 et 512ko

256k c'est trop "juste" (je n'utilise pas de metatiles sur les tilemaps, du coup les tilemaps en brut devraient faire ~256ko  (4 niveaux ; 4 banks de maps / niveau ; 1 bank = 16ko).
Pour le fun, j'ai quand même testé la faisabilité de compresser ca en ZX7 (algo léger/simple, n'utilise pas de ram et bonne compression), mais à part se faire -un peu- chier...
Décompresser les plus grandes maps en ram (256x1024) prendrait 8ko de ram, c'est à dire l'intégralité de la ram et ca, forcément, ce ne serait pas possible.
Donc on pourrait feinter en mettant ca en sram (bon j'avais déjà prévu d'y sauvegarder le score) et se servir de la 2ème bank  de sram pour décompresser (la sms permettant d'avoir 2 x 8ko de sram, mais de mémoire, ca n'a jamais été utilisé)

sinon, j'ai fait la structure du 1er niveau au complet (9 maps) !
Mais structure de "base" (pour caler les limites/collisions vs sprites), faut mettre au propre les tiles (là c'est posé "à l'arrache"), les placements de monstres, items et "events" (boule, chauve souris, etc)

[kawickboy]

quand on voit la tournure du projet on se sit que le seul obstacle à l'époque pour un rick sms c'était son pad...

fano, avant la sms il y a rick128 avec choix du level svp.
cela parle de rick2, à part la version md de alekmaul (testée à la pgr), il y a des choses de prévues pour le 2e épisode ?

[ichigobankai]

Et encore, le pad ca n'aurait pas trop été un "vrai" souci.
Non, honnêtement, rien n'aurait empêché Rick de sortir à l'époque sur SMS.

Sinon ca avance pour les maps sous Tiled, bon par contre y'en a pour qq heures... à chaque zone/maps.
C'est le prix à payer pour ne pas utiliser de metatiles et autre pattern répétitif.

[nemokantio]

Tes maps font combien par combien ?
Ca prend pas trop d'espace mémoire en tile de 8x8 ?

[ichigobankai]

elles ne sont pas tous identiques.
Les plus grosses font 256 x 1024px (32 x 128 tiles).

Et "oui" ca utilise pas mal de place (c'est même ce qui va prendre le plus dans le jeu).

Une map de 32x128 prend très exactement 8192 bytes (sur sms, 1 tile de map = 2 bytes),
enfin quand on n'utilise pas de metatiles et/ou compression par dessus.

[Tryphon]

Si je me souviens bien, ce jeu ne scrolle en vertical que quand tu arrives a une extrémité de l'écran ?

Du coup y'a peut-être moyen de ne charger en RAM que 2 écrans (ça doit faire du 256x448 ou un truc du genre) ?

Mais c'est plus chiant à gérer...

[ichigobankai]

oui le jeu ne scroll qu'en vertical (quand il scroll)
ca détecte à 32px du haut/bas et ca scroll/recharge un morceau de 64px (8 tiles de haut).
Je dois donc juste recharger la partie de map dont j'ai besoin de rom à vram.
Pendant le scroll, l'action est complètement "figée".

sur SMS, l'écran "visible" fait 256x192, mais on peut charger 256x224 (soit 4 lignes de plus).

[Tryphon]

Du coup si tu veux compresser, y'a moyen de se débrouiller avec 2 buffers en RAM dun peu moins de 2 Ko.

Par contre faut décompresser en cours de jeu, ce qui peut être un peu lourd...

[ichigobankai]

oui, c'est forcément un petit peu plus pénible à mettre en place.
Mais vu que je n'ai pas de souci de place/taille de rom, je ne vais pas trop m'emmerder non plus

je préfère optimiser pour avoir le max de temps libre pour y coller de jolis samples in game

[troudki]

Sinon ca avance pour les maps sous Tiled, bon par contre y'en a pour qq heures... à chaque zone/maps.

Les monsters , Bonus qu'on voit sur tes maps sont placés sur un calque Tile ou Images ?
On peut exporter ensuite les coordonnées de ces objets ?

[ichigobankai]

Oui ils sont dans Tiled et dans un calque de type Objet


certains objets ont des propriétés avancées (type, zone de detection, nombre de point, etc)

Je n'ai pas testé/fouillé avec l'api en python, mais de ce que j'en avais lu ce n'était pas dedans.
(mais je n'ai pas creusé plus que ca, je dis peut être une connerie)
Du coup je me suis fait un petit parser TMX(XML) vers WLA-Dx (asm) SMS en python.

Dans le fichier TMX (qui est un bête XML, je le rappelle), en bas tu y trouveras ce genre d'infos :

Code:

 <objectgroup name="obj" visible="0">
  <object id="4" name="rick" type="start" gid="209" x="0" y="96" width="24" height="24"/>
  <object id="13" name="trap" type="arrow" gid="215" x="0" y="348" width="24" height="24">
  <properties>
    <property name="detect" type="int" value="80"/>
    <property name="posx_max" type="int" value="208"/>
  </properties>
</object>
</objectgroup>


Suffit d'aller dans objectgroup et de lister les object, recupérer les valeurs dont tu as besoin, checker si des propriétées sont ajoutés, etc.

[Invité]

Je trouve ton travail sur le jeu assez impressionnant ,c est incontestablement plus beau que les versions 16bits .

[Templeton]

Je suis du même avis que Touko, c'est visuellement bien meilleur.  
C'est juste un poil trop contrasté mais c'est inhérent à la palette limitée de la S.M.S je suppose.

Autrement elles sont ou les nouvelles toiles d'araignées? Plus de place?

[ichigobankai]

il me reste 18 tiles pour l'instant, mais sur ces 18, 4 sont réservés pour les blocs où l'on s'agrippe (comme les échelles)


Les bonus (artefact, dynamite, munitions) et l'ancien bloc de pierre qui tuait au contact (que j'ai remplacé par des ronces)
sont passés en tiles, pour limiter le flickering (dépassement de sprites/ligne)

original : "rocher" /// sms : ronces



et oui, on doit composer avec la palette SMS... pas tjs simple, mais j'essaie de faire au mieux (et que ca me plaise)

[ichigobankai]

La boule qui roule est dans la place



- la couleur n'est pas encore tranchée (grise ou marron...)
- la zone n'est pas terminé au niveau "tiles"

j'ai volontairement fait la boule un peu plus rapide que Rick ;
stress, tension, tout ca ^^

[F.L]

Impressionnant !

[ichigobankai]

Merci FL
j'ai accélérer la boule encore un peu plus, maintenant c'est quasi au pixel

[Révo]

C'est trop beau <3 Par contre tu pourrais faire un effort pour le scrolling et faire quelque chose de mieux que l'original ^^

[TotOOntHeMooN]

Il est certain que lorsqu'on est pas vraiment limité par le stockage, ça aide. 
Pas de réelle prise de tête, juste se faire plaisir à composer au fil de l'eau. 

Marrant que tu ais évidé le solide dans la première salle, car j'avais fait de même dans Risky Rick pour essayer... Mais ça ne rendait pas bien vu les limitations graphiques du TMS9918.

Les rooms (pièces verticales de la map) font effectivement 256x1024 max.
Sur Coleco/MSX c'est exactement la taille pour tenir en mémoire pour ensuite scroller en déplaçant le pointeur vidéo. Comme si le jeu avait été pensé pour ce VDP ! 

[ichigobankai]

Merci !
pour le scroll je ne peux pas trop le changer, car ca altère le gameplay (qui est basé sur la mémoire des "salles" qui ne sont pas encore affichées)
avec un scrolling au pixel, ce serait trop facile à anticiper ^^

je modifie quand même certains petits détails vis à vis de l'original,
comme indiqué au dessus la vitesse de la boule est plus rapide que l'original, là c'est vraiment au poil de cul près (enfin faut juste pas s'arrêter pour ne pas mourir, ca va, c'est pas trop compliqué)


Les ennemis ne vous touchent pas au pixel près, j'ai été un peu plus cool niveau "hitbox".

[TotOOntHeMooN]

Oui, tu fais bien d'adapter le gameplay car quoi qu'en disent les fanatiques, ce n'était pas agréable à jouer.
(sinon, la petite fleur a manqué de peut de se faire écrabouiller)

[drfloyd]

à la base Rick Dangerous c'est un gameplay très basique et plutot austère.

Son succès à sa sortie vient je pense du manque de jeux action-plateforme "façon Nes" à l'epoque sur micro... lié au faut que Indiana Jones etait un nom porteur dans les années 80 !

[ichigobankai]

Clair que ca transpire Indiana Jones, rien qu'avec le (gros) clin d'oeil de la boule dès le début.

PS. j'ai mis un gif animés dans le post précédent pour montrer la boule qui vous "frôle"

[TotOOntHeMooN]

Ils ont vraiment voulu profiter de la notoriété d'Indiana Jones pour vendre le jeu.
Le niveau du temple d'amazonie était au début le niveau 2 et l'Egypte en niveau 1, mais ils ont inversé les deux.

[Stef]

Je veux pas faire mon chieur mais on voit le clipping de la boule quand elle rentre sur l'écran. Je crois que la position X des sprites est en 8 bits seulement sur cette machine donc il faut activer le black border à gauche pour l'éviter, c'est ça ? Mais si tu fais ça alors il manque 8 pixels  des graphismes d'origine :-/

[ichigobankai]

t'inquiete, je l'ai vu aussi ^^

J'avais pensé à 3 façon de faire
-1ère, rien à battre, car de toute façon sur CRT c'est bouffé/masqué
mais bon ca c'est pas trop mon genre, déjà que je me fais chier à placer les rechargement de palettes le plus bas possible pour ne pas voir l'écriture cram
-2ème, faire tomber la boule par le haut au départ (peut être sympa)
-3ème, masquer le souci ; faire un pseudo masque 1 pixel sur 2 noir en 1er plan pour "limiter l'effet bloc" ou juste mettre un peu plus de végétation (le plus rapide)


En plus je crois que c'est le seul cas de figure où un élement arrive/disparait de ce coté (de l'autre c'est pas grave car ca disparait proprement)

Mais pour sûr, je n'activerai pas la colonne de gauche (et oui ca bouffe une col de 8px)

PS. sur Amiga & cie, ils se font encore moins chier, la boule apparait comme de par magie...

[Stef]

Je crois que la solution 2 ou 3 serait pas mal en effet, je vois ce que tu veux dire avec le masque de 1 pixels sur 2 en progressif peut être, ça pourrait bien rendre :)

[upsilandre]

meuhh non pas besoin de tout ca   . Justement sur Master System et sur TMS9918 y a une solution hardware a ce probleme (contrairement a la NES). bit 3 du registre 0 y a un flag pour shifter les sprites de 8 pixels vers la gauche, c'est un peu plus chiant a gérer si tu veux a la fois sortir proprement a gauche et a droite (dans ton cas c'est pas nécessaire j'ai l'impression) mais ca marche tres bien (je l'ai testé sur Coleco et sur Master System)

[ichigobankai]

Ah pas con !  
j'avais complètement zappé ce flag.
En plus ca tombe bien, j'avais un byte en rab dans la définition des zones.

Et voilà, impec.

Merci Upsi pour le rappel

[upsilandre]

C'est plus jolie