Re: Megadrive et Super Nintendo : parlons technique !

par Invité Dim 21 Oct 2018 - 16:37

ah ok, il me semblait qu'on mettait un jack entre la sortie casque et le MCD à l'arrière. La MD est en stéréo en étant relié au PCB?

par Invité Dim 21 Oct 2018 - 16:52

Hein ? Dans le mode d'emploi du MCD2, SEGA indique de relier la prise jack au MCD puis d'utiliser la sortie rca à brancher sur une chaine hifi ou la télé.

par Invité Dim 21 Oct 2018 - 16:53

En effet oui, t'as raison.

Megadrive et Super Nintendo : parlons technique ! - Page 7 Captur12

par Invité Dim 21 Oct 2018 - 16:56

Hein ? Dans le mode d'emploi du MCD2, SEGA indique de relier la prise jack au MCD puis d'utiliser la sortie rca à brancher sur une chaine hifi ou la télé.

C'est vieux mes souvenirs me font défauts, à mon avis c'est seulement mon MCD qui était en stéréo alors, et le son de ma MD devait sortir sur la TV.

par Invité Dim 21 Oct 2018 - 17:07

ichigobankai a écrit:par contre n'attaque pas l'ASM sur un truc tres gros/chiant (comme la collision)

J'ai presque envie de dire que c'est sûrement le truc le plus important à faire en asm Mr. Green

par Invité Dim 21 Oct 2018 - 18:20

Touko a écrit:@shingo:
C'est codé en 100% C :

Eh bien... eh bien... il y a donc de quoi faire de beaux projets non?

par Invité Dim 21 Oct 2018 - 19:32

Oui, mais le mec code en C depuis 10 ans, donc il sait comment bien gérer son truc .

par Invité Dim 21 Oct 2018 - 22:04

D'accord, faudra attendre encore quelques années pour que puisse développer sur PC ENGINE MDR

Tout de même, le fait de ne pas pouvoir coder aussi facilement en C sur Super Nintendo que sur Mega Drive est franchement un frein de nos jours, pas étonnant que la scène homebrew soit plus active sur la console de SEGA et à juste de titre !

Petite question, s'il est assez facile de développer sur Mega Drive en C, en est-il tout autant pour des machines comme le X68000 de chez Sharp ?

par Invité Dim 21 Oct 2018 - 22:14

shingosama a écrit:Petite question, s'il est assez facile de développer sur Mega Drive en C, en est-il tout autant pour des machines comme le X68000 de chez Sharp ?

Ben tout dépend de ce que tu appelle facile , niveau compilateur C oui après le hardware est moins connu que la MD donc pour afficher un simple hello world , c'est pas gagné Mr. Green

Donc ne t'attend pas a avoir un SDK dessus , voir même la lib stantard ,faudra sûrement manger un peu de bas niveau pour afficher un truc et récupérer quelque entrée clavier/joypad !

par Invité Lun 22 Oct 2018 - 9:42

Ah quel dommage, j'aurais adoré développer sur ce genre de bécane. Il n'y a vraiment personne qui a du temps à perdre pour nous pondre un SDK ?!

par **Tryphon** Lun 22 Oct 2018 - 10:02

Si bien sûr, j'ai justement rien à faire les 1O prochaines années...

Tu sais combien de temps Stef a passé sur SGDK ?

Sinon, la doc sur le X68K elle est certainement bien fournie et disponible ! Le SDK existe certainement déjà. N'hésite pas à y jeter un œil Wink

Ah, un détail : il est en japonais...

par Invité Lun 22 Oct 2018 - 10:06

J'avais mis sur mon wiki perso quelque doc et code exemple (en asm) pour coder sur le Taito F3 et le CPSII , je dis cela parce que j'avais entendu (ou plutôt lu) que le X68000 niveau hard est proche du CPSII , enfin c'est ce qu'on dit...

Je viens de vérifier et les deux machine ont une memory map assez différente :
celui du CPSII :

