Re: Sgdk - Sega Megadrive / Genesis Development Kit

[ichigobankai]

Aucun à ma connaissance - du moins ca n'a pas été écrit,
cependant je ne sais pas avec quel(s) outil(s) a été fait Oh Mummy Genesis (de 1985 alternativo),
ainsi que Uwol : Quest for money.

[Invité]

Ça m'étonne .... Bon OK merci.
Quid de cette solution pour créer et publier des jeux MD ???
Bex serait il la seule solution viable ?? ( Ah je ris 
.. )
Bon parce que j'aimerais m'y mettre a la SGDK donc bon, on verra bienGGG

[Invité]

Tu troll aussi Vetea ?
Il y'a deja eux des jeux en C comme Pier Solar , après pour SGDK peut être qu'il manque de maturité et de 'pub'.

[Invité]

Non je ne "troll" pas, c'était une question sérieuse.
Après tout qui ne tente rien n'a rien, alors on va s'y mettre et utiliser mon boulot sur Papi Tennis comme base.
Merci !! :)

[Tryphon]

@Papi : ta question est intéressante et je ne peux que spéculer sur les réponses. Voici quelques arguments :

* SGDK est clairement plus complet, plus puissant, plus souple que BEX

* Mais il est aussi moins agréable à utiliser, parce qu'on dira ce qu'on veut, mais le C, c'est chiant

* BEX est beaucoup plus friendly, avec, outre un langage plus avenant, des éditeurs d'à peu près tout intégrés (même si le générateur de ressources de SGDK est au final beaucoup plus puissant et permet d'utiliser ses propres outils)

* pour un "petit" jeu, BEX est suffisant ; Papi Commando est indéniablement un vrai jeu, et un bon, et il représente à peu près le summum de ce que tu peux faire en BEX (d'ailleurs tu as toi même dit que tu avais codé certains passages en asm) ; les autres jeux développés en BEX sont quand même beaucoup plus rudimentaires

* donc ceux qui partent sur SGDK directement partent sur un jeu plus ambitieux. Souvent, ils ne le terminent pas (je pense aux différents protos de très bonnes qualité de ChilyWilly si je me souviens bien, tous sont très aboutis mais aucun n'est terminé au point d'être commercialisable)

* ceux qui codent en C ont souvent un niveau de programmation assez élevé (je ne parle pas de moi ) et savent aussi coder en asm, ce qui rend la niche du C d'autant plus réduite (je pense à Sik par exemple, qui crée de très belles choses en asm) (mais n'en finit aucune)

[ichigobankai]

* [...], parce qu'on dira ce qu'on veut, mais le C, c'est chiant

Je ne peux pas être d'accord avec ca... mais ca n'engage que moi !

[Tryphon]

Note bien que j'aime le C

[Invité]

Je dirai que uwol est en asm, et oh mumy en C .
Il me semble que sacred line est egalement en C.

Y a aussi les homebrew non commercialisés du coréen qui a fait des protos de darius, et un manic en c.
Antarex il me semble est en c, mais je sais pas si il l'est entiément .

[ichigobankai]

Sacred Line c'est pas vraiment du C, c'est fait avec "Gincs" un moteur de "visual novel"
(tu tapes meme pas une ligne de code.. tu m'étonnes que c'est über moche au final)

Uwol c'est fait en C, c'est Shiru qui avait fait le portage :
http://shiru.untergrund.net/software.shtml (en bas y'a le source)
Et apparemment c'est fait avec le devkit de Stef (indiqué dans la readme.txt)

[Invité]

Merci pour vos éclaircissements !!

[Invité]

Uwol c'est fait en C, c'est Shiru qui avait fait le portage :

C'est pour ça que je pensais qu'il l'avait fait en ASM .

EDIT:le coréen c'est rael16x .

[Tryphon]

Ixion est peut-être le homebrew MD le plus impressionnant que j'ai vu. Par moments, y'a tellement de boulettes qu'on se croirait sur 32 bits.

