pouët.net

First of all, that's a pretty obvious observation, not really a "narrative".

Second, you accused me of "pushing my narrative", yet you're the one making factual claims, and refusing to back up your claim when asked. So no, the "pushing of a narrative" seems to really happen on the other side of the argument here.

It's really sad to see that we've come to the point where criticism of admin behaviour is met with attempts at gaslighting from other admins.

have a nice day kusma :)

I'm just another bystander, but FWIW it seemed like he was banned for repeatedly spamming his hello world project, and not for "disagreeing with Gargaj". Speaking of gaslighting, it probably didn't help that he wrote off the criticism from multiple people as a borderline conspiracy.

what absence said with the addition that he'd negatively derail the initial thread with arguing that the others are wrong and he's right which is NOT a nice thing to do in a thread that's pretty much 'hello, i am new to the demoscene, i need some help plz'. kinda like what you folks are doing right now! (hint) :D

@absence: I guess I just don't get why promoting a demoscene project on a demoscene forum is a problem in the first place. And even if that somehow is a problem, I don't see any warnings given about it, just discussion (and disagreement).

Does the user seem a bit disillusioned and overly enthusiastic about their project? Sure. But that's not a good reason for banning, is it?

Maybe not, but I don't read this situation as someone getting banned for being disillusioned and overly enthusiastic.

Lol, absence and post malone aka Maali *kunserned* about topics getting derailed.

am not, just explaining what went on. but nice try!

Reading comprehension is hard...

i recently figured out that people are automagically always right when they only read their own arguments yeah :P

@havoc: you are a mod. you know what they say about opinions :D

Defiance: I've never baked a cake, but here is a starting point for a chocolate cake.
Gargaj: Do not use that recipe. The recipe is missing key ingredients such as chocolate and 2 hours in the oven is too long.
Defiance: But it is a good place to start.

KisanoWasTaken: I want to bake a strawberry cheesecake.
Defiance: Take a look at my chocolate cake recipe.
Gargaj: No!
Defiance: Do not listen to Gargaj, he didn't like the layout of my recipe.

Well done helping Kisano, everyone!

Gotta love how this place never disappoint for its ability to go in record time from a new comer's question to multilayered drama between old timers.

Kudos also to the smartasses who add just as little value as the people they criticize \o/

I'm still depressed there isn't a 0-to-deferred renderer tutorial with OpenGL DSA. The bindful model made GL by far the hardest API for me to learn. So many friends gave up on gfx coding because of it and it's totally understandable.

I think GL DSA is pretty much perfect (outside of not receiving new features). Very easy to understand and i have been teaching it to friends just to avoid the pain of the enormous amount of historical baggage in GL. I spent 6 months all day writing vulkan and have a bunch of WebGPU apps (e.g. my painting app), but GL just leads to most fun and productivity.

Even though GL DSA is great, just because of the lack of resources, I'd never recommend people to learn GL if they don't have friends to help out. So what's left?

WebGL has less functions - it's easier to get into, but you have less features and the insane global state machine.
WebGPU is more sane in terms of API, but leads beginners to think they should engineer their whole engine around pipelines and descriptors. Also not as fun as GL.
Vulkan/DX12 are structured very similarly to WebGPU, which also leads to bad practices if no experience with other API. But most importantly are a gigantic time sink. Not just verbose but super hard to code correctly (extensions, sequels to extensions, layout transitions, sync... also no uniforms in Vulkan)
High level abstractions like raylib/processing/etc - get the job done, but you are tied to their way of doing things and have less control.

My point is - we should use 3dfx Glide.

Isn't that also true for OpenGL? From your description of Vulkan and DX12, it sounds like you don't really want the control.

@absence, The only thing you get with VK/DX12 is features that were never added to OpenGL, *after* it was deprecated. But if you disregard that, if you accept you are not getting the newest shiniest things, you can do the exact same thing in GL as you would in VK/DX12. The difference is in VK/DX12 you have to pretend to be a driver and being a driver does not involve fun lower level hardware stuff. It involves abstract bullshit like descriptors and pipelines. VK/DX12 are not hardware APIs, they are triangle drawing APIs.

Will VK/DX12 be faster? Well they do not force you to do data driven design, GPU driven rendering and multidrawindirect (which you can do in GL...). Will they be faster because of information about dependencies between resources? OpenGL already has almost all of this information. Disregarding that - judging by nsight and my personal profiling - it's a negligible difference whether you do hard barriers between passes or not.

The useful control you get in dx12/vk is over memory sync/allocation - but is it worth it? You need to invest your whole life into battling a graphics API instead of making art for some *potential* perf gain. The other useful thing is bindless images/buffers, but OpenGL already has bindless images as core and my buffers use the NV extension.

OpenGL offers plenty of control for when you want to draw triangles on the screen, which demos seem to do sometimes I think.

I agree the GL 4.6 endgame (including DSA, separate samplers, etc.) is much nicer than what came before it; unfortunately, it never came to macOS, which is stuck on 4.1.

The thing that I'm mainly annoyed with is drawcall overhead. Not because I want to make more calls, but because I want to use the CPU on the UI thread for other stuff :-)

@Sesse you have the possibility to use multithreading by rendering into a framebuffer in another thread with a linked OpenGL context and then the main thread only needs to copy it to the screen.

Yeah, I know, but it's an utter pain. One of my programs has like 20 GL contexts for different uses and threads and stuff :-( And copies are definitely not free either (I want to work on laptop, in settings with limited memory bandwidth).

Sorry for the late reply about this (I'm rarely able to make too much time), but when I ran CMake and used Mingw32-make, all I got were a bunch of undefined references to different things. All of the references were to things that either started with "__imp_" or with "Dwm". When I opened VSCode to see what the problem was, I saw that the main.cpp file had 13 errors. Please explain what is going as if I was a complete newbie to C/C++ (because I am)

Please provide a bit more context - what were you trying to compile, how did you set it up, what the errors were specifically?

I just "git clone --recurse-submodules"'d the repo, then "git submodule update --init"'d it for good measure. I ran CMake GUI under the Mingw32-make build system. When I tried using the command Mingw32-make, I got a wall of errors. Here's one sample:
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: external/crosswindow/libCrossWindow.a(Win32Window.cpp.obj):Win32Window.cp:(.text+0x6e1): undefined reference to `DwmExtendFrameIntoClientArea'

mingw32-make[2]: *** [CMakeFiles\OpenGLSeed.dir\build.make:136: bin/OpenGLSeed.exe] Error 1
mingw32-make[1]: *** [CMakeFiles\Makefile2:155: CMakeFiles/OpenGLSeed.dir/all] Error 2
mingw32-make: *** [Makefile:90: all] Error 2

Which repo please? :)