Close to the release of Win9, I swear they will once again begin hyping how this is "the biggest rewrite of Windows that we have ever seen", while it actually will be the same Win32-style base turbocharged, with some new tweaks applied and some others taped on the top.
A really basic and powerful thing to learn: grit! It has helped me tremendously. Continue humbly improving your project, source file after source file, and never give up. Learn to finish a project properly from start to beginning. You will need this skill anyway, when you ultimately delve into the bigger projects, as they tend to get rather complex. But complexity can be managed too, so don't worry about it too much.
It's very interesting what kind of circus the Windows 8 major updates have become. Instead of Service Packs, you now have Windows 8, Windows 8.1, and Windows 8.1 Update 1. Now, the support carpet is suddenly pulled for anything before W8.1U1. Along the way, various platform changes in the UI front have been introduced: start button goes away, start button comes back, ability to snap Modern apps, Modern apps get a title bar, Modern apps can appear in the taskbar, start menu is coming back. Also the settings are still wonkily spread across the classic Control Panel and the Modern UI "PC settings" application, not to speak about the "charms bar" which integrates really badly with the paradigms of the normal desktop, which the user is using at the same time.
It's interesting because in the past Microsoft planned these things very carefully beforehand, and after the release of OS was very careful to not change core functionality. Maybe this is the future, then.
Uh, no. I simply meant keeping cached copies of the compiled shaders on that particular computer. Shaders would still be uploaded and run normally on the GPU.
So the problem is exactly those hardware specific instructions. We cannot ship a game with precompiled shaders to hundreds of different chip families by NVIDIA, AMD, and Intel.
What we could do however, is to cache the compiled shaders locally and recompile them only if a hardware change is detected.
You are an idiot. You are saying "one can" like it is as easy as baking a cake. I would love to replace windows with ubuntu or mint or something for all my gaming needs, but I wouldn't have the slightest idea on how to even start coding a feature for linux. This is some pretty specialized stuff.
This is very true. We need to get out of the mentality that open source automatically means that everybody can contribute to projects just like that. One cannot usually craft even a simple 10-line patch if they do not understand the architecture of the project, and something like that can take months to grasp. Oh, and then people maybe do not even want your patch or you find that your commit tags were wrong or your MUA screwed up something and all that circus.:D
It's like saying that "everybody can contribute to the research of cosmology, the current research and complex mathematical equations are freely available".
Seems simpler to just say this than to try to explain how there are no games for linux because its graphics and gaming capabilities have historically been terrible
But they haven't been that terrible. Linux has had a rather good OpenGL support for a long time. Sound has mostly worked well enough, especially if you tapped directly to OSS or ALSA. After that, what else do you need than input support and possibly networking. All the ingredients for a game are there. During the last 10-15 years, I do not see any terrible endurances if you really wanted to make a game for Linux.
I say it's been more about the lack of interest (it's been a small market after all) rather than technical capabilities.
The problem with OpenGL isn't speed or load times. Microsoft made directx so 3D programming in windows would be easier. It's just like C# or VBA. They made it much easier to use, and therefore much cheaper to hire for. If you're hiring people to write a new 3D engine using OpenGL you need people at the top of their field... If you're hiring for DirectX there are dozens of local tech colleges filled with mediocre talent that will fit the bill. Now, you could argue that you should be getting top talent anyways, but that's why you don't run a major game producers.
Not really. Direct3D and OpenGL are mostly the same stuff, and both require a developer with a high level of competence. With DirectX you also wind up doing some crusty Win32 trickery, even opening the window is quite painful process. When you combine OpenGL with SDL or SFML, you get that kind of boilerplate stuff done much cleaner.
FFS they've already stopped porting Adobe Reader years ago and don't patch the main Flash plugin on Linux unless a big security vulnerability is exposed.
The PPAPI version of Adobe Flash plugin for Google Chrome under Linux is still being developed and is doing fine. The old NPAPI plugin will remain frozen in the 11.2.x.x tree and receive occasional security updates, as you correctly said.
Actually the hardware support is quite good already. I agree with your other points though: Linux world is a mess with parts missing, lots of bugs, and lacking quality assurance.
And that also has little do with how shaders are precompiled I think.
As far as I know, you cannot precompile shaders anyway because the compiled code is hardware-dependent. The shader processors are different among architectures and manufacturers, and do not have a common baseline like "x86-64" to target, like we have on the CPU side.
Maybe it will fist require a popular tech website to run a Top-10 Worst Privacy Infringing Apps in Google store.
Could as well flip it around and instead make a third party give a "Privacy Gold Star" for apps that don't infringe your privacy and don't require unnecessary permissions from the phone operating system.
The higher-level languages are often either interpreted or run as cross-platform bytecode. Those make up for the main performance hit, not bounds-checking.
We have fast computers. Why not sacrifice some of it to security? I mean, we are still probably not talking about 50-time slowdowns, like when you run a program under Valgrind.
Slashdot Mirror
Close to the release of Win9, I swear they will once again begin hyping how this is "the biggest rewrite of Windows that we have ever seen", while it actually will be the same Win32-style base turbocharged, with some new tweaks applied and some others taped on the top.
Some people have said that you can cram it inside Chromium, but that it is a royal pain in the ass to do.
Your comment inspired me to take computer graphics to the 8th level!
A really basic and powerful thing to learn: grit! It has helped me tremendously. Continue humbly improving your project, source file after source file, and never give up. Learn to finish a project properly from start to beginning. You will need this skill anyway, when you ultimately delve into the bigger projects, as they tend to get rather complex. But complexity can be managed too, so don't worry about it too much.
It's very interesting what kind of circus the Windows 8 major updates have become. Instead of Service Packs, you now have Windows 8, Windows 8.1, and Windows 8.1 Update 1. Now, the support carpet is suddenly pulled for anything before W8.1U1. Along the way, various platform changes in the UI front have been introduced: start button goes away, start button comes back, ability to snap Modern apps, Modern apps get a title bar, Modern apps can appear in the taskbar, start menu is coming back. Also the settings are still wonkily spread across the classic Control Panel and the Modern UI "PC settings" application, not to speak about the "charms bar" which integrates really badly with the paradigms of the normal desktop, which the user is using at the same time.
It's interesting because in the past Microsoft planned these things very carefully beforehand, and after the release of OS was very careful to not change core functionality. Maybe this is the future, then.
That's a bit unfair. Almost no software running on a PC has been completely perfect with no vulnerabilities at all.
Uh, no. I simply meant keeping cached copies of the compiled shaders on that particular computer. Shaders would still be uploaded and run normally on the GPU.
Programming in OpenGL ES is still very similar to programming in normal OpenGL.
Ha! I'll make sure that that award goes to me!
So the problem is exactly those hardware specific instructions. We cannot ship a game with precompiled shaders to hundreds of different chip families by NVIDIA, AMD, and Intel.
What we could do however, is to cache the compiled shaders locally and recompile them only if a hardware change is detected.
You are an idiot. You are saying "one can" like it is as easy as baking a cake. I would love to replace windows with ubuntu or mint or something for all my gaming needs, but I wouldn't have the slightest idea on how to even start coding a feature for linux. This is some pretty specialized stuff.
This is very true. We need to get out of the mentality that open source automatically means that everybody can contribute to projects just like that. One cannot usually craft even a simple 10-line patch if they do not understand the architecture of the project, and something like that can take months to grasp. Oh, and then people maybe do not even want your patch or you find that your commit tags were wrong or your MUA screwed up something and all that circus. :D
It's like saying that "everybody can contribute to the research of cosmology, the current research and complex mathematical equations are freely available".
Seems simpler to just say this than to try to explain how there are no games for linux because its graphics and gaming capabilities have historically been terrible
But they haven't been that terrible. Linux has had a rather good OpenGL support for a long time. Sound has mostly worked well enough, especially if you tapped directly to OSS or ALSA. After that, what else do you need than input support and possibly networking. All the ingredients for a game are there. During the last 10-15 years, I do not see any terrible endurances if you really wanted to make a game for Linux.
I say it's been more about the lack of interest (it's been a small market after all) rather than technical capabilities.
Yes.
The problem with OpenGL isn't speed or load times. Microsoft made directx so 3D programming in windows would be easier. It's just like C# or VBA. They made it much easier to use, and therefore much cheaper to hire for. If you're hiring people to write a new 3D engine using OpenGL you need people at the top of their field... If you're hiring for DirectX there are dozens of local tech colleges filled with mediocre talent that will fit the bill. Now, you could argue that you should be getting top talent anyways, but that's why you don't run a major game producers.
Not really. Direct3D and OpenGL are mostly the same stuff, and both require a developer with a high level of competence. With DirectX you also wind up doing some crusty Win32 trickery, even opening the window is quite painful process. When you combine OpenGL with SDL or SFML, you get that kind of boilerplate stuff done much cleaner.
FFS they've already stopped porting Adobe Reader years ago and don't patch the main Flash plugin on Linux unless a big security vulnerability is exposed.
The PPAPI version of Adobe Flash plugin for Google Chrome under Linux is still being developed and is doing fine. The old NPAPI plugin will remain frozen in the 11.2.x.x tree and receive occasional security updates, as you correctly said.
Actually the hardware support is quite good already. I agree with your other points though: Linux world is a mess with parts missing, lots of bugs, and lacking quality assurance.
Maybe those companies think that Linux is somehow a bad platform to develop to. In that case it would be Linux's fault.
And that also has little do with how shaders are precompiled I think.
As far as I know, you cannot precompile shaders anyway because the compiled code is hardware-dependent. The shader processors are different among architectures and manufacturers, and do not have a common baseline like "x86-64" to target, like we have on the CPU side.
Aha!
Maybe it will fist require a popular tech website to run a Top-10 Worst Privacy Infringing Apps in Google store.
Could as well flip it around and instead make a third party give a "Privacy Gold Star" for apps that don't infringe your privacy and don't require unnecessary permissions from the phone operating system.
"Regional dialects". :D What an explanation.
The higher-level languages are often either interpreted or run as cross-platform bytecode. Those make up for the main performance hit, not bounds-checking.
Agree, that's a fine article.
The Heartbleed vulnerability existed for a long time, then it was fixed quickly when finally discovered.
The recent Internet Explorer vulnerability existed for a long time, then it was fixed quickly when finally discovered.
We have fast computers. Why not sacrifice some of it to security? I mean, we are still probably not talking about 50-time slowdowns, like when you run a program under Valgrind.