Un truc qui pourrait rendre SGDK plus populaire chez les amis de BEX, ce serait un IDE plus ou moins tout intégré du genre GameMaker, où plutôt que de tout coder tu insères des scripts (le moteur du jeu étant figé). C'est moins souple (perso je n'aime pas) mais plus facile pour démarrer, et puis t'as toujours la possibilité d'éditer le source final. Pas sûr que ça soit réellement faisable sur MD cela dit (GameMaker est connu pour être lent - je ne suis même pas sûr qu'il compile au final-, ce qui n'est pas gênant sur les PC actuels, mais le serait sur MD)

[Invité]

Des IDE pour le C tu on as belle lurette , eclipse , Code Block , Geany ect

[Tryphon]

Je me suis mal exprimé : je parle d'un IDE style GameMaker : tu crées à la souris les maps, les ressources, les objets qui vivent sur les maps, puis quand tu édites un objet, tu peux sélectionner dans un menu le code à effectuer lorsqu'il entre en collision avec un autre objet, avec le background, etc.

Dur à expliquer si tu n'as jamais vu GameMaker (ou un autre truc du genre), y'a des tuto (certains en français) sur Youtube si ça t'intéresse (si ma connexion internet était pas si foireuse, j'en aurais linké un).

[Invité]

Le probleme c'est que gamemaker est sur PC,et le processeur et la ram d'un PC est très grande ,  je doute qu'on puisse espérer faire pareil sur un processeur de 8mhz avec 32ko
Il est vrai que la mega drive est 'puissante' pour l'époque , mais son processeur reste tout de même très faible cela demande des langage bas niveau pour pouvoir programmer dessus (actuellement un processeur embarqué comme avr atmel a quelque euros et facilement 10 fois plus puissante que le 68000 de la mega drive).
Pour Bex , pour le moment j'ai vu aucun jeu très technique dessus (je parle de technicité , on exploitant le matériel).
Le C reste le bon compromis ,  après si tu veux mon avis c'est que quoiqu'on dise le C reste un langage qui demande d’être un minimum 'pro' dessus , et la plupart de ceux qui code en C actuellement sont des programmeurs du dimanche (pas tous) donc oui utilisant un langage aussi puissant que le C demande un très bon niveau pour bien le maîtriser.
Je ne parle pas de sa syntaxe , mais aussi de savoir ce que fait le compilo  , la machine cible ect.
Le C demande une très grande rigueur (beaucoup beaucoup plus que du basic) , et a partir de la si on obtient pas cette rigueur , il est difficile de faire un projet de jeu vidéo avec le C.
J'ai était étudiant aussi a la Fac beaucoup étudiant en 3 eme année (donc 3 ans de pratique en C) serait bien incapable de faire un super mario bros , donc des personne qui pratique le C de manière occasionnel n'a pas plus de chance que cela.

L'autre point , c'est que tu veux qu'une librairie se transforme en moteur de jeu , une librairie n'a pas pour but de devenir un moteur de jeu loin de la (en plus une librairie offrira toujours un optimisation bcp plus grande qu'un moteur de jeu) et dans notre cas cela reste primordial.

[Invité]

C'est bien pour cela que j'ai toujours eu du mal avec le C / Pascal en Fac ...

Je suis un vrai codeur du Dimanche ! Je me suis jamais considéré comme un "développeur" mais plus comme un créateur de jeu.

Néanmoins, je serai un peu plus optimiste quant à la possibilité de réaliser un véritable jeu avec la SGDK de Stef.
Si j'y suis arrivé avec Bex ( qui est LOIN d'être simple, détromper vous avec la soi disante accessibilité de ce DevKit ), je pense y arriver avec SGDK.
Bfg m'a gratifié de nombreux conseils sur le C / Sgdk et j'ai aussi quelques ouvrages de Mr Delannoy traitant sur le C.

Aprés je peux me tromper et me planter misérablement.
Mais avant de mettre un point final, je vais essayer d'y mettre mon ";" !

Salutations.

[Tryphon]

Le probleme c'est que gamemaker est sur PC,et le processeur et la ram d'un PC est très grande ,  je doute qu'on puisse espérer faire pareil sur un processeur de 8mhz avec 32ko
Il est vrai que la mega drive est 'puissante' pour l'époque , mais son processeur reste tout de même très faible cela demande des langage bas niveau pour pouvoir programmer dessus (actuellement un processeur embarqué comme avr atmel a quelque euros et facilement 10 fois plus puissante que le 68000 de la mega drive).

