Vulkan game engine

[jdc]

Shaw a guy posting the vulkan on a comment.

For high graphics performance they say they out performe open gl in most if not all aspects.

Baldurs Gate 3 have brutal graphics in what seems a open source option or at least free?

https://store.steampowered.com/app/1086 ... rs_Gate_3/

Don't know how performe goes in the SDK, things like unity3d is extremly slow for old hardware. If you looking for retro stuff ray lib and pure C is probably better since vulkan is in C++ will not have that high performance. Still they claim that is faster because they use the hardware better then openGl still the language not the most optmizised it still out perform.

https://www.vulkan.org/learn#videos

[freem]

For a start, C++ can outperform C in many aspects. A typical example of this is the comparison between qsort and std::sort. C qsort is slower because it uses a callback, where C++ std::sort uses templates, which allows for much more compile-time optimizations.
In the past, C++ had worst performances than C, because compilers were not as mature, but I do not think there's still such a big difference nowadays (if any).

The only place where C can arguably beat C++ is on micro-controllers with very, very little ROM (something about several dozens of kilobytes) because C++ requires one more step to initialise programs, which requires some storage (not much, but then sometimes storage is very precious). With bigger ROM storage, you're likely to be willing to disable some C++ features like RTTI or exceptions, too, but this is frequently done in video games anyway (and is perfectly standard thing in C++).

Now, about vulkan. Vulkan requires support from the drivers, otherwise it will go through a layer that translates it to GLSL, so on old hardware, openGL will outperform vulkan.
On hardware that supports vulkan, yes, vulkan will outperform openGL because it does more low level stuff. It's also more complicated to use and requires more code to setup things.

As for baldur's gate 3, it is not FOSS at all, as written in the licence you can read from steam.

[bzt]

For a start, C++ can outperform C in many aspects.

Do you have any proof of that? Links to measurements, etc? Because all the cool guys thinks otherwise (Stallman, Linus, ESR, etc.). Hell, even it's creator, Stroustrup admitted in an interview, that C++ supposed to be a joke.

{l Code}: {l Select All Code}

Stroustrup: Well, it’s been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it’s taken them a lot longer than I thought it would.

Said the creator of C++...

A typical example of this is the comparison between qsort and std::sort. C qsort is slower because it uses a callback, where C++ std::sort uses templates, which allows for much more compile-time optimizations.

Not true. Okay might be true in some special edge cases, but not for your example for sure. As long as sort concerned, there's only one comparator call needed, and both C and C++ compilers are capable to inline that. On the other hand using templates in C++ involves an additional abstraction layer with virtual method calls, while in C that's just a simple function call like any other.

In the past, C++ had worst performances than C, because compilers were not as mature, but I do not think there's still such a big difference nowadays (if any).

And I'm pretty sure there is. The most common problem with C++ that it is OOP, meaning it is pretty heavy on memory allocation, calling new and delete all the time, repeatedly. No C++ compilers can eliminate that handycap, but it return since the language extremely poorly designed, C++ compilers are unbelievably SLOOOOOOOOOW... (there are some optimizations in the allocators, not in the compiler to mitigate that unavoidable OOP handycap. See jemalloc for example, it is anything but simple.)

In short, I can do lot more rapid prototyping and development cycles with C, as the compiler is about 100x times faster... And the result is always a smaller and faster binary. Not to mention that debugging native code generated from C is easy and straightforward, while debugging C++ code is a major PITA, and not just because of the name mangling. I've done that for years, I know what I'm talking about.

The only place where C can arguably beat C++ is on micro-controllers

Challenge accepted! Please write any C++ code for desktop, show me the code and I guarantee that I can write a counterpart in C which will compile much faster and will run and perform much faster than your C++ version. Come on, it's going to be fun! Let's do measurements for evidence.

Cheers,
bzt

[bzt]

Okay, just for the fun of it, I've did the measurements for your sort example (used the source C++ code here as-is, I've just removed variations, leaving the default operator), and implemented it in C too.

TL;DR: the C version is better in all metrics, and the C++ output isn't even correct!!!

The data set was the same for both code (here reduced, but you can find the entire data set in the attachment):

{l Code}: {l Select All Code}