Code:: 000000-07FFFF : Program ROM socket #3 080000-0FFFFF : Program ROM socket #4 100000-17FFFF : Program ROM socket #5 180000-1FFFFF : Program ROM socket #6 200000-27FFFF : Program ROM socket #7 280000-2FFFFF : Program ROM socket #8 300000-37FFFF : Program ROM socket #9 380000-3FFFFF : Program ROM socket #10 400000-4FFFFF : Sprite generator registers 500000-5FFFFF : Unused (no /DTACK, system hangs if accessed) 600000-61FFFF : Z80 /BUSREQ area 620000-63FFFF : Expansion area #1 /CS 640000-65FFFF : Unused (no /DTACK, system hangs if accessed) 660000-67FFFF : Expansion area #2 /CS 680000-6FFFFF : Unused (no /DTACK, system hangs if accessed) 700000-701FFF : Sprite RAM bank #1 (8K) 702000-707FFF : Sprite RAM bank #1 (mirrored locations) 708000-709FFF : Sprite RAM bank #2 (8K) 70A000-70FFFF : Sprite RAM bank #2 (mirrored locations) 710000-7FFFFF : Unused (no /DTACK, system hangs if accessed) 800000-87FFFF : I/O area 880000-8FFFFF : Unused (writes are ignored, reads return $FFFF) 900000-93FFFF : System RAM (256K) 940000-EFFFFF : Unused (writes are ignored, reads return $FFFF) FF0000-FFFFFF : System RAM (upper 64K of 256K)

Et celui du X68000:

Code:: 0x000000 - 0xbfffff RAM (Max 12MB), vector table from ROM at 0xff0000 maps to 0x000000 at reset only 0xc00000 - 0xdfffff Graphic VRAM 0xe00000 - 0xe1ffff Text VRAM Plane 1 0xe20000 - 0xe3ffff Text VRAM Plane 2 0xe40000 - 0xe5ffff Text VRAM Plane 3 0xe60000 - 0xe7ffff Text VRAM Plane 4 0xe80000 CRTC 0xe82000 Video Controller 0xe84000 DMA Controller 0xe86000 Supervisor Area set 0xe88000 MFP 0xe8a000 RTC 0xe8c000 Printer 0xe8e000 System Port (?) 0xe90000 FM Sound source 0xe92000 ADPCM 0xe94000 FDC 0xe96000 HDC 0xe96021 SCSI (internal model) 0xe98000 SCC 0xe9a000 Serial I/O (PPI) 0xe9c000 I/O controller [Expansions] 0xe9c000 / 0xe9e000 FPU (Optional, X68000 only) 0xea0000 SCSI 0xeaf900 FAX 0xeafa00 / 0xeafa10 MIDI (1st/2nd) 0xeafb00 Serial 0xeafc00/10/20/30 EIA232E 0xeafd00 EIA232E 0xeafe00 GPIB (?) 0xec0000 - 0xecffff User I/O Expansion 0xeb0000 - 0xeb7fff Sprite registers 0xeb8000 - 0xebffff Sprite VRAM 0xed0000 - 0xed3fff SRAM 0xf00000 - 0xfb0000 ROM (CGROM.DAT) 0xfe0000 - 0xffffff ROM (IPLROM.DAT)

source MAME Very Happy

Et ces memory map sont suffisante pour comprendre le hard, faut juste lire le code source pour savoir comment ça fonctionne en détails !
(meme si certaine I/O ne sont pas documenté et non émulé...)

J'avais abandonner l'idée pour ces bornes d'arcade parce que impossible de test sur du vrai Hard , malheureusement sur ces deux machines on lisant le code source de MAME , elle sont assez mal émulé et spécifique a certain jeux...
Pareil pour le Sharp X68000 , je risque pas de dépenser 600Euros dessus pour faire un SDK minimaliste MDR

