pouët.net

converting v2/4klang/64klang/oidos/... to C# sounds really hard, and not worth it imo.

Best idea would be to build a synth from scratch in C#, or do it in GLSL (better compression) & use glReadPixels to grab the output audio data, then send it to WaveOut.

(Also you can use aplay on linux & mono, WaveOut only works on Windows)

NOP

using pinvoke alllover (==c(++)) makes it happen!:

Extra (many) bytes for:
-> everything initializing .net (while not being able to use it anyway)
-> c# itself (for startup-code) adds extra-bytes aswell!

...all for nothing better/ontop or even easier coding!

Even TinyDX, some Library to get access to the GPU via C#.NET is huge, so maybe read the next paragraph aswell:

Way to go for sizetros will stay ASM forever! ;) Some C-code does not hurt, as it compiles into ASM-code way better than humans code by now anyway in most cases (given 10thousands of opcodes available in modern processors!)
-> that said: my 4k/8k-frameworks are still completely in C...wasting like 70-120 bytes each intro, wild-guessing! ;)
(while one could let VisualStudio save a file of the compiled ASM-code and just fiddle around in there to get it even smaller...or just take it as is! --> I just change it too often, every intro to be true, so i never went the extra-mile yet!)

Also i would say: .NET counts as extra-code! It´s a very BIG library full of pre-worked procedures ready to be used...we cannot just say, lets forget about it! ;)
We had that problem with allowing the Graphics-Libraries (DirectX, OpenGL) before...and many people disliked it...and they were right: coders used stuff like createCube() which was in there and made "4K"s from it...me included btw! ;)
But the point of using them and us having allowed to use em was to get access to the screen at all! ;) Without them we would still code on CPU only and would have a resolution of 640*480 at best still!
We do not use createXYZ() anymore btw!

So let me tell you again: we even waste many bytes to use those gfx-libs, just so we get some framebuffer (around 350-400 bytes still today in DirectX11, not counting windows-init, with it would more like 650-700 bytes!), something to put pixels on! But also yes: we can use Shaders aswell thanx to it...you should not feel bad about it...without we would still look at gouraud-shaded vectors and alike...not even some Amiga-effects would be doable at all, because of no coprocessors available!
Maybe just think of it like this: Amiga had 3 coProcessors...all were used to ultimate <-> PCs just have 1 "coProcessor"==GPU ! ;)

Shader-Code is bigger than ASM btw, as it´s C-like! :P (maybe Compressors make it smaller again then...get into it and you´ll know if or if not! haha! Obfuskation!)

you´d need to wrap everything from c# to c is what i wanted to say in my first sentence after the NoOPeration. Even the wrapping-code would be so damn many extra-bytes...all for no benefits at all in the end! ;)

I had a BOSS in my job in 2010...he asked if i could do a 4K in C# back then...my answer was immediate and it was: "NOP!" ;)
I then recherched and tested for like half an hour...: Impossible! ;)
Even for 64K it should be impossible until today! If you make it possible it´ll be a World-First and an Achievement, but it will not be sth that can compete at all, very basic bullshit is what i´d await as an outcome! Short in playtime and shortlived fame, not worth the hassle at all!

Go C and have fun! It´s not as if C would be that hard compared to c# ;) It´s almost the same, just no Garbage-Collection! ;) (Memory-Management is hard! But getting used to it makes you a better coder anyway!)

nice initiative though. I attempted a demo engine using CSGL for the opengl bindings in C# and several .NET wrappers for e.g. BASS/Assimp/Rocket that kinda stuff ~3 years ago as a little hobby exercise to speed up my familiarity with C#, but it got just a myriad of unsafe{ fixed{}} pointer hacks or 'i hope this is the right way to do it!'-marshaling quite fast the moment you have non-atomic datatypes such as float arrays or binary data that you wanna pump to your GPU ;)

C# != .NET

C# is a language. And it's definitely thinkable to create a native executable out of it. There's just no practical compiler or .NET free runtime for intro-making purposes, but I think that could be changed.

xTr1m: I'm actually more interested in making a fully .NET intro (i.e. no native code) than just compiling C# to native code. There are a number of tools that do the latter (on which crinkler etc. can be let loose), but nobody knows how to make a .NET binary small.

I know ASM 68030, ASM X86, C/C++ ... now I just want experiment small executable size with full C#... Actually I have a 3D metaball openGL scene in full C# with an 35Ko executable Size (no native compilation)... I think I could do better ... There is lots of work but It's interesting ...

If a DOS 64b intro triggers int 10h, should the BIOS count as extra code? What about the DLLs used by native Windows intros?

