Logicielsmoto.com
http://www.logicielsmoto.com/phpBB/

Outillage pour développement de jeux sur TO8
http://www.logicielsmoto.com/phpBB/viewtopic.php?f=3&t=620
Page 39 sur 40

Auteur:  Bentoc [ 21 Nov 2022, 16:22 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

Je n’ai pas encore intégré tes deux dernières optims … c’est sur la todo list :tourne:
Merci :bien:

Auteur:  Bentoc [ 23 Nov 2022, 23:02 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

ça y est :
- dernières optims commit
- mise à jour de toutes les démos avec la nouvelle routine RunObjects

Auteur:  Bentoc [ 26 Nov 2022, 22:54 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

tiens ... j'ai remarqué un oubli d'optimisation dans mon générateur de sprite compilé :

Code:
adr_fnt_3x7N_50_DN0
   LEAU 120,U

   LDA #$00
   STA 120,U
   STA -120,U
   LDA 80,U
   ANDA #$0F
   ORA #$00
   STA 80,U
   LDA 40,U
   ANDA #$0F
   ORA #$00
   STA 40,U
   LDA ,U
   ANDA #$F0
   ORA #$00
   STA ,U

   LDU <glb_screen_location_1
   LEAU 140,U

   LDA 100,U
   ANDA #$0F
   ORA #$00
   STA 100,U
   LDA -60,U
   ANDA #$0F
   ORA #$00
   STA -60,U
   LDA -100,U
   ANDA #$0F
   ORA #$00
   STA -100,U
   RTS


quand on a un pixel plein index couleur 0 et un pixel transparent, on fait un ORA #$00 totalement inutile.

Auteur:  Samuel Devulder [ 27 Nov 2022, 00:39 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

J'ai aussi remarqué dans le code qu'on fait souvent des ANDA #$00 pour nettoyer la partie haute de D.

Alors ok c'est 2 cycles, c'est rien, mais c'est surtout 2 fois plus d'octets que CLRA. Au final ces petits octets s'accumulent et ajoutent une bank RAM qui pourrait servir plus tard. Idem avec LDA #0, qu'il vaut mieux remplacer par CLRA généralement parlant.

Le seul cas ou ANDA #0/LDA #0 se justifie c'est lorsqu'on veut préserver la retenue (CLRA l'éfface).

Auteur:  Yoann Riou [ 28 Nov 2022, 15:33 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

Bentoc a écrit:
tiens ... j'ai remarqué un oubli d'optimisation dans mon générateur de sprite compilé :

quand on a un pixel plein index couleur 0 et un pixel transparent, on fait un ORA #$00 totalement inutile.


De meme qu'un ANDA #$FF si t'en as

Auteur:  Samuel Devulder [ 03 Déc 2022, 12:24 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

Samuel Devulder a écrit:
Sur 32s d'execution, il n'y a qu'une seule lecture dans la zone $4000-$5FFF, en $4774 suite à un LDA D,Y en $3C70. Ca ressemble plus à un débordement de tableau qu'un truc volontaire: https://www.cjoint.com/doc/22_10/LJEv5a ... .html#3C70


Je pense que c'est un bug de l'outil d'analyse car je viens de fixer un soucis faisant apparaitre des lectures à des adresses fantômes.
https://github.com/Samuel-DEVULDER/DCMo ... e816fR2091

Auteur:  Bentoc [ 03 Déc 2022, 12:44 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

ah super, merci pour l'info.
J'avais fait quelques tests mais n'avais pas réussi a reproduire le problème.

Auteur:  Samuel Devulder [ 07 Déc 2022, 21:42 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

Groumph, je fais un test d'installation du source sur une nouvelle machine (linunx pour simplifier) et je repars de 0.

Déjà après le checkout j'ai 75 fichiers modifiés par GIT à cause des \r\n qui trainent. Bon ca ca va je sais gérer, mais je suis surpris par le nombre de fichiers en CRLF. Je pensais que tout avait été nettoyé.

Ensuite je compile mais je tombe sur cette erreur:
Code:
$ java -jar ../../java-generator/target/game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar ./s2-EHZ-halfline2-linux.properties
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
Load Game configuration: ./s2-EHZ-halfline2-linux.properties ...
Build error.
java.lang.Exception: Impossible de charger le fichier de configuration: ./objects/main-character/sonic/Sonic.properties
        at fr.bento8.to8.build.Object.<init>(Object.java:55) ~[game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
        at fr.bento8.to8.build.GameMode.<init>(GameMode.java:118) ~[game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
        at fr.bento8.to8.build.Game.<init>(Game.java:176) ~[game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
        at fr.bento8.to8.build.BuildDisk.loadGameConfiguration(BuildDisk.java:201) ~[game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
        at fr.bento8.to8.build.BuildDisk.main(BuildDisk.java:127) [game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]
Caused by: java.io.FileNotFoundException: ./objects/main-character/sonic/Sonic.properties (No such file or directory)
        at java.io.FileInputStream.open0(Native Method) ~[?:?]
        at java.io.FileInputStream.open(FileInputStream.java:219) ~[?:?]
        at java.io.FileInputStream.<init>(FileInputStream.java:157) ~[?:?]
        at java.io.FileInputStream.<init>(FileInputStream.java:112) ~[?:?]
        at fr.bento8.to8.build.Object.<init>(Object.java:52) ~[game-engine-0.0.1-SNAPSHOT-jar-with-dependencies.jar:?]

Et effectivement, sur mon disk, le fichier ./objects/main-character/sonic/Sonic.properties est écrit ./objects/main-character/sonic/sonic.properties avec un s minuscule. Comment ca se fait que je ne découvre cela que maintenant ? Les compiles précédentes sur l'autre machines n'avaient pas ce soucis.

Une fois cela corrigé, je me dis qu'enfin c'est bon, mais hélas:
Code:
                        ./generated-code/Bridge/Img_bridge_log_0_ND1.lst lwasm.exe DRAW cycles: 501 computed cycles: 501
                        ./generated-code/Bridge/Img_bridge_log_0_ND1.lst lwasm.exe DRAW size: 316 computed size: 316
Generate Tilesets ...
        EHZ tileset: Tls_EHZ
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at fr.bento8.to8.image.SpriteSheet.prepareImages(SpriteSheet.java:469)
        at fr.bento8.to8.image.SpriteSheet.<init>(SpriteSheet.java:431)
        at fr.bento8.to8.build.BuildDisk.generateTilesets(BuildDisk.java:579)
        at fr.bento8.to8.build.BuildDisk.generateTilesets(BuildDisk.java:552)
        at fr.bento8.to8.build.BuildDisk.main(BuildDisk.java:137)
Fin, arg oui cette machine n'a que 8Go de ram alors que la précédente en avait 32. Je ne pensais pas qu'il fallait autant de ram. Est-ce que j'aurais fais un truc de travers ?

Auteur:  Bentoc [ 07 Déc 2022, 22:39 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

Salut Sam,

Désolé pour ces déboires.

je viens de commit la correction du S majuscule. Etant sous Windows je ne vois malheureusement pas ces erreurs.
Pour les CR LF je vais regarder ... mais il faut que je trouve une solution pour contrôler de manière automatique car j'ai l'impression que le problème va revenir régulièrement.

En ce qui concerne la RAM c'est la première fois que je vois le problème.
J'ai regardé le profil de consommation :
On est à 150Mo au début, dès qu'on commence le tileset EHZ c'est là que ça monte fort : 1400Mo
On termine le build à 2200Mo avec des pics vers 2400Mo

est-ce que tu utilises une JVM 32 bits ? As tu possibilité de lancer une JVM 64 bits ?
Il me semble que c'est 2Go la limite pour une JVM 32 bits (sauf cas particuliers de certains Kernels linux)

Un coup de profiler ne ferait pas de mal sur le code du builder mais comme je vais le réécrire en grande partie ...

Auteur:  Samuel Devulder [ 07 Déc 2022, 23:00 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

C'est une JVM64bits. Pour tout dire je suis sous WSL2 (avant: WSL1) avec 8gb de limite de RAM. J'ai du mal à comprendre pourquoi java manque de mémoire sous ces conditions. Il me semble qu'il y a moyen de dumper la mémoire sur disk quand cela se produit, et l'analyser avec MAT. Je vais voir ca dès que je peux. Si ca se trouve c'est un bug dans le jdk (11.0.17 de mémoire) ou WSL2.

Auteur:  Bentoc [ 07 Déc 2022, 23:06 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

tu peux mettre : -verbose:gc -XX:+PrintGCDetails
pour tracer ce qui se passe.

As tu configuré un disque de swap ? (swapon, ...)

Auteur:  Samuel Devulder [ 07 Déc 2022, 23:39 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

oui il y a un petit swap de 2G.. Un truc que je suspecte est que les ByteBuffrers java ne sont pas alloués dans le HEAP java, mais à coté via un bon malloc() de base sous linux (source). Résultat: quand yen a trop d'alloués/désalloués ca fragmente la mémoire un max. Bon, ca n'est qu'une hypothèse.

Auteur:  Bentoc [ 08 Déc 2022, 08:29 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

Mea culpa j'ai bien fait une erreur dans le code.
... une erreur qui fait que j'alloue dans le cas d'un tileset, une quantité astronomique de mémoire.

dans SpriteSheet.java / prepareImages :

Code:
      int paddedImage = 80*height;
      pixels = new byte[subImageNb][2][paddedImage];
      data = new byte[subImageNb][2][paddedImage];


=> 2 allocations de [479][2][80*7664] => deux tableaux de 587 Mo continus !

a été corrigé par :

Code:
      int paddedImage = 80*(height/subImageNb);
      pixels = new byte[subImageNb][2][paddedImage];
      data = new byte[subImageNb][2][paddedImage];


=> 2 allocations de [479][2][80*16] => deux tableaux de 1,2 Mo

Outre le problème de la quantité requise, c'est bien la nature "continue" de la mémoire demandée qui a provoqué le out of memory.

Correction commit sur le repo.

Auteur:  PulkoMandy [ 08 Déc 2022, 09:15 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

Citation:
Pour les CR LF je vais regarder ... mais il faut que je trouve une solution pour contrôler de manière automatique car j'ai l'impression que le problème va revenir régulièrement.


Cela peut se faire dans la configuration de Git avec l'option "autocrlf"

https://git-scm.com/book/fr/v2/Personna ... ion-de-Git

On peut l'utiliser des deux côtés: sur la machine Windows qui crée les fichiers, ou sur la machine Linux qui essaie de les utiliser.

Auteur:  Bentoc [ 08 Déc 2022, 12:28 ]
Sujet du message:  Re: Outillage pour développement de jeux sur TO8

super merci pour l'info !

Du coup de mon coté (windows) j'ai joué la commande : $ git config --global core.autocrlf true

Citation:
Git peut gérer ce cas en convertissant automatiquement les fins de ligne CRLF en LF lorsque vous validez, et inversement lorsqu’il extrait des fichiers sur votre système. Vous pouvez activer cette fonctionnalité au moyen du paramètre core.autocrlf. Si vous avez une machine Windows, positionnez-le à true. Git convertira les fins de ligne de LF en CRLF lorsque vous extrairez votre code :

$ git config --global core.autocrlf true
Si vous utilisez un système Linux ou macOS qui utilise les fins de ligne LF, vous ne souhaitez sûrement pas que Git les convertisse automatiquement lorsque vous extrayez des fichiers. Cependant, si un fichier contenant des CRLF est accidentellement introduit en gestion de versions, vous souhaitez que Git le corrige. Vous pouvez indiquer à Git de convertir CRLF en LF lors de la validation mais pas dans l’autre sens en fixant core.autocrlf à input :

$ git config --global core.autocrlf input
Ce réglage devrait donner des fins de ligne en CRLF lors d’extraction sous Windows mais en LF sous macOS et Linux et dans le dépôt.


J'ai refait la liste des fichiers avec crlf sur l'index :
git ls-files --eol | grep i/crlf

et j'ai push/commit les fichiers en question ...
Normalement il n'y a plus de fichiers en crlf sauf les binaires evidement.

Page 39 sur 40 Heures au format UTC + 1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/