pouët.net

Go to bottom

DemoSystem - A simple demo framework

category: code [glöplog]
All of our demos pre 2018 (from 2001 onwards) started life as:

https://nehe.gamedev.net/tutorial/your_first_polygon/13002/

With immediate modes, if/then gotos, memory leaks and what not. And kind of still run (- if not, that's shader errors).
added on the 2023-01-25 17:13:47 by Navis Navis
Quote:
This is, and I agree, boilerplate code, but at least is a practical place to start.

No, it is an absolutely horrid place to start, unless you very quickly want to hit a dead end. You didn't read anything we wrote, _especially_ the part where you're supposed to make a demo FIRST and _then_ teach others what you learned.
added on the 2023-01-25 17:56:33 by Gargaj Gargaj
Navis: it's indeed how I made my first PC prods :D
added on the 2023-01-25 18:06:42 by keops keops
Gargaj: I read everything you wrote. With some stuff I agree, with other I don't. You don't like it due to the way it's written, I get it. But please, don't make it appear as if it is the worst possible thing out there, scaring off everyone wanting to give it a try.
added on the 2023-01-25 18:11:02 by Defiance Defiance
I don't know if it's the worst thing ever, but it's outdated, it's horribly written, it shows a lack of understanding, and in general it's bad enough that scaring people off it is a net positive. (Except maybe as a cautionary tale.)

For the third time, go make a goddamn demo with it and prove that it doesn't suck.
added on the 2023-01-25 18:17:34 by Gargaj Gargaj
Quote:
All of our demos pre 2018 (from 2001 onwards) started life as:

https://nehe.gamedev.net/tutorial/your_first_polygon/13002/

With immediate modes, if/then gotos, memory leaks and what not. And kind of still run (- if not, that's shader errors).


sorry to derail the framework bashing but kinda related:

I tried a few ASD Demos recently (new gfx card and all) but sadly almost all of them have some minor or major (shader-)glitches :(. I know they ran fine back in the day and all but any chance on making them more "future proof" so in a few years youtube captures wont be all thats left?

Of course I have just my own system with win11 and latest drivers for my 4070 to test on but its still sad.
added on the 2023-01-25 18:45:03 by wysiwtf wysiwtf
and dont get me started on WQHD compatability. from all the demos ive tried more of them didnt work than did.

I mean its completely ok if a demo is optimized for 720 or 1080p and doesnt scale right with anything else, but having those resolutions still show up in the config window beforehand, probably even defaulting to the desktop resolution doesnt really help here.
added on the 2023-01-25 18:47:35 by wysiwtf wysiwtf
ASD prods are top notch. I also dig the fact that Navis coded most (all?) them bare hands, which is one of the main aspects I appreciate in the demoscene and similar diy communities.

Similar to the rising of ready to use 3D engines, I have experimented similar phenomenon in remotely controlled (rc) hobby. There, we used to get many electronic components and build quadcopters and planes almost from scratch -- also tinkering with flight controller code. It was very exciting to learn while we crashed things.

Then DJI and others came and started producing professional rc which, while undeniably awesome (I own some of them), basically killed the hobbyist aspect of it. RC forums are now dominated by people who don't know what is positive or negative, have no idea how a flight controller works, and technical discussions are now basically non existent.

I am not against evolution, I love it. But... something smells wrong to me when it reaches diy circles.

That is just me, so, that's ok then.

"Hard times create strong men. Strong men create good times. Good times create weak men. And, weak men create hard times."

G. Michael Hopf
added on the 2023-01-25 19:26:06 by imerso imerso
I m going through a process of evaluating the post glsl shader era demos to work out why the heck they glitch on modern cards. Usually you get warnings and errors and only takes one shader to mess it up. I have nvidia hardware so will try these with the latest drivers (assuming I find the original codes somewhere).

Regarding demomaking I had a great discovery recently which makes things a lot easier (* for those still hardcoding, so this is not for unreal or notch users): midi controllers. Massive aiding tools!
added on the 2023-01-25 20:32:00 by Navis Navis
(extremely energetic female voice-over) Please follow us next week when Gargaj, of Conspiracy fame, will get "conspiracied" by Defiance with his new, advanced "immediate mode opengl 1.1 demo" which will rock Pouet like it's 2003 again !

("Pouet The Anime" Ending starts) slideshow of old computers displaying green C: prompts, green rotating wireframe cubes on black screens, with super enthusiastic 8bit remix of 4-Mat and Willbe by Byproduct, kanjis scrolling on the right, shots of matrices filled with cos, sin, and even (gasp !) tan values...
added on the 2023-01-25 20:41:51 by TomS4wy3R TomS4wy3R
why does immediate mode get so much shit? I think it is brilliant!
added on the 2023-01-25 20:47:25 by Navis Navis
@Navis : I do too ! :D It's VERY useful, I was just making fun of... everything, really. Not of something in particular. I'm a big ASD fan, btw. Always have been.
added on the 2023-01-25 20:53:47 by TomS4wy3R TomS4wy3R
Midi controllers are great, indeed! Have one here although never experimented coding anything around it.

But yes, cool tools.
added on the 2023-01-25 21:16:29 by imerso imerso
I find it kinda funny that this evolved into my demosystem is bigger and better than yours. Sigh. :)
added on the 2023-01-25 21:22:35 by Defiance Defiance
Toms: thanks.
I always loved immediate mode and opengl, you can do simple things quickly. It's good enough for a few 100ks of triangles (and who needs more than that hey..). And definitely good enough for an "impromptu" small particle system with billboards. Or just a starfield:

for (int t=0;t<1000;t++) {
glBegin (GL_POINTS);

glVertex (rand()%100, rand()%100, (rand()+time)%100);

glEnd();
}



Midi controllers are great because they have separate focus to keyboard, so you can adjust values while running through the shader code on editor, WHILE the demo is running.
added on the 2023-01-25 21:22:55 by Navis Navis
I also think OpenGL immediate mode is easy and quick to use! Then on the other hand I haven't released any PC demo since 2002...
added on the 2023-01-25 21:23:16 by Sdw Sdw
I always used immediate mode in my prods. I have never coded a shader.
added on the 2023-01-26 07:50:53 by Adok Adok
Quote:
I also dig the fact that Navis coded most (all?) them bare hands

Wait. Has everybody else been doing it wrong all the time? Should we be using chopsticks? Should we be wearing gloves?! I NEED TO KNOW.

Fuck this. I’m buying coding gloves now. That way, when shit gets tough, they can come off!
added on the 2023-01-26 09:20:05 by Bombe Bombe
When doing engines for DirectX, one of the first things I've always done was to implement a vertex-streamer class, basically giving me the OpenGL-style immediate mode rendering. It's excellent for simple one-off things like post-processing rectangles, or some debug-rendering etc.

I wouldn't base my whole engine based on it, though.

That being said, not that many years ago, I was researching efficient vertex submission for an employer. In the end, at least on NVIDIA hardware, we were unable to beat immediate mode + display lists. The NVIDIA driver just does an amazing amount of optimizations under the hood that you can't realistically match with more explicit API usage.
added on the 2023-01-26 10:55:59 by kusma kusma
The problem with display lists seems to be that they take some (?) time to compile. This is my only regret, otherwise I use them very often.
added on the 2023-01-26 10:57:42 by Navis Navis
Yes, they do. It's really only something you want to use if you're going to repeat them over and over again, because they move a lot of processing from run-time to init-time.

Display lists have a kinda janky API, for some historical reasons. They're far from perfect, but it's one of those things that can still be surprisingly useful.
added on the 2023-01-26 13:13:00 by kusma kusma
There are many interesting points made here I want to address, hope this doesn't turn into a rant. First, implementing support for pixel shaders and .obj model/.jpg image loading is high on my todo list. Second, I agree that nvidia and ryzen/amd hardware seem to kinda treat shaders differently each other and also vastly different from older models to newer ones. So a shader that worked say back in an nvidia card from 2008 may look broken nowadays on a machine with nvidia for no reason. Also, yeah this was coded on machines with nvidia cards and works pretty flawlessly (also tested on other machines with intel/ryzen with no issues), I agree with kusma on the optimizations the nvidia driver brings to the table. Finally, two more minor issues, in the GetAsyncKeyState func when I calced the 'correct' bit the exit key was working but the function was trying to detect if it was pressed constantly (so the user had to press ESC constantly to exit), calcing the 'wrong' bit made it detect a single key press. In the frame limiter, couldn't find a better way to avoid a Sleep func and ended up with the 'busy spinning', hope implementing shaders will fix this as well (correct me if I am wrong on this one).
added on the 2023-01-26 16:37:42 by Defiance Defiance
For simple frameskipping, pick a framerate you like (I use 100 FPS). Every frame poll the timer of your choice (timeGetTime() is good enough to start with). Measure time between this frame and the last. Figure out how many updates you need to run. Run those updates.

Code: int accumulatedTime = 0; int FRAME_TIME = 10; //10 milliseconds for 100FPS int MAX_UPDATES_PER_FRAME = 100; //lower cap of 1 FPS ... void update() { int currentTime = timeGetTime(); int elapsed = lastFrameTime - currentTime; accumulatedTime += elapsed; //run one or more logic updates if needed int updates = 0; while (accumulatedTime >= FRAME_TIME) { updateLogic(); accumulatedTime -= FRAME_TIME; updates++; //if update or rendering is very slow, frames will accumulate //and this will lead into an infinite loop. So bail out //if this happens. It will screw up the timing but it won't //crash if (updates > MAX_UPDATES_PER_FRAME) break; } lastFrameTime = currentTime; }


(might contain bugs)
added on the 2023-01-26 17:02:23 by Preacher Preacher
Yeh, contains bug. Should be:

Code: int elapsed = lastFrameTime - currentTime;
added on the 2023-01-26 17:03:20 by Preacher Preacher
FFS. currentTime - lastFrameTime.
added on the 2023-01-26 17:03:39 by Preacher Preacher

login

Go to top