Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CopperSpice, a Modern C++ Fork of Qt

copperspice.com

Post reply on HN
Print view View original

81–90 of 104 posts

Re: CopperSpice, a Modern C++ Fork of Qt

#81

Post by nhaehnle »

dman wrote: post #67
scrollaway wrote: post #63

Earlier quoted context omitted.

It's an obscure fork of a massive project, on an outdated version, with no chance of further support, no VCS, no discussions, no background and no author here to back any of it up. The negativity really shouldn't be a surprise.

To be perfectly honest a fork in Qt does not surprise me. Most of the people I know who are using Qt use the QWidgets api which has been neglected since 4.8 . Increasingly Qt development appears to be geared for completely new paradigms (Mobile, Scene graphs, Styling via CSS, QML, QtQuick ...) while leaving the core desktop functionality at a stand still.

None of this is an argument in favor of a fork. Even if what you write were true (and that hasn't been my impression), somebody would still have to do the work of improving QtWidgets even further. They might as well do that work in Qt itself without producing a fork.

It's obvious judging from other comments in this thread that Qt has some problems making people unhappy. However, where those problems are genuine, the author's energy would be better spent to fix those inside Qt rather than creating a new project/fork. (If the goal is actually to help other developers; of course, if all the author wanted was to create an interesting proof of concept, then more power to them.)

Re: CopperSpice, a Modern C++ Fork of Qt

#82

Post by ci5er »

coldtea wrote: post #27
IshKebab wrote: post #8

Earlier quoted context omitted.

There are some downsides to Qt5. * It's huge - something like 30 MB for "hello world" on Windows. * Deployment is a nightmare (loads of plugin DLLs, there's some crazy path stuff going on, if you use QML you have to include a load of system qml files). There is a windeployqt tool which helps but it still isn't as easy as with Qt4. * QML/QtQuick are very nice for some things, but in a lot of ways they kind of suck. E.…

> It's huge - something like 30 MB for "hello world" on Windows. First, 30MB for "hello world" doesn't mean it will get linearly bigger as code grows. Most is one time off overhead. Else something like Kate would be an 1 TB binary. Second, 30MB hasn't been an issue since 2002. Heck, I have 20+ apps, each over 30MB, on my PHONE.

> Second, 30MB hasn't been an issue since 2002. Heck, I have 20+ apps, each over 30MB, on my PHONE.

Good for you?

That doesn't mean that it is not an issue.

Re: CopperSpice, a Modern C++ Fork of Qt

#83

Post by [deleted] »

nhaehnle wrote: post #81
dman wrote: post #67

Earlier quoted context omitted.

To be perfectly honest a fork in Qt does not surprise me. Most of the people I know who are using Qt use the QWidgets api which has been neglected since 4.8 . Increasingly Qt development appears to be geared for completely new paradigms (Mobile, Scene graphs, Styling via CSS, QML, QtQuick ...) while leaving the core desktop functionality at a stand still.

