SDK ultime

[uran]

Salut les barbus et les imberbes!

Vu le florilège de SDK spécifiquement orientés vers nos consoles fétiches qui sortent et/ou sont mis à jour plus ou moins régulièrement ET l'outil que Orion est entrain de développer.

Je me suis demandé pourquoi n'existerait-il pas un projet commun de SDK multiplateforme? Intégrant les bas niveau de chaque hardware, et une librairie haut niveau (pour de vrai) qui elle s'affranchit totalement du matériel (comme du vrai haut niveau). Cela permettrait le multi-plateforme/portage plus aisé.

Vous savez! Un SDK pour les gouverner tous, un SDK pour les trouver.
Un SDK pour les amener tous et dans les ténèbres les lier.

La tache est certes ardue! J'en ai bien conscience. Mais cela amènerait les curieux à s'essayer et pourquoi pas  à sortir des jeux extraordinaires.
J'utilise des utilitaires qui s'approchent de genre de chose sur de l'embarqué STM au boulot. L'idée est de garder le genre concept et l'adapter à la création de jeux vidéos.

[Invité]

Je remercie, la Ciel, la Terre et le Soleil pour la création de ce topic.
Merci Uran.

[Hpman]

Mouais, sur le papier c'est cool mais en pratique tu vas finir avec un pseudo game maker ayant comme limites le plus petit dénominateur commun des machines supportées.

C'est pas des machines (j'imagine qu'on parle des 16 principalement ici) qui permettent de s'affranchir des specs hardware. Tu as besoin de contrôler ce qui se passe au niveau hardware.
Rien que poser un HUD à l'écran, ça n'aura rien à voir sur MD, SNES ou NeoGeo. Ça me parait improbable de concilier les specs de chaque machine dans un haut niveau d'abstraction.

Je pense que le fait d'écrire les jeux en C permet un niveau de portabilité suffisant pour qui veut bien se donner la peine un minimum.

[uran]

Attention, je ne parle pas de sortir des jeux qui mettent le hard sur le genoux non plus.


L'idée serait d'avoir au moins! un générateur de projet où on a juste le code du jeu à caler avant de compiler!

Et, c'est dommage de se limiter aux consoles 16 bits je trouve, j'aimerais bien; par exemple; compiler un jeu pour Commodore64 ou Atari2600 ou encore NES (vu que je les ai).

D'ailleurs faudrait un nom genre FLquelquechose :)

[Hpman]

Ouais enfin bon, tu concilie comment les sprites entre une nes et une neogeo ?

[uran]

Ouais enfin bon, tu concilie comment les sprites entre une nes et une neogeo ?

Dans ce cas ce sont des sprites style NES qui resteraient pour la NEOGEO, faut rester un minimum logique voyons.

[Hpman]

Ouais du coup je sais pas si faire des jeux NeoGeo avec une tronche de jeu 2600 c'est vraiment ultime

[uran]

Tu dis ça parce que tu dors pas en ayant lu l'annonce de la sortie de Cosmos ce soir!

Mais tu peux pourrait avoir ton jeu NEO GEO sur dreamcast, avec le même outils

[fanoplusplus64K]

Salut les barbus et les imberbes!

Vu le florilège de SDK spécifiquement orientés vers nos consoles fétiches qui sortent et/ou sont mis à jour plus ou moins régulièrement ET l'outil que Orion est entrain de développer.

Je me suis demandé pourquoi n'existerait-il pas un projet commun de SDK multiplateforme? Intégrant les bas niveau de chaque hardware, et une librairie haut niveau (pour de vrai) qui elle s'affranchit totalement du matériel (comme du vrai haut niveau). Cela permettrait le multi-plateforme/portage plus aisé.

Vous savez! Un SDK pour les gouverner tous, un SDK pour les trouver.
Un SDK pour les amener tous et dans les ténèbres les lier.

La tache est certes ardue! J'en ai bien conscience. Mais cela amènerait les curieux à s'essayer et pourquoi pas  à sortir des jeux extraordinaires.
J'utilise des utilitaires qui s'approchent de genre de chose sur de l'embarqué STM au boulot. L'idée est de garder le genre concept et l'adapter à la création de jeux vidéos.

