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).
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).
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.
Navis: it's indeed how I made my first PC prods :D
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.
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.
For the third time, go make a goddamn demo with it and prove that it doesn't suck.
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.
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.
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.
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
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
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!
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!
(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...
("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...
why does immediate mode get so much shit? I think it is brilliant!
@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.
Midi controllers are great, indeed! Have one here although never experimented coding anything around it.
But yes, cool tools.
But yes, cool tools.
I find it kinda funny that this evolved into my demosystem is bigger and better than yours. Sigh. :)
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.
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.
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...
I always used immediate mode in my prods. I have never coded a shader.
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!
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.
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.
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.
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.
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.
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).
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.
(might contain bugs)
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)
Yeh, contains bug. Should be:
Code:
int elapsed = lastFrameTime - currentTime;
FFS. currentTime - lastFrameTime.