par **Tryphon** Lun 22 Oct 2018 - 10:21

6OO€... si t'as du bol Megadrive et Super Nintendo : parlons technique ! - Page 7 435303

par Invité Lun 22 Oct 2018 - 10:33

Tryphon a écrit:6OO€... si t'as du bol

Je connais pas les prix en vigueur, mais c'est assez rare le seul que j'ai trouvé : https://www.ebay.fr/i/192682514714?chn=ps&dispItem=1
et acheter un lecteur disquette et des disquettes aussi !
Et puis faudra ouvrir un Patreon pour taffer h24 aussi pour 2-3 péquenaud dessus Mr. Green

(excuse-moi shingo mais ça reste assez spécifique comme plateforme) !

par **Tryphon** Lun 22 Oct 2018 - 10:53

À chaque fois que j'ai regardé il me semble que c'était le double. Après, y'a plusieurs modèles, je sais pas quel est celui-là...

par Invité Lun 22 Oct 2018 - 11:07

Je ne sais pas du tout le temps qu'a mit @Stef pour concevoir SGDK, en tout cas j'espère qu'il va continuer de bosser dessus !

par **TotOOntHeMooN** Lun 22 Oct 2018 - 11:55

shingosama a écrit:Ah quel dommage, j'aurais adoré développer sur ce genre de bécane. Il n'y a vraiment personne qui a du temps à perdre pour nous pondre un SDK ?!

C'est le genre de bécane qui demande d'avoir un certain niveau pour en tirer proprement partie. Donc, ça serait certainement perdre son temps de faire cela...
Les gens qui veulent vraiment l'exploiter le font par eux-même. Tu es vernis d'avoir un SDK pour la MD. Il y a de la marge entre tes essais et un Thunder Force.

par ichigobankai Lun 22 Oct 2018 - 12:07

TotOOntHeMooN a écrit:Tu es vernis d'avoir un SDK pour la MD.

Et surtout de la CHANCE que ce soit Stef qui soit derrière.
Quelqu'un de pro, réactif, courtois et dans ta langue natale !

par **TotOOntHeMooN** Lun 22 Oct 2018 - 13:18

ichigobankai a écrit:Et surtout de la CHANCE que ce soit Stef qui soit derrière.
Quelqu'un de pro, réactif, courtois et dans ta langue natale !

Clair. Un vrai coach à domicile ! Cool

par Invité Lun 22 Oct 2018 - 13:52

Tout a fait d'accord, c'est une perle, faut pas le lâcher. Wink

Et il continuera tant qu'il y aura des projets sous Sgdk. Le top sera une réelle édition d'un jeu avec son SDK, et un jeu plutôt bon et réussi bien sur. Very Happy

par Invité Lun 22 Oct 2018 - 15:48

Personne n'a réellement édité un jeu avec SGDK ?

par Stef Mar 23 Oct 2018 - 20:00

shingosama a écrit:Je ne sais pas du tout le temps qu'a mit @Stef pour concevoir SGDK, en tout cas j'espère qu'il va continuer de bosser dessus !

