Re: Sgdk - Sega Megadrive / Genesis Development Kit

[fourchette]

De mémoire le bitmap engine utilise une résolution de 256x160 pixels, en double buffer ça te fait déjà plus de 40 Ko de bouffé en VRAM ! ensuite si tu retires les tables / tilemap / font, alors il te reste plus grand chose pour les tiles de plan B :-/ Il faudrait que j'optimise l'organisation VRAM car là je pense qu'il doit te rester 100 ou 150 tiles pour le fond :-/ tu peux écraser la font pour en gagner 96... en enlevant le double buffer tu gagnes beaucoup de VRAM (mais tu auras du tearing).

je voudrais éviter le tearing. en serrant un peu le fond devrait faire 100-120 tiles ça pourrait peut être le faire.

[fourchette]

Y a t il a une limite pour les tailles des images supportées par les fonctions BMP_drawBitmap et BMP_drawBitmapScaled ?

en testant avec une version simplifié du sample bench sgdk (bmp_test.c) , en remplaçant par une image 128x128 ou 172x172 j'ai un soit un illegal instruction soit un écran noir...

[Stef]

C'est pas une palette, ce sont des tiles pleines. Tu te sers souvent de celle pleine de 0. Les autres, si tu ne t'en sers pas, tu peux les écraser si tu veux...

J'ai essayé de les retirer dans une ancienne version de SGDK car effectivement à part le tile 0, les autres ne sont pas très utiles je trouve mais certains "utilisateurs" ont demandé à ce que je les ré-intègre... bon après ça ne coute que 15 tiles Il y a aussi la 'font' qui devrait être optionnelle mais vu qu'il y a des fonctions drawText(..) intégrés, je la laisse par défaut (libre au développeur de l'écraser s'il souhaite gagner quelques tiles).

[Stef]

Y a t il a une limite pour les tailles des images supportées par les fonctions BMP_drawBitmap et BMP_drawBitmapScaled ?

en testant avec une version simplifié du sample bench sgdk (bmp_test.c) , en remplaçant par une image 128x128 ou 172x172 j'ai un soit un illegal instruction soit un écran noir...

J'inspecte ça mais je pense que ce qui pose problème c'est la compression, si tu as le code de bmp_test.c, tu verras que je décompresse l'image de test en amont et ensuite je l'utilise pour l'affichage et la demo "bench" est déjà à la limite sur la mémoire (à cause du double buffer bitmap en RAM interne). Si tu testes avec une image non compressée ça devrait passer

[fourchette]

il me semble avoir testé avec et sans compression, pour un même résultat.

je réessayerai.

[Stef]

En tout cas techniquement sur la méthode utilisée, rien n'empêche d'avoir une grosse image source... mais je viens de me rendre compte que je ne fais aucuns tests de limite, du coup si tu "sors" du buffer bitmap, alors ça tape n'importe où en mémoire  Bon faudrait que j'améliore ça, en attendant tu dois t'assurer de ne pas dépasser la taille du buffer bitmap (256x160).

[fourchette]

J'ai compris mon erreur. A priori on ne peut pas écrire en dehors de la zone du bitmap. Tant qu'aucune partie de mon image ne dépasse la zone, pas de soucis, mais dès que 1px dépasse ça plante d'une manière ou d'une autre. J'avais pas percuté, je pensais que la lib se démerdait pour couper la zone qui dépasse. De toute façon mon image fait 172x172 donc au-delà de 256x160...
Je pense que je vais stocker en ROM les étapes du zoom.

-edit-

Est-il possible de positionner verticalement le bitmap à l'écran ? je l'ai fait horizontalement avec VDP_setHorizontalScroll mais ça ne semble pas fonctionner verticalement.

[Stef]

C'est exactement ce que je venais de dire, la méthode ne protège pas de l'écriture en dehors du buffer... je vais corriger ça car sinon effectivement ça va souvent poser problème

Sinon le vertical scroll est utilisé en interne pour le double buffering donc non tu ne peux pas l'utiliser hélas :-/

[fourchette]

@stef

quel serait le meilleur mapping mémoire afin d'obtenir un maximum de tiles à disposition, avec comme contraintes
- résolution 320x240
- plan A et plan B en 64x32
- 80 sprites
tout le reste je ne l'utiliserais pas (pas de window, pas de scrolling)

est ce qu'il y un documentation quelque part qui précise la taille de vram nécessaire en fonction des différentes configurations/éléments utilisés ?

[Stef]

Si tu utilise le mode bitmap alors tu es obligé de passer les plan en 64x64 à cause du double buffering ce qui consomme hélas pas mal de VRAM, sinon la config par defaut de SGDK est assez optimisé (64x32 et très peu de mémoire réservée pour la window qui est rarement utilisé).

Récupéré depuis le fichier vdp.c de SGDK :

Code:

#define WINDOW_DEFAULT          0xD000      // multiple of 0x1000 (0x0800 in H32)
#define HSCRL_DEFAULT          0xD800      // multiple of 0x0400
#define SLIST_DEFAULT          0xDC00      // multiple of 0x0400 (0x0200 in H32)
#define APLAN_DEFAULT          0xE000      // multiple of 0x2000
#define BPLAN_DEFAULT          0xC000      // multiple of 0x2000

