Re: Programmer la SEGA Megadrive en Basic

par **Urbinou** Mer 19 Fév 2020 - 11:29

Le hasard existe-t-il ? Rdv dans le topic métaphysique Razz

Si tu seed avec le tick count par exemple, tu es plus ou moins assuré d'avoir de l'aléatoire. Avec des guillemets.

Touko a écrit:
Le but d'un seed, et de limiter le nombre dans une liste il me semble .

Non, c'est un point de départ, tu le constates aisément en examinant les codes ci-dessus Wink

par Invité Mer 19 Fév 2020 - 11:31

Si tu seed avec le tick count par exemple, tu es plus ou moins assuré d'avoir de l'aléatoire. Avec des guillemets.

Même pas, du moins sur console, car si ton compteur est initialisé à un moment, tu auras toujours le même nb de ticks à un instant T .
C'est pour ça qu'en général on fait intervenir les entrées du/des pad(s) dans l'algo de random,c'est quasiment le seul événement aléatoire dans un jeu 16 bits .

par **Urbinou** Mer 19 Fév 2020 - 11:36

Oui (d'où mon plus ou moins), réflexe de PC/micro-iste Very Happy

Mais l'allumage d'une console est vraiment constant à la milliseconde ?
Tu as un exemple (et pas en asm68K Wink

) ou un résumé simple faisant intervenir le pad ?

par Invité Mer 19 Fév 2020 - 11:37

Oui, réflexe de PC/micro-iste

Sur Pc tu as un générateur fiable de nombres aléatoires il me semble ??

Tu as un exemple (et pas en asm68K ) ou un résumé simple faisant intervenir le pad ?

Non ,mais je vais expliquer comment ça marche .
En général tu as un nombre 8 ou 16 bits ou plus que tu modifies dans ta routine random .
et bien le but est de modifier ce nombre le plus souvent possible, et le plus aléatoirement possible .
Et bien tu fais ça dans ta routine qui gère les actions du joueur,et comme en général le joueur ne joue jamais pareil à la frame près, cela suffit à être assez aléatoire et ne pas de donner toujours la même suite de nombre à chaque partie .

par ichigobankai Mer 19 Fév 2020 - 11:38

Tu rajoutes une LUT en ROM et tu sauvegardes son index en SRAM.
Sa valeur te servira comme seed de départ de ton pseudo aléatoire.

par **Urbinou** Mer 19 Fév 2020 - 11:40

L'algo dépend du langage non ? Mes maigres besoins dans ce domaine se sont toujours satisfaits d'un Randomize(TicksCount()).

par Invité Mer 19 Fév 2020 - 11:44

Normalement non,mais plutôt de comment a été implémenté l'algo .

par **drfloyd** Ven 21 Fév 2020 - 19:59

Touko a écrit:
Urbinou a écrit:Non, avec une seed identique, tu dois obtenir la même suite de nombres "aléatoires". Dans son monde procédural, c'est essentiel, sinon d'une partie à l'autre l'univers ne serait plus le même : )
Mouai, bah je me demande du coup où est l'aléatoire là dedans ??
Le but d'un seed, et de limiter le nombre dans une liste il me semble .

Edit: Non autant pour moi, vous avez raison

Le RANDOMIZE Seed de Second Basic st bien buggé, ca empêche de générer des jeux procéduraux facilement. Je laisse tomber mes tests (même si comme l'explique le Prof on peut créer son propre Randomize seed)

par **Tryphon** Ven 21 Fév 2020 - 20:01

À mon avis, si tu t'arrêtes à cause de ça, c'est que tu fais bien (parce que tu vas rencontrer bien pire comme problème) Wink

Tu veux que je t'aide à le coder en C ?

par **drfloyd** Ven 21 Fév 2020 - 20:02

Tryphon a écrit:
drfloyd a écrit:faut que je vois si la structure du jeu puisse tenir dans les 64ko de RAM en dev un proto (les 64ko de RAM VIDEO devraient suffire)

Deux choses :

1) la structure du jeu, c'est quoi ? Le code ? Les données ? Si c'est le code, tu le mets en ROM, pas en RAM. Idem pour les données si elles ne doivent pas être modifiées. T'es pas sur ordi, t'es sur console

2) La RAM VIDEO ne sert pas à stocker la structure du jeu (quoi que ça puisse concerner). Tu n'y as de toutes façons pas accès de façon simple.

QUESTION :
On est d'accord que ce langage gère bien les sauvegardes sur la pile de la cartouche ? On peut stocker combien d'informations ?

Aucune idée.

Oui oui je mets tout en ROM, mais malgré tout j'avais besoin de pas mal de RAM car beaucoup de variables.

