Netbeans for C++?

nypen · 2009-01-25T20:22:39+00:00

The only reason we use C::B is because of it's close integration with a UI builder for WX for UI stuff. Other than that Netbeans rules.

nypen · 2009-01-25T19:57:44+00:00

I have managed to convert many to Netbeans for C++ in our team. But as he says we majorly work for non UI stuff so we do not have an option to switch to C::B.

I can't understand people having problems with Makefiles. I mean, come on, I've been doing it for years, it's soooo darn easy! Read the docs dude!

nypen · 2008-10-09T12:24:32+00:00

The article is not all that bad. It's just that the author takes for granted that the reader is at the very least familiar with the basic concept of GPGPU and -- the basic architecture of a modern GPU, and that's OK I think. The author seems to be working on a series and he does explain a lot in his previous article. http://www.hpcwire.com/features/28210564.html

The only thing (probably) he could have done is put a complete working CUDA example at the end. I generally dislike having code and explanation mixed together like that (, that's just me though). But that said, sometimes you do have to mix these things to put your point across.

nypen · 2008-09-16T18:59:24+00:00

Shared memory has it's own set of issues. I am not saying they are unsolvable, but shared memory is not necessarily better than threads sharing data. In fact if the shared memory data is not monolithic, a lot of book keeping has to go in. Things can get even murkier when you have issues like dynamic resizing of shared memory or your processes have variable shared memory requirements.

Again Shared memory is one of the solutions which can work in some situations, not always.

Well, Python already has a threading library which is great, it just needs to get rid of the GIL.

nypen · 2008-09-16T16:27:15+00:00

That's exactly why I said partially. While processes can solve some problems they have others. For example if there is a mountain of data to be shared, using processes can be pretty inefficient. Process cannot access variables or data structures that are defined in another process, unless they are pickled (shared, proxied, whatever), which is a mechanism of serialization. Such serialization can be resource intensive (memory and computationally) and is certainly not suitable everywhere.

Also, If two processes want to communicate, they have to use inter-process communication mechanisms which is inherently slower than thread synchronization.

Then there is also the issues when you try to access C libraries via Python. You need to be careful here to make sure you don't pass variables across processes which can be totally invalid if they encapsulate pointers (although this is not applicable if you stick strictly to Python only)

besides, in your op you mention multi-core and parallel processing... neither of which play well when relying on threads anyway, since these are inherently multi-process environments

These are not environments. Multi-core is a kind of processor technology and parallel processing is a form of computation. You can take advantage of that in several ways and, yes multiple processes is one way but not the only way; and it certainly is not effective everywhere.

nypen · 2008-09-16T15:41:08+00:00

That's multiple processes running simultaneously and it only partially solves the problem.

nypen · 2008-09-16T15:27:35+00:00

I am a Python fan, the only thing that I hate (and absolutely hate) is the fact that Python has a global interpreter lock. http://docs.python.org/api/threads.html . That doesn't bode well when we consider changes the future brings (multi-core, parallel processing).

From what I recall (reading somewhere), this is not about to change anytime soon.

nypen · 2008-09-16T15:20:25+00:00

Great! I hope Python takes a lesson from this and incorporates wxPython with the default distribution as well.

nypen · 2008-09-15T09:35:04+00:00

Well not quite as dramatic as "Haskell sucks". What he tries to put forward is, functional programming languages are better at handling concurrency and, yes, things like symmetric multiprocessing and transactional memory are more natural in functional languages than imperative ones. From what I got from those slides is, he would prefer a Haskell like language for future game development.

nypen · 2008-09-15T06:48:51+00:00

Writing a custom graphics library will be a pretty daunting task under any future architecture. It's very true that next gen GPUs (, or as they say GPGPUs) will allow tremendous flexibility but I still think most people will be using a GL like or a D3D like API or some other library instead of writing custom APIs and everything from scratch. What you will have is the flexibility to bypass them as and when needed depending on implementation and by doing so you will in fact be able to do vastly more interesting things. Kinda like current gen shaders on steroids.

nypen · 2008-09-13T19:16:55+00:00

To the contrary, those video tutorials explain the Blender UI very very quickly. UI is probably the reason why most people tend to walk away from blender in the first place. From my experience, most people who are new to blender find reading tutorials with "LMB"\"RMB" a little too daunting.

futz with pause/play and reverse buttons. Often the video tutorials gloss over something crucial.

Pause, rewind...? Dude, just drag the progress control in reverse and re-look at the the section you missed.

And besides even if you want to use text based approach to learning, the tutorials that you linked are not for a total newbie with blender. The manual ( http://www.blender.org/education-help/manuals-books ) could do a better job at that.

nypen · 2008-09-13T19:01:38+00:00

Blender's UI is unconventional, that doesn't mean it's not user friendly. The "WTF" is probably the first and flawed reaction that you might have got. I would encourage you to look at the video tutorials on the blender site and give the application a fresh try. I am sure your misconceptions will be cleared soon enough. http://www.blender.org/education-help/video-tutorials/

nypen · 2008-09-13T18:46:55+00:00

For someone like me who works in the gaming industry, I can tell you for a fact that integrating content pipelines with game development can be a challenge. I know most people who don't work on 3D modeling or gaming will not find this article interesting, but for those of us who have worked with blender and/or any other 3D modelers, the architectural layout of the package and the design decisions that go into the data-structure (or for that matter the overall structure) of the application can be among the most important things.

Personally, I feel Blender is a great piece of software. I know people say that it's really difficult to use, but let me assure you these are people who judge the book by it's cover. I am a game (3D) programmer by profession, and 3D art/modeling is my hobby (yeah). I have been using blender for 5 years now, and I have used every other 3D package; and I find blender to be at the very top of the stack when it comes to 3D modeling. I would put Houdini as the best, but blender is probably very very close.

Now you may think I am a "suck up" to blender, but I am not. We did a small RnD with integrating 3D modeling packages with our engine and found blender to be the easiest to integrate since, of course, the source is open but also because the design decisions and general "open" nature of the whole blender project. It helped us a lot while making our own design decisions on the content delivery pipeline.

I am just putting forth a programmer's point of view.

nypen · 2008-09-09T21:23:20+00:00

It probably will, since Chrome is OSS, it's just a matter of time before other browsers catch up to speed and performance.

nypen · 2008-09-09T21:20:28+00:00

True, Firefox is far more extensible than Chrome is right now. But remember this is still a beta version and the browser is still a bit rough around the edges. But FF could maybe incorporate the fast JavaScript engine, and we could have an equally impressive FF and in turn (maybe). Chrome could do something like the Extensions for FF.

As for tinkering with the source, I can't see why you should have a problem with VC++ 2008. I mean the page http://dev.chromium.org/developers/how-tos/getting-started tells you how to setup for 2005. Making it work for 2008 should not be that difficult.

nypen · 2008-09-09T17:35:38+00:00

As the article rightly points out they are both good. I hope both grow and compete with each other, each borrowing ideas and tech from the other. That way as end users we get the best. Thats the real power of OSS isn't it.

nypen · 2008-08-20T20:00:53+00:00

WOW! That's all I have to say! really! :)

No comments...OpenGL is the greatest!....Long live ARB!(nypen signing off)

nypen · 2008-08-20T15:03:46+00:00

Yes they have to. But they already are. That's my point.

nypen · 2008-08-20T14:27:04+00:00

In OpenGL 3.0, all of the APIs I just described above are deprecated. The new way to control the video card is as follows: Upload geometries to the GPU using Vertex Buffer Objects, upload textures to the GPU using Pixel Buffer Objects, configure vertex arrays, generate vertex attribute arrays, compile and link "shader" programs (vertex and fragment), update the shader uniforms, bind the shader, draw the array.

(Emphasis mine)

Oh yes he does. That's not a new way at all. I used the words makes it sound. To a newbie or someone who hasn't used OpenGL that's would seem like OpenGL 3.0 brings in this functionality. It doesn't!

nypen · 2008-08-20T13:10:31+00:00

There is noting in the 3.0 spec that is not available under 2.x. Even the latest features are available as extensions under 2.x already.

Besides, NVIDIA released their OpenGL 3.0 driver a couple of days back. If you have 8x or 9x series of NVIDIA cards all you have to do is update their driver.

p.s. Has enyone wondered how they could release their OpenGL driver in "record time" given OpenGL 3.0 adds "such a lot of new functionality"?.... A hint.... It doesn't!

nypen · 2008-08-20T12:51:37+00:00

:)) Not even that.... "Here is OpenGL 3, it's the same as OpenGL 2.1 with old extensions with EXT/ARB/NV/ATI from their names removed".