#include <algorithm>
#include <functional>
#include <array>
#include <iostream>
#include <string_view>
 
int main()
{
    std::array<int, 10000> s = {5100,1324,4556,2001,8619,545,3952,9570,6956,...753,3130,2604,5276};
 
    auto print = [&s](std::string_view const rem) {
        for (auto a : s) {
            std::cout << a << ' ';
        }
        std::cout << ": " << rem << '\n';
    };
 
    std::sort(s.begin(), s.end());
    print("sorted with the default operator<");
}


and

{l Code}: {l Select All Code}

#include <stdio.h>
#include <stdlib.h>

#define LEN(a) (sizeof(a)/sizeof(a[0]))

int cmp(const void *a, const void *b) { return *((int*)a) - *((int*)b); }

int main(int argc, char **argv)
{
    int i, s[10000] = {5100,1324,4556,2001,8619,545,3952,9570,6956,...753,3130,2604,5276};

    qsort(s, LEN(s), sizeof(int), cmp);

    for(i = 0; i < LEN(s); i++)
        printf("%d ", i);
    printf(": sorted qith C qsort\n");
}


One can easily argue that except for the "cmp" function, the C version is much more readable, but let's just put that aside for a moment.

Here are the results:

{l Code}: {l Select All Code}

$ time gcc sort.c -o sortc

real   0m0.077s
user   0m0.056s
sys   0m0.019s

$ time g++ sort.cpp -o sortcpp

real   0m0.478s
user   0m0.417s
sys   0m0.055s


So compiling the C version was about 5 times faster than compiling the C++ version. And this was just a plainfully simple code, imagine what difference that makes for a large project...

What about binary size?

{l Code}: {l Select All Code}

$ du -h sortc sortcpp
60K   sortc
72K   sortcpp


Yeah, that figures, the C++ version is considerably bigger, even for this extremely simple example.

And running it:

{l Code}: {l Select All Code}

$ (time ./sortc) &>sortc.txt
$ cat sortc.txt | grep real
real   0m0.005s
$ (time ./sortcpp) &>sortcpp.txt
$ cat sortcpp.txt | grep real
real   0m0.012s


So running the compiled binaries, it turns out that the C version is more than twice as fast.

But the funniest thing, the C++ code produced incorrect results. Seriously, I took an example code from cppreference.com, compiled it and it failed to sort an array properly!!! ROTFL!!!

Cheers,
bzt

[freem]

On the other hand using templates in C++ involves an additional abstraction layer with virtual method calls, while in C that's just a simple function call like any other

No. Templates are compile-time stuff, that have nothing to do with RTTI and OOP.

The most common problem with C++ that it is OOP, meaning it is pretty heavy on memory allocation, calling new and delete all the time, repeatedly.

This is the mark of bad C++ programming. Average skill C++ programmers don't realloc everytime they add elements to a vector... thankfully! (basically, instead of stupidly doing push_back in a for loop, just call reserve before that, and you'll eliminate a lot of realloc calls with all it's cost).

while debugging C++ code is a major PITA, and not just because of the name mangling

On this one, I agree, but by experience using LLVM's libc++ instead of the horrible GNU libstdc++ helps A LOT on the issue, they don't do one line functions that just calls other one-line functions, from files that mix tabs and space for indentation!



For sources, I've read more than one accross the internet, but you know how benchmarks are (very situational, does not shows much if anything of real life, etc, etc)... Here is one, though.
The remark about benchmarks obviously applies to the rest of this message.

Also, your example is *not* measuring only the difference between sort and qsort, as it includes I/O, notably from the shitty streambuf lib. You're also not using the same sort code in both cases, in one of them you rely on std::less, in the other one you do "a - b". One of the important differences here is this phrase, extracted from man-page:

If two members compare as equal, their order in the sorted array is undefined.

So your C code is basically going to trigger undefined behaviors (each time the values are equal, depending on the compiler, you will have different results, this is likely to explain the behavior difference you're talking about).
In this trivial case, those UB are only going to impact performance, but as long as you use qsort for more complex expressions it might have other implications.

The fact templates takes more time to compile is not a news, neither, but when I compare performances, I usually don't talk about how much time to compile, this is pretty irrelevant except for debugging purposes. This is usually only a problem when one uses boost, which is both widely loved and widely despised (I'm in the 2nd category. This bunch of libs is just over-engineering that will make easy to debug problems serious pains in your ass, not to mention infamous compile time... it does bring some interesting features, but I prefer to avoid it still, as many people).

