Re: [Mégadrive] Pang !

[youki]

Si je fais un jeu sur megadrive, il me faudra 30 ans pour remplir la cartouche!... i

[Invité]

MDR, rassures toi ça va très vite, même si avec 32Mb tu as quand même pas mal de marge .

Un bon 8Mb pour commencer c'est déjà pas mal .

[Stef]

Stef j'avais discuté avec ichigobankai, sur le fait que tu allais intégré dans ta librairie , la Lib pour master system que vingazole a fait.

Est ce toujours d'actualité ?

Il me semble au contraire que je disais que ça n'avait que peu de chances d'arriver non ?
A mon sens c'est un projet totalement différent et merger les 2 n'a que peu d'intérêt :-/
Ce que j'ai en tête c'est éventuellement d'ajouter le support pour le MegaCD (mais ça ne viendra pas tout de suite).

[pckid]

Petite Question Stef,

Comment ranges tu les projets sous sgdk , doit on avoir un repertoire par jeu avec les res ?
et copier toutes les librairies ?

Ou l'on peut laisser les librairies sous sdgk et compiler nos sources dans un répertoire du meme niveau que Sgdk ?

car pour l'instant je mets tout dans res sous sgdk, mais j'aimerais séparer par test.

merci ton aide ou votre aide si d'autres répondent

[Invité]

Bah normalement SGDK doit connaitre l'emplacement des ses libs, donc si tu compiles un:
 printf("Hello world");

Que le source soit dans test1\test1.c ou test2\test2.c ne change rien .
Par contre si tu crées tes propres libs, il faut les indiquer au compilateur .
#include "chemin_de_ma_lib\ma_lib.c(ou .o)"

Je suppose que SGDK doit fonctionner pareil .

[Stef]

Petite Question Stef,

Comment ranges tu les projets sous sgdk , doit on avoir un repertoire par jeu avec les res ?
et copier toutes les librairies ?

Ou l'on peut laisser les librairies sous sdgk et compiler nos sources dans un répertoire du meme niveau que Sgdk ?

car pour l'instant je mets tout dans res sous sgdk, mais j'aimerais séparer par test.

merci ton aide ou votre aide si d'autres répondent

Oui comme le dit Touko tu peux mettre tes projets où tu veux et la librairie ne bouge pas ! D'ailleurs dans le répertoire de SGDK tu as un sous répertoire "sample" qui contient quelques exemples où chaque projet à son propre répertoire. Je te conseille de travailler ainsi, un répertoire par projet et ensuite dans le répertoire de ton projet tu peux faire un répertoire "src" pour les sources et un répertoire "res" pour les ressources.
En utilisant le makefile de SGDK (makefile.gen) normalement il va automatiquement chercher tes fichiers sources dans "src" et les fichiers resources (.res) dans "res" en plus de chercher directement dans la racine.

[vingazole]

Stef j'avais discuté avec ichigobankai, sur le fait que tu allais intégré dans ta librairie , la Lib pour master system que vingazole a fait.

Est ce toujours d'actualité ?

Il me semble au contraire que je disais que ça n'avait que peu de chances d'arriver non ?
A mon sens c'est un projet totalement différent et merger les 2 n'a que peu d'intérêt :-/

Voire même aucun

[Stef]

Oui voilà, enfin après la MD utilise également un Z80 et est compatible avec la Master System mais clairement SGDK est fait pour le développement MD, pas Master System C'est quoi d'ailleurs cette librairie Master System ? ^^

[pckid]

Bah mince alors ! Ichigobankai , m'a pas menti, il faut que je retrouve ce thread !

Moi je trouve un interêt ! developper sur la master system, avec la facilité du sgdk !

[vingazole]

M'enfin SGDK produit du code 68000, non ?

[Stef]

Oui, enfin tu as un assembleur Z80 quand même, pour programmer ton propre driver son si tu le souhaite mais y'a pas de compilateur C pour le Z80 par exemple...
Le gros atout de SGDK, c'est la librairie faite pour exploiter les ressources de la Megadrive... il faudrait avoir le même genre de librairie pour la Master System pour qu'il y ai un intérêt et SGDK n'a rien pour ça !

[pckid]

Je n'arrive à pas à retrouver le message de ichigo sur master system france,

Je crois qu'il parlait que de ce compilo http://www.z88dk.org/forum/

et Vingazola avait fait des librairie mieux en asm, et qu'il allait etre intégré dans le sgdk ou un truc comme çà.

Je le retrouve et je reviens

[vingazole]

Je crois que tu as confondu SGDK et SDCC.

Pour clarifier: Ichigo avait commencé à coder son clone de Bomberman avec le compilateur C z88dk, pour lequel un gars (haroldoop, un brésilien) avait créé une library pour la SMS (contenant juste une dizaine de fonctions).

z88dk étant très peu performant, j'avais dû recoder certaines fonctions écrites en C par Ichigo en ASM z80.

Ichigo avait trouvé par la suite un comparatif z88dk/SDCC (un autre compilateur C pour z80) sur un forum CPC qui indiquait que SDCC était bien meilleur : on a donc basculé de z88dk vers SDCC (il a fallu pour cela que je code un crt0 - routine de démarrage - spécifique à la Master System et que je convertisse les fonctions de la lib de haroldoop prévues pour z88dk pour que ça marche sous SDCC).


Quant à "Vingazola", non, je n'ai pas l'intention de lancer ma propre marque de Cola

