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

41–50 of 104 posts

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

#41

Post by nadams »

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

Back in 2004 a demoscene group created a FPS in 96kb - http://www.pouet.net/prod.php?which=12036

That 96kb includes textures, engine and music. No they aren't downloading content or streaming from the internet. I know how they did it - and with some tweaking of gcc command line parameters you can write C you can get close to those file sizes.

When I see that the game RAGE, while an excellent game, takes up 20GB of disk space I just shake my head. Now I'm not advocating that everyone should be making FPSes at 96kb - but I feel like 20GB is a little unnecessary for the game RAGE (especially how short it was).

I personally try to be as efficient as possible when it comes to using other people's storage and memory.

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

#42

Post by vezzy-fnord »

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.

Heck, I have 20+ apps, each over 30MB, on my PHONE.

I don't recall most smartphone OS being well known for intelligent resource utilization.

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

#43

Post by amyjess »

janoc wrote: post #39
lmm wrote: post #25

Earlier quoted context omitted.

> Cross-platform portability obviously isn't their goal. As someone who runs a couple of obscure platforms, I swear every time I have to use a non-Autotools project. Autotools may be slow and may check for seventeen different fortran compilers even if your project never uses fortran, but portability-wise it simply works.

I suggest that everyone defending Autotools in this day and age actually reads one of these blogs (and check the date on them!): http://freecode.com/articles/stop-the-autoconf-insanity-why-... http://www.shlomifish.org/open-source/anti/autohell/ That should give you the idea why Autoconf/Automake setups are past their sell-by date. For more than a decade.

CMake is so wonderful. There's no reason to use it over autotools.

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

#44

Post by scrollaway »

nadams wrote: post #41
coldtea wrote: post #27

Earlier quoted context omitted.

> 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 Back in 2004 a demoscene group created a FPS in 96kb - http://www.pouet.net/prod.php?which=12036 That 96kb includes textures, engine and music. No they aren't downloading content or streaming from the internet. I know how they did it - and with some tweaking of gcc command line parameters you can write C you can get close to those file sizes. When I see that the game RAG…

That is a phenomenally ridiculous comparison. They are doing procedural textures/audio etc. RAGE is 20GB because it has a massive amount of high resolution textures, meshes and audio.

Nothing to do with the libraries they use.

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

#45

Post by lmm »

janoc wrote: post #39
lmm wrote: post #25

Earlier quoted context omitted.

> Cross-platform portability obviously isn't their goal. As someone who runs a couple of obscure platforms, I swear every time I have to use a non-Autotools project. Autotools may be slow and may check for seventeen different fortran compilers even if your project never uses fortran, but portability-wise it simply works.

I suggest that everyone defending Autotools in this day and age actually reads one of these blogs (and check the date on them!): http://freecode.com/articles/stop-the-autoconf-insanity-why-... http://www.shlomifish.org/open-source/anti/autohell/ That should give you the idea why Autoconf/Automake setups are past their sell-by date. For more than a decade.

I'm not unaware of those. Much of the first article's claims are simply false, and the second article's claims that CMake breaks less often than auto* are, uh, not borne out by my experience. (CMake is by no means the worst though; if you must use something non-autotools CMake is probably the best option). The facts simply don't match the rhetoric.

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

#46

Post by [deleted] »

scrollaway wrote: post #44
nadams wrote: post #41

Earlier quoted context omitted.

> Second, 30MB hasn't been an issue since 2002 Back in 2004 a demoscene group created a FPS in 96kb - http://www.pouet.net/prod.php?which=12036 That 96kb includes textures, engine and music. No they aren't downloading content or streaming from the internet. I know how they did it - and with some tweaking of gcc command line parameters you can write C you can get close to those file sizes. When I see that the game RAG…

That is a phenomenally ridiculous comparison. They are doing procedural textures/audio etc. RAGE is 20GB because it has a massive amount of high resolution textures, meshes and audio. Nothing to do with the libraries they use.

[deleted]

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

#47

Post by eklavya »

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.

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

#48

Post by purerandomness »

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.

How large do you think is a "Hello World" app that uses .NET?

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

#49

Post by SEMW »

[deleted] wrote: post #46
scrollaway wrote: post #44

Earlier quoted context omitted.

That is a phenomenally ridiculous comparison. They are doing procedural textures/audio etc. RAGE is 20GB because it has a massive amount of high resolution textures, meshes and audio. Nothing to do with the libraries they use.

[deleted]

> games should do procedural terrains

The decision between prerendered and procedurally generated terrain/textures/etc. is a tradeoff between.. oh, I dunno, developer time, artist time, platform disk space, download time, platform CPU usage, platform graphics usage, and other factors. If you believe game studios have been consistently going for the less optimal choice, then you or someone else could start a studio that makes the better choice, exploit that inefficiency, and gain a market advantage. (Perhaps the demographic of gamers with modern CPUs but 1990s hard drives is ripe for tapping?).

If on the other hand there is no such market potential, then it isn't clear to me in what practical sense the assertion that games 'should' be procedurally generated holds.

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

#50

Post by joezydeco »

IshKebab wrote: post #8
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).

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.…

When you begin to get serious about app size using Qt (especially when you're on embedded) you configure and compile the libraries from scratch instead of pulling the SDK libraries in.

I can typically get under 6MB on ARMv7. Nothing to brag about, but if you want a demoscene-sized app targeted for a single architecture you aren't using Qt anyway.

Post reply on HN