Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

Et pk ne pas le mettre juste hors de l'écran sur Y pour le cacher ??

[r_songo]

Touko : a la base ce que je voulais était de pouvoir le supprimer afin de libérer la place.
Car comme on doit updater les sprites en précisant le nombre, si tu as 64 sprites, avec les sprites 20 à 30 hors écran pourquoi les updater. Pourquoi faire un sprites jusqu'a 64 au lieu de 54.

Stef : pour la musique en wav, tu fais une compression quand même non ? Car ma musique de 3Mo passe à 1.5Mo

[Stef]

Et pk ne pas le mettre juste hors de l'écran sur Y pour le cacher ??

Si ça marche en fait mais en mettant "never visible" ça accélère un peu le traitement car il faut le dire ma méthode SPR_update(..) est abominablement lente :-/ Déjà en la passant en assembleur je pourrais probablement gagner un bon facteur (2x au moins), mais elle est reste assez complexe quand même donc même en assembleur ça sera assez lourd :-/

Touko : a la base ce que je voulais était de pouvoir le supprimer afin de libérer la place.
Car comme on doit updater les sprites en précisant le nombre, si tu as 64 sprites, avec les sprites 20 à 30 hors écran pourquoi les updater. Pourquoi faire un sprites jusqu'a 64 au lieu de 54.

En utilisant le "never visible" sur les sprites 20 à 30 tu devras quand même utiliser un update sur l'ensemble des sprites, c'est juste qu'en interne je les écarterai plus rapidement.

Stef : pour la musique en wav, tu fais une compression quand même non ? Car ma musique de 3Mo passe à 1.5Mo

En fait tout dépend du driver que tu utilises pour jouer tes fichiers wav et donc de comment tu les as déclaré dans le fichier ressource

[Invité]

Touko : a la base ce que je voulais était de pouvoir le supprimer afin de libérer la place.
Car comme on doit updater les sprites en précisant le nombre, si tu as 64 sprites, avec les sprites 20 à 30 hors écran pourquoi les updater. Pourquoi faire un sprites jusqu'a 64 au lieu de 54.

Stef : pour la musique en wav, tu fais une compression quand même non ? Car ma musique de 3Mo passe à 1.5Mo

Oui mais la tu prends un cas favorable,cad des sprites qui se suivent, mais si tu as des trous, et comme tu uploades via dma, je pense que de tout uploader est moins couteux que de faire un test sur chaque sprite pour voir si ils sont caches ou non,enfin moi je le vois comme ca .
Edit': je viens de voir le post de stef, ok je comprends alors 

[Stef]

Haha non ouais on est très loin du simple transfert DMA :p
Le sprite engine est pratique car il gère beaucoup de chose pour toi (organisation automatique des sprites dans la SAT, allocation automatique des tileset en VRAM, gestion des meta sprites..) mais du coup c'est bien lourding :p
En plus pour ne rien arranger c'est codé en C... clairement ça ne te permettra pas d'animer des tonnes de sprites à toute vitesse mais pour un jeu assez simple ça te facilite beaucoup le travail
Pour un jeu plus intensif, tu utiliseras des méthodes de plus bas niveau.

[Invité]

Lol qu es ce qu il faut pas faire pour pas effrayer les nouveaux venu 

[Stef]

Ca m'a servi aussi mais bon...
A la base effectivement c'était pour simplifier la gestion des sprites
Ca mériterait une bonne doc quand même car là à part en essayant de comprendre en lisant le doxygen du fichier spr_eng ou en regardant le sample "sprite" qui est assez minimaliste, y'a pas grand chose... c'est même pire que ça, y'a un wiki mais complètement outdated. Limite je devrais le virer car beaucoup l'utilise et partent sur de mauvaises méthodes à cause de ça :-/

[Invité]

Bon apres c est sympa d avoir un devkit complet, surtout que rien n empeche d optimiser en asm par la suite .

[r_songo]

Pour les wav j'ai utilisé le xgm

[Stef]

