Re: topic officiel Project Y - Paprium

[Hpman]

L'ASM ira plus vite, quelle que soit la qualité du compilateur.

Donc historiquement les programmeurs de l'époque font de l'ASM. Les programmes ont aussi régulièrement des structures "folkloriques" que tu ne verrais pas en C.
Le C n'est également pas vraiment gaulé pour les systèmes de banking, très répandus à l'époque.

Y'a des exceptions bien entendu, Gauntlet arcade à été écrit en C, et à l'époque on compilait via un terminal, pas sur son ordi perso

Bref SGDK c'est très bon mais j'ai pas encore vu tourner dessus de jeux aussi "intenses" que les jeux commerciaux de l'époque.

[TotOOntHeMooN]

Il ne vis que sur les dons de préco ?

Il ne vie pas sur les dons des préco... Vous êtes vraiment mauvaise langue. Le choix d'habiter en Chine pour concrétiser ses aventures et un choix lié au fait que la vie est extrèmement moins cher et qu'être sur place permet de maitriser la qualité de la chaine de fabrication. On peut aussi espérer pour lui que les ventes confondues de la version HD de PierSolar ont permis d'aider à continuer dans ce sens.

[Tryphon]

Donc historiquement les programmeurs de l'époque font de l'ASM. Les programmes ont aussi régulièrement des structures "folkloriques" que tu ne verrais pas en C.

Réciproquement, tu vois aussi du code très sale, sous-optimal, utilisant des structures non adaptées en asm

Le C n'est également pas vraiment gaulé pour les systèmes de banking, très répandus à l'époque.

C'est certainement ce qui explique son succès sur MD : le banking est rarement nécessaire.

Bref SGDK c'est très bon mais j'ai pas encore vu tourner dessus de jeux aussi "intenses" que les jeux commerciaux de l'époque.

Tu as testé ma démo de Shinobi ? J'ai plus d'objets que sur Shadow Dancer MD (pourtant nerveux et codé en asm), sans une perte de frame. C'est pas parfait, mais les problèmes sont davantage dus à du fine-tuning (hitbox notamment, ou placement des persos) qu'aux perfs. En particulier, j'ai 2 frames d'input-lag, exactement comme les meilleurs jeux commerciaux d'époque (Revenge of Shinobi par exemple, c'est 3 frames).

Et je suis pas le plus compétent des codeurs... Du coup je suis assez confiant pour Paprium...

[Invité]

Ben les compilateurs jusque dans les années 90 n'optimisaient pas assez le code et donc il fallait faire de l'ASM pour faire mieux que les compilateurs, et gagner plusieurs images par seconde à l'exécution.

Je suis pas tout à fait sûr de ça. SGDK utilisait jusqu'à il y a peu la version 3 de GCC, qui date de 2OO1, et les résultats étaient déjà bons.

5 ans plus tôt GCC était moins performant, mais d'autres compilateurs devaient ne pas en être très loin. La théorie des compilateurs est au point depuis longtemps, et le C date quand même de 1972...

Ben que ça soit les compilateurs ou le rendu 3D , on a la théorie depuis longtemps , le souci est qu'un bon compilo ça prend pas mal en ressource.
Quand tu compile sur ton PC d'aujourd'hui en 2 ou 3 GHz et que ça peut prendre plusieurs dizaine de seconde , alors imagine à l'époque !
En 2001 , on commençais a avoir de très bon proc sur PC

Réciproquement, tu vois aussi du code très sale, sous-optimal, utilisant des structures non adaptées en asm

Ben non le code sale ne dépend pas du langage (enfin rarement) , mais effectivement ça dépend du programmeur et pour être efficace en asm faut être surtout à l'aise dessus .

[TotOOntHeMooN]

J'ai trouvé de nouvelle photos du Book avec la partie technique.
Ca peux-être intéressant pour apprendre plus de chose sur la partie sotfware pour ceux qui capte l'anglais

C'est intéressant, même si comme souvant avec les réponses d'interview, on apprend un peut mais pas autant qu'on voudrait.
Ca confirme aussi que le circuit personnalisé boost l'affichage en gardant une ROM de taille réduite par rapport au contenu du jeu.
La fonctionnalité réseau pour partager ses scores en ligne et éventuellement jouer à plusieurs c'est cool, si les gens jouent le/au jeu.