Si tes plans sont en 64x64 (à cause du bitmap engine) alors tu n'as pas le choix :
Tu dois utiliser au moins 0xC000-0xDFFF et 0xE000-0xFFFF pour les 2 plans. Ensuite tu peux caser tout le reste de 0xB000-0xBFFF. Mais dans ce cas ça te laisse pas grand chose pour les tiles en dehors de ceux réservée pour le bitmap engine.

[fourchette]

J'ai laissé de coté mon problème sur les bitmap. Ma question ne portait pas là dessus.

Je souhaites avoir un maximum de tiles disponibles. Et donc virer de la VRAM (si c'est possible) tout ce qui n'est pas nécessaire suivant les contraintes précisées soit résolution 320x240 avec seulement des plans A et B en 64x32.

[TotOOntHeMooN]

En arcade, dans certains jeux c'est le level design qui est fait en fonction pour jouer d'astuce.
Par exemple dans Ghosts'N Goblins, il y a des zones de transitions in-game pour changer de set.

[Tryphon]

Dans Ghouls'n Ghosts aussi (ce qui est spectaculaire dans la version MD, c'est qu'en plus elles sont compressées).

[Invité]

@Stef as-tu pensé à proposer des logos à intégrer dans la présentation ou le générique de fin des jeux ?

[Stef]

Y'a bien un logo dans la librairie SGDK mais il est désactivé par défaut car d'une part je ne veux l'imposer et d'autre part il n'est plus très représentatif on va dire
Cela dit si tu veux l'activer, passe le define SHOW_LOGO (ou quelque chose dans ce genre) à 1 dans le fichier config.h de SGDK (répertoire 'inc') et recompile la lib, et hop tu as un logo qui claque :p

[Tryphon]

C'est le Sonic gribouille ?

[Stef]

Ouais, en plus le Sonic n'est même pas de moi (enfin je l'ai recopié on va dire ^^), je le trouvais trop chouette

[Invité]

@Stef ça marche super :)

Je voulais également te demander si tu envisages prochainement de créer un logo dédié à SGDK qu'on puisse l'imprimer sur des tshirt. Je serais très fier et content d'en porter !

Si ce n'est pas d'actualité, je vais prendre le temps de voir ce que je peux faire de ce coté là. Normalement, je devrais prochainement avoir le dessin du héro principal d'IRENA, je pourrais réaliser un logo SGDK avec le personnage, je pense que ça en jetterais !

[Invité]

Et aussi lui faire un petit don sur sa page :
https://stephane-d.github.io/SGDK/

[Stef]

Heu.. en fait on m'a déjà fait des logos sympas pour SGDK c'est juste que je ne les ai pas intégré encore ^^
Je vais essayer de les retrouver et les mettre en ligne après mon retour !

@vetea> tu es mon premier donateur, et de loin, merci encore :-)
Prochainement j'envisage de mettre en place un patreon ou quelque chose dans ce style, je pense que ça sera mieux et plus officiel qu'un simple don PayPal, ça sera aussi peut-être un meilleur endroit pour communiquer sur mes projets :-)

[Invité]

Dès que je serais en mesure de faire le don, je le ferais je vous le promets.

Je voudrais optimiser mon code pour le PAL et du coup j'ai besoin d'augmenter la vitesse, jusque-là pas de problème, mais quelle valeur utiliser ?

Quelqu'un à mesurer exactement la différence de vitesse entre le PAL et le NTSC ?

Si j'a un scrolling qui se met à jour à chaque frame, donc 1, faut-il passer ce nombre à 2 ?

Merci les lapins !

[Invité]

Non tu le laisses à la frame .

[Hpman]

Faut tout multiplier par 1.2 si tu veux que le 50Hz aille à la même vitesse que le 60.

[Invité]

merci beaucoup :)

[ichigobankai]

une règle de 3... wahou ^^

edit. désolé, ce soir, je suis en mode pseudo con.

[Invité]

[Zarnal]

20%

[fourchette]

Salut à tous.

J'ai un petit soucis avec l'arrêt de vgm avec XGM_stopPlay(), ça craque ou plutôt l'arrêt n'est pas très propre au niveau des canaux du PSG (du moins le SN4). Pas trop de soucis pour les canaux FM et PCM.

C'est assez gênant lors d'un sound test quand on mute par exemple ou lors d'un passage d'une musique à une autre...

Y aurait il une solution ou un contournement pour éviter cet effet ?

[Stef]

C'est assez bizarre, normalement passer l'enveloppe à 0 est suffisant (ce que fait normalement le XGM_stopPlay()), est-ce que il y a une autre commande qui passe entre temps ? As tu essayé de faire un XGM_pausePlay() à la place voir si ça fait une différence ?

[fourchette]

ça semble plus propre avec la pause.

XGM_isPlaying renvoie quelle valeur quand la piste est en pause ?

[Stef]

Il renvoie 0 (FALSE) normalement...