Le projet dont je parle n'est qu'un frontend à un développement en C. Le code généré par le bousin serait du C. GameMaker lui-même utilise son propre langage il me semble, mais d'autres projets du même genre génèrent du code dans un autre langage, qui peut parfois être compilé.

Il est clair que tu ne peux pas refaire GM sur MD (au passage 64Ko de RAM la MD, + 64 Ko de VRAM, merci pour elle ), mais un truc intermédiaire, sans problème. Il y a un soft assez célèbre axé RPG qui s'appelle RPG Maker, il y en a eu des versions sur des machines pas plus puissantes que la MD (même la SNES il me semble).

Après, ça nécessiterait de créer des GUIs (je ne sais pas faire) et un moteur de jeu assez générique en SGDK C (je crois que ChilyWilly avait un projet basé sur SGDK, Propeller de mémoire, ça pourrait servir de base).

Pour Bex , pour le moment j'ai vu aucun jeu très technique dessus (je parle de technicité , on exploitant le matériel).
Le C reste le bon compromis ,  après si tu veux mon avis c'est que quoiqu'on dise le C reste un langage qui demande d’être un minimum 'pro' dessus , et la plupart de ceux qui code en C actuellement sont des programmeurs du dimanche (pas tous) donc oui utilisant un langage aussi puissant que le C demande un très bon niveau pour bien le maîtriser.
Je ne parle pas de sa syntaxe , mais aussi de savoir ce que fait le compilo  , la machine cible ect.
Le C demande une très grande rigueur (beaucoup beaucoup plus que du basic) , et a partir de la si on obtient pas cette rigueur , il est difficile de faire un projet de jeu vidéo avec le C.
J'ai était étudiant aussi a la Fac beaucoup étudiant en 3 eme année (donc 3 ans de pratique en C) serait bien incapable de faire un super mario bros , donc des personne qui pratique le C de manière occasionnel n'a pas plus de chance que cela.

Le C, c'est le pas juste au-dessus de l'assembleur. C'est une sorte d'assembleur multi-plateformes en fait. Si tu ne comprends pas comment les données sont stockées en mémoire, comment on y accède, si tu n'as pas une idée de comment sera traduit ton code, et si tu ne sais pas évaluer la complexité d'un algo, tu écriras de la merde.

Anecdote : à une époque, les Java-istes démontraient que Java c'est pas si lent, c'est même parfois plus rapide que le C, la preuve, concaténons des chaînes, et là d'un côté t'avais un programme en C qui passait son temps à recopier le résultat de la précédente concaténation pour concaténer la suivante, là où le Java utilisait un StringBuffer. C'était complètement crétin comme comparaison (suffisait d'allouer un Buffer assez grand en C) mais c'était le genre d'âneries qu'un mauvais codeur C pouvait faire.

Cela étant, ce genre de connaissances est utile dans n'importe quel langage, et j'ai envie de dire que c'est plus difficile dans un langage de haut-niveau parce que tu ne sais pas bien comment il est implémenté (genre les listes dans Python, c'est assez obscur pour moi).