[Tryphon]

Ben que ça soit les compilateurs ou le rendu 3D , on a la théorie depuis longtemps , le souci est qu'un bon compilo ça prend pas mal en ressource.
Quand tu compile sur ton PC d'aujourd'hui en 2 ou 3 GHz et que ça peut prendre plusieurs dizaine de seconde , alors imagine à l'époque !
En 2001 , on commençais a avoir de très bon proc sur PC

Je pense que même en 95, les devs avaient accès à des machines assez puissantes. En plus, si tu découpes ton projet, tu as rarement besoin de recompiler tous les fichiers (mais oui, pour avoir fait de l'ASM et du C y'a 25 ans, c'était lent )

Ben non le code sale ne dépend pas du langage

Bien sûr que si ! T'as jamais fait du Basic dans les années 8O ?

Même sans ça, quand tu as un langage qui dispose de bibliothèques implémentant les structures, les algos d'accès optimaux, tu n'as plus qu'à savoir quelle structure est la mieux adaptée à quel usage.

[Hpman]

Tu as testé ma démo de Shinobi ? J'ai plus d'objets que sur Shadow Dancer MD (pourtant nerveux et codé en asm), sans une perte de frame. C'est pas parfait, mais les problèmes sont davantage dus à du fine-tuning (hitbox notamment, ou placement des persos) qu'aux perfs. En particulier, j'ai 2 frames d'input-lag, exactement comme les meilleurs jeux commerciaux d'époque (Revenge of Shinobi par exemple, c'est 3 frames).

Si bien sur c'est propre, mais shinobi reste quand même assez plan-plan comparé aux jeux les plus aboutis du système, non ?

Ca confirme aussi que le circuit personnalisé boost l'affichage en gardant une ROM de taille réduite par rapport au contenu du jeu.

Bah non ça boost pas l'affichage, ça permet juste de garder une rom relativement petite par rapport au contenu.
Le mapper dans SF2 ne boost pas les perfs de la MD, il permet juste d'agrandir la cartouche. Ici c'est pareil.

[Invité]

Si bien sur c'est propre, mais shinobi reste quand même assez plan-plan comparé aux jeux les plus aboutis du système, non ?

Bah oui, c'est du Omebrou. 

[Invité]

Ben non le code sale ne dépend pas du langage

Bien sûr que si ! T'as jamais fait du Basic dans les années 8O ?

Même sans ça, quand tu as un langage qui dispose de bibliothèques implémentant les structures, les algos d'accès optimaux, tu n'as plus qu'à savoir quelle structure est la mieux adaptée à quel usage.

Ben j’étais pas né en 1980 et en 1990 j'avais 2 ans !

(et jamais fait de basic).
Tu sais les programmes assembleurs ont fait des progrès tu sais depuis les années 80 , tu peux faire des macro assez évolué pour presque avoir un genre de inline /fonction C-like , et pour les structures ben on peut les avoir aussi en asm , on arrête pas le progrès , pour cela que je suis très difficile niveau programme assembleur , un programme assembleur qui n'offre pas de macro , label temporaire je refuse de coder en full asm dessus
Sauf sur PS2 , ou tu code le VU en full asm  et le programme assembleur est ultra basique mais bon pas le choix

Par exemple voilà le main de mon A-RPG :
https://paste.ofcode.org/ZhhkLhVNjMcYGL9CdJwNy6
Certe ce n'est pas le code le plus propre (et je devrait pas mettre le game loop dans le main ), mais ça reste assez lisible a mon sens et c'est assez bien structuré :p

[zouzzz]

T'as raté ton quotage Studio, je rectifie car je n'ai pas grand chose à faire ces 2 prochaines minutes :

Si bien sur c'est propre, mais shinobi reste quand même assez plan-plan comparé aux jeux les plus aboutis du système, non ?

Bah oui, c'est du Omebrou. 

Voilà qui est mieux.

[Tryphon]

Si bien sur c'est propre, mais shinobi reste quand même assez plan-plan comparé aux jeux les plus aboutis du système, non ?

Ben il fait mieux que Shadow Dancer MD, qui date de 1993...

Plus précisément, il gère 8 objets dynamiques de bonne taille (typiquement 4Ox6O) affichables à l'écran (donc chargement des frames à la volée lors des animations), + 16 statiques (toutes les frames sont en VRAM, ce sont les otages et les projectiles principalement). Chaque type d'ennemi a une IA pas complètement simpliste.

