Re: Rick Dangerous II pour Megadrive

[Invité]

aurais tu les templates au format PSD de cette version, je connaissais pas, désolé.

[Metalik]

ou alors plus simple, et plus respectueux de l'original : retirer le rick dangerous 2 du bas,
et avoir une jaquette plus classique comme ça :

Perso, je la trouve pas terrible. Surtout au dos, avec le fond blanc.
Pourquoi ne pas utilisé le modèle bleu des jeux de dernière génération ?

[Tryphon]

Kôôôaaaa ? Y'a pas plus classe que les box MD à carreaux

Par contre j'aurais viré le fond noir derrière le perso.

[Invité]

Excellent boulot et en peu de temps !
Bravo copain !

[F.L]

aurais tu les templates au format PSD de cette version, je connaissais pas, désolé.

je l'ai en format classique. je ne sais pas me servir de photoshop
si tu m'envoye tes fichiers, je peux essayer de la faire c'est rapide
avec paint et selection transparente, je fais des miracles

et pour Metalik,
je n'aime pas vraiment la jaquette us de barbarian. je l'ai toujours trouvée moche.
mais tu apprendras à savoir que je ne rajoute jamais ma touche personelle :
si l'arriere de la boite était comme ça, et bien pour le remake il en sera de meme

[dub]

Ok, petite mise à jour du dimanche.

Ce qu'il reste à faire :
1) trouver comment gérer la priorité de ce pu.. de PLAN_WINDOW, les sprites en prio 1 sont devant, alors que d'après les specs, le PLAN_WINDOW en prio 1 devrait être devant.

Pour moi dans la doc, les sprites en prio 1 seront toujours devant : https://emu-docs.org/Genesis/sega2f.htm

§  11  PRIORITY
 
 PRIORITY between SPRITE, SCROLL A and SCROLL B can be designated.
 
PRIORITY can be designated by each PATTERN NAME and ATTRIBUTE PRIORITY
bit.  It will be set for the SCROLL SCREEN on a cell unit basis and for
each SPRITE.  By combining each priority bit, PRIORITY will be as follows:
However, the BACKGROUND PRIORITY is always the lowest.
 
 

S pri	A pri	B pri	PRIORITY
0	0	0	S>A>B>G
1	0	0	S>A>B>G
0	1	0	A>S>B>G
1	1	0	S>A>B>G
0	0	1	B>S>A>G
1	0	1	S>B>A>G
0	1	1	A>B>S>G
1	1	1	S>A>B>G

 
                      S  :  SPRITE
                      A  :  SCROLL A
                      B  :  SCROLL B
                      G  :  BACKGROUND

[fourchette]

Et last, but not the least, j'attends vos remarques sur la globalité du jeu :)

je ne peux tester qu'avec émulateur, donc ça ne présage pas du comportement sur le véritable hardware, mais le héro se met à accélerer sans raison, de manière aléatoire. il semble revenir à sa vitesse normale au changement de zone ou suite à un scrolling. testé sur mednafen et blast'em (que je considère comme les plus précis) ainsi que sur Kega Fusion.

pour tout le reste, c'est du bon, bonne maniabilité, animation, etc. mais gâché, dans mon cas, par les accélérations intenpestives du héro.

et pour confirmation : il tourne bien à 60 Hz ?

[F.L]

moi aussi j'ai les variations de vitesse du héro avec l'emulateur kega fusion
au début par exemple il va vite et quand les lasers sont autour de lui, sa vitesse ralentit
je n'ai pas testé sur mon everdrive : demain je te dis si ça le fait sur ma megadrive

[fanoplusplus64K]

Ce qu'il reste à faire :
1) trouver comment gérer la priorité de ce pu.. de PLAN_WINDOW, les sprites en prio 1 sont devant, alors que d'après les specs, le PLAN_WINDOW en prio 1 devrait être devant.
2) gérer le scrolling des sprites suivant le décors, y'a toujours le décalage.
3) optimiser des parties du codes, ça lague avec les sprites affichés.