J'avoue m'être déjà interessé au 'problème'.J'ai déjà quelques outils qui sont multiplateformes mais j'avoue que faire le design du coeur du SDK reste le plus difficile, c'est limite si il faudrait faire un noyau propre à chaque machine sur lequel le code utilisateur vient se greffer sous forme de modules.

[uran]

Salut les barbus et les imberbes!

Vu le florilège de SDK spécifiquement orientés vers nos consoles fétiches qui sortent et/ou sont mis à jour plus ou moins régulièrement ET l'outil que Orion est entrain de développer.

Je me suis demandé pourquoi n'existerait-il pas un projet commun de SDK multiplateforme? Intégrant les bas niveau de chaque hardware, et une librairie haut niveau (pour de vrai) qui elle s'affranchit totalement du matériel (comme du vrai haut niveau). Cela permettrait le multi-plateforme/portage plus aisé.

Vous savez! Un SDK pour les gouverner tous, un SDK pour les trouver.
Un SDK pour les amener tous et dans les ténèbres les lier.

La tache est certes ardue! J'en ai bien conscience. Mais cela amènerait les curieux à s'essayer et pourquoi pas  à sortir des jeux extraordinaires.
J'utilise des utilitaires qui s'approchent de genre de chose sur de l'embarqué STM au boulot. L'idée est de garder le genre concept et l'adapter à la création de jeux vidéos.

J'avoue m'être déjà interessé au 'problème'.J'ai déjà quelques outils qui sont multiplateformes mais j'avoue que faire le design du coeur du SDK reste le plus difficile, c'est limite si il faudrait faire un noyau propre à chaque machine sur lequel le code utilisateur vient se greffer sous forme de modules.

C'est un peu l'idée que j'en ai.
Après, c'est avoir une lib de fonctions communes (plus ou moins bridée suivant la cible) genre SpriteXYZ(..) avec laquelle tout le jeu est codé. Ca évite les blagues de gestion matériel en plein milieu d'une routine du jeu.

[Stef]

Comme Hpman je trouve que c'est quand même super chaud de faire ce genre d'outil. Déjà pondre un SDK "user friendly" (avec une API facile à comprendre) pour une machine retro c'est pas évident alors en avoir un qui en plus gère plusieurs plate formes ça me semble vraiment compliqué...
L'idée est séduisante mais pas vraiment réalisable je pense.

[uran]

Pff z'êtes pas joueur les gars!

[Invité]

Bah commences à le faire. Un Hello world sur tous les 8/16 bits.
Tu as 6 mois ... 

[uran]

Bah commences à le faire. Un Hello world sur tous les 8/16 bits.
Tu as 6 mois ... 

[Invité]

Pas mieux ... 

[Metalik]

Je n'y connait rien dans ce domaine, mais je n'envisage pas autrement un SDK spécifiquement créer que pour une seule machine. Surtout sur les consoles retro avec des hardwares limité, et avec leurs spécificité bien précise.

J'aurais plus tendance à penser qu'il vaudrait mieux continuer à optimisé les SDK existant et créer tout un tas de modules compatible autour.

De toute façon, un SDK multi plate forme deviendrait inutile puisque dès le perfectionnement vers une machine en particulier, c'est comme si tu utilisait le SDK le plus connu performant déjà existant pour la dite machine.

Exemple:
Pourquoi utiliser le UrbanSDK multi plate forme pour faire un jeu Megadrive alors que tu as déjà le SDGK de Stef ?
C'est inutile, à moins de proposer mieux et plus performant !

[uran]

Attention, vous dérapez!
Certes le terme "SDK" est un poil fort pour commencer, mais l'idée est de donner un outil permettant de sortir, a minima, un moteur complet d'un jeu où il ne manquera plus qu'à mettre les gameplay/niveaux afin de s'affranchir du côté (parfois) compliqué pour pas grand chose du matériel!
Et si on peut le faire pour une machine, pourquoi pas pour d'autres!
Par exemple, ca pourrait être une surcouche à l'excellent SGDK de Stef, et au NeoDev de HPman, et au pvsneslib de Alekmaul, etc etc

[65c02]