Here is what I have with codes that really compares the langs and their features, instead of using the very ugly stream shit that nobody serious would use when in need of performances (despite this benchmark being pretty poor).
Data is generated on a linux box with:

{l Code}: {l Select All Code}

for i in $(seq 1 10000); do   od -A n -t d -N 4  /dev/urandom; done > /tmp/data


And injected & edited (to add ',' at end of lines) in source code (in my case, with vim, but any editor can do).

C code:

{l Code}: {l Select All Code}

#include <stdio.h>
#include <stdlib.h>

#define LEN(a) (sizeof(a)/sizeof(a[0]))
int cmp(const void *a, const void *b) { return *((int*)a) - *((int*)b); }

int main()
{
    int s[] = { /* data generated by urandom and inserted in source code */ };

    qsort(s, LEN(s), sizeof(int), cmp);

    for(int i = 0; i < LEN(s); i++)
        printf("%d ", i);
    printf("\n");
}


{l Code}: {l Select All Code}

% clang  test.c -o cc && time (for i in $( seq 1 10000 ); do ./cc > /dev/null; done)       
( for i in $( seq 1 10000 ); do; ./cc > /dev/null; done; )  17,82s user 2,74s system 102% cpu 20,075 total
% clang -Os test.c -o cc && time (for i in $( seq 1 10000 ); do ./cc > /dev/null; done) 
( for i in $( seq 1 10000 ); do; ./cc > /dev/null; done; )  15,47s user 2,88s system 102% cpu 17,874 total


{l Code}: {l Select All Code}

#include <algorithm>
#include <iterator>
#include <stdio.h>

int main()
{
   int s[] = { /* data generated by urandom and inserted in source code */ };
   std::sort( std::begin( s ), std::end( s ), []( int a, int b ){ return a < b; } );
   for( int i : s )
      printf("%d ", i);
   printf("\n");
}


{l Code}: {l Select All Code}

% clang++  test.cpp -o cpp && time (for i in $( seq 1 10000 ); do ./cpp > /dev/null; done)
( for i in $( seq 1 10000 ); do; ./cpp > /dev/null; done; )  25,15s user 4,61s system 101% cpu 29,278 total
% clang++ -Os test.cpp -o cpp && time (for i in $( seq 1 10000 ); do ./cpp > /dev/null; done) 
( for i in $( seq 1 10000 ); do; ./cpp > /dev/null; done; )  15,13s user 3,50s system 102% cpu 18,143 total


So, you're right, it seems a bit slower. Not twice, though. On my system, there's only 0.269s difference, which means the C++ version, which does not have UB (unlike C one) runs 1.5% slower (in -Os build). Fixing the UB in C code would slow it down a lot, as this involves a condition. Let's give it a try:

{l Code}: {l Select All Code}

#include <stdio.h>
#include <stdlib.h>

#define LEN(a) (sizeof(a)/sizeof(a[0]))
int cmp(const void *a, const void *b) { int ret = *((int*)a) - *((int*)b); return ret == 0 ? -1 : ret;  }

int main()
{
    int s[] = { /* data generated by urandom and inserted in source code */ };

    qsort(s, LEN(s), sizeof(int), cmp);

    for(int i = 0; i < LEN(s); i++)
        printf("%d ", i);
    printf("\n");
}


{l Code}: {l Select All Code}

% clang test.c -o cc && time (for i in $( seq 1 10000 ); do ./cc > /dev/null; done)   
( for i in $( seq 1 10000 ); do; ./cc > /dev/null; done; )  17,17s user 3,00s system 102% cpu 19,691 total
% clang -Os test.c -o cc && time (for i in $( seq 1 10000 ); do ./cc > /dev/null; done)     
( for i in $( seq 1 10000 ); do; ./cc > /dev/null; done; )  15,87s user 2,88s system 102% cpu 18,271 total