Viens de tester ça sur ma MD, effectivement y'a un souci de vitesse, est ce que tu ne gagnerai déjà pas à réguler la vitesse pour tourner à 25/30 fps pour correspondre au jeu original car il tourne en full speed c'est limite injouable.Sinon, pour le scroll, effectivement c'est décalé, après c'est dommage aussi qu'il ne soit pas plus fluide.
A part ça , j'ai l'impression qu'il manque quelques bruitages (bon j'ai plus souvenir de la version CPC).Le rendu sonore des thèmes est largement mieux en YM qu'en SID à mon gout même si la sonorité est plus 'simple'.Par contre, les fréquences sont elles ajustées car j'ai l'impression des fois que ça sonne un peu faux (quelqu'un avec l'oreille 'éduquée' sera surement plus compétent que moi là dessus)
C'est un peu déroutant au début d'avoir bombe et tir sur un bouton différent mais au final c'est top , plus de prise de tête à faire glisser les bombes, plus de tir intempestifs, bref juste nickel (bon le saut sur C ça déroute au début )
Viens de m'apercevoir d'un truc en testant, quand tu sautes devant une échelle, rick s'accroche à l'échelle au lieu de sauter.

[fanoplusplus64K]

Au passage

[NeoGeoThai]

Je n'aime pas la cover originale Atari de l'epoque.
L'artwork de Rick ne ressemble pas du tout au perso dans le jeu...

J'ai fait une version ASIA pour le fun...

[Invité]

Pour moi dans la doc, les sprites en prio 1 seront toujours devant : https://emu-docs.org/Genesis/sega2f.htm

§  11  PRIORITY
 
 PRIORITY between SPRITE, SCROLL A and SCROLL B can be designated.
 
PRIORITY can be designated by each PATTERN NAME and ATTRIBUTE PRIORITY
bit.  It will be set for the SCROLL SCREEN on a cell unit basis and for
each SPRITE.  By combining each priority bit, PRIORITY will be as follows:
However, the BACKGROUND PRIORITY is always the lowest.

Etonnant, car ici http://md.squee.co/VDP#Priority, ils disent bien que la Window est supérieure en priorité, je vais creuser ...
Merci en tout cas de tous vos retours, ça me motive pour finaliser le jeu :)

[tetsuro]

Le jeu est en plein écran ? Super, je n'aimais pas le petit carré au mileiu de l'écran pour le 1.
D'accord aussi la jaquette n'était pas très jolie.

[Invité]

J'ai fait une version ASIA pour le fun...

J'aime bien. Tu peux me filer les originaux en PM que je les rendes dispo sur mon site ?

[NeoGeoThai]

Je viens de te les envoyer en MP sur FB

[F.L]

Tres sympa ! C'est vrai que çacomme mieux à l'esprit du jeu !

[Invité]

Et c'est dispo sur le site :)

[kawickboy]

L'artwork d'origine est cohérent avec celui du 1er épisode.

[NeoGeoThai]

Je dirais qu'aucun artwork correspond au perso du jeu.

Dans le jeu et dans l'intro (Rick 1 et 2) le perso est petit et trapu au gros pif...alors que les arts montrent un pseudo indiana jones..

[TotOOntHeMooN]

Ce n'est ni le premier ni le dernier jeu à avoir un artwork qui repose principalement sur :
- L'idée qu'on peut se faire du titre du jeu
- Des éléments en rapport avec le premier niveau

Il fallait faire rêver à travers la jaquette, car c'était le moyen de vendre de l'époque.
Ca fait aussi parti d'un tout... Les montages "maison" ne sont que rarement dans l'esprit.

[uran]

Testé vite fait sur MD avec mes 2 p'tits, c'est dur comme jeu qu'il disent :|
Mais ils aiment!

[Templeton]

Au passage

Classe !  Rick Dangerous en Overscan sur les cotés, j'adore!

[Metalik]

Va t-il y avoir une version finalisé ?
Parce que là, vue le nombre de bugs, ça donne juste super envie d'y jouer mais dans une version digne. Dès les premières seconde les sensations sont là.

Je joue sur everdrive, voici les bugs:
-Problème de collision des sprites (surtout à la verticale).
-Jeu qui accélère.

[Invité]

Va t-il y avoir une version finalisé ?
Parce que là, vue le nombre de bugs, ça donne juste super envie d'y jouer mais dans une version digne. Dès les premières seconde les sensations sont là.