Ok, dans ce cas le sample est automatiquement converti en mono 8bits @14KHz.
Si ton WAV d'origine était en 16 bits @14Khz ou en stéréo ça explique la taille divisée par 2.
Si tu avais mis un WAV 16 bits @44Khz stéréo (qualité CD) tu aurais un fichier résultat 12.5x plus petit :p

A noter que si tu n'utilises que du WAV sans musique VGM/XGM, autant utiliser le driver 2ch ADPCM, tu divises encore la taille par 2 avec une meilleur qualité (par contre 2 channels seulement, une pour la musique, une pour les bruitages et basta )

[Stef]

Bon apres c est sympa d avoir un devkit complet, surtout que rien n empeche d optimiser en asm par la suite .

Oui voilà tu as toujours le choix... Après il est sur que tu vas attirer plus de monde avec un truc plus abordable :p

[r_songo]

Ok, dans ce cas le sample est automatiquement converti en mono 8bits @14KHz.
Si ton WAV d'origine était en 16 bits @14Khz ou en stéréo ça explique la taille divisée par 2.
Si tu avais mis un WAV 16 bits @44Khz stéréo (qualité CD) tu aurais un fichier résultat 12.5x plus petit :p

A noter que si tu n'utilises que du WAV sans musique VGM/XGM, autant utiliser le driver 2ch ADPCM, tu divises encore la taille par 2 avec une meilleur qualité (par contre 2 channels seulement, une pour la musique, une pour les bruitages et basta )

Mon wav était en 16 bit 14Khz en mono.
Je vais utilise le driver ADPCM alors. Car à la base je n'ai prévu qu'une musique avec 1 bruitage à la fois.

[Stef]

Dans ce cas utilise des WAV de plus haute qualité, le driver ADPCM utilise du 22 Khz. A noter que si le format WAV n'est pas dans le bon format, rescomp va le convertir automatiquement comme il faut mais pour garantir la meilleure qualité qu'il soit il vaut mieux être au moins sur la même fréquence d’échantillonnage (22 Khz ici) car le ré échantillonnage induit des pertes (surtout de la manière dont je le fais :p).

[Invité]

Oui voilà tu as toujours le choix... Après il est sur que tu vas attirer plus de monde avec un truc plus abordable :p

C'est sur, j'ai vu des trucs sympas en homebrew fait avec, dommage que peu aillent jusqu'au bout, c'est un peu le lot de toutes les machines en général .
Tu sais si le shoot MD antarex est fait avec ??

[Stef]

Oui voilà tu as toujours le choix... Après il est sur que tu vas attirer plus de monde avec un truc plus abordable :p

C'est sur, j'ai vu des trucs sympas en homebrew fait avec, dommage que peu aillent jusqu'au bout, c'est un peu le lot de toutes les machines en général .
Tu sais si le shoot MD antarex est fait avec ??

Pour Antarex ils utilisent SGDK mais pas pour tout justement, là où ils veulent plus de controle ils font leurs propres routines Il me semble qu'ils sont assez content du nouveau driver son (auparavant ils utilisaient le driver VGM en C qui, s'il est bien pratique, a quand même ses limites).

[r_songo]

Enfait, il faudrait se mettre à plusieurs pour faire un jeu.
Un jeu gamopat sur Megadrive :)

[pckid]

Le compilateur de sgdk(sdcc) est bcp plus puissant que celui de Huc .

En effet, il envoit du lourd je croise les doigts pour pouvoir arriver l'adaptation d'un jeu sur Sgdk et je verrais après pour Huc. Merci à toi

[Invité]

tu as le source de go planes ici :
http://www.sega-16.com/forum/showthread.php?28977-Goplanes-Source

[pckid]

Merci pour ce lien,
c'est intéressant cela peut aider pour les tiles et la map, et la gestion des collisions.

Comme dis Michel, il faut aller petit à petit en décomposant pour maitriser chaque élément.

Il me faut encore 2 week end et je vous post sur un autre topic, mes avancées.