Now, we do have an inverted difference: C++ std::sort is faster (in -Os build) by 0.128s, which is 0.7%.

Those differences in time *are* negligible, but they show that, with a well defined behavior, C++ is indeed faster. It's also easier to read imo.

As for build times:

{l Code}: {l Select All Code}

% time clang -Os test.c
clang -Os test.c  0,06s user 0,00s system 99% cpu 0,068 total
% time clang++ -Os test.cpp
clang++ -Os test.cpp  0,31s user 0,02s system 99% cpu 0,335 total


As expected, C++ takes longer to compile.

[freem]

Oh, I'm missing one of the measurements, sorry!

Here is the binary size one:

{l Code}: {l Select All Code}

% clang++ -static -Os -fno-rtti -fno-exceptions test.cpp -o cpp && strip cpp
% clang -static -Os -fno-rtti -fno-exceptions test.c -o cc && strip cc       
% ls -lh cc cpp
ls -lh cc cpp
-rwxr-xr-x 1 ... ... 771K 11 oct.  11:34 cc
-rwxr-xr-x 1 ... ... 775K 11 oct.  11:34 cpp


Yes, C++'s binary is bigger indeed: by 4 kilobytes. That's 0.5%. We could do better and use muslC though, this would strip the binary sizes a lot
Of course here, I'm taking the real size of what is loaded into memory. Glibc IS a big bloatware, to the point that when dynamically allocated it will always consume ~600Kio for nothing, while static linking or dynamic linking with muslc will not do that, resulting in much smaller RSS (resident memory footprint, I'm not even talking about the VSZ).

[PeterX]

Hell, even it's creator, Stroustrup admitted in an interview, that C++ supposed to be a joke.

There at the link you gave it says it was a fake interview! But the mentioning of Stallman, Linus and ESR remains true. And the rest of critisizing C++ remains true, also.

Geetings
Peter

[bzt]

This is the mark of bad C++ programming. Average skill C++ programmers don't realloc everytime they add elements to a vector... thankfully!

First, constructor allocating memory and destructor freeing it is part of any OOP language, there's nothing you could do about it. Good programmer or bad programmer doesn't matter, you must use "new" one way or another with objects, no escape.
Second, adding elements to a vector involves realloc under the hood too...

My issue with so called "high level" languages exactly is this, important steps are now hidden from the programmer, so most of them don't even realize what's actually going on. I'm certain this is the primary reason why an average C++ programmer is writing a lot worse code than an average C programmer. Simply because a C programmer must pay attention, therefore they tend to write better code in general. (And more the language "helps", this just gets worse. Using Javascript efficiently is hard, but with jQuery it's almost impossible. It's not that jQuery isn't written properly, but because programmers can't see through the syntactic sugar so they tend to choose the worst inefficient solutions, just because the source code looking nicer... And the same about GC. Lazy programmers tend to not freeing memory, because why bother when there's a garbage collector, right? Yeah, just completely forgetting about performance and resource efficiency...)

Also, your example is *not* measuring only the difference between sort and qsort, as it includes I/O, notably from the shitty streambuf lib.

Both only printing to kernel buffered stdout, so I/O overhead should be the same. But okay, let's remove that print, I agree the results would be more accurate that way.

So your C code is basically going to trigger undefined behaviors

Absolutely not. People are too often and too quickly throwing in the phrase "UB".

So, you're right, it seems a bit slower. Not twice, though.

I've just copy'n'pasted the "time" output. It was twice as fast on my computer.

Fixing the UB in C code would slow it down a lot, as this involves a condition. Let's give it a try:

{l Code}: {l Select All Code}

int cmp(const void *a, const void *b) { int ret = *((int*)a) - *((int*)b); return ret == 0 ? -1 : ret;  }


First, there's no UB with the subtraction at all. Second, your code does have exactly the same subtraction, so if there really were an UB here, your code would have exactly the same UB too, you have fixed nothing (but you have introduced an unoptimizable trinary conditional and an additional stack local variable without any reason).

As expected, C++ takes longer to compile.

Which is one of the disadvantages of C++ that I hate the most. It not only kills productivity by having to wait for the computer, but also always derails my "creative mindset" (I don't know how to explain this, it's like having a flat tire around every other corner.)

Cheers,
bzt

[dulsi]

Languages are to enable building the program. I'm sure you can come up with scenarios where X is better than Y regardless of the value of X and Y. Just make games and leave the language tribalism to other sites.

Either way Baldur's Gate 3 is not open source. As for supporting old machines, they are always being left behind. Developers have limited time to optimize their code and at a certain point the game just can't run on old machines without completely changing the game. But there are also people creating new games for old consoles. If you want to use old computers, you can. Although you might not be able to access websites.

[PeterX]

Languages are to enable building the program. I'm sure you can come up with scenarios where X is better than Y regardless of the value of X and Y. Just make games and leave the language tribalism to other sites.

Yeah, true words. I think as @bzt about C++. As does Prof. emer. Knuth.

There are facts, for example that G++ isn't the best compiler and that C++ programs are bigger. Etc...

But it does serve as C with OOP which is good. Writing bigger programs is more fun in C++ for me. For other people it is C. Some love Go, Python, whatever. One good thing about C++ is that it supports nearly 100% of C. So you can do Assembler-like stuff like operating with pointers and more, while still being an OOP-language.

Greetings
Peter

[bzt]

There at the link you gave it says it was a fake interview!

Yes, this is well-known meme. I've used the wording "supposed to be", and used that link deliberately instead of the original catv link, just in case someone isn't familiar with the meme.

I think as @bzt about C++. As does Prof. emer. Knuth.

Wow, do you have a link to Knuth's stance by any chance? That would be huge, a great argument backing up my claims. Not many ppl are qualified to question Knuth on programming languages :-)

One good thing about C++ is that it supports nearly 100% of C.

Yeah, at least that is what they say. In reality I always piss blood with code that has to compile with gcc and g++ as well. Closer to the truth is, there's a small, hacked subset of the C language that works with both.

Cheers,
bzt

[PeterX]

Here's what Prof. Knuth said:
http://www.clbooks.com/nbb/knuth.html

C++ is too complicated. At the moment, it's impossible for me to write portable code that I believe would work on lots of different systems, unless I avoid all exotic features. Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said "OK, we'll do them both". So the language is too baroque for my taste

But please let's accept the fact that C++ is good for some programmers.

Greetings
Peter

[jdc]

If you do a game in C what will happen is that people will still play it in 2022

https://www.youtube.com/watch?v=cyCgMQvG_rc 300k views

while a game done in C++ is long considered dead in 2022.

https://www.youtube.com/watch?v=CRfkef-cMD8 2k views

Unreal at the time have the same if not more popularity then Quake 3. It is noticible in most videos on unreal the frame loss.

[dulsi]

If you do a game in C what will happen is that people will still play it in 2022

No. No one cares what language your game is in. If people keep playing your game it has to do with the game or other factors (updates, tiktok trend, etc.).

[drummyfish]

C is better than C++, it definitely isn't slower, it's probably faster in most cases, you're just making it run slow on purpose (or by lack of knowledge). Remember that C can use macros to implement what C++ (redundantly) does with templates (yes, I know templates are "advanced", "type safe" etc., I don't think that's good but it's irrelevant, we're only talking about speed now). Of course a callback is going to be slower than direct call, but if you're making C use callback even if it doesn't have to (it can use a macro), you're just purposfully making it run slower to "prove" your point. Just wanted to leave this here to clear this up a bit.

[jdc]

I don't say i will not use C++, i personaly prefer procedural style. Don't see the point in abstracting every thing directly. There a lot of stuff you can do to keep improving and updating your code. Like i do in The Box. Is just the filosofy : you can keep updating.

The code that professional release is probably the worst design you will ever see in your life. Which defeat the purpose of keep updating your code. Valve for which Quake they develop a new engine from scrach, probably to win more money. Like a product. If you offer something new, people have to pay for it. Quake 3 It have a poor design, one of the badest design i look at. We don't understand nothing.

Vulkan updated C++ code it look atractive. if you read the article at wikipedia they explain it quiet clear. It have functions that are hard to design; the benefict is not in the code efficiencey which probably have none; the efficiency is in the functions it offer. You can have better interaction width the hardware. That is where the performance is comming not code. It workes so well It out performs openGl and Directx11. But it have nothing to do width code optimization or performance, or lowest level. Every coder or professional coder knows the lowest level is the fastest. Its in the videos they explain it.

Still the code it seems is coming in a framework format, it can have better performances in high level computers or supported ones. As stated in the begining don't know if old computers are not better width RayLib because the cargo is less and people are adopting it for every thing now. Because of is high quality sintax.

https://en.wikipedia.org/wiki/Vulkan

[bzt]

Here's what Prof. Knuth said:

Ah, this isn't a technical argument, just an opinion. That's a pity, but better than nothing.

But please let's accept the fact that C++ is good for some programmers.

Yep, I've never questioned that. I'm just pointing out that programs written in C++ will always be worse performance-wise, simply because there are language features which need run-time support (and with that, will always add run-time overhead). And, because the language hides from the programmer which parts need those run-time support, an average joe will always fall into using them without realizing the performance impact.

No. No one cares what language your game is in.

Come on, dulsi, as someone who enjoys reviving old games you know this isn't true. Your game has lot better chance to compile 30 years later if it's in C than if it's in any other language (like QBasic or Cobol for example).

For example, I've tried to use a 5 years old Go project, and it doesn't even compile with the latest compiler (okay, not a game, but you get my point). The overhyped Rust language suffers from the same problem (and in addition to introducing breaking changes every full moon, even has ABI incompatibility issues between versions, meaning your executable WILL break without recompilation). Just do a websearch on "Rust example doesn't compile", you'll be surprised by the sheer number of results. This is not the case with C, using a compiler with the latest C standard might give some warnings, but it will compile any C89 code just fine.

Same with the "modern" libraries too, I have no issues compiling 30 years old X11 applications, but I can't even compile the original Wayland hello world example any more...

If we are thinking on the long run, and care about preserving programs, then the language and its dependencies do matter a lot.

Vulkan updated C++ code it look atractive.

Vulkan is written in C and not C++. Even though there's a (terrible and ineffective) C++ wrapper API, this means it does not really use any of the C++ language features, and in return the vulkan library can be accessed from any C ABI compatible programming language. See this tutorial about the Vulkan C (not C++) API.

(Note there's a difference between ABI and API. The C++ ABI is C++ only and nothing else understands it, however the C ABI is the de facto ligua franca, supported by almost every compilers ever created, no matter the programming language. Of course this also means there's no place for any language specific features in the C ABI, as that would break compatibility between languages. If you want those features, you must do workarounds, like C++ name mangling for example.)

Cheers,
bzt

[dulsi]

No. No one cares what language your game is in.

Come on, dulsi, as someone who enjoys reviving old games you know this isn't true. Your game has lot better chance to compile 30 years later if it's in C than if it's in any other language (like QBasic or Cobol for example).

Well I was specifically responding to "people will keep playing your game if it is in C". Players don't care what language your game is in. It just needs to be easy to run and that depends on how you package it for them/

Sure C is easy to compile 30 years later because the language hasn't changed in 30 years. If I want to create a thread, the language can't do it. You have to add pthread or some other library. If you want to do graphics that's another library. Could I compile Thrust? Sure but I couldn't run it because it used X11 psuedo-color mode.

In my experience, compiling old C++ code is typically pretty easy. You get a few errors but they are easy to fix. The big problem are libraries that break compatibility. Granted modern C++ can't do graphics by itself yet and may never get that functionality. But I do like the threading functionality and improved random number generators.

[bzt]

Well I was specifically responding to "people will keep playing your game if it is in C". Players don't care what language your game is in. It just needs to be easy to run and that depends on how you package it for them/

Ah, I see, that's true. But I'm still curious how one would run a Rust application in 10 years from now without recompilation, considering its ABI is a moving target. I can run an executable that I compiled 10 years ago from a C source without probs (as long as that horrible glibc versioned function names feature not used, but that's not the C language's fault).

Sure C is easy to compile 30 years later because the language hasn't changed in 30 years.

This isn't so. ANSI C has changed a lot over the years, it's just all the changes were done by experts and the smart way, keeping backward compatibility.

If I want to create a thread, the language can't do it. You have to add pthread or some other library.

Well, yes and no. This is a tough question. Pthread is basically part of the language (as well as threads.h for later sources), so much so that many libc implementation includes it out-of-the-box (for example musl, where threads.h is just a wrapper around pthreads). But you're right in a way, because POSIX specifies pthreads not ANSI C, and sadly there's no clear boundary where the ANSI C spec ends and POSIX starts. It would be more fortunate if the language and the underlying OS interface would have been clearly separated from the start. This is an issue with C, I give you that. Luckily all non-POSIX OS have wrappers (most notably Win32 API has cygwin and mingw as well) to provide a common libc interface for the language.

If you want to do graphics that's another library. Could I compile Thrust? Sure but I couldn't run it because it used X11 psuedo-color mode.

Yes, library dependencies are a headache. Luckily C has lots of well-maintained and multiplatform libraries, like SDL for example (which has SDL_Threads, so threading is a non-issue with that, no matter the OS.) X11 is pretty persistent and hasn't changed much over the years, but indeed there was a minor break in the API when xfree86 was replaced by xorg. (For example, here's xstoneage, which I originally wrote for xfree86. I had to change the window calls a bit to get it working with xorg, but the rest (Ximage, GC etc.) works unmodified.) I'm surprised that you had issues with the color mode, because that's a part of X11 that notoriously kept backward compatibility (and received the most critisism btw, because it is a considerably big part of any x server implementation although nobody has or needs a 2 colors or 16 colors visual any more.)

In my experience, compiling old C++ code is typically pretty easy. You get a few errors but they are easy to fix. The big problem are libraries that break compatibility. Granted modern C++ can't do graphics by itself yet and may never get that functionality. But I do like the threading functionality and improved random number generators.

Interesting, I have exactly the opposite experience (but I admit this highly depends on what projects you try to revive.) Last time I've modified Scorched3D so that I can compile it with the latest compiler and latest libs, and it wasn't a piece of cake... I've lost more hair during the process than I prefer to admit. (But you're right, most problems were library dependency related, not language related.)

Cheers,
bzt

[jdc]

Vulkan not done in C++

Nice, the base is in C we can read in the bidings : https://vulkan.org/tools#language-bindings

They fail to mention that in wikipedia article.

but most of their examples are in C++ https://github.com/khronosGroup/Vulkan-samples

For what i read ya, it is a direct translate from pure C.

Nice that we have one more engine to tweek. People that said that learning C is not that good may be a bit disapointed now; whent to high paid frameworks like Unity Unreal when they have a good option in open source.

*They have a SDK for Linux... https://www.lunarg.com/vulkan-sdk/

[dulsi]

Nice that we have one more engine to tweek. People that said that learning C is not that good may be a bit disapointed now; whent to high paid frameworks like Unity Unreal when they have a good option in open source.

Vulkan is not an engine. Unity/Unreal does lots of things beyond graphics. People who were choosing Unity/Unreal/Godot are not going to suddenly drop them and write an engine using vulkan. Unity/Unreal aren't even high paid frameworks. Both are available for free to develop with and pay only based on sales.

[jdc]

Ya right, they make experiments on you if you do get to design a high quality game they get a high % and the better features are in the paid version. You can't acess the source code, so you will not learn nothing from using these engines. Become dependent on them.

Open source is slow but will get there one day. Look at Linux we are a couple of years away from other OS to desapear. I know this guy that know nothing from computers absolute noob, today is using Linux.

Not to mention that these engines do not suport old hardware they are heavly comercial products.

Good look width these engines.

[dulsi]

Ya right, they make experiments on you if you do get to design a high quality game they get a high % and the better features are in the paid version. You can't acess the source code, so you will not learn nothing from using these engines. Become dependent on them.

Unreal and Unity both provide the source code. Also I include the open source engine Godot as an engine people use instead of writing their own. As someone who has created his own engines and used Godot, Godot can get you up and running faster and it is still open source. Additionally Godot gets you html, Mac, Windows and Android ports out of the box and has a company that will help on console ports. (Open source games generally won't do a console port but it's a nice option to have.)

You are right that they won't run well on old hardware. That's a perfectly good reason to write your own.