pouët.net

Hey, newbie in demo coding here, are there any good resources for making windows/linux demos with OpenGL that can be at a reasonable size?

Now on linux, I have sorta gotten smaller programs (24kb), but they rely on the user having alot of libraries installed, I would want the stuff to all be in the program, or use as few libraries as possible, any good starting points?

There's a comprehensive collection of resources for 4k intro development at in4k.

I have one of my windows 4k intros on GitHub: linky

For real fun, go oldskool.

I do plan to do C64 later down the line, but I am more interested in 3D stuff, also those resources dont cover linux, sadly.

Im seeing how compressed I can get a 3D engine on Linux using SDL2 + freeglut.

Not a smart idea, I think, but I can have the linux executable under 64kb at the very least.

As already stated here, for Windows Crinkler is the way to go. If you are looking for a possibility to make intros on Linux, I have two possible directions for you:

1. Use smol together with oneKpaq. It should work pretty well and the exe gfx made by blackle are a good starting point.

2. If you are willing to experiment a little bit, we (epoqe) are taking an approach very similar to Crinkler for Linux. This project in going on for some time now and the worst bugs are fixed. I guess future changes will bring the sizes closer to what Crinkler does, but we are talking about only 100 bytes difference here roughly. On top of this we have a small intro build system and a code template to get a project started. Feel free message me on Discord (see my profile), I'll be happy to show you the setup :D.

For Linux materials, check out...
https://in4k.github.io/wiki/linux

and possibly there was more about it on this thread:
https://www.pouet.net/topic.php?which=12187&page=1#c573339

I don't see 4k being mentioned as an explicit constraint anywhere..?

The desire to release a single executable or 'runnable' affects the size majorly. Detailed post.

Which programming languages do you prefer? This affects how greatly you understand the functioning of your code (and is the greatest factor of enjoying coding and having fun exploring and creating).

Many scripted or bytecode languages can interface with all 3 APIs. They derive a great benefit from libraries and frameworks supporting 3D cards, as well as shader languages. This saves 99+% of code size - depending on what you are doing. Wrappers and helpers abound on GitHub.

OpenGL is completely abandoned and unsupported since quite a few years. It still runs, so you can have fun with it and run experiments and maybe find an effect that isn't completely complicit with GPU gaming developments past 2 decades. It can then be novel, otherwise not.

Vulkan gives finer control over rendering pipeline and so performance than any of the 3 APIs. By this, it has a greater potential for a possible new effects than OpenGL (and alternatives). It has replaced OGL and offers newer shading languages aside GLSL (again, this implies complicity with GPU X). BeRo has a Youtube channel featuring Vulkan. :)

Even though Vulkan is the only cutting edge API, it usually requires more code (inside your release, that is!) even for non-cutting edge stuff in your release for compiled languages. To support this cutting edge, the Demoscene could develop something JVM-like for Linux and Windows as an accepted release platform.

If you want to stick to OpenGL, the traditional way is cpp+makefile+text editor on Linux, the Windows port can need attention to fit.

In no way can I recommend cpp (nor obviously Rust) as compiled languages for size over e.g. Javascript/Java/Python. There is such great support for the latter.

Performance depends on implementation (and actual machine used to record the Youtube video), but the script or bytecode can be run anywhere and rely on these existing interfaces, frameworks, and engines developed over the past 2 decades to require minor patching and give a much greater size reduction.

Okay, first of all I want to stress what ferris said, it all depends on the specific size (and maybe compo at a party) you are targeting. Smol+oneKpaq as well our toolchain targets executables <= 4k and maybe <= 8k. I cannot say much about 64k though.

I disagree that compiled languages are not preferable for size, but more importantly they are not allowed for most size-limited compos, if you wish to participate. Ubuntu with nothing but graphics driver installed seems to be the most common choice.

Yeah I might be able to kinda get away with freeglut/sdl2 and stuff with the user needing to install the libraries needed through sudo apt.

Should work, but the Windows versions would be bigger, if I make any Windows version.

Sorry, i just realised that this sentence was poorly worded. I wanted to say that installing extra packages might not be allowed, so compiled executables linked to libraries, which are installed by default, are the way to go for the categories mentioned.

The packages would be freeglut and sdl2, or just freeglut, which some applications ask for to begin with.

Its just more of a requirement for debug builds of apps before the developer puts the library into the executable.

It seems this golden piece has not been linked yet: http://www.sizecoding.org/wiki/Main_Page

I'd personally not use sdl2 nor freeglut - you get an opengl context using XLib with not too much calls (which you can also use for any resolution selectors). XLib is almost always available on fresh linux installs. You can do sound with libasound, which should also be there by default.

you can load opengl extensions by yourself for the smaller sizes (using dlopen and dlsym).

But only my two cents on this :) you go ahead & make your own experiences, its loads of fun!

*mumble* *mumble* :)

I remember using OldSkoolDemoMaker many moons ago lmao