Ça se voit pas trop parce que la réalisation du jeu est assez dépouillée, mais on est sur un standard de jeu MD commercial de milieu d'exploitation.

Par exemple, je ne suis pas certain de pouvoir le reproduire à l'identique sur SNES, même en asm (mais je suis pas spécialiste de la SNES)...

Je pense qu'avec le même moteur, je peux refaire un BTA à progression...

[Invité]

Oui désolé pas très doué de faire ça sur mon Samsoule A5.
Merci pour la correction.

[ace76]

Si bien sur c'est propre, mais shinobi reste quand même assez plan-plan comparé aux jeux les plus aboutis du système, non ?

Ben il fait mieux que Shadow Dancer MD, qui date de 1993  1991.

Fixed

[TotOOntHeMooN]

Tu sais les programmes assembleurs ont fait des progrès tu sais depuis les années 80 , tu peux faire des macro assez évolué pour presque avoir un genre de inline /fonction C-like , et pour les structures ben on peut les avoir aussi en asm , on arrête pas le progrès  

Tout à fait. Voici une loop du code d'affichage des scores de Risky Rick

Code:

.loop   
      call MENU.Film.Show
      call GRID.Flip   
      call ShowGrid
      call MENU.Show.TitleOnly
      
      ld HL,EnterName
      ld DE,(22*32)+8
      call MENU.Text.DrawOffscreen
      ld A,52
      out (VDP.PortData),A
      
      call Pointer.Thinker
      call Pointer.Draw
      call NameEnter
      
      call CONFIG.WaitSync
      call GRID.ShowCurrentScreen

      jr .loop

[Tryphon]

Ben j’étais pas né en 1980 et en 1990 j'avais 2 ans !

(et jamais fait de basic).

Ah c'est pour ça

Tu sais les programmes assembleurs ont fait des progrès tu sais depuis les années 80 , tu peux faire des macro assez évolué pour presque avoir un genre de inline /fonction C-like , et pour les structures ben on peut les avoir aussi en asm , on arrête pas le progrès

Je dis pas qu'on peut pas. Je dis que c'est suffisamment chiant de programmer des parcours de graphes ou des quadtrees en asm pour que j'en ai pas vus souvent dans les jeux que j'ai désassemblés.

La plupart des devs (pro ou pas) ne veulent pas se faire chier. Si c'est trop dur à faire dans un langage, ils ne le font pas, ou changent de langage. Vu que sur 16 bits il était impensable de faire autre chose que de l'asm, la plupart du temps (il y a des exceptions) ils ne l'ont pas fait...

, pour cela que je suis très difficile niveau programme assembleur , un programme assembleur qui n'offre pas de macro , label temporaire je refuse de coder en full asm dessus
Sauf sur PS2 , ou tu code le VU en full asm  et le programme assembleur est ultra basique mais bon pas le choix

Par exemple voilà le main de mon A-RPG :
https://paste.ofcode.org/ZhhkLhVNjMcYGL9CdJwNy6
Certe ce n'est pas le code le plus propre (et je devrait pas mettre le game loop dans le main ), mais ça reste assez lisible a mon sens et c'est assez bien structuré :p

Oui, j'ai vu pire

Mais je ne peux m'empêcher de penser qu'en C, ce serait 3 fois plus court
Y'a-t-il un asm où sont automatiquement générées des macros où pour appeler une fonction, tu tapes :

Code:

MA_FONCTION(1, 2)

et ça se transforme en :

Code:

moveq #1, d0
moveq #2, d1
jsr ma_fonction

voire

Code:

MA_FONCTION(1, ptr)

en

Code:

moveq #1, d0
move (ptr), d1
jsr ma_fonction

