Auteur Sujet: Intro 64K en C#  (Lu 1391 fois)

0 Membres et 1 Invité sur ce sujet

Je fais des tests de compression des executables .Net pour une éventuelle intro en 64ko ...

Je suis tombé sur RPX basé sur UPX qui est vraiment pas mal.
http://rpx.codeplex.com

Quelqu'un à déjà fait des tests d'intro 64k en C# ?
Le code IL peut-il être aussi compressible que du X86 ?
Les intros en .net sont elles autorisées en demo party ?

Merci.
 


n'importe quelle démo et même n’importe quoi est autorisé en party, pour le cou une démo C# à besoin de l'environnement C# , ça reviendrait à du 64K sur plateforme C# comme si c'était une machine virtuel,
mais c'est une bonne question que tu pose, tout ce que j'ai développer en c# ben je peut même plus l'exécuté,
le mieux c'est le JS !  y a bien eu des 64K en js même une 1K de xt95 avec des métaballs j'me souvient c'est cette démo qui ma fait commencer à coder en js pour la toute premier fois  le code me parlait, pourtant js à besoin de firefox,, mais ça compte comme une démo js, toi ça sera démo c# ou dot net, de toute façon y a toujours des classification pour les 64K évidement entre les plateformes les new school et les old machine faut pas mélanger les pinceaux à l'huile et à eau,

Salut backlash,

J'ai étudié la question il y a quelques années et en fait, même s'il est possible de faire une intro 64k en C#, c'est beaucoup trop limitant pour l'utiliser, car in-fine ce serait bien moins efficace en terme d'escape/qualité/ratio compression qu'une intro en C.

En gros, tu perds énormément de place dans l'exécutable .NET d'origine avec les metadatas des assembly .NET (qui stocke dans le détail la signature de toutes les méthodes, classes, structs, enums, des assemblies et types référencés...etc.), même en utilisant des techniques d'optimisation des metadatas (link de plusieurs assemblies en un seul, obfuscation pour réduire la longueur des identifiants... etc.) couplés avec des compression classiques intro 64k (type kkrunchy).

J'avais pensé aussi à une solution hybride où le code exe (non .NET) contiendrait en fait du code C# minified avec un appel direct de la VM/host CLR, avec compilation d' un assembly .NET au démarrage... mais vu l'effort que cela aurait demandé, j'ai trouvé que cela ne valait pas le coup par rapport au travail qu'il faut déjà fournir pour développer une bonne intro 64k.

Donc je ne conseille pas trop. En revanche, c'est parfait pour faire des démos d'autant que tu peux développer les tools avec (typiquement, les démos du groupe STILL par example sont en C#, ils ont même publié leur tool sur github https://github.com/framefield/tooll ). Et aujourd'hui avec CoreCLR, on peut développer des applis/demos .NET standalone cross-platform sans installation.

Pire le .net en plus des metadatas embarque ce que j’appelle du code mort, si vous avez une classe ou des méthodes dans votre projet que vous n'utilisez pas, elles seront quand même incluses dans l’exécutable, pour un Exécutable 64Ko ça ne facilite pas la vie ... Je ne sais pas si il existe un outil pour supprimer le code mort ?
Bon je pense que je vais faire une croix sur le C# pour une intro ...

Historiquement, après avoir développé « FxGen », qui est un générateur de texture « à la Farbraush », j'ai toujours eu pour but de réaliser avec cet outil écrit en C++ un jeu le plus petit possible en taille ... 
https://sourceforge.net/projects/fxgen/

C'est lorsque j'ai découvert XNA que j'ai réécrit FxGen en C# et commencé un shoot-them-up avec la logique du jeu gérée par les « Stack Operator », les décors sont entièrement procéduraux, les déplacements des ennemies sont procéduraux ... bref j'ai toujours gardé pour but d'avoir un exécutable le plus petit possible ...
https://procfxgen.wordpress.com/2015/02/21/voxels-destruction/

Aujourd’hui j'utilise monogame qui est un excellent framework mais je commence à regretter le C++, peut être mieux adapté pour mes objectifs de contenus procéduraux ...



code en C++ si tu est sérieusement porté par l'optimisation de l'exécutable en poid,  et code en C# si justement tu veux pas te faire chier ,
à moins que tu découvre que le C# peut être avantageuse , avec sont environnement, de toute façon l'exécutable n'est pas important, seul le code source et le résultat final compte ,

Pire le .net en plus des metadatas embarque ce que j’appelle du code mort, si vous avez une classe ou des méthodes dans votre projet que vous n'utilisez pas, elles seront quand même incluses dans l’exécutable, pour un Exécutable 64Ko ça ne facilite pas la vie ... Je ne sais pas si il existe un outil pour supprimer le code mort ?
Bon je pense que je vais faire une croix sur le C# pour une intro ...

Il est possible de réduire la taille des assemblies et de supprimer le code mort, via par exemple ILMerge ou ILRepack couplé a Mono.Linker. C'est ce que j'avais utilisé à l'époque dans mes tests via un petit outil SharpPak que j'avais testé sur SharpDX.

C'est la méthode utilisée pour faire de la compilation AOT dans Xamarin (lorsque l'on dévelope une appli iOS). .NET Native (pour les applis UWP sous Windows) utilise une technique similaire mais le code n'est pas open-source.

Merci pour vos réponses  :)

Je vais continuer mes tests en c# c'est quand même plus excitant d'essayer de contourner ces nouvelles limites ...

Le .net Core est justement très intéressant ...


tkt frère tu vas nous faire une grosse 4 K qui déchire et qui pète tout  :'(  :o :D

Pour les règles, ça dépend des demoparties. Il faut vérifier en avance pour être sûr. Mais c'est accepté à Revision (https://2016.revision-party.net/compos/pc).

Pour la taille, ça dépend aussi de ce que tu veux faire et de tes ambitions.

Très peu d'intros utilisent vraiment les 64ko : si tu optimises, 64ko représente vraiment beaucoup de code. Donc même si .NET prend un peu plus de place, ce n'est pas forcément grave. Tu perds un peu de place, mais tu peux gagner en productivité. C'est pas forcément un mauvais choix.