O npeut imaginer une chaine de compilation multiplateforme en C avec des makefiles capables de passer par des tools de conversion de datas adaptés.
Si c'est en théorie possible, cela reste soumis à des limites.
Tu ne fera pas un jeu VCS 2600, intellevision ou videopac sur la meme base qu'un jeu megadrive.
De même, les vieilles plateformes imposent leur propre algo d'affichage.
Elles poussent à construire des astuces qui ne concerne qu'elles.
L'affichage d'un jeu fait pour oric ou pour zx spectrum ne sera pas compatible tel quel sur amstrad ou amiga.
Ou alors cela veut dire que tu prévois un moteur de rendu oric sur amiga et cela n'a aucun sens (autre que je peut tout porter sur tout) car tu devras faire autant de moteur que d'algo d'affichage fois le nombre de plateformes
Mais bon, l'idée de base au sens large est bonne.
Faire en sorte que les SDK soient pensé globalement pourrait permettre de mutualiser les outils et les formats de fichier.
On pourrait déjà commencer par faire un sdk capable de compiler des roms de tout et n'importe quoi; sans se préoccuper des datas).
Juste un répertoire de fichiers C et un make avec paramétre te pond la rom qui correspond.
Un truc dont tous les sources serait sur github et qui pourrait marcher sous linux (histoire de ne pas pleurer la fin du monde si windows bloque l'univers en mode S)
Déjà rien que faire une chaine de compile qui marche sur un processeur ARM sous linux ou un INTEL sous windows, ce serait un mini challenge.
Perso je suis sour raspberry pi et je suis souvent confronté à ce problème.
Si les tools de conversion ne sont pas livrés avec leur sources, je coince. Et j'ai rarement envie d'en coder un nouveau.
Rien que ça c'est du boulot.
Et je ne parle que de faire un makefile et des tools de conversion de binaire, de graph.
Après imaginer un "basic" ou gamemaker multiplateforme c'est un peu du rêve.
Plus une machine est vieille plus elle demande du skill pour chaque petit details.

[Tryphon]

Deux remarques :

1) développer un tel SDK serait un boulot autrement plus difficile qu'en développer un spécifique à une machine, et déjà peu de machines peuvent se targuer d'en avoir un de bonne facture

2) pour quel public ? Si je veux développer un jeu rapidement, pour exprimer ma créativité sans trop de contraintes, je développe sous GameMaker ou Unity pour PC

Bref, désolé mais j'y crois pas, même en rêve...

[65c02]

A la rigueur, si le but c'est de permettre à n'importe qui de prétendre avoir fait un jeu sans effort on peut faire un éditeur de megaman ou de mario qui pond des rom hack. 

[philip]

Attention, vous dérapez!
Certes le terme "SDK" est un poil fort pour commencer, mais l'idée est de donner un outil permettant de sortir, a minima, un moteur complet d'un jeu où il ne manquera plus qu'à mettre les gameplay/niveaux afin de s'affranchir du côté (parfois) compliqué pour pas grand chose du matériel!
Et si on peut le faire pour une machine, pourquoi pas pour d'autres!
Par exemple, ca pourrait être une surcouche à l'excellent SGDK de Stef, et au NeoDev de HPman, et au pvsneslib de Alekmaul, etc etc

Une surcouche de sgdk m'interesse. Pour mon projet de scrolling shooter, je rencontre des problèmes de ralentissements, et je ne suis pas le seul, la plupart rencontre ce problème.
KanedaFr :
"I can't use more than 10 sprites using 32 tiles per frame and I still have a lot of VRAM.
The only problem ? Too much code per sprite (anim, move, collide, behavior) which slow down everything"
http://gendev.spritesmind.net/forum/viewtopic.php?f=2&t=2103