(ça s'adapte au type de paramètre) ?

C'est certainement possible à faire, mais il faut que tu écrives les macros à la main. Y'a-t-il un asm qui fasse ça automatiquement ?

[Tryphon]

Si bien sur c'est propre, mais shinobi reste quand même assez plan-plan comparé aux jeux les plus aboutis du système, non ?

Ben il fait mieux que Shadow Dancer MD, qui date de 1993  1991.

Fixed

Au temps pour moi, c'est même 199O au Japon, je le voyais plus récent

Mais bon, Aladdin est sorti en 93 et n'est pas plus exigeant...

[Hpman]

Shadow dancer c'est 1990 oui.

Beaucoup de jeux d'époque sont aussi contraints par la taille. Shadow dancer c'est 4megs, il va finir à combien shinobi ?

[Invité]

Comme tu le dis , tu peux le faire en assembleur (et tu peux changer et les adapter le code en paramètre il y'a des if spécifique pour les macro) mais faut le faire a la main.

Mais je ne peux m'empêcher de penser qu'en C, ce serait 3 fois plus court

Sûrement , après je fais beaucoup de C , mais plus sur les consoles de 5-6 générations couplé a de l'asm pour les parties critiques

Je trouve que l'asm et le hard de l'époque reste encore correct pour un programme en full asm et puis si je l'aurais pas fait , mon niveau au bas niveau n'aurait pas progressé
(Et puis sur SNES t'as pas trop le choix , tu n'as aucun bon compilo C pour du 65816)

[lord2laze]

Il ne vis que sur les dons de préco ?

Il ne vie pas sur les dons des préco... Vous êtes vraiment mauvaise langue. Le choix d'habiter en Chine pour concrétiser ses aventures et un choix lié au fait que la vie est extrèmement moins cher et qu'être sur place permet de maitriser la qualité de la chaine de fabrication. On peut aussi espérer pour lui que les ventes confondues de la version HD de PierSolar ont permis d'aider à continuer dans ce sens.

Quelle abnégation, quel don de soi.

Il se dit qu'il ne mange que une fois par jour une ration de 45 grammes de patate afin de pouvoir consacré tout son argent au jeu, et qu'il vit sur le parking de l'usine pour suivre la fabrication des cartouches.

Je crois qu'il vit des dons des adeptes de SEGA en leur promettant un monde meilleur ou la MD surpasserait la SNES et ou elle aurait un son cristallin et afficherait toutes les couleurs de l'arc-en-ciel.

Il est l'élu, celui qui est plus fort que toi, celui qui fait what Nintendon't, celui que l'on attendait depuis si longtemps (2001 je crois)

[TotOOntHeMooN]

Quelle abnégation, quel don de soi.

Je ne ferai pas de commentaire, c'est totalement déplacé de ta part.

[Tryphon]

Shadow dancer c'est 1990 oui.

Beaucoup de jeux d'époque sont aussi contraints par la taille. Shadow dancer c'est 4megs, il va finir à combien shinobi ?

Je dirais 8, peut-être 16.

Shadow Dancer compresse les ressources graphiques, moi pas. Mais si nécessaire, je peux le faire (une fois décompressé ça rentre en RAM sans problème).

Ce n'est pas le moteur de jeu qui prend de la place, et peu de choses sont précalculées dans le jeu.

[invité]

Question a Tryphon : pourquoi tu as l'habitude d’écrire 0 (zéro) O ?
Ca m'intrigue 

[Tryphon]

On m'a posé la question 2O fois

La touche "zéro" de mon portable ne fonctionne plus (je dois copier-coller des zéros quand j'en ai vraiment besoin)

[invité]

Ok, je me demandais si c'était un toc ou de la pensée magique (je t'aurais alors cafté direct a xorion) 

[Tryphon]

Le pire, c'est que je ne supporte pas les gens qui utilisent un symbole à la place d'un autre parce que "c'est presque pareil"

Je suis un typograf-nazi

[lord2laze]

Quelle abnégation, quel don de soi.

Je ne ferai pas de commentaire, c'est totalement déplacé de ta part.

C'est surtout bien naïf de ta part de penser que Monsieur est en Chine parce que la vie y est moins chère et que ca lui permette de mettre tout son argent dans ses jeux pour votre seul plaisir, et ne pouvoir suivre le bon déroulé de l'avancement de son jeu.

Déjà si c'est pour suivre le bon déroulé de la production qu'il est en Chine, c'est un vrai gland vu que rien n'est sorti en plus de 6 ans.

Penser que la vie est moins chère en Chine pour un petit blanc avec une grosse moustache relève de la Chymère. Elle est moins chère pour le paysan ou l'ouvrier Chinois qui tente de survivre, c'est tout.

Il ne t'a jamais traversé l'esprit que si il est en Chine c'est pour que sa société échappe à la fiscalité Française qui est beaucoup moins tendre que la fiscalité Chinoise ?

Que vu que ces clients sont en Europe, si il décide de vous glisser la carotte vous aurez plus difficilement des recours vu que sa société est en Chine ?

Alors bien sur, tu vas me dire que si il est en Chine pour payer moins d'impôts, c'est qu'il veut mettre plus d'argent dans ses jeux pour le plaisir de ses fans....mais la ca relève de la foi aveugle.

En tout cas si PayPal bloque l'argent récolté, c'est qu'il y a quelque chose de pas normal. Vous râlez après PayPal, mais si ca se trouve, ils sont entrain de sauver vos 100-200 boules quand WM se déclarera en cessation de paiement.

[Hpman]

Bah si on en crois ce qu'on lit, un certain nombre de personnes ont du faire annuler la transaction par leur banque/paypal pour se faire rembourser.

Du coup ça doit clignoter bien rouge sur le tableau de bord chez paypal

[lord2laze]

Bah si on en crois ce qu'on lit, un certain nombre de personnes ont du faire annuler la transaction par leur banque/paypal pour se faire rembourser.

Du coup ça doit clignoter bien rouge sur le tableau de bord chez paypal

Et clairement on ne peut pas leur en vouloir.

Ceux qui ont mit des billes se retrouvent face à deux choix :

- Les retirer le plus rapidement possible, parce que si ca s'écroule, y aura pas assez pour rembourser tout le monde
- Aller jusqu'au bout, et si ca foire, s'asseoir sur l'argent mis dedans

[polton]

au bout de six ans vous voulez faire comment avec paypal pour annuler une transaction ?
les remboursements se font au bon vouloir de WM

[Stef]

L'ASM ira plus vite, quelle que soit la qualité du compilateur.

Donc historiquement les programmeurs de l'époque font de l'ASM. Les programmes ont aussi régulièrement des structures "folkloriques" que tu ne verrais pas en C.
Le C n'est également pas vraiment gaulé pour les systèmes de banking, très répandus à l'époque.

Y'a des exceptions bien entendu, Gauntlet arcade à été écrit en C, et à l'époque on compilait via un terminal, pas sur son ordi perso

Bref SGDK c'est très bon mais j'ai pas encore vu tourner dessus de jeux aussi "intenses" que les jeux commerciaux de l'époque.

Comme Tryphon je pense que tu sous estimes un peu ce qu'on peut faire juste en C. C'est l'implémentation qui prime..
Je t'invite à essayer Omega blast que tu peux trouver ici :
https://nendo16.jimdo.com/omega-blast

Codé 100% en C (avec SGDK).

Je pense que plus de jeux qu'on pense étaient codés en C (au moins partiellement) sur MD. Sur SNES effectivement c'est une autre histoire, mais c'est à cause du CPU qui est trop limité, franchement je vois pas comment on peut pondre un compilo correct sur un CPU pareil (trop peu de registres, banking..). Même en faisant un compilo spécifique.. à moins de te limiter à un pseudo méta assembleur.

[F.L]

Ben que ça soit les compilateurs ou le rendu 3D , on a la théorie depuis longtemps , le souci est qu'un bon compilo ça prend pas mal en ressource.
Quand tu compile sur ton PC d'aujourd'hui en 2 ou 3 GHz et que ça peut prendre plusieurs dizaine de seconde , alors imagine à l'époque !
En 2001 , on commençais a avoir de très bon proc sur PC

Je pense que même en 95, les devs avaient accès à des machines assez puissantes. En plus, si tu découpes ton projet, tu as rarement besoin de recompiler tous les fichiers (mais oui, pour avoir fait de l'ASM et du C y'a 25 ans, c'était lent )

Ben non le code sale ne dépend pas du langage

Bien sûr que si ! T'as jamais fait du Basic dans les années 8O ?

Même sans ça, quand tu as un langage qui dispose de bibliothèques implémentant les structures, les algos d'accès optimaux, tu n'as plus qu'à savoir quelle structure est la mieux adaptée à quel usage.

Popopopo....
Le basic c'est pas sale ! Et meme si le code est sale mais que ca marche et bien ça n'est pas un code sale (pour moi )
Vive le code manouche qui sent la schneke poilue (avis aux connaisseurs)