Sunday, December 03, 2017

Far ground

Je tente d'intégrer mes bouquins-totems comme décor de fond du niveau vertical ... après quelques essais/erreurs pour faire le bon montage, qui ne consomme pas trop de mémoire vidéo, quelques corrections pour que le moteur de jeu puisse utiliser effectivement les 256KB dont il dispose plutôt que de s'auto-brider à 128K, je commence à avoir quelque chose... Enfin presque. L'état du code pour la gestion du décor en parallaxe n'est franchement pas terrible

I'm trying to integrate the tiki-books as the background of the secret vertical level. it took a few trials to get something that fits in the renaining video memory, which is much easier after I grant access to the full 256KB allocated. well, sort of ... Unfortunately, the code for parallax scrolling is carrying lots of legacy, hard-coded settings suited for 512x256 -picture, while this new level needs it the other way round. The wale also picks camera coordinates directly, leading to a. weird offset on screen.

  • le code qui effectue le chargement de l'image ne supportait que la taille de 512x256 pixels alors que je veux maintenant utiliser le système en 256x512.
  • le code de scrolling utilise directement les coordonnées de la "caméra" en les divisant par deux, de sorte qu'il me décale le décor de 64 pixels sur la droite
  • on dirait que seul un des deux "écrans" est utilisé, en boucle, plutôt que d'avoir un décor deux fois plus haut que large ... à l'exception de certains endroits où le décors est sans dessus dessous.
Il va y avoir un peu de travail pour corriger tout ça.
plus, l have only half the picture showing up, rather than two sets stacked onto each other. And at some place, the scenery is completely messed up. it will take some work to get all that fixed. Maybe if I hack some forced, auto-scrolling, the defects will become clearer.

edit: je devrais essayer de mettre un auto-scrolleur sur le plan de décor, tiens... ça simplifierait les tests.
edit2: en effet, ça simplifie.
  • [done] le coup des décors sans dessus-dessous vient probablement du fait que je ne chargeait que la moitié de ma map (eh oui, il faut 2 bytes par pavé, pas un seul)
  • [done] par contre il y a clairement quelque-chose qui annule l'effet du réglage "32x64" (l'ordre d'appel des fonctions, en fait). 
  • [done] Et pourquoi ai-je un VBL handler appelé deux fois, pour deux maps différentes, et qui modifient les registres des deux plans ? 

2 comments:

PypeBros said...

http://sylvainhb.blogspot.be/2007/12/yes-ca-scrolle.html Pas de schéma pour expliquer les xmin, xmax, xscreen et ... view. Dommage...

PypeBros said...

Bon, donc, non, on ne va pas couper sauvagement InfiniMap pour avoir d'une part la gestion du scrolling et d'autre part les fonctions "get tile type, clear block, ..." : clearblock a besoin de mettre à jour la map //et l'écran// pour un effet réussi. Pour ça, il lui faut les variables qui savent quelle portion de la map est en VRAM et à quel emplacement. Donc les infos de scrolling.