L'autre point , c'est que tu veux qu'une librairie se transforme en moteur de jeu , une librairie n'a pas pour but de devenir un moteur de jeu loin de la (en plus une librairie offrira toujours un optimisation bcp plus grande qu'un moteur de jeu) et dans notre cas cela reste primordial.

Pour un utilisateur avancé, oui. Pour un débutant en C non. Et quoi que tu dises, des projets avancés en SGDK, y'en a pas beaucoup qui ont été au bout. Et tous les utilisateurs de SGDK te diront que les premiers pas sont délicats (peu de tutos, pas forcément à jour).

Heureusement, il y a Stef   . Mais le jour où Stef en aura marre, ça va être difficile...

Perso j'ai toujours le github de SGDK ouvert à la page des include pour lire la doc, voire vérifier l'implémentation. Le débutant n'a pas envie de faire ça...

[Tryphon]

C'est bien pour cela que j'ai toujours eu du mal avec le C / Pascal en Fac ...

Je suis un vrai codeur du Dimanche ! Je me suis jamais considéré comme un "développeur" mais plus comme un créateur de jeu.

C'est exactement pour les gens comme toi que je pense qu'un GameMaker-like vaudrait le coup. En plus toi, tu serais capable de tuner le code et de lui faire faire des choses pas prévues. Le LocoMalito de la MD (mine de rien, Maldita Castilla est une vraie bombe).

Néanmoins, je serai un peu plus optimiste quant à la possibilité de réaliser un véritable jeu avec la SGDK de Stef.

Je n'ai aucun doute que tu y arriveras
En plus, t'as Stef sous la main ! Ça promet de belles conversations ici ! Je rêve de discuter dev en Français, j'en ai marre de poser des questions plus ou moins pointues dans un anglais approximatif et de comprendre à 80% seulement la réponse !

Si j'y suis arrivé avec Bex ( qui est LOIN d'être simple, détromper vous avec la soi disante accessibilité de ce DevKit ), je pense y arriver avec SGDK.
Bfg m'a gratifié de nombreux conseils sur le C / Sgdk et j'ai aussi quelques ouvrages de Mr Delannoy traitant sur le C.