[Stef]

Le compilateur de sgdk(sdcc) est bcp plus puissant que celui de Huc .

En effet, il envoit du lourd je croise les doigts pour pouvoir arriver l'adaptation d'un jeu sur Sgdk et je verrais après pour Huc. Merci à toi

SGDK utilise GCC, pas SDCC qui est un compilo pour le Z80 il me semble. Je le dis parce-que certains après vont faire l'amalgame avec SGDK et SDCC qui sont 2 choses complètement différentes (c'est déjà arrivé :p).
GCC n'est pas un très bon compilo mais il a l'avantage de supporter beaucoup de target, dont le 68000... un truc bien pourri avec GCC, c'est que plus les versions progressent et plus le code généré pour les anciens cpu comme le 68000 devient pourri :-/
Par exemple dans SGDK j'utilise un vieux GCC (3.4.6) car les versions 4 et > produisent un code vraiment moins bon. En fait les meilleures versions de GCC pour le 68000 c'est les 2.x, elles produisent un meilleur code mais le problème c'est qu'elles ont quelques bugs bien génants.
Pour le compilo Huc, je ne sais pas ce qu'il vaut mais le problème c'est plutot l'architecture du CPU qui se prête vraiment pas à la logique du code C. Limite il faudrait un langage et un compilo adapté pour le 6502 mais je pense que ça ressemblerait plus à du meta assembleur qu'à du C ou autre.

[Invité]

ah ok dsl alors !!

Pour le compilo Huc, je ne sais pas ce qu'il vaut mais le problème c'est plutot l'architecture du CPU qui se prête vraiment pas à la logique du code C. Limite il faudrait un langage et un compilo adapté pour le 6502 mais je pense que ça ressemblerait plus à du meta assembleur qu'à du C ou autre.

Non même si l'archi ne permet pas d'avoir du code aussi efficace que sur 68000, le code généré est bien pourris, car en plus d'être du code asm 6502, il est bourré de macros et de code compilé inefficace et lourd .

Il suffit rien que de voir la traduction d'un while(1) ..
Huc est juste utilisable pour débuter et se faire la main, rien de plus, pour des projets un peu ambitieux il nécessite pas mal de twick asm, comme par exemple l'accès aux tableau qui est lent à mourir car mal géré  (géré en FAR même si dans le mappage mémoire).Sans parler qu'il n'est plus maintenu depuis 2005 

tu peux avoir de bons résultats quand même :

[vingazole]

SGDK utilise GCC, pas SDCC qui est un compilo pour le Z80 il me semble. Je le dis parce-que certains après vont faire l'amalgame avec SGDK et SDCC qui sont 2 choses complètement différentes (c'est déjà arrivé :p).
GCC n'est pas un très bon compilo mais il a l'avantage de supporter beaucoup de target, dont le 68000...

SDCC supporte plusieurs targets, aussi :

SDCC is a retargettable, optimizing ANSI - C compiler suite that targets the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (z80, z180, gbz80, Rabbit 2000/3000, Rabbit 3000A, TLCS-90) and STMicroelectronics STM8. Work is in progress on supporting the Microchip PIC16 and PIC18 targets. It can be retargeted for other microprocessors.

...mais pas le 6502 et son inénarrable BCD

[Invité]

mais pas le 6502 et son inénarrable BCD 

 
The killer mode  ,voilà pk c'est the best CPU ever, le mode BCD, quelle magnifique trouvaille 
PS: Humour inside (au cas où) "Avec ça on est au même niveau qu'un ARM  "

[Stef]

Non même si l'archi ne permet pas d'avoir du code aussi efficace que sur 68000, le code généré est bien pourris, car en plus d'être du code asm 6502, il est bourré de macros et de code compilé inefficace et lourd .

Il suffit rien que de voir la traduction d'un while(1) ..
Huc est juste utilisable pour débuter et se faire la main, rien de plus, pour des projets un peu ambitieux il nécessite pas mal de twick asm, comme par exemple l'accès aux tableau qui est lent à mourir car mal géré  (géré en FAR même si dans le mappage mémoire).Sans parler qu'il n'est plus maintenu depuis 2005 