fwiw I also think a .net packer could be quite fun to make. Lots of room to play with CIL-specific context models I'd imagine (on-the-fly disasm-based like squishy, reordering-based like kkrunchy, ...). Could also/rather go one level higher and hook into roslyn and selectively tweak optimizations to generate code with less entropy, or even do away with CIL bytecode altogether (or at least its encoding) and ship most code as a custom blob that's JIT-compiled back to CIL at the start of the intro. Tip of the iceberg.

C# is just such a lovely language... I also like Scala, but C# is unmatched. I know the .NET platform implies that the executable files are not native code and also that the code can be easily decompiled. At my last job we used a code obfuscator for this reason, in order to prevent competitors from stealing our algorithms. But, C# is simply too lovely. I'd love to code demos in C#.

Have I understood it correctly that IL2CPP converts code from the intermediate language into C++ source code? If so, this is certainly a highly useful tool. It would allow to create a demo using C# and then have it processed into a native Windows executable.

projektbezeichnung.Projektbeschreibung ..? \o/

Then do it :)

Someone needs to do the groundwork. Alas, there is *a lot* of it.
But yes, that would be nice.

ferris: MSIL bytecode itself isn't too verbose, and the encoding is very simple (one- or two-byte instruction, plus optional literal/mdref argument), so kkrunchy- or squishy-style compression would be very effective. It wouldn't be worth it to reinvent a new encoding, though (except maybe replace some opcodes by others to decrease the entropy a bit, eg. using one variant of the ldc opcodes, and removing useless opcode prefixes). Also the C# compiler doesn't emit all possible opcodes, but those are actually useful for some hacks.

However, I think the metadata tables eat quite a bit of space, as they have quite a bit of redundant and/or useless information stored in various ways (huge ints, UTF-8 strings, UTF-16 strings, and some data is just random blobs, see part II and III of the standard). As one row is needed for every external 'symbol' (type/method/field/...) used AND for every internal type/method/field/... defined, these can grow quite large. So investing some time in this (by eg. trying to come up with a representation that isn't all over the place) will also be needed. (However, if these are stored in a nonstandard way, a decoder will be needed, which might have to be .NET code which would be readable by the runtime.. i.e. more fun! There's lots of stuff that can probably be thrown out while keeping the runtime happy, though. Also 'optimization' passes like lifting nested classes out of their parent class, erasing enum types to ints, etc. will be useful as well here.)

Adok: as I said, using IL2CPP (or variants) isn't very interesting. Logicoma etc. make 64k using rust, but as it's native code, it isn't that interesting. .NET bytecode is a completely different target platform. Also I don't care about programming language tastes (or at least not in this thread). Plus, compiling to native code means I will hate you because it won't run on Linux without any good reasons :)

And if you want to make a C# demo, you don't have to wait for anyone.

Zavie: I would do it... if I had the time, and if I didn't have so many projects/ideas for projects already. Though if other people have the same sentiment, I can always offer some help.

porocyon: would it run on linux anyway as soon we start getting some graphics on screen?
And ofcourse especially not as soon as we pinvoke win32/directx/opengl to get gpu access (whoever requires the the fewer calls to wrap)

We could also just make the obvious 4k .net intro about it: GreyScreenOnWinForms.exe

adok is right! ;) (did i really just say that? again?)
We all love C#! I´d love to code my demoscene-shit in C#...but this will never get ==true! sadly! :(

What library would you use for drawing primitives in C#? I use MonoGame for my gamedev projects, which includes SharpDX. Yet I have tried and failed to draw a simple rectangle. For my gamedev projects I use sprites so I never run into the problem of drawing primitives.

Adok: There is lots of wrappers for OpenGL
https://www.khronos.org/opengl/wiki/Language_bindings#C.23

I work on a NetPacker, I can now found unless methods and I remove ILCode.
When project will been more advanced, I'll shared It on GitHub.

psycho: you'll probably have to tell the runtime to load stuff from those DLLs, yes (and maybe GetProcAddress<->dlsym), but there are standard ways to tell the runtime to use different ones depending on the OS, while using a native-code unpacker will require it to be recompiled for every OS, and it'll probably have to muck around with either mscoree.dll or libmono*.so.

Adok: MonoGame or FNA should be ok, but drawing stuff via the GPU (called "primitives" by these libs for some reason) requires some iteration to get to work, but that's because of how GPUs and low-level graphics APIs work.

fxgen: interesting, I'll probably have a look then :)

C# is really nice language. I would love to see some neat 64K intros done with it.
What is the main goal here : to produce a x86/x64 executable non dependent of CLR ? (it would contain no IL at all, just plain asm instructions with some Win32/OpenGL/DX API calls) or to produce a regular .NET executable, but with metadata stripped as much as possible to make it small?

Mine at least is the latter, it sounds like a much more interesting challenge.

Code one yourself? Making a basic synthesizer isn't hard if you're willing to put in a couple of hours.

Does soundtracker editor with synthesis sound exist ?