Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Dec 2005
Offline Last Active Today, 08:10 AM

#5178904 c++/SDL2 and various platforms rendering

Posted by Bregma on 08 September 2014 - 11:48 AM

However, what concerns me is what happens on other platforms? Will SDL2 use whatever version of OpenGL is on the machine, or if none available (like on some phones) will it choose the ES versions or another rendering option (with last fallback of software rendering)?

If the version of OpenGL you specify in the context flags is not available, you get a failure.
The default context in libSDL2, for a device that supports OpenGL, is OpenGL 2.1.  That's most desktop devices these days.  Most desktops provide binary support for later versions, too, even if it requires software rendering.  An extension wrangler will help with forward-support on older contexts.
The default context on a device that does not support OpenGL but supports OpenGL|ES 1 is OpenGL|ES 1.1.
The default context on a device that does not support OpenGL or OpenGL|ES 1 is OpenGL|ES 2.0.  That's most mobile devices these days.
The default is to not use EGL for OpenGL and to use EGL for OpenGL|ES.  Some platforms (eg. Wayland and Mir on Linux) you want to use EGL for everything otherwise you'll get failure, some it doesn't matter (X11) and others (Microsoft Windows) will fail if you try to use EGL for OpenGL..  You may need to probe to see what's supported.
Your best bet is to explicitly set the desired OpenGL version before opening the window, and write to that version.  You may want to use an extension wrangler, and you may want compile-time selection between Gl and GL|ES code paths where the two are API-divergent.

#5178631 Critique my approach to writing RAII wrappers

Posted by Bregma on 06 September 2014 - 08:20 PM

If you're not acquiring a resource in your constructor, you're not implementing RAII.  You're not (necessarily) writing bad code, you're just not implementing RAII.


If you have instantiated an object that does not acquire a resource, it is not implementing "resource acquisition is instantiation".  It might be wonderful, perfect code that does exactly what you want in the best way possible.  It's just not RAII.  You might initialize an object to a known state, and that's grand, but if the purpose of the object is to acquire a resource, and the object can exist without acquiring that resource, it's not implementing RAII.  Simply initializing an object to a known state and freeing any resources on object destruction isn't RAII, it's just general object-oriented programming with deterministic destruction.


If you use RAII, the statement "if the object exists, the resource is allocated" is always true.  Also, the statement "if the resource is allocated, the object exists" is true.  It is a boon to reasoning about program logic.  But the point of RAII is that you never have to reason something like "the object exists, and it may or may not have acquired resource X, so...."


Standard containers are not an example of RAII.  The standard smart pointers are not an example of RAII.

#5178500 Critique my approach to writing RAII wrappers

Posted by Bregma on 06 September 2014 - 07:13 AM

AII is actually a total misnomer. The reason it's used has almost nothing to do with resource allocation (or indeed initialisation or instantiation) and everything to do with resource cleanup.

That's not correct either, although you're right that it's a bit of a misnomer, and resource cleanup is the mandatory sequelae to resource acquisition in RAII.


RAII means the object invariant is ownership of a resource.  Once the object has been constructed, you have the resource, and once the object has been destroyed you no longer have the resource.  If at any point you do not have the resource and you have the object, the invariant has been contravened and you do not have RAII.  Similarly, if you have the resource but not the object, it's not RAII.


The point of the invariant is that it's a guarantee that the object == the resource.  Both ways. Always and forever.


If you are using deferred construction (as frob was discussing), you are not using RAII because it breaks the object invariant.


If you have singular objects or nullable objects (eg. smart pointers) you are not implementing RAII (although you can use std::unique_ptr to implement RAII if you remove the move operations).  It breaks the invariant.


Things that do the above are valid and useful, but they're not implementing RAII.  You're not using RAII just because you clean things up in your destructor: that's just basic object oriented programming.


So yes, RAII is very very much about resource acquisition on instantiation, and also about resource release on destruction.  Like NVI, the tag for the idea is not a complete description of what it means but if you're not acquiring the resource on object instantiation, you're not implementing "Resource Acquisition Is [Object] Instantiation".

#5178497 GOTO, why are you adverse to using it

Posted by Bregma on 06 September 2014 - 06:43 AM

Perhaps you should read Dijkstra's original letter.


I have found the judicious use of goto for handling error conditions in pure C code to be advantageous: it allows for the explicit and graceful unwinding of resource acquisition.  I have never found any other advantageous use for the construct.  Source code is meant to be read by humans, and unstructured code offers very poor legibility.  I say this because of 30 years experience reading other peoples' code.  Most people write bad code; unstructured code is badder code.

#5178143 Critique my approach to writing RAII wrappers

Posted by Bregma on 04 September 2014 - 02:26 PM

RAII does not mean "allocate resources".

"Resource allocation is instantiation" does not mean resource allocation is instantiation?  What kind of wacky newspeak are we dealing with here?
Perhaps the simple answer is that if you can not control the lifetime of a resource, you can not use RAII to wrap it.  It's just not the appropriate tool for the job.

#5177968 Did I begin learning late?

Posted by Bregma on 03 September 2014 - 09:04 PM

When I read the thread title I thought the man was 50 years old...

Careful, I don't think I started learning Python until I was 50 years old and now I use it frequently in my day job.  By the time you're old enough to know you don't know everything, you already know you're not too old to learn new stuff.

#5177561 Did I begin learning late?

Posted by Bregma on 01 September 2014 - 08:14 PM

By age 15 there are already irreversible changes taking place in your body and even hormone shots will have limited effect in helping you become a Python programmer.  Perhaps with the help of a really good therapist and the love and support of your family you could be happy doing JavaScript.  In fact, many devops lead happy and fulfilling lives and nobody even knows what kind of foundation classes they have hidden under their every-day wardrobe.


It's a good thing you haven't chosen to become a doctor or a lawyer;  they need to have advanced degrees before they can even speak full sentences.  Don't get me started on how the life of a priest begins at conception, and circus clowns have to pie before they're even a twinkle in their father's eye.


Seriously, where did this weird ageist meme come from?

#5175456 Are degrees worth it for Level / Environment design areas?

Posted by Bregma on 22 August 2014 - 07:03 AM

I have some required reading for students, especially those in your position.

#5175111 Checkstyle

Posted by Bregma on 20 August 2014 - 02:47 PM

No need to strictly stick to the traditional 80 characters (as derived from when we coded via terminals)

Dude, you are sooo wrong.
It came from when we used punched cards, which only had 80 columns.  I still have boxes of them from when I was in university.  Those babies predate digital computers even.  Noah used them in the bible when he got the 10 commandments, that's why none of them are more than 79 characters (the first column marked the commandment as a comment).

#5174906 Ubuntu + Performance

Posted by Bregma on 19 August 2014 - 08:17 PM

Well, those hardware specs are better than mine, and I develop the Unity DE, so I think you'll be fine.


Keep in mind that when you're running in fullscreen mode with Unity you're going directly to the hardware:  compositing is turned off.  Use a lighter DE if you wish: Lubuntu or Xubuntu do not use a compositor, but you won't see much difference in fullscreen mode.


Don't bother looking for the proprietary Intel drivers:  they're a part of Mesa.  Intel open-sources their drivers and contributed them to and maintain them as a part of Mesa.  Mesa is not just software drivers.

#5174431 Event/Action Management

Posted by Bregma on 18 August 2014 - 06:46 AM

I've already encountered some pitfalls with this approach, particularly the catches with using function pointers, and void* variables, and was curious to see what other people were doing in this kind of case?

I see from the fact you're using std::map that you're already partially using C++.  You could go a step further and use std::function instead of the C way of raw pointers and void* and avoid most of those catches you've encountered.

#5173191 QT vs. wxWidgets for OpenGL

Posted by Bregma on 12 August 2014 - 04:21 PM

Coming back to QT and setting aside the development build setup are people's overall opinion on QT more favorable that wxWidgets?

Consider this: there is an entire Linux desktop environment based on Qt (KDE).  Canonical, the company behind Ubuntu, has dumped GTK as their toolkit of choice and is developing their new multi-platform desktop using Qt.  There is no desktop using WxWidgets.


WxWidgets is pretty close to a free clone of Microsoft's MFC.  Microsoft recommends against the use of MFC and has done so for quite some years now. 

#5173188 What's the industry like?

Posted by Bregma on 12 August 2014 - 04:15 PM

I live in Ontario, Canada - What's the industry like here?

Just a FYI, but Ottawa has a burgeoning gamedev industry, and local university Carleton offers a degreed gamedev program (not a coincidence).  It may be possible to both work in the industry while gaining specialized formal education there.

#5173078 Can't solve problems without googling?

Posted by Bregma on 12 August 2014 - 07:23 AM

A tourist had just arrived in Manhattan with tickets to a concert and didn't know his way around.  The curtain time for the show was fast approaching and the tourist was becoming increasing desperate to find the venue.


Finally, he approached a man walking swiftly and carrying a violin case, a sign he might have knowledge of the local entertainment industry.


"Excuse me," said the tourist, and the hurrying man looked up.


"Can you tell me how to get to Carnegie Hall?" queried the lost and desperate man.


The man with the violin case paused briefly and stared intensely at the tourist.  After a beat, he spat "Practice!!!" and hurried on his way.


To get good at something, you practise.  It's that simple.  Learning and repeating what others have done is one of the more effective ways of practising.

#5168624 C++ files organisation

Posted by Bregma on 23 July 2014 - 05:32 AM

I work with oodles of free software projects.  I've seen plenty with a separate includes/ directory and many that have them combined.  I've seen many with a deep or broad hierarchy and the same with everything dumped into a single subdirectory.  Technically it makes no difference and there is no de facto or de jure standard, it's entirely up to the taste of the most vocal or dominant developer.
Since packaging project source inevitably means installing into a staging directory, that isn't relevant.  Since installing means copying out of the sources into an installation directory, that's not relevant.
What is relevant is when someone comes along to try and read and understand the code, it's a lot easier when there isn't a separate include/ directory in the project, and the header and other sources files are all combined in one hierarchy.  I've noticed the most vocal proponents of the separate include/ hierarchy tend to be those who spend no time maintaining other people's code.  There is also no argument that in larger projects readability is improved by namespacing components into separate subdirectories and all include references are relative to the top of the hierarchy.  If each component produces a static convenience library (or, if required, a shared library) that also makes your unit testing easier.