J'ai du commencer à m'interesser au coe sur MD en 2003, mais je crois que la première version officielle de SGDK (GenesisDev à l'époque) date de 2006... Après bon je fais ça sur mon temps libre et ces dernières années ça se résume à une poignée de jours par an mis bout à bout :-/

ichigobankai a écrit:
TotOOntHeMooN a écrit:Tu es vernis d'avoir un SDK pour la MD.
Et surtout de la CHANCE que ce soit Stef qui soit derrière.
Quelqu'un de pro, réactif, courtois et dans ta langue natale !

C'est gentil tout vos messages amoureux

mais je dois admettre qu'à la base je développais SGDK surtout pour moi Embarassed

car il n'y avait rien de potable pour coder sur MD ^^ Puis bon après le projet devenant plus gros et surtout voyant qu'il pouvait servir à d'autre alors j'ai continué à le développer. Mais réellement pour mettre un gros coup de boost à SGDK, il faut que moins même je développe un jeu complet complet avec (ce que je n'ai jamais fait sauf pour un mini jeu très limité). Ainsi je serai "contraint" d'ajouter / compléter mes outils et autres fonctions manquantes (gestion des MAP en autres, meilleur outil pour la gestion de sprites et animation etc...).

shingosama a écrit:Personne n'a réellement édité un jeu avec SGDK ?

Hmm pour être honnête il me semble pas, enfin si y'a quelques bootleg russes ou chinois qui l'utilisent (genre le angry birds ^^) mais bon MDR

Après il y a pas mal de jeux en développement, presque finis mais effectivement à ma connaissance pas encore de jeux réellement édités..

par Invité Mar 23 Oct 2018 - 20:07

On va tout faire pour, et te payer des vacances prolongées en Asie ... Wink

par Stef Mar 23 Oct 2018 - 20:11

StudioVetea a écrit:On va tout faire pour, et te payer des vacances prolongées en Asie ...

Pour mes vacances en Asie, je peux te dire que ça doit être de loin les vacances qui m'ont couté le plus cher (bon de bonnes raisons heureusement) MDR

par Invité Mar 23 Oct 2018 - 23:45

Après tant qu'on peut créer des jeux avec la version actuelle, c'est l'essentielle !

J'ai pu faire tous ce que je voulais techniquement et je pense pouvoir arriver au bout du développement, en tout cas je ne vois pas rien qui pourrait m'empêcher au niveau de la programmation à moins de vouloir intégrer pleins d'effets de fou furieux.

Je ne sais pas si c'est "normal", mais avec 30 bullets avec 10 ennemies, le joueur et ses deux modules, j'ai eu des ralentissements. Est-ce les limites de la Mega Drive avec SGDK ? Je trouve que c'est quand même pas mal, car il y a déjà pas mal d'éléments en mouvement à l'écran avec plusieurs collisions à gérer.

par Hpman Mer 24 Oct 2018 - 0:27

Faut mettre un job meter, pour voir ce qui rame. rambo

par Stef Mer 24 Oct 2018 - 20:35

30 bullets et 10 ennemis, ça fait déjà 300 collisions (si tu fais la méthode brute) par frame, et oui c'est pas mal surtout pour du C. Après il y a toujours moyen d'optimiser ça (tu peux vraiment avoir jusqu'à 30 bullets à l'écran ??).

par Invité Mer 24 Oct 2018 - 22:10

Le maximum que j'avais défini c'était 30 bullets, mais dans les faits la scène affiche 15 bullets après vérification. J'ai un peu triché pour éviter de trop consommer en accélérant un peu les bullets.

par Invité Mer 24 Oct 2018 - 22:13

C'est aussi une technique. Wink

par **Tryphon** Mer 24 Oct 2018 - 23:21

Stef a écrit:30 bullets et 10 ennemis, ça fait déjà 300 collisions (si tu fais la méthode brute) par frame, et oui c'est pas mal surtout pour du C. Après il y a toujours moyen d'optimiser ça (tu peux vraiment avoir jusqu'à 30 bullets à l'écran ??).

Les 30 bullets, c'est pas forcément toutes des bullets du joueur Very Happy

Mais oui, ça fait pas mal. On doit pouvoir gérer ça, même en C, mais il faut utiliser des structures plus rigolotes.

par Stef Jeu 25 Oct 2018 - 17:44

Vu comment il le présentait je pensais qu'il parlait vraiment des bullets du player (et vu sa réponse c'était visiblement ce qu'il avait prévu). Effectivement accélérer les bullets c'est une astuce pour limiter leur nombre à l'écran... perso moi je n'aime pas trop les shump avec des boulettes trop rapides, ça fait trop "rigide". C'est d'ailleurs un défaut qu'on retrouve d'dans beaucoup de shump SNES (comme SA ou R²) :p