ok pour le point 2 sinon

par **drfloyd** Ven 21 Fév 2020 - 20:03

Tryphon a écrit:À mon avis, si tu t'arrêtes à cause de ça, c'est que tu fais bien (parce que tu vas rencontrer bien pire comme problème)

Tu veux que je t'aide à le coder en C ?

je ne penses pas que j'aurai rencontré d'autres problemes, j'avais fait un test global (un petit prgorgamme qui reprend tout ce dont j'ai besoin)

Pour ta proposition, j'y réfléchis Mr. Green

(car là j'ai repris à fond COSMOS 2 et je m'éclate)

par **drfloyd** Ven 21 Fév 2020 - 20:07

Urbinou a écrit:
Tryphon a écrit:Maintenant on utilise un algo plus robuste appelé le Mersenne Twister, mais c'est mathématiquement plus coton.

Qu'entends-tu par robuste ? Cet algo "simple" produit bien du pseudo aléatoire, que gagne-t-on à le complexifier ?

Il faut un algo très robuste !

Je me suis rendu compte avec Cosmos qui simule quand meme des maps pouvant faire 1 000 000 x 1 000 000 de cases (pour représenter une galaxie) que le hasard n'est pas si hasardeux que ça ! Si tu ne gères pas ça de manière subtile tu tombes sur des récurrences (des bouts de galaxies qui se ressemblent par exemple)... ca se voit bien lorsque du fais une représentation visuelle à l'ecran.

Ca dépend beaucoup de l'algo qui gère le random.... celui de Purebasic est pas trop mal.

par **drfloyd** Ven 21 Fév 2020 - 21:19

allez, je tente le C... CODEBLOCKS ca existe toujours ???? Mr. Green

Je me donne 48h pour m'auto convaincre que le C C bien

par **Tryphon** Ven 21 Fév 2020 - 21:25

Perso j'utilise notepad++ et la ligne de commande

par Monos Sam 22 Fév 2020 - 4:15

Comme moi Tryphon.
Un bon notpad++ et un fichier .bat avec les commandes de compilation. J'ai testé d'autre éditeur de texte, souvent des usignes à gaze, souvent faut passer plus de temps à le paramétrer que de coder...

je me donne 48h pour m'auto convaincre que le C C bien

Trop court. Si tu veux directe porter ton jeu en C, tu as des chances de te casser la gueule...

Faut partir sur des trucs simples.

par **F.L** Sam 22 Fév 2020 - 8:45

Monos a écrit:Comme moi Tryphon.
Un bon notpad++ et un fichier .bat avec les commandes de compilation. J'ai testé d'autre éditeur de texte, souvent des usignes à gaze, souvent faut passer plus de temps à le paramétrer que de coder...

je me donne 48h pour m'auto convaincre que le C C bien

Trop court. Si tu veux directe porter ton jeu en C, tu as des chances de te casser la gueule...

Faut partir sur des trucs simples.

+1
en 48h, faire bouger un sprite a l'ecran sur un background ca sera deja pas mal ! Cool

par **drfloyd** Sam 22 Fév 2020 - 9:33

Bah je connais un peu, je ne part pas de z&ro, j'ai déjç tenté le C dans le passé... plusieurs fois...

et j'ai rééessayé hier soir... de 22h à 0h j'ai commencé un proto de COSMOS en C... et mes vieux démons sont revenus : putain d'accolades, putain de point virgule, putain de &&, putain de barres verticales.....et les fameux pointeurs de l'horreur Mr. Green

(le pire de tout) Après 200 lignes de codes j'ai eu envie de balancer le PC sur le mur... j'ai pas les bons reflexes, il faudrait que je force durant 15 jours peut etre... reste le manque de temps.... mais franchement je prends pas de plaisir.... aucun.

par **Tryphon** Sam 22 Fév 2020 - 10:12

Perso ça va mieux. Mais je dirais jamais que coder en C est agréable Razz

Mais on s'y fait ! Le truc que j'ai jamais réussi, c'est compiler des sources C d'un autre programme en gérant les dépendances. Je ne sais réellement pas du tout faire !

par **drfloyd** Sam 22 Fév 2020 - 12:03

Je veux dév COSMOS en me passant totalement des pointeurs ?

par **Urbinou** Sam 22 Fév 2020 - 12:06

Doit bien y avoir des classes qui gèrent des tableaux de structures en faisant le sale boulot pour toi non ?

Moi non plus je peux pas blairer le C... pukel

par Monos Sam 22 Fév 2020 - 12:20

Je veux dév COSMOS en me passant totalement des pointeurs ?

