pouët.net

I think this deserves its own thread, so that people can find it easier, give feedback, etc.

DemoSystem is a simple demo framework for everyone to use. In case you are in the beginning and don't know where to start or you want to quickly put some stuff on the screen and don't know how, this gives a good head start. It uses GLFW + BASS and is entirely written in C++ so that you can modify it as you see fit.

download link (Build 20220507)

demozoo page

Have fun! :-)

I would highly caution anyone trying to use this, it's some of the worst code I've seen.

Everything is in globals, all variable names are flat lowercase, the indentation is all over the place, there's an arbitrary mix of C and C++/STL use of variables, some of the macros are resolved into literals (in GetAsyncKeyState, which then tests the wrong bit), the framerate limiter just busyspins the window (also, 50hz? on a PC?) and it uses immediate mode fixed-function OpenGL which is SEVERAL generations behind on technology, etc etc, I could go on.

The world is full with great OpenGL tutorials; this instead will actively establish bad coding practices.

Like, maybe make a few demos first before you make demosystems for others. It'd clue you in on what you're doing wrong.

Cool idea to release it - here my cents:
* Consider using CMake or the like as build system, not CodeBlocks project files. Then people can choose their favorite IDE & compiler for working on the project and aren't restrained to Code::Blocks and MinGW (which you're using appearantly).
* Don't release object files.
* Give YAML a try as config file format. It makes reading (as in editing by hand) and parsing really easy :)
* The libraries you use have a license, for example glfw, you should include that into the archive if you package binaries & headers.
* You want to use a much more readable code style - I can recommend this article on the matter :)
* Maybe you could bring your project to https://github.com/ for easier sharing & maintenance (are you using git already? If not, you definitely should!)
* Also what Gargaj said.

did you get chatgpt drunk and then generated it?

Maali, it's about as good as your code, so maybe pump the brakes.

Can I nominate it for Meteoriks? :>

nah, i use a drunk tabnine so it's better

friendly code review is friendly!

“Tell me you have never used YAML without telling me you have never used YAML.”

Holy crap, YAML is one of the worst “human- and machine-readable” formats that I have ever seen and had the displeasure of being forced to work with. Ask a Norwegian.

I use yaml as config file format in my own engine. It has several advantages:
* trivial grammar. parsers available everywhere.
* if you need validation, json schema works, as the subset I use is equivalent and converted easily.
* YAML has comments, JSON doesn't.

But I'm open to suggestions. I have used RON before (which lacks parsers in many languages and has a nontrivial grammar), JSON (lacks comments), INI (lacks typing)

oh and of course xml, which is exactly what you dont't want when you think of "editable in a text editor without pain".

My ideal "small" demo framework would have (apart from opening a window):

Easy way to make a new "part" (with init/render functions to be made by the user)
Functions for timing, input control (including midi), loading simple resources (jpgs / .objs)
Some wrapping of commonly used things in Opengl like shaders and VBOs
Some math classes

As a side note, try to compartmentalize functionality and don't use global variables. The framework is not useable as is.

Literally nothing about YAML’s grammar is trivial. The YAML specs are longer than the XML specs (!) and that alone should tell you that there is definitely no triviality involved.

Parsers may be available “everywhere” but parsing still is an adventure that you simply don’t want to undertake:

country: de – easy peasy, right?
country: fr – trivial, right?
country: no – how about now? Nope, this is now “false.”

offset: 04 – yes.
offset: 09 – nope, numbers starting with 0 are parsed as octal.

There’s valid constructs in YAML that e.g. Ruby parsers can parse, Python parsers cannot.

YAML can contain code that gets executed when parsing. Totally the best idea!

There are many more things that are completely fucked in YAML, I could go on for quite a while but you get the picture. I also don’t care what you use but do not go around telling people YAML is trivial. It is anything but.

Not to interrupt the crusade or anything but why does a demo system need config loading and especially saving in the first place? Generally you're not allowed to permanently write on the HDD - anyone who ever made a demo knows that.

😡 This crusade is important!

yaml, xml, cfg? Meh... all raw binary ftw!

...just load it all to RAM and start the demo! ;)

ok, I understand your crusade better now.



country: "no" seems like the most natural solution to this. I'd quote string literal values in general.



09 is not even a valid octal number. IIRC, 0o prefixes are used for octal. Might be a parser bug of the specific parser you used? The spec indicates this.

the grammar size is a wrong claim from me, it's huge, but then again, you're not forced to use all features of the language. You can use a sensible subset (and the subset I have in mind when typing this has a trivial grammar).

I'm curious tho, which config file format are you using? Might be suited better for my applications as well

You can't apply line based version control to it that easily (you'd need to write a diff- and merge tool), also it's not exactly humanly readable (you'd have to write an editor). That's really a heap of boilerplate just for saving some flags, filenames and render graph setups.

What is wrong with a text config that goes like:

Fullscreen: 0
AA: 2

(can't think of anything else really, it's probably 5-6 things you need for a demo, if nothing at all - why not just ask the user at the beginning).

navis: what you write is valid yaml :) that's what I mean with yaml subset.
I'd personally add arrays, tree-like structure (by indentation) and string literals. That's it.

hm but do you need arrays and trees etc. for a demo config? what other uses would there be... (talking about demos always). But the pointer to YAML (didn't know of it) is a good reference anyway

Wow, did not expect such feedback! Even though it's sharp, I do accept it, and I'll do keep it in mind next time this gets updated. This project started mostly because back in the days I did not have a framework to start with, mostly tutorials which could not help me at least. Newcomers came and went and I pointed them to OpenGL tutorials only to confuse/disappoint them even more, etc, etc. This is, and I agree, boilerplate code, but at least is a practical place to start. Also the config is mostly for dev purposes and that's why it's closed by default. Peace. :)

If you write the parser yourself instead of using a library, the scope quickly becomes more sensible than YAML...