None of this is an argument in favor of a fork. Even if what you write were true (and that hasn't been my impression), somebody would still have to do the work of improving QtWidgets even further. They might as well do that work in Qt itself without producing a fork. It's obvious judging from other comments in this thread that Qt has some problems making people unhappy. However, where those problems are genuine, the…

[deleted]

Re: CopperSpice, a Modern C++ Fork of Qt

#84

Post by artificial »

nadams wrote: post #79
Qwertious wrote: post #58

Earlier quoted context omitted.

So, now you need your artists to be programmers. I don't think you quite understand what you're asking. The number one rule for high-quality aesthetics in games is that you let the ARTISTS call the shots, with someone in-between to tell them when that's a terrible idea technically. This would break that horribly. And that's ignoring the load times, which increases massively if you have to procedurally generate it. An…

> So, now you need your artists to be programmers. There is some arguments if you should allow artists to program (Blender does have a built in scripting language). However, the same group that created the FPS demo also created a tool to create demos - artists can go as wild as they want without needing to write a line of code: http://www.farbrausch.com/prod.py?which=168 If you want something a little more well docum…

>Downloading that 20GB RAGE game has turned into quite a challenge Dated First World problems notwithstanding I immensely enjoy the harping on RAGE, especially the fixation on the assets (and the resulting download size). GTAV is nearly 60GB and is immensely popular. It uses a traditional texture model compared to the Megatexture technique used in idtech. Computing the quantity of textures on install would result in people remarking how long it takes to install instead of download.

> You are forgetting the step in between. Using your argument that disk space is cheap (and assuming they don't use their hard drive to store anything else...) in the US ISPs are playing a dangerous game. A small DSL provider has a 5GB cap and will charge outrageous fees for going over Canadians have been dealing with dinky quotas for awhile and entertainment streamed or downloaded thrives there. In the states there are plenty of people on dial up who live out in the sticks or are on satellite connections and you know what? I'd wager these people aren't the target market. For the vast majority of businesses the most expensive thing is employee overhead. Storage is cheap and getting cheaper, developer time not so much. I appreciate technical efficiency as much as anyone. The reality is that the junk pile is full of technically superior products that died because the competition beat them to market or out marketed them.

>However, the same group that created the FPS demo also created a tool to create demos - artists can go as wild as they want without needing to write a line of code: http://www.farbrausch.com/prod.py?which=168 If you want something a little more well documented and updated you should check out ZGameEditor - http://www.zgameeditor.org/. Neat. I'd sincerely enjoy seeing an attempt at making a game like RAGE with zgameeditor. I see excellent examples of toy tools. Using the right tool for the right job makes a world of difference, take a look at Unreal4, ZBrush, Maya, and a host of others involved in asset pipelines. You'll notice many of these tools are specialized. Pay close attention to the features and compare those to zgameditor.

Re: CopperSpice, a Modern C++ Fork of Qt

#85

Post by ehvatum »

Presumably, Digia is following the money with their emphasis on Javascript smartphone stuff. Qt taken as a whole is profitable for Digia, I have heard.

However, it's very clear that the effort directed towards Javascript on smartphones is effort not directed towards long-pressing desktop C++ Qt issues. Lack of QPainter OpenGL core profile support, for example. Because OS X GL compatibility profile supports almost nothing beyond OpenGL 2.1 and QPainter can only work in compatibility profile, a cross platform application that wants to draw into the same OpenGL context with straight OpenGL calls and QPainter is limited to OpenGL 2.1.

This absolutely sucks. Of course, the javascript stuff works with GL core profile - because the effort that should have gone into QPainter instead went into stuff relevant to the javascript-land. Digia is well aware of the issue: https://bugreports.qt.io/browse/QTBUG-33535 WONTFIX, because out-of-scope. It's out of scope because anything that isn't directly and urgently required by the Javascript adventure is out of scope, I worry.

The changes required are not so complex as the WONTFIX excuse would imply. Almost all of the shader code that has to be updated to replace/remove legacy calls is contained in one file: https://github.com/qtproject/qtbase/blob/dev/src/gui/opengl/... Most of that file is not GLSL. The GLSL that is there is mostly boilerplate.

It turns out that QPainter GLSL drawing is actually elegantly implemented and quite straightforward, especially in comparison to how Windows did "GPU accelerated" drawing last I looked (during the Vista days). I made decent progress with my first hack-and-slash attempt to implement core profile support in just an hour.

How about a Metal backend? And a Vulkan backend? Will QtWidgets ever have either? I have been getting a lot of signals that, indeed, QtWidgets is the past, and "NO, why don't you try javascript? How about Javascript? In addition, Javascript. It's Javascript you're looking for, friend." Never mind that Qt Quick Controls are currently extremely limited...

If Digia is not, in fact, making money on the Javascript side and is making money from the desktop and enterprise C++ side, I would gently suggest that more consideration should be made of the needs of existing paying customers. If Javascript really is paying the bills, then great. I'll continue not liking it, but at least the decision to go all-in on Javascript would be rational.

PS, I would welcome any tips for getting a GL 4.1 context texture into a GL 2.1 context on OS X without passing the texture through main memory...

Re: CopperSpice, a Modern C++ Fork of Qt

#86

Post by asermersheim »

DocSavage wrote: post #9
scrollaway wrote: post #3

Why? And why 4.8? The 5.x branch is a far better version of Qt. This looks ridiculous. Qt is a massive framework - the work of hundreds, if not thousands, of people - and this seems to be the work of a random dev with zero backing and a 2004-style website with zero content (everything, even the 14-forum completely empty phpbb forum).

The lack of a public repo of some kind and obvious licensing makes this a no-start for me.

We had everything set up on sourceforge and we hit the limits of what we could accomplish on sourceforge last month.

We have been moving everything including downloads and forums to a better location. We have not yet moved the git repo to a publicly accessible location, but this is in progress. Thank you for bringing this to our attention, and I apologize for the inconvenience.

Re: CopperSpice, a Modern C++ Fork of Qt

#87

Post by asermersheim »

scrollaway wrote: post #63
eklavya wrote: post #47

Oh my god. And he/she is forcing me to use this, that too for free? Whatever will I do? Such a waste of his/her time, I demand compensation. Why so much negativity people? It's a huge undertaking and an awesome accomplishment. Why shouldn't he/she do it? Remember, we are (most of us?) in it for the love of it.

It's an obscure fork of a massive project, on an outdated version, with no chance of further support, no VCS, no discussions, no background and no author here to back any of it up. The negativity really shouldn't be a surprise.

We just found out about this thread 10 minutes ago, and we have been on reddit for the past 8 hours answering questions. We are stunned by the level of interest and feedback.

We have been using git from day 1 in house for our version control and that will be available to the public shortly.

We have been focusing on outreach to the local SF Bay area developer community, and we presented CopperSpice at the SF Bay Area Association of C/C++ users meeting in February. You are welcome to peruse the meeting notes and our slides:

http://www.meetup.com/SFBay-Association-of-C-C-Users/events/... https://docs.google.com/presentation/d/1Sxei-Em6cnYbE0Zj16j6...

In terms of 'backing any of it up', the code speaks for itself. I am happy to answer any specific questions you may have.

Re: CopperSpice, a Modern C++ Fork of Qt

#88

Post by scrollaway »

nadams wrote: post #79
Qwertious wrote: post #58

Earlier quoted context omitted.

So, now you need your artists to be programmers. I don't think you quite understand what you're asking. The number one rule for high-quality aesthetics in games is that you let the ARTISTS call the shots, with someone in-between to tell them when that's a terrible idea technically. This would break that horribly. And that's ignoring the load times, which increases massively if you have to procedurally generate it. An…

> So, now you need your artists to be programmers. There is some arguments if you should allow artists to program (Blender does have a built in scripting language). However, the same group that created the FPS demo also created a tool to create demos - artists can go as wild as they want without needing to write a line of code: http://www.farbrausch.com/prod.py?which=168 If you want something a little more well docum…

Here's the thing: Procedural rendering is a tool. It's useful in some cases (like, say, randomly generating massive universes with distinctive patterns a la elite, minecraft, etc). It's useless if you want to do predictable things which obey a designer's vision. Going from concept art/blueprint to a live mesh is completely impossible with the tooling we have today to do procedurally.

Yes, most games could certainly optimize their contents. I'm certain there's dozens of gigabytes of data which could be shaved off on any gamer's computer between all the installed games, but most of what's in there is there for a reason. Also ... something about frying fish.

So treat that technique as a tool. Not everything is a nail. Is RAGE too large? Maybe. Would procedural generation be appropriate for it (in a way that meaningfully reduces contents size)? Certainly not... not without redesigning the game from the ground up.

Re: CopperSpice, a Modern C++ Fork of Qt

#89

Post by asermersheim »

sirspudd wrote: post #62
hobarrera wrote: post #29

> The redesign allowed us to completely remove the Qt Meta-Object Compiler (moc) system. I recall having heard that this was one of the new goals for Qt now that we have C++ 11. Is the intention of this fork to merge back at some point? I don't see the fragmentation working out for everyone in the long run.

It is Qt 4.8 based, there is clearly zero intention of remerging it. They changed the build system! There are lots of people seeking to repackage Qt's work, add their own spin (pittance of work) and then attempt to profit off of it as a discrete product.

CopperSpice is a fork of Qt 4.8 but we have evolved considerably past the Qt version we started from.

We switched the build system to autotools in order to get away from the brittle and complex bootstrap system that Qt must maintain.

With respect to your comment about 'a pittance of work' here are some current numbers from CopperSpice:

43426 files changed, 2062325 insertions(+), 7974133 deletions(-)

Since CopperSpice is an open source project released under the GPL & LGPL, we are not looking to profit from it nor can we. Now, if someone throws money at us, we certainly will not refuse. But we did this for the love of the game.

Re: CopperSpice, a Modern C++ Fork of Qt

#90

Post by [deleted] »

sirspudd wrote: post #62
hobarrera wrote: post #29

> The redesign allowed us to completely remove the Qt Meta-Object Compiler (moc) system. I recall having heard that this was one of the new goals for Qt now that we have C++ 11. Is the intention of this fork to merge back at some point? I don't see the fragmentation working out for everyone in the long run.

It is Qt 4.8 based, there is clearly zero intention of remerging it. They changed the build system! There are lots of people seeking to repackage Qt's work, add their own spin (pittance of work) and then attempt to profit off of it as a discrete product.

[deleted]
Post reply on HN