tu peux avoir de bons résultats quand même :

Perso je trouve que le jeu de plate forme est pus qu'honnête pour un truc fait en C.
C'est vraiment 100% C ? si c'est le cas c'est déjà pas mal vraiment !

[Stef]

SDCC supporte plusieurs targets, aussi :

SDCC is a retargettable, optimizing ANSI - C compiler suite that targets the Intel MCS51  based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (z80, z180, gbz80, Rabbit 2000/3000, Rabbit 3000A, TLCS-90) and STMicroelectronics STM8. Work is in progress on supporting the Microchip PIC16 and PIC18 targets. It can be retargeted for other microprocessors.

...mais pas le 6502 et son inénarrable BCD

Ah oui c'est vrai que SDCC supporte plusieurs target mais ça n'a rien à voir avec GCC quand même Ca se limite à de "petits" CPU si j'ose dire... enfin c'était surtout pour éviter les amalgame surtout

[Stef]

mais pas le 6502 et son inénarrable BCD 

 
The killer mode  ,voilà pk c'est the best CPU ever, le mode BCD, quelle magnifique trouvaille 
PS: Humour inside (au cas où) "Avec ça on est au même niveau qu'un ARM  "

C'est quoi le délire avec le BCD du 6502 ? Je sais qu'ils l'ont viré sur le 2A03 de la NES mais à part ça je ne vois pas.

[Invité]

Perso je trouve que le jeu de plate forme est pus qu'honnête pour un truc fait en C.
C'est vraiment 100% C ? si c'est le cas c'est déjà pas mal vraiment !

Oui, c'est 100% C, le RPG était leur premier jeu commencé en 2005 et sorti en 2012 je crois ..

C'est quoi le délire avec le BCD du 6502 ? Je sais qu'ils l'ont viré sur le 2A03 de la NES mais à part ça je ne vois pas.

Mais rien, ça te permet de faire des calculs directement en base 10, et non en binaire . 
Il parait que c'est le seul brevet du 6502, tu n'as rien à payer en royalties si tu n'as pas ce mode, vu que la fabrique du CPU était gratos semble t'il .
Et on sait tous que chez big N, y'a pas de petites économies 

[Stef]

Perso je trouve que le jeu de plate forme est pus qu'honnête pour un truc fait en C.
C'est vraiment 100% C ? si c'est le cas c'est déjà pas mal vraiment !

Oui, c'est 100% C, le RPG était leur premier jeu commencé en 2005 et sorti en 2012 je crois ..

C'est quoi le délire avec le BCD du 6502 ? Je sais qu'ils l'ont viré sur le 2A03 de la NES mais à part ça je ne vois pas.

Mais rien, ça te permet de faire des calculs directement en base 10, et non en binaire . 
Il parait que c'est le seul brevet du 6502, tu n'as rien à payer en royalties si tu n'as pas ce mode, vu que la fabrique du CPU était gratos semble t'il .
Et on sait tous que chez big N, y'a pas de petites économies 

Oui mais le BCD c'est supporté sur n'importe quel CPU d'ou mon interrogation :p Sauf justement sur le 2A03 où il a été viré pour des raisons de brevet (ah ces vieux rats chez Nintendo...)

[Invité]

Je sais pas si le Z80 possède ce mode .

[Stef]

Perso je ne connais pas de CPU qui ne supporte pas le BCD (à part le 2A03).
Sur le Z80 c'est l'instruction DAA qui te converti une valeur binaire classique au format BCD. Je pense que les nouveaux CPU n'intègre plus d'instructions BCD (sauf ceux qui ont besoin d'une retro compat) car ça n'est plus d'aucune utilité... Déjà moi même je n'utilise jamais ces instructions :p

[Invité]

C'est surtout pratique pour les calculs de score dans les jeux, bcp plus rapide que les méthodes software .