Si je puis donner un conseil, c'est : étudie les structures de données (tableaux, listes chaînées, structures, arbres, ...), c'est incroyablement utile (j'ai vu ça en Prépa y'a 20 ans, dans le - à l'époque - tout nouveau cous d'Algorithmique en Caml, c'est dingue comme ce truc a changé ma façon de voir la programmation)

Aprés je peux me tromper et me planter misérablement.
Mais avant de mettre un point final, je vais essayer d'y mettre mon ";" !

N'oublie pas les {} !

[Invité]

Le projet dont je parle n'est qu'un frontend à un développement en C. Le code généré par le bousin serait du C. GameMaker lui-même utilise son propre langage il me semble, mais d'autres projets du même genre génèrent du code dans un autre langage, qui peut parfois être compilé.

Game maker intreprete le code , même le moteur Unity interprète le code.
De nos jours il n'est plus forcément utile de compiler le code.

Pour un utilisateur avancé, oui. Pour un débutant en C non. Et quoi que tu dises, des projets avancés en SGDK, y'en a pas beaucoup qui ont été au bout. Et tous les utilisateurs de SGDK te diront que les premiers pas sont délicats (peu de tutos, pas forcément à jour).

Heureusement, il y a Stef  Very Happy . Mais le jour où Stef en aura marre, ça va être difficile...

Perso j'ai toujours le github de SGDK ouvert à la page des include pour lire la doc, voire vérifier l'implémentation. Le débutant n'a pas envie de faire ça...

J'ai envie de dire , si on est un grand débutant vouloir faire un jeu sur MD est une mauvaise idée

MD (au passage 64Ko de RAM la MD, + 64 Ko de VRAM, merci pour elle Mr. Green ),

Oui , enfin la VRAM je le compte pas de toute façon toute les consoles de cette génération possède une VRAM de 64ko

Si je puis donner un conseil, c'est : étudie les structures de données (tableaux, listes chaînées, structures, arbres, ...), c'est incroyablement utile (j'ai vu ça en Prépa y'a 20 ans, dans le - à l'époque - tout nouveau cous d'Algorithmique en Caml, c'est dingue comme ce truc a changé ma façon de voir la programmation)

les liste chaînées utile vraiment ?
J'ai codé beaucoup de chose (des jeux , des moteurs 3D en C ect ) et les liste chaîné ne m'ont jamais était utile.

Apres pour le C , si Vetea ou d'autre veulent des conseils ou amélioration de leur code en C, je peux toujours aidé si bien entendu on veut écouter mes conseils x)

[Stef]

Wahoo ça a beaucoup parlé C et SGDK ici ^^

Pour moi qui suis habitué à programmer en C ou Java, je dois admettre que la syntaxe du basic (et particulièrement BEX) je la trouve assez indigeste. Et au final j'ai beaucoup plus de mal à réaliser ce que je veux en BEX qu'avec du C classique (voir mon wrapper du driver XGM en BEX...).

Ce qui est bien avec BEX, c'est que tout est intégré comme le dit Tryphon et ça les utilisateurs aiment beaucoup :)  Et réellement j'ai toujours souhaité faire un package "tout-en-un" qui inclus l'IDE (Code::Blocks) préconfiguré avec SGDK et des outils intégrés pour faire les graphismes et même lancer en debug avec un émulateur (avec du vrai débogage pas à pas). Hélas par manque de temps et aussi par manque d'outils adaptés (aucun émulateur supportant GDB ne fonctionnent correctement de ce que j'ai pu tester).

Cela dit si SGDK avait au moins un vrai tutoriel pas à pas bien fichu et à jour, je suis sur qu'ils auraient beaucoup plus d'utilisateurs car au final je dirais même qu'il est encore plus haut niveau que BEX (en terme de fonctions offertes par la librairie).
Pour l'instant les meilleurs tutoriaux ce sont encore les samples inclus avec SGDK :-/
Il y a l'exemple "sprite" tout simple que je devrais développer mais qui permet déjà de montrer un minimum comment manipuler les différentes capacités de la machine (manette, plan, sprite et sons) avec SGDK. Et je pense que pour faire l'équivalent en BEX tu dois faire bien plus de code que ça :
https://github.com/Stephane-D/SGDK/blob/master/sample/sprite/src/main.c

Ensuite effectivement c'est du C, il faut connaitre ce langage, c'est indéniable... Mais l'apprentissage de ce langage "universel" ne sera jamais une perte

les liste chaînées utile vraiment ?
J'ai codé beaucoup de chose (des jeux , des moteurs 3D en C ect ) et les liste chaîné ne m'ont jamais était utile

Sisi définitivement toutes les structures ont "leur application", pour les listes chainées, c'est très utile quand tu dois faire beaucoup d'insertions / suppressions dans la liste. Là où un tableau te demande de recopier une partie de la liste, une liste chainée va juste te demander de mettre à jour 1 lien ou 2. D'un côté tu as une complexité en O(n) et de l'autre en O(1). Bien évidemment si tu ne fais que de la lecture / écriture indexée alors une liste sous forme d'un tableau est bien plus pertinente et performante Tout dépend de ce que tu vas faire avec cette liste...

[ichigobankai]

[...]je dois admettre que la syntaxe du basic (et particulièrement BEX) je la trouve assez indigeste.

Cool y'a pas que moi 

[Invité]

Ce qui fait la popularité d'un devkit, ce sont les jeux qui ont été réalisé et édité avec.
Depuis Bomb on basic city et Papi Commando, pas mal de nouveaux ont débarqué sur Bex et Second Basic. Il faut donc des projets sérieux porteurs.
J'ai l'intention de porter Papi Tennis avec Sgdk avec certainement publication a la clé.
Grâce à Stef et sa grande gentillesse et accessibilité, j'espere mener le projet à bien e' plus du fait que le C pourrait m'etre utile personnellement et professionnellement.
Je me prend pas la tête et vais y aller tranquille.
Après c'est qu'un outil de plus ...

[philip]

Ça m'étonne .... Bon OK merci.
Quid de cette solution pour créer et publier des jeux MD ???
Bex serait il la seule solution viable ?? ( Ah je ris 
.. )
Bon parce que j'aimerais m'y mettre a la SGDK donc bon, on verra bienGGG

SGDK est une très, très bonne solution (j'en suis encore à la v1.01 avec Code::Blocks 10.05). Je dev un scrolling shooter (et une version de fission), pour Antarex ils utilisent xgm donc j'ai compris qu'ils utilisent sgdk, la Team 88 également :
https://www.gamopat-forum.com/t87848-team-88-alien-hates-japan-megadrive
BFG aussi :


Stef est très sympa et toujours disponible, j'en suis à 2048Ko pour mon scrolling shooter avec une multitude de variables, 13 listes chainées, 24 pointeurs pour les animations, plein de tableaux, un peu de dma pour le score, et le pompom : je ne pige rien à l'assembleur, je programme à l'ancienne comme avec un basic (mon parcours PC: darkbasic puis purebasic, le truc nouveau pour moi c'était le pointeur). Aucun bug sur le matériel réel, soit la vrai console... bref, c'est du solide.

Le plus long tu le sais, c'est le travail artistique, comme un tableau ou une sculpture, cela peut prendre des années... surtout si on est perfectionniste (ou très lent, ou pas très doué, ou les deux à la fois, hum).

Quand à se faire publier, là, c'est toi qui va nous apprendre comment faire.

[Invité]

Merciiiii Philip pour ton témoignage !!!
Ma question a fait avancer le schmilblick !

[F.L]

Pour Bex , pour le moment j'ai vu aucun jeu très technique dessus (je parle de technicité , on exploitant le matériel).

quoi ? comment ? que lis-je ?
et mon barbarian, il est pas technique ??
regarde celui-ci, 100% en basic, pas une ligne d'assembleur, meme pas pour la musique ou les graphismes
meme pas une fonction. que du if,then et goto. du vrai basic sequentiel bien de chez nous :
(sur la video il s'agissait de la version work in progress, la version finie est mieux finie et plus rapide quand meme )

[Invité]

Ahah !!
En fait je pense qu'il voulait parler de scrolling parallaxe, effet de zoom, rotation, etc ...
Chose que l'on peut faire avec Bex bien entendu moyennant des routines en asm bien sur. 
Après les if then goto , c'est la genèse !! La base ... Le Basic quoi.

[uran]

Le C, c'est le pas juste au-dessus de l'assembleur. C'est une sorte d'assembleur multi-plateformes en fait. Si tu ne comprends pas comment les données sont stockées en mémoire, comment on y accède, si tu n'as pas une idée de comment sera traduit ton code, et si tu ne sais pas évaluer la complexité d'un algo, tu écriras de la merde.

Mwai c'est peut être juste au dessus de l'assembleur mais ça reste ce que l'on appele un langage de haut niveau où l'on peut très souvent faire une belle abstraction du matériel en utilisant des librairies et autres drivers adaptés, appelez ça comme vous le voulez.

Et la prise en main d'un langage comme le C est quand même pas mais alors vraiment pas compliqué pour peu que l'on ait les bonnes explications / exemples. Ce n'est pas pour rien que c'est un des langages compilés les plus répandus dans l'industrie.

[Invité]

Arrête de flooder uran ... Merci !
Merci pour ce message mon ami, conclusion brillante de notre conversation de tout a l'heure au travail.

[Invité]

En fait je pense qu'il voulait parler de scrolling parallaxe, effet de zoom, rotation, etc ...

Oui je parle plus de cela.

Et la prise en main d'un langage comme le C est quand même pas mais alors vraiment pas compliqué pour peu que l'on ait les bonnes explications / exemples. Ce n'est pas pour rien que c'est un des langages compilés les plus répandus dans l'industrie.

Non le C est pas choisi pour sa simplicité , la preuve dans le jeux vidéo il a était complètement oublier au profit du C++ (qui est beaucoup plus complexe que le C maintenant).
L'avantage du C , c'est que c'est un langage compilé performant et le compilateur est facile a faire (donc dans l'embarqué il est apprécié).
D'ailleurs hors de l'embarqué le C n'est pas utilisé en préfère des langages plus haut niveau comme le java , C# entre autre

[uran]

Le C++ est complexe certes mais le C... pfiou c'est quand même super friendly comme langage et super abordable, le java tend à être aussi oublié au profit du perl ou python, il n'existe que pour du "web" ou autres systèmes archaiques "qu'il faut maintenir" plus par fainéantise de passer sur des langages plus souples et modernes qu'autres choses. Après chacun voit midi à sa porte.

Pour l'amateur du dimanche, le meilleur langage c'est celui dans lequel il est à l'aise et avec lequel il arrive à réaliser ses idées, même si "ce n'est pas comme çà qu'on fait dans la vraie vie!".

C'est bien stérile comme discussion tout ça :|

[uran]

Arrête de flooder uran ... Merci !
Merci pour ce message mon ami, conclusion brillante de notre conversation de tout a l'heure au travail.

Oui tu as raison allons plutôt ici continuer cette conversation sans fin :)