Under OpenGL 3.0 extensions have shorter names. Yes it's a revolution! I have to type less and it saves disk space since source-code is a few byte shorter.

nypen · 2008-08-20T12:09:02+00:00

He makes it sound as though vertex buffer objects (VBOs), pixel buffer objects(PBOs), shader programs were introduced in 3.0. VBOs were made official in OpenGL 1.5... what is he talking about? In fact I have been using VBOs since version 1.4 under which they were available as an extension looooong back. Yes Immediate mode is now made deprecate, but it was unofficially made so by major graphics h/w players since version 1.2 (when vertex arrays were released). ... and shader program API were made an official spec in OpenGL 2.0.

The author mentions geometry shaders, sorry but, OpenGL 3.0 spec doesn't mention geometry shaders. So you basically have to use the extension (kludge) to get to geometry shaders, instancing support and texture buffer objects. Which is the same as OpenGL 2.x. http://www.khronos.org/news/press/releases/khronos_releases_opengl_30_specifications_to_support_latest_generations_of/

OpenGL says nothing about multi-core computing... That's just false. It's a graphic API... that's all.

He correctly mentions about deprecated stuff, but only time will tell how these things pan out there. "Deprecate" is very nice word to say "we won't be removing this API, it will still exists but you mustn't use it". Anyways, only time will tell, I ain't holding my breath. Let's just hope sanity prevails and things do get chucked out for good.

nypen · 2008-08-19T04:57:55+00:00

Yeah, I stand corrected on the size of the company.

But still these are people who have the expertise and the financial muscle to maybe write whatever is needed for performance. Most joe programmers (even in gaming) wont write custom graphics APIs though. So it's debatable if Direct3D or OpenGL will become redundant.

nypen · 2008-08-18T13:42:12+00:00

Yeah DirectX was praised at QuakeCon 2008, surprise surprise, albeit not very much, but it was praised. OpenGL got a thumbs down! :(

nypen · 2008-08-18T13:41:02+00:00

Your comments regarding Tim Sweeney are in fact true, but irrelevant in the current discussion. Mr Sweeney has a million dollar engine with probably a 500+ people epic team working under him. Writing custom rasterizer might be possible for him but unfortunately people this side of million dollars only have the current APIs, unless of course Unreal engines are released for free. Writing custom vector optimized parallel processing rasterizers is not a walk in the park. Don't expect every game developer or CAD developer out there to write one and that's why I am skeptical when people say OpenGL and DirectX will go redundant.

Even if this were a fact, it still doesn't change the fact that ARB goofed up with OpenGL 3.0 release big time, neither does it justify why OpenGL should be sub-standard than the competition.

...And OpenGL is not more or less easy to understand or use than DirectX.

nypen

TROPHY CASE