[pckid]

Désolé pour le Coca, j'ai rippé,

Oui j'ai confondu mince de mince, alors vous allez sortir cette librairie pour master system sur SDCC ?

Sorry my friend

[vingazole]

Pas de souci, buddy

Oui, j'ai quelques petits trucs à revoir et je vais rendre la lib publique.

Mais pour l'instant il y a très peu de fonctions dans la lib et il reste beaucoup à faire. Je ne voulais publier qu'une fois la lib plus complète mais comme je fais déjà pas mal d'autres trucs à côté (sans compter que j'apprends un nouveau métier depuis quelques mois) je n'ai/n'aurai pas spécialement le temps de m'en occuper.

Je compte bien que les spécialistes de SMSpower (entre autres) enrichissent la lib et que le dév sur SMS décolle enfin

[Invité]

Quant à "Vingazola", non, je n'ai pas l'intention de lancer ma propre marque de Cola 

 
J'ai failli pisser dans mon froc quand j'ai lu ça !!

[Stef]

J'avoue que ça m'a bien fait rire aussi 😆
Enfin du coup je comprend mieux... Effectivement avoir une librairie du style de sgdk pour la master system ce pourrait être sympa, après je pense que l'utilisation du C pour une machine 8 bis a ses limites aussi, déjà que pour la MD c'est pas toutes génial (SGDK utilise un peu d'assembleur).

[ichigobankai]

z88dk étant très peu performant, j'avais dû recoder certaines fonctions écrites en C par Ichigo en ASM z80.

tu m'étonnes, Z88DK est plutot "bien merdique" niveau optimisation...pas contre il est tres permissif au niveau de la syntaxe en C (ca m'a permis de me lancer dans le C sans trop me prendre la tête) contrairement à SDCC qui est assez strict.
Et c'est vrai que l'algo de Y-order, les déplacements sram > vram  & cie, heureusement que tu as converti ca en ASM à l'époque, quand je vois déjà la lenteur du bouzin

mais bon la lib SDCC en l'état actuel est déjà pas trop mal, y'a du bankswitch (on peut faire des roms de 1mo) et un lecteur de musique/son en psg...manque la musique FM et peut etre d'autres trucs a optimiser via à vis du code d'origine d'Haroldoop (le wait_vbank ?)

bon moi je suis une grosse bit* finie en ASM (meme si j'arrive a modifier un peu dedans),
donc je ne peux pas t'aider a modifier la lib elle même...

Quant à "Vingazola", non, je n'ai pas l'intention de lancer ma propre marque de Cola

Tu tiens un filon, vas-y fonce

[bfg]

Petites news du projet.

La gestion des plateformes destructibles/indestructibles est faite. Il faut maintenant que je réencode les datas des niveaux pour qu'ils s'adaptent à la résolution x de 320 au lieu de 256 de la coleco.

J'ai corrigé un bug qui faisait que le jeu était plus lent que sur la Coleco :) :)

Je vais tenter aussi un nouveau type de détection de collision pour avoir des rebonds plus réaliste sur les plateformes. (Pas évident du tout ...)

Restera la gestion des bonus et je serais à 100% comme la version Coleco. Restera à améliorer ensuite :)

[Invité]

et j'avais zappé ce topic ...

abonné :)

[Invité]

Petites news du projet.

J'ai corrigé un bug qui faisait que le jeu était plus lent que sur la Coleco :) :)

Tu es sur que c'était un bug ca ??? 

[philip]

Petites news du projet.

La gestion des plateformes destructibles/indestructibles est faite. Il faut maintenant que je réencode les datas des niveaux pour qu'ils s'adaptent à la résolution x de 320 au lieu de 256 de la coleco.

J'ai corrigé un bug qui faisait que le jeu était plus lent que sur la Coleco :) :)

Je vais tenter aussi un nouveau type de détection de collision pour avoir des rebonds plus réaliste sur les plateformes. (Pas évident du tout ...)

Restera la gestion des bonus et je serais à 100% comme la version Coleco. Restera à améliorer ensuite :)

Tu peux nous expliquer ce bug ?

[bfg]

C'est à cause des tests Boules/Plateformes.
J'ai un max de 20 plateformes en mémoire (même si je n'ai pas un écran qui utilise 20 plateformes) et les plateformes ont 3 types HORIZONTAL,VERTICAL et NUL.

Quand j'ai initialisé les plateformes je les ais initialisé à ... NULL avec 2 L. Pourquoi comme un con sur la version Coleco il n'y à qu'un seul L, surement pour me rappeler mon niveau :) :) :)

Bref, lors du test de collision je ne teste que les boules + les plateformes différentes de NUL. Or NUL <> NULL donc je me tapais quand il y à toutes les boules : 16 * 20 = 320 tests de collisions par tour ...

Donc une bonne initialisation et ça ne rame plus.

En sachant qu'en plus la routine de collision est trop "complète" pour ce type de collision ,ben oui, elle est faire pour tester 2 objets en mouvements, et que les plateforme bouge pas, donc je peux précalculer quelques infos et simplifier la routine en fait, j'ai encore une bonne marge d'optimisation ...

[philip]

320 tests, c'était effectivement beaucoup, merci pour ton retour.

[ShiningBZH]

Je n'avais pas vu ce sujet , hop abonné ! 

ton jeu me fait beaucoup penser au jeu PSP " Run ghost run "