Un 68010 (1981, plus puissant de 20% à la même fréquence qu'un 68000 de 78) aurait été un choix plus pertinent à l'époque (voir blog de totoonthemoon sur gamekult, up: semble plus disponible) . La plupart des jeux de la belle époque subissent des ralentissements, surtout les scrollings shooters, et en 60Hz c'est la cata. Avec un 68010 à 10 MHz, ils sont fluide.
djcouchycouch a ouvert un sujet sur ce problème, plusieurs solutions hard pour un meilleur équilibre CPU/VDP :
http://gendev.spritesmind.net/forum/viewtopic.php?t=1274&postdays=0&postorder=asc&start=0

Chilly Willy propose un SH2 (co-entreprise de sega et hitachi à l'époque), peut-être que tu peux envisager de travailler avec lui. Et plus fort encore avec ton projet de portage multi-plateformes, tu peux éventuellement envisager un portage MD/Saturn/Dreamcast avec une puce de la même famille Super H. Les Jcores sont des puces libres compatible d'après ce site :
http://0pf.org/j-core.html

[Hpman]

Si ça mouline, c'est pas une énième surcouche qu'il te faut, mais mettre les mains dans le cambouis pour adapter le code et les ressources à ton jeu.

[drludos]

L'idée est hyper intéressante, même si moi aussi je pense que le boulot pour arriver à concrétiser ce projet serait titanesque.

Une approche intéressante pourrait être celle qu'on trouve derrière la langage Haxe: tu écrit ton code dans un langage "source", qui sera ensuite "traduit" vers plusieurs langages différents selon la plateforme sur laquelle faire tourner le programme.

Dans le cas de Haxe, tu écrit ton code une fois (en langage Haxe donc, qui ressemble au JavaScript mais avec un typage fort), et il est ensuite automatiquement convertible en C/C++ (natif windows et linux), Objective-C (natif iOS), Java (natif Android), ActionScript (natif Flash) ou Javascript (natif HTML5).

Dans la pratique, même avec un moteur aussi puissant que Haxe, ils ont du faire des "concessions" pour faire un outil vraiment multiplateforme. Concrètement, afin de pouvoir prendre en compte les possibilités de chaque plateforme, tu as une API "générale", qui contient des fonctions accessibles à toutes les plateformes, et des API "spécifiques" qui regroupent toutes les fonctions qui ne marcheront que sur une plateforme donnée.

Donc, si tu code uniquement avec l'API générique, ton code est vraiment multiplateforme, sinon il ne tournera que sur les quelques plateformes choisies.

Si tu te lances dans le projet UranSDK, cette approche te permettrait peut-être de concilier "base pour toutes les consoles" et "gestion des spécificité de chaque machine".

Je serais toi, j'essaierai de fractionner le projet en étape pour ne pas me noyer dans un truc trop complexe au départ. Par exemple, je commencerai par essayer de faire une surcouche qui ne vise que les plateformes 16 bits (MD, SNES et NeoGeo), afin d'avoir pas trop trop de différence entre les machines, et surtout assez de puissance CPU pour gérer le code spécifique à ton SDK. Ou alors, encore plus "simple" pour démarrer, faire un outil commun à la GameBoy Color et à la Game Gear. Les machines sont différentes certes, mais elles ont la même résolution d'écran, un nombre de sprites (8x8 ou 8x16) assez similaire, et une puissance de calcul comparable. Certains ont même déjà commencé à créer un outil permettant de transposer un jeu GameBoy codé en C (avec GDBK) vers un jeu GameGear / MasterSystem codé en C (avec DevKitSMS) :
https://github.com/haroldo-ok/sms-gbdk-compat

Bref, quoi qu'il en soit, bon courage pour ton projet, et je suis curieux de voir son avancement !

[fanoplusplus64K]

Si ça mouline, c'est pas une énième surcouche qu'il te faut, mais mettre les mains dans le cambouis pour adapter le code et les ressources à ton jeu.

Merci de rapeller l'évidence
On touche ici à l'inconvénient de tout faire dans un language de plus haut niveau, y'a un moment pour des raisons de performances il faut descendre à plus bas niveau pour optimiser...

[Tryphon]

Moi ce que j'aimerais parfois c'est un langage intermédiaire entre l'ASM et le C.

Où tu pourrais écrire des expressions mathématiques, des blocs de données, des boucles, des vrais tests, des fonctions inline ou non. Voire des trucs plus haut niveau comme des modules, de la programmation objet...

Mais aussi où tu pourrais coder sur un registre comme sur une variable, où tu peux préciser si on doit sauvegarder les registres dans la pile ou pas, etc...

Le tout avec une syntaxe sympa genre Python.

[philip]

Si ça mouline, c'est pas une énième surcouche qu'il te faut, mais mettre les mains dans le cambouis pour adapter le code et les ressources à ton jeu.

Merci de rapeller l'évidence
On touche ici à l'inconvénient de tout faire dans un language de plus haut niveau, y'a un moment pour des raisons de performances il faut descendre à plus bas niveau pour optimiser...

Je suis admiratif de votre travail, mais le sujet ouvert ici par uran est le haut niveau. Nous avons des jeux d'action de la belle époque, codé bas niveau, qui souffrent de ralentissements (sur toutes les 16bits) qui deviennent très pénibles en 60Hz.
Sega a corrigé le problème à l'époque avec son propre CPU, le super H (pareil pour tendo avec ses propres solutions hardware pour sa snin).
Déroulage de boucle, code en assembleur, partie critique codé en Hexa, mode secret du vdp 128ko, et autres trucs et astuces bas niveau... Ce n'est pas du haut niveau, voir le tres haut niveau: je programme en C, voir en basic, un jeu (pas un mini jeu, un vrai jeu), sur MD et tout roule sur celle-ci et les générations suivantes (même chose pour les tendo). À moins que je n'ai pas compris le sujet de ce post ?

[Hpman]

Bah je sais pas, tu nous dis que tu rencontre des problèmes de ralentissement, et la que tout va bien

Puis c'est pas parce que c'est en assembleur que c'est pas codé avec les pieds cul niveau performances (cf par exemple metal slug 2).

[Invité]

Ce topic est a l'image de son instigateur, de haut niveau.

[fanoplusplus64K]

Je suis admiratif de votre travail, mais le sujet ouvert ici par uran est le haut niveau. Nous avons des jeux d'action de la belle époque, codé bas niveau, qui souffrent de ralentissements (sur toutes les 16bits) qui deviennent très pénibles en 60Hz.
Sega a corrigé le problème à l'époque avec son propre CPU, le super H (pareil pour tendo avec ses propres solutions hardware pour sa snin).
Déroulage de boucle, code en assembleur, partie critique codé en Hexa, mode secret du vdp 128ko, et autres trucs et astuces bas niveau... Ce n'est pas du haut niveau, voir le tres haut niveau: je programme en C, voir en basic, un jeu (pas un mini jeu, un vrai jeu), sur MD et tout roule sur celle-ci et les générations suivantes (même chose pour les tendo). À moins que je n'ai pas compris le sujet de ce post ?

Il est vrai qu'on s'est un peu égaré mais ça reste dans le thème.Avant de vouloir sortir l'artillerie lourde (meilleur proc, co-pro, etc...), faudrait déjà exploiter au mieux la machine.La réalité est têtue mais il y a un moment si tu recherches la performance, tu sera bien obligé de descendre à plus bas niveau, toi ou le dévellopeur du sdk.Et descendre à plus bas niveau ne signifie pas pour autant programmer en ASM, rien que certaines optimisation en C, c'est déjà le faire descendre dans le niveau d'abstraction (tsé ces trucs horribles qui rendent le code difficile à lire et a maintenir) et tout faire pour le compilo sorte du code le plus efficient possible même si ton source est déguelasse.

Moi ce que j'aimerais parfois c'est un langage intermédiaire entre l'ASM et le C.

C'est exactement la remarque que je me fais régulièrement.L'ASM est parfois pénible et le C génère énormement d'instructions pour parfois pas grand chose.
Après, difficile de formaliser un tel language, ça sort totalement des sentiers battus et je dois avouer qu'on est formatté par ce qui existe déjà.
Après dans le cadre d'un sdk qui se veut multiplateforme, peut être que le mieux est plutôt de ne laisser l'utilisateur accéder au propriétés des objets déjà définis par les devellopeurs (extensible pour quelqu'un d'expérimenté par exemple) voire la possibilité de les affecter par les 'micro-scripts' facilement optimisables par le générateur de projet.

Ce topic est a l'image de son instigateur, de haut niveau.

T'as un truc à demander à Uran toi

[Invité]

Uran je le sollicite tous les jours dans le cadre de ma profession.
Tout ce que j'ai à dire, c'est que c'est un Troll de personnage.