C'est toujours sympa les commentaires comme ça, "vu le nombre de bugs" ... j'apprécie, surtout qu'en on sait que l'on fait cela à notre temps libre.
Pour l'instant, je suis sur d'autres sujets qui me motivent plus (et où je n'ai pas ce genre de retours concernant les bugs), mais tu peux faire ta propre version si tu veux :)

[Metalik]

[Invité]

Tiens une petite nouvelle sympa from Tectoy :
http://blogtectoy.com.br/classico-de-computadores-antigos-rick-dangerous-2-ganha-versao-para-mega-drive/

Ca fait toujours plaisir !
Et puis te vexes pas pour si peu, defois on se rend pas compte du temps que l'on passe la dedans ... Et en plus tu partages tout ca librement avec de quoi réaliser sa petite édition.
Faut prendre ca au 3eme degré.

J'espere que Papi Commando a toujours une toute petite place dans ton coeur.

[nemokantio]

@alekmaul
Je viens de tester sur emu le niveau 1.
Bravo le gameplay, graphisme, sons et musiques sont respectés, pas de souci sur la qualité globale de ta conversion. C'est un sacré boulot.

Par contre (et ne te fâche pas) je vais te faire remonter les soucis que j'ai pu voir (au niveau 1) :
- souci de collision, parfois rick ne se cale pas sur une tile du sol et peut être décalé (et les autres sprites présents à ce moment là aussi)
- souci de vitesse de l'électricité au sol, trop rapide, pas pu passer (mais c'est peut être moi)

Ensuite, il faudrait voir ce souci de décalage des sprites par rapport au scrolling vertical. C'est pas une histoire du moment où tu mets à jour les sprites par rapport au moment où tu mets à jour le scrolling ?
Le vdp qui prendrait en compte le scrolling à un moment, et les mises à jours des sprites la vbl suivante ?
Voire deux vbl après quand ça ralenti ?
Tu as essayé je suppose de modifier l'endroit dans le code où tu fais ces mises à jour ?
Par contre je ne vois pas comment régler ce problème de dépassement de la vbl pour ton code, à moins de rajouter un truc pour ralentir exprès en 2 vbl...

Et je termine en disant que oui, c'est pas évident du tout de mener ce genre de projet, encore bravo !

[nemokantio]

Je viens d'y rejouer ce matin, j'apporte quelques précisions...
Pour le décalage des sprites par rapport au scrolling vertical, j'ai l'impression que c'est autre chose.
Tu as séparé le décalage à faire sur les sprites lors d'un déplacement vertical de Rick, par rapport au décalage par 8 pixels des tiles.
Ce qui fait que lorsque Rick commence à se déplacer en vertical d'un pixel (saut, monte à une échelle ou un tuyau), les sprites bougent du même pas de 1 pixel, mais pas les tiles qui attendent 8 pixels pour bouger.
Essaye dans un premier temps d'appliquer le même décalage de 8 pixels d'un coup pour les sprites.
Le mieux serait de séparer scrolling vertical et déplacement vertical de Rick. Le scrolling doit servir à recentrer la caméra si besoin. Comme ça Rick monterait de 1 pixel aux échelles/tuyaux au lieu de 8 pixels en décalé.

Et pour le décalage collision sol, j'ai remarqué que ça arrivait quand Rick tombe de plus haut qu'un simple saut.

J'espère t'aider avec mes remarques.

[Invité]

@nemokantio, merci de tes retours constructifs, je vais regarder tout cela. J'ai déjà réglé le pb de vitesse en appliquant effectivement une réduction du nb de vbl si cela va trop vite (si on est à moins de 2 vbl, on attend ...)

[dlfrsilver]

Rick Dangerous 2 est un jeu conçu sur l'Atari St et porté ensuite sur Amiga, PC, C64 etc..
Il a été pensé pour être porté plus facilement sur l'ensemble des micro 8-16/32 bit de l'époque, d'ou sa résolution de 256*200 (Zone utile 256*192).
La bande noire en bas sur Megadrive  parait donc normale vu sa résolution supérieur. Ce qui ne l'est pas c'est le scrolling Vertical saccadé.
Sur ST/Amiga il tourne en 2VBL 50Hz donc en 25 Fps (comme le reste du jeu) ce qui est relativement fluide.
Alekmaul est super doué et il va corriger ce problème sans difficulté, ne vous inquiétez pas !

En tous cas, félicitation pour ce portage éclair Alekmaul! C'est très sympa!
Rick Dangerous 2 est un jeu particulièrement retord et sadique, j'ai adoré le finir à l'époque !  

Le moteur de rick dangerous 1 et 2 a été conçu avec les specs du ZX spectrum pour la zone écran (256x192), et des sprites format C64 de 24x21. Ces specs ont été utilisées sur toutes les autres plateformes.

Informations confirmées par Simon Phipps sur son site. Seul Rick 2 a été commencé sur Atari ST et porté comme tu l'as dis sur les autres machines, mais toujours avec les specs ZX et C64 pour les assets graphiques.

[kawickboy]

Sinon Alekmaul est parti, mais savez-vous s'il a avancé sur les derniers bugs (le scrolling je crois, vu avec lui lors d'une PGR) ou complètement lâché l'affaire ?