Tu peux te passer des *pointeur bidule chose. Le seul truc que tu risques d'utiliser c'est les noms des tableaux que tu passes en paramètres dans certaine fonction. Perso sur atari la je fais du déplacement de mémoire entre tableau et mémoire vidéo. Je fous mon tableau en source et 'l'adresse de la mémoire vidéo (j'ai une fonction) donc je manipule indirectement des pointeurs mais ça soule pas. Après dit quoi juste qu'un pointeur c'est une variable qui contient une adresse mémoire ! (Je compte pour moi écrire une page web pour me faire un mémo sur les pointeurs car avec les *, les & et chez pas quoi sur les pointeurs, j'en perd mon latin aussi.

Mais je re signe ce que j'ai dit, partir à porter ton directos en C comme ça , ça ne vas pas marcher... Commence avec un truc simple rétro. Même si tu ne fais pas un jeu, test le devkit SMS en C... Le SDK est simple pour te faire afficher un sprite, et des tiles... Ou le SDK d'alek maul pour la colecovision... (A vrais dire le SDK de steff pour la meg peut être cool aussi) mais ne cherche pas à utiliser ses grosses fonctions, reste juste "simple". Afficher un sprite, un tile, poser plusieurs tiles à l'écran en fonction de tes tableaux de Data... Entre un basic et le langage C , c'est proche n’empêche.

par **drfloyd** Sam 22 Fév 2020 - 12:46

tu as raison, si je continue, ca sera sur le DSK Colecovision... sans grosses fonction, sans pointeur

et je vais relire les cours de base de Mimi :
http://www.gamopat.com/gamopat-cours-de-programmation.html

par ichigobankai Sam 22 Fév 2020 - 12:48

Mets toi à l'ASM Mr. Green

Mais plaisanterie à part, les "pointeurs" sont vraiment bcp plus simple à assimiler / comprendre (et utiliser) en ASM.

Les pointeurs de fonctions, c'est quand même (bien) pratique.

Faire du C en se passant des pointeurs, c'est un peu comme rouler en Porsche sans passer la 2nde vitesse... Ca roule, mais il manque un petit truc.

par lincruste Sam 22 Fév 2020 - 15:04

Le C j'en ai fait une seule fois dans ma vie pour le GBDK , parce que c'était ça ou l'assembleur Z80 si tu veux programmer sur Game Boy. Hé ben je confirme, faut vraiment être câblé à l'envers pour trouver ça agréable. Par contre quand t'arrive à 0 erreurs de compilation et que ton truc fait à peu près ce que tu imaginais t'as l'impression d'être le maître du monde.

par **Tryphon** Sam 22 Fév 2020 - 15:41

Bah le C, c'est pas très compliqué mais ça nécessite de la rigueur et comprendre exactement ce qu'il se passe en mémoire. Et comme dit Ichigo, le mieux pour comprendre ce qu'il se passe, c'est quand même d'avoir fait de l'asm...

Moi ce que j'aime pas trop dans le C, c'est sa syntaxe et me fait que faire de l'objet t'oblige à pas mal de circonvolutions...

par lincruste Sam 22 Fév 2020 - 16:11

Attention je ne critique pas le langage en particulier parce que j'en aime aucun. Pour moi c'est comme conduire, c'est bien pratique dans la vie, on peut vivre très bien sans, mais aimer ça pour le seul plaisir de le faire c'est de la perversion.

par lincruste Sam 22 Fév 2020 - 16:23

J'en connais, j'ai des noms.

par **Urbinou** Sam 22 Fév 2020 - 16:24

Y en a même qui aiment ET programmer, ET conduire !

par **Tryphon** Sam 22 Fév 2020 - 17:11

J'aime programmer, mais j'aime pas conduire : je ne suis donc qu'à demi pervers Razz

(c'est cool la programmation, c'est un peu comme un jeu de construction où t'as pas besoin d'être habile de tes mains Razz

)

par **F.L** Sam 22 Fév 2020 - 18:25

on s'ecarte un peu du sujet là, non ? Mr. Green

Doc, je peux t'apprendre à traduire ton listing basic en C, c'est 65c02 qui me l'a appris et en fait c'est tout con MDR

par **drfloyd** Sam 22 Fév 2020 - 20:15

Merci FL, je peux toujours faire du C "de manouche"... j'rrive deja à faire des trucs.... mais franchement je prend pas plaisir :/ Et j'ai pas beaucoup de période ou je peux etre seul pour me concentrer.... En Pure j'arrive à programmer tout en étant à 5 dans la salle et TV à fond Mr. Green

Pour la version PC aucun interet à le convertir en C en tout cas, y aurait aucune différence au final

Pour faire un jeu Coleco pourquoi pas... Y a pas un tuto complet du kit de dev Coleco en C ???????