last version of C::B Advanced

Discuss anything not covered by any of the other categories.
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: last version of C::B Advanced

Post by frag.machine »

revelator wrote:most of them do still support xp, its just a matter of providing the right --march= --mtune= flags :)
so for core2 its --march=core2 --mtune=core2, codeblocks has the option now to set these in build options.

My only gripe atm is that the fsf is pushing all there cards on C++11 and later C++ apis while breaking earlier C++ standards. Also breaking a ton of stuff with clang alike checks that should only be warnings but end up as errors because everyone and there mother has adopted the stance that any warning=error so a lot of packages now simply wont tolerate any warning at all and they enforce it by building with -Werror. The big problem is that to fix this collosal blunder would mean that a lot of sources would have to have serious surgery to even build again and there is no guarantee that they wll even work when built with these new versions.

So either they stop this crap or im done with gcc. Clang seems to be allmost production ready anyway on windows.
Let me tell you a little secret: this isn't (just) the FSF pushing the zero tolerance with warnings trend. It's disseminated among the younger developers in most languages, not only C++. For example, I work in a big C# project where this "warning=stop the build" is adopted, too.

Personally ? I'm fine with it as long is adopted since the very start of the project and is part of a bigger effort including good test coverage and proper continuous integration. Changing the rules in the middle of something big just because is trendy ? It's a nightmare, and a very stupid decision.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

I agree somewhat, probably to late to change now though sigh...

Allthough i think they are somewhat fighting for there lives with clang taking over more and more of the linux world as the default compiler for building kernels, but it's a rather stupid move cause even so gcc wont go away any time soon cause it still supports things that clang does not, like fortran ada java and go. Maybe in time clang could support these as well but i do not see this in the foreseeable future.

Competition is good but useless competition is just well useless.

And dont get me wrong C++11 and later is a big step forward, but that does not mean it should be ok breaking builds that have no problems besides using an older api.
Open Watcom also plan on C++11 support but differing from the usual stance they will not make this the default C++ api, and i somewhat cheer on that decision :).
Productivity is a state of mind.
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: last version of C::B Advanced

Post by frag.machine »

I see a lot of hubris in the OSS community. It is easier to make a project fork than find a consensus. What people don't see is how this attitude waste efforts and produces little if any practical results.

Also, frequently you see younger developers just throwing legacy work under the bus just because they want a clean slate to start. This almost happened with the AngularJS project when they decided to rewrite almost everything in version 2, changing some important architectural decisions, and announced that AngularJS 1.* would be discontinued and people should just, you know, rewrite everything from scratch. The user community reaction was huge and they were forced to change plans, but in the end you stop trusting in the project future and the team maturity.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

Pretty much spot on.

I allways been an advocate of change is good so long as you dont take it to far and breaks things that do no need fixing in the first place. So this new attitude of just updating everything and to hell with the consequences is in my eyes just catering to programmers who know to little of the background mechanics and just want something they can work in easily and to hell with the rest of us who do know.

Well it would be nice to have easy coding but more times than not you just end up having to hack around stuff anyway cause that is the only way to get what you want, especially when working on older codebases.

Sure you could rewrite them... Its just some of these codebases are pretty freaking large so by the time you get it out of the door the next big change breaks everything you just spent a lot of time fixing and so the story continues.

So the right thing to do would be to just default to the oldest api unless specified that you want to use the newer ones, this way the developers can implement changes over time and make absolutely certain nothing breaks before release and still have something that works in the meantime.
Productivity is a state of mind.
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: last version of C::B Advanced

Post by frag.machine »

One could argue that always assuming legacy on by default can be prejudicial to innovation, and this maybe true in some cases. I find the Java model of deprecation is a good compromise, because i doesn't just break things to open room for innovations; both worlds coexist for a more than reasonable long time ( you can still run 1.1 code in Java 8 with little if any change, although you're clearing missing a lot in terms of efficiency and features). Of course, there is a price to pay dragging lots of legacy code with the JDK/JRE just to support those old apps using Vectors or entity beans from EJB 2.*, but it's far less disruptive.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

There are allways edge cases indeed :)
Most people today would rather see jave diaf because of its security holes and a long history of being targeted by hackers,
but theres a rather "hard" core of devs who in no way wishes java to go away and they will not allow anyone to remove it ever as long as they have anything to say in that matter.
Hell they still update it and now also have the open source guys doing work on it with openjdk.

But many also forget that there is no such thing as safe software, it does not exist and newer will.
Mainly because if you plugged all the holes you would end up with something that would not work at all anyway.

And safe hardware... well after the blunder with meltdown and spectre we can safely assume that that is also a pipe dream.
My once pretty monstrous pc only took a hit of about 50% performance loss from the patch that should plug one of the holes,
it also broke a lot of software i was using. Intel is in for a shitstorm the likes that would probably bring them close to bankrupcy,
AMD is also affected but only by spectre, meltdown is intel exclusively.
The problem with spectre is that there actually is no fix, and the hype about pluggin atleast some of the holes might end up breaking more than it fixes (see performance).
But one should probably not be to scared of using a PC ever again since triggering the spectre bug is rather hard (allmost impossible) even without these patches.

But meltdown is a big problem and unfortunatly i have an intel :S so basically my only saving grace would be buying a new cpu (and i can asure intel it will newer be from them ever again) so ill probably get a ryzen when i saved up enough.
Productivity is a state of mind.
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: last version of C::B Advanced

Post by frag.machine »

And yet Java stills the 2nd most used language in corporative world and not everyone hates it - actually it' s a small but very vocal group, strangely enough composed in great part by .NET programmers. There is also a lot of misinformation about the Java security holes: most of them were fixed long time ago and were in the applet API, which must DIAF for other reasons. The server side Java has no such vulnerabilities and is rock solid, despite Oracle efforts to shoot his/her own foot in the QA department.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

Aye, corps just love managed code ;) and java is by far the easiest one of the bunch to work with.
As for the security holes. most of them have indeed been plugged, but once you get a bad reputation it tends to stay.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

Btw anyone had a look at the OrangeC compiler ?.
Its built by one of the LADsoft devs (yes the one responsible for the RADasm compiler suite) as an update to his old CC386 compiler.
Atm its DOS and Win32 only with preliminary support for Linux as well, 64 bit will also make it in in time.
It uses some rather interresting ideas (different than most compilers out there) it also supports C++14,
so calling it OrangeC might be alittle misleading it has full support for C++ :biggrin:

You will need atleast the msvc 2010 sdk to build anything with it as it only comes with the RTL, but it picks that one up automatically if installed correctly :smile:
Productivity is a state of mind.
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: last version of C::B Advanced

Post by qbism »

A new compiler sounds interesting for DOS retro games vs djgpp (code optimization, ASM, user-friendly? etc). There are a few active DOS game projects like Q2DOS. If it doesn't have a DOS port, a pre-1999 console port, or at least a smegging win32 software renderer, it's not 'retro'. :)
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

It uses nasm style for ASM so it might not accept old gas code out of the box, but the OrangeC dev might know more :)
It also has it's own IDE which while minimal is advanced enough to make most things.

omake as it's make utility is called, uses gnu make syntax so there should be no surprises there in comparison with djgpp.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

compiler has reached a size thats impossible to upload, due to numerous support libraries and tools.
Unpacked it would amount to close to 120 gb :shock: so even if i made a spanned version zipped with 7zip on ultra
the user would have to download about 120 archives, and noone wants to do that. Also i discovered that the archives had a tendency of going corrupt while uploading, so thats also something to consider.

I fixed numerous packages that normally would not build with msys2 - mingw64 which is kindof a shame since many of them are pretty usefull. But if i can manage ill try and make them as seperate pkgbuild packages, for installing with pacman.

Atleast some of my fixes have been accepted upstream, so normal users of msys2 can benefit from my work.

The compiler now supports building .NET - QT - vulkan - Python(2,3) code besides C C++ fortran ada objc.
The new clang compiler is a bit buggy atm, but it should suffice for building simple programs. Quake does build with it.
Productivity is a state of mind.
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: last version of C::B Advanced

Post by frag.machine »

Have you considered using some kind of project manager to take care of the bazillion dependencies this one requires ?
I am not very familiar with C++ toolchain but I heard good things about CMake and autotools.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

It allready sports one from the linux world called pacman, my one problem is in setting up a repository, but i will look at options to do so. Unpacked size was actually closer to 200GB :twisted: so its a monster thats grown out of control.
Atleast it can build allmost anything out there now :biggrin: only gripe and one i been unable to get around is that even though it defaults to linking the runtimes statically pthreads MUST in most cases be linked to the dll or things break.
And gcc is at 7.4.0 because gcc-8 breaks a lot of things like gnat, and the TDM patches also do not work with it anymore.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: last version of C::B Advanced

Post by revelator »

After some deliberation, i came to the conclusion that the easiest approach would be for me to supply an installer like the one Msys2 uses, with only a barebones compiler and no support libraries backed by my specialized codeblocks IDE.
One could then do a pacman -S "whatever tool or library" you need, and work from there. The big problem is that
quite a lot of the tools or libraries had to be handpicked because of breakage in the latest versions, so they might not allways be the latest versions avaliable, but atleast they will work.

I know many would prefer a zipped compiler, but that might be a rather bad idea since Msys2 is not really relocatable the same way Msys was. Msys2 is much closer to the original cygwin code than Msys was. For instance you can remove a single line in /etc/fstab and you would have /cygdrive prefixes, Msys eliminated /cygdrive completely and used some elaborate code to translate windows paths to posix and vice versa. Msys2 uses much the same code cygwin does and also supports symlinks which Msys does not. You could actually build the entire X server with Msys2 and a minimal version of it is actually avaliable from another user for use with fontforge.

As for tools that might be interresting to get as a game developer, heres a small list.

blender (mostly works as it should, however in some cases you might run into a bug where it refuses to start, in that case start it with -noaudio.) The older 2.78 version did not have this bug, and the developer blames bad drivers so...

assimp (this one is for .ass models like the ones found in doom3).
cegui (renowned gui and menu framework in C++, can use Ogre and Irrlicht engines as well as opengl1-3 and direct3d9-11).
gimp (an image manipulation program that has a good set of tools but can be a bit hard to get around in in earlier versions. Version 10 is luckily much easier to handle).
inkscape (vector based image manipulation engine, bit like paint on steroids).
git gitg gitk (windows versions of git + a gui for keeping track).
vulkan cg glew glfw (opengl libraries used in many engines).
Productivity is a state of mind.
Post Reply