Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Sep 2000
Offline Last Active Oct 19 2016 03:13 PM

#5033879 Experience without a degree

Posted by on 18 February 2013 - 02:13 PM



I started in this industry at a time where most people had no degree...either from just not bothering or 'dropping out'.  Degrees became a little more the norm over time and as such there came to be a point along my path where most people new to the industry did have a degree and I was largely surrounded by quite a lot of 'qualified competition'.


i.e. I've been through this.


As a result, I spent many a year around that time wondering whether to get a degree or not.  I never did take the leap and nowadays I’m glad about that, as the time would have been wasted.  The only thing that really mattered was that I was always able to do the work and after years of doing that, the relevance of a degree that I might have taken time to earn 10, 15 or 20 years ago is just obsolete.  Nobody really cares nowadays and for the most part never legitimately did, either I just have much more experience than most people around me which nullifies their issue or, they have enough experience in addition to their degree to now understand it doesn’t matter.  Stick with it and you will find yourself in the same position.


People can be a judgmental as they wish but if you can do the work they will never have a legitimate complaint so please bear in mind that this speaks more of them, than any failure of your own.


Thus, I agree…if you do get it, do so because it adds to your skillset and not to get a +1 in the eyes of your shallow colleagues.


I would also add, the best +1 you’ll get is working with them and holding your own, especially if they ever struggle on something and you can help them out.  This will serve as experience on their part and help them overcome their issue.  Resist the old ‘well, look where your fancy bit of paper got you’ dance either way because that will just distract such people from appreciating your own efforts.

#4999340 Convicted Felon as a game programmer

Posted by on 09 November 2012 - 10:43 AM

You want advice? Well, if after all that you've decided to get on with life and are going to U of U, it looks to me like you're already rebuilding things positively.

Just get on with things as you are. You will never shake this off (you already know this) but don't fear it too much because the impact it has will lessen over time. In deciding what you want to do and just getting on with it you're accepting the thorn in your side that it is. It's better you try this, than write yourself off as a career criminal and don't try...or worse. It will become a much smaller thorn quite quickly if you stay on the straight and narrow, perhaps even set an example for others.

Doing well at school, will put it one step behind you and potential employers will have something both more recent and positive to focus on in hiring you. Do well at your first employment and I think other potential employers will trust that you're not the kid who made a mistake, but a potential employee.

Although you might find some places that won't employ you, I'm sure you will find many who will overlook it especially for something done as a minor. When it comes to applying for jobs, be up front about it but personally I would say 'not so up front'. Putting this in your initial application is probably not a good idea, but I would say that if you're invited for interviews you need to start thinking about talking at that point to their HR. In this industry, usually there are phone interviews and I would consider speaking about it at that point and possibly follow up with an email to the hiring manager or HR. In both cases, explain that you have a history, aren't hiding it but wanted to get chance to speak first and you were always going to be 'up front'. If you are following up with something in writing after a call, then point out you were up front in the call, backing up the idea you were up front at the most appropriate point.

Get references, including those of the character kind along the way. College professors will be quite ideal for this because what they think will be respected. Get a job while you are at college too, for the same reasons - effectively showing that you are a reliable employee.

Be careful what you get up to for the next few years and if you're ever in a place where you could be in trouble with the police even just by association, think about not staying there. Party with weed about...consider going home. At a bar...don't get too drunk, avoid getting into fights, etc. You don't have to be an angel by any means, just don't take risks.

Do remember that we all have skeletons in the closet one way or the other.

Incidentally, do bear in mind the above 'do computer science over game design' is common advice around here and with very good reason. If you are intent on programming and can change that over, I would.

#4998255 Rendering to texture(s)

Posted by on 06 November 2012 - 05:36 PM

It doesn't matter if I add a renderbuffer or not, as long as I have a depth-texture target the screen is black
If I don't have depth-texture target it draws fine, just without depth-testing anymore

So, with no test it works but with a test it fails. It sounds like the test may be wrong or at least not configured how you expect it to be. At least make sure glDepthMask, glDepthRange and glDepthFunc are set as you expect them to be, personally it sounds like your fragment output is rejected due to depth working but not as you expect.

It's probably also worth reviewing (googling) the concept of 'framebuffer completeness' to be more certain about what you understand a framebuffer can/can't do. That will cover the necessary minimum and clarify what attachments need to be in place.
Checking for framebuffer completeness via glCheckFramebuffer status is a good idea and may help to debug any obvious errors you might have. You will find the concept of rendering to a depth buffer alone is considered 'incomplete' which is possibly where your actual problem might be. This might be specific to GL ES, but is worth checking anyway.

Specifically, what you might be witnessing above is a misconfiguration of depth parameters when you do have a renderbuffer and when you don't (if I'm reading your 'chain' correctly), you may have a framebuffer incomplete problem.

#4986922 TDD in game development?

Posted by on 04 October 2012 - 04:05 PM

1.) Is TDD applicable to game development? I'm guessing the answer is yes for large projects/teams, but I don't know about small project games like what I've mentioned I've done/am working on.

It's applicable to development, so game development would not be ruled out...but it is something that you'll find is practiced more widely outside of games than in, although there is no particular reason for that.

It can apply to small projects just as appropriately as it can to large projects. Larger projects are in some ways more difficult if the entire team is not using the technique, because other team members might break your tests or you'll keep the tests very small and based around what you author only, possibly at the sub-feature level.

But do remember there is more than one way to boil an egg. Some people get similar benefits by doing other things and some people just frankly have a preference for one thing over another. There is no single correct methodology and if there is a best one, it's often a mixture of things anyway.

2.) If it is, what kinds of tests would one run?

A test, which will likely be a set of smaller tests but collectively considered that validates whatever feature you're implementing. These will be tests that confirm you get an expected output for the given input, Fake and mock tests that simulate real use of the code, either in full or in part and so on. A test that takes you through the entire 'use case' of the feature or code, possibly from initialization, gathering the results/output and validating them as being valid and/or within certain constraints and testing even the destruction of the system to finish.

The general idea is that the tests also define your requirements, so TDD is often considered efficient because you're not authoring a whole lot of imaginary requirements or documents elsewhere, you're doing the requirements, the tests and the code pretty much all in the same place which many people consider is productive.

Also, it can also include tests that test memory and performance impact...particularly if you have specific requirements there.

If you are working on an object, you might run a test every once in a while to make sure the object is in a correct state at any one time, sometimes people try and keep an object in what is known as a class invariant state for example which basically means it's never broken between operations, or at least that kept to a minimum. I used to work at place where as part of their coding standard, each object had an 'invariant' function that would be asserted to be true at various points. Such a function can play a role in these tests.

Basically...whatever tests you want, but enough so to validate against your requirements. Anything less is not really TDD, although that doesn't necessarily mean less is not still valuable.

Is it a good idea/worth learning? etc

It's a good idea, but like many good ideas they often represent more of a personal preference and/or is going to be based on your own personal situation, the sort of code your are authoring and so on. Some people take to concepts like this well and others just feel it gets in the way, or they might not benefit from it much so it's nothing but overhead. It's productive and productivity is a good thing, but you need to figure out whether the productivity it offers you is valuable and/or enough to justify it.

Start small, definitely more at the class unit test level rather than testing higher level features and the entire output of a program or specific feature. This will let you dabble in it without diving in head first. i.e. if you're interested, do enough to figure out how much personal value this is to you and whether or not you want to spend more time on it.

Try and figure out whether it'll be productive for you at both the small and large scales i.e. at class level,more of at the class unit test level or at the feature level...or both (again thinking in terms of many small results sum to a big result). You'll have to also maintain, develop and iterate the tests you author so you need to understand whether that's overhead for you or not.

Ultimately, you need to determine that you can accept the overhead and consider it tolerable, understanding whether the net result of all the work still yields productivity or some other benefit that has value to you. You might actually suffer a productivity loss from any concept such as this, but consider that to be okay given the quality of code coming out of the other end. Again, that's a very personal decision and assessment. Programming is all about making trade offs and not all have black and white results.

Bear in mind that it can help to put together an extensive framework to run these tests. I don't recommend doing that initially, but there is a point where if you take this on running many little tests all the time by hand becomes cumbersome so do consider that if you run with this, it is quite inevitable you'll spend time automating the entire process. That will payoff in the long run, but there'll be a period in time where you're not working on new code and putting together a framework and build system.

#4986402 How much math do I need to use directx?

Posted by on 03 October 2012 - 08:49 AM

Its been my dream to make a crappy hobbyist quality 3d engine, but if i need to know a truckload of math that would be a hearbreaker =(

Bear in mind that a lot of the knowledge you need to do this to the level you mention is actually what you can pick up from DirectX tutorials and books, which you'll have to do anyway if you're new to DirectX.

A couple of people have commented on that sort of thing as a possibility and/or whether or not it's a good idea, but I would classify it as giving it as go or 'making headway' as GeneralQuery mentioned. I think the advantage of doing that is that you'll learn more about your own limitations during the process, including understanding whether you need to pick up a little more math knowledge.

If you already know calc 1 then do consider that through practice and application, the fuzzyness you describe will disappear and you are somewhat already set up to be filling in blanks from other math topics.

Also bear in mind that there are many 'graphics programmers' out there who don't necessarily operate at the cutting edge of R&D and are quite often following others. Really, the idea these same people are top math students or not is more a measurement of how much more easily they'll be able to devour white papers to follow new research but even the lack of an ability to do that does not preclude a lot of people from developing 3D engines. For many, it just means they're devouring knowledge at a different (higher) level, perhaps after others have turned said white papers into tutorials and pseudo code, in other cases it's often using libraries developed by others and gradually picking up the knowledge that is initially quite alien.

#4986155 Which versions of OpenGL is not worth to learn anymore?

Posted by on 02 October 2012 - 01:18 PM

And what i probably will be missing ,if i start learning OGL 3.3 now, after a year ?

3.x is a fine target and I'd second the very specific 3.2 as a good place to be. 2.x can still be quite popular and/or relevant but for the most part I'd be hard pushed to say you'd miss anything because improvements were made and a lot of older cruft has now been removed. Chances are you'd be missing more by going with an earlier version, if only because some of the now mandatory good parts were previously optional and you might just overlook them for that reason, which can also be a little misleading.

#4982529 [iOS] Drawing Anything Causes Terrible Performance

Posted by on 21 September 2012 - 05:09 PM

I don't think you can tell based on whether or not it is distorted or whether or not other things are seemingly correct - I seem to think your other gl calls will correct distortion alone regardless of whether it was allocated/re-allocated for the current orientation or not and this particular oddity is very much a non-obvious under the hood thing anyway.

If you think everything is okay, it probably isn't this problem, but yes if that's where you think you are then the easiest way to rule it out is to do this very specific profile. This 'fast path or not' test is in the Core animation profiler. You'll want to be looking at the core animation options (not the time profiling ones) and under that, the debug options. Check the 'Color OpenGL Fast Path blue' option and run the app. Everything that is rendered via the fast path will be colored with a blue tint. You might however also like the other profile options in here too, but I'd flick them on and off one at a time only...you'll see why.

I believe this profiling tool only works on the main renderbuffer - not an off screen target so if you're rendering to an off-screen buffer then doing a copy/present (as you appear to be) then only the whole screen will be blue (or not), but that's enough to expose this problem in this case. For direct to renderbuffer rendering this is actually a pretty useful tool as it will highlight individual polygons that for some reason have fallen back to the slower path.

Bear in mind that if you are on the slow path then it can be for other reasons too, not just this - but that's where you'd go back to the source code and double check.

#4982462 quick question about OpenGL

Posted by on 21 September 2012 - 12:58 PM

I read on some recent thread that OpenGL is backwards compatible with obsolete code? So that means if I were to pick up a book from 7-8 years ago, the code would still run without any tweaking on the newer version of OpenGL?

Don't count on it. New functionality in OpenGL often comes in via extensions. Often, the extensions were such a good idea they were then adopted into the core profile in the next version and whatever was the common practice prior has often been deprecated and won't work unless you specifically choose a version or a legacy compatibility mode.

There's so much OpenGL reference out there that it's actually quite easy to be looking at an older example and not realizing why it won't work. A good example of this would be based on vertex data. The original methods were dropped a long time ago and just about everyone knows that, but things like vertex buffer objects were still optional at that point, yet by 3.X were mandatory. A lot of 2.X examples will compile under 3.X, but won't work...and there are an awful lot of examples out there that are 2.X but not obviously so. To add to the confusion, you'll find a lot of reference where people think they are talking about vertex buffer objects but are actually talking about the predecessor. Then you've got the idea that the internet is also littered (due to the boom in mobile development) with current Open GL ES examples, which might work in 2.X but not in 3.X for the same reasons.

For OpenGL, make sure you have the latest references and if you go looking for examples, try and ascertain the version. Also read the spec, but bear in mind a few key things are described sometimes in just one not very obvious sentence in the open gl spec. RTFM doesn't always apply with open gl due to non-obviousness, even if the information is actually there.

Is the same true for directx?

To some extent yes, but largely no.

For starters, DirectX doesn't have the problem introduced by mobile/ES.

I'd also say that generally, it's a little more obvious when looking at DirectX code which version you're looking at. A lot of this has to do with the idea DX9 was prevalent for a long time and a lot of the examples of DX10/11 are not only flagged as such but also do have some obvious differences and as yewbie mentions, many of the newer features force a differing implementation in the surrounding code. This is very much different to the Open GL vertex buffer objects examples I mentioned above, which look very similar between versions, often with the same function call being used with the only difference being one parameter.

DirectX may at least in part suffer the same problem over time - we could find ourselves in a position at some point where the wealth of DX9 examples are nothing other than misleading.

I think at some point, were going to need some sort of internet command to delete old information or search engines that filter/age out results more intelligently. We'll also be much more thankful of things like Wiki's too - where someone else will come and delete whatever old example I posted 25 years before I died.

#4982454 [iOS] Drawing Anything Causes Terrible Performance

Posted by on 21 September 2012 - 12:24 PM

Quick check...but was your renderbuffer storage allocated at a time where your orientation was the opposite of what your game is generally running? Even if orientation did not change (program might start out thinking it's portrait when it's not)? If so, reallocate it. I've seen large frame rate drops for that reason, although not as low as 30fps. It's worth ruling out though given it's a similar enough problem to yours.

A quick way of checking this would be via looking at the code or recollection from memory of course, but also don't overlook the Core Animation profiler and seeing if the non-fast path rendering is kicking in, not just for this reason but for others too. Definitely check that tool out because it's often overlooked in favor of the more comprehensive profiling options yet a handful of things it might highlight won't show up elsewhere.

#4982125 OpenGL vs DirectX

Posted by on 20 September 2012 - 01:03 PM

Neither are bad and both have matured well enough, appropriately and look to be continuing to do that. If the platforms you're targeting don't force the decision somewhat, then I'd look into both and make a personal decision based on preference. I'd also say that if you have the time, consider doing both anyway...your own software architecture will be much stronger when based on concepts supportive of both targets.

So...find a reason to rule one or the other out (such as platforms) and make the decision easy for yourself if possible, if that's not an option try both and make a personal decision and if you can afford the time and effort, do both, or at least do one in full and keep your hand in the other anyway.

Either way, never say never. I did that and was never a fan of Mac's, so if five years ago someone was to suggest to me that I'd have spent last year on Open GL ES doing mobile and this year on Open GL 3.2 and Mac, I'd have thought they were on crack yet it's been surprisingly good fun. The Mac is a fairly decent platform for OpenGL development actually.

Direct3D or OpenGL...you'll have good fun on either or both paths regardless.

#4960497 Complete beginner

Posted by on 18 July 2012 - 08:58 AM

I'm a complete beginner at programming, I tried to teach myself C++ a while ago and it all went downhill. I struggled a lot with it and was really put off, but I've always regretted giving up.

Persist and keep trying, if not with C++ then something else. At some point things will click and probably sooner than that you'll realize that you did learn something from your prior experience, even if you think a little negatively of it now.

Bear in mind that a little of people have difficulties learning some aspects of C++, including and commonly things like pointers. Don't worry too much about this, just keep trying with such concepts and eventually it will fall into place. We all went through this and if it held us back which is comment, it was eventually proven to be a temporary setback, as will your challenges.

I made a topic a while ago about dyscalculus and programming and many people here posted about how they'd dealt with it so I've decided I'm going to work on it as well, but I don't know a good place to start.

I don't have much knowledge of that in particular but bear in mind plenty of programmers have one issue or another that holds them back. I've always had a problem remembering formula for example and while it is not as serious as dyscalculus I do have to more or less constantly look things up.

Also bear in mind that programming and math have a strong link, but not all programming involves doing math. Doing non-math programming will help eventually bust through the barrier of other challenges.

What languages would you suggest for a total beginner? And what books?

Don't know about current books and for the most part I'd say 'use the internet for the same' anyway, but as far as languages go a lot of people recommend C# over C++ as a first language.

Personally I would try several different languages and in addition to C#, try Java and Python in order to get a feel for which one you like best and are going to be most comfortable with. While all languages are different, there are many traits that are shared and learning one will help you learn another. Finding what is easiest for you will either way help you learn the language you eventually desire (even C++) and you won't be wasting time looking at any of them because what you do learn in one language, even if it does not transfer directly (and it often does) will broaden your knowledge and experience FTW.

Because I'm interested in Game Development is it advised I focus on that area more so? Or just programming in general?

You don't need to focus on games to learn programming. There are many examples of small games however that do make good exercises. For whatever aspect of a language you are currently learning, follow whatever source material you use (books/web) and learn with their examples first. Then I would search the web for other examples of the same language aspects, which should introduce you to other programs which use the same. This'll tell you a lot about how the various concepts are applied, which should give you good ideas for how you might want to pursue exploring them further, via a game or whatever.

That's actually a masked suggestion to look at other peoples code as often as possible. You'll learn a lot from others, both good and bad ways and experience will eventually guide you down the good path...but don't be scared to learn the bad either. You need to crash and burn in order to take the best path later on.

Don't try anything too big until you have learnt enough. How to judge that? Well, you'll gradually sense this more than anything and it won't hurt to start things and then try something smaller. Testing your boundaries like that is par for the course. You may not realize this, but you've already been doing this by the sounds of it.

Time and patience is more the issue than anything else. If you have those, try out various languages as I've mentioned and take your time to do whatever you feel comfortable with.

Also...just ask, as you have done here. There are plenty of people that will help with whatever you are stuck on so in many ways there is no need to even go near the highest levels of frustration.

#4959772 Personalizing my portfolio + feedback

Posted by on 16 July 2012 - 03:50 PM

Not bad stuff at all. A little more than 2c from me...

Like Ashaman, I too found the navigation a little clumsy. I think the intention here is good and it does look at little better than a basic alternative, but it does have issues.

Part of the issue for me is the idea of using mouse hover to open up the menus progressively. Too easy to miss the target and cancel the progression IMHO, so I think this is always done best by responding to clicks and I do think that would take one level of clumsiness away.

I can see however that it does respond to clicks, but in two ways. For the leaf nodes, I think what it does is okay - I select one option and it gives me a final page for that project. For the non-leaf/intermediate menu nodes (portfolio->games and portfolio->tree) the fact that clicking on it doesn't open up the leaf node, but adds yet another page presenting the same information as the intermediate non-leaf node is something I find a little clumsy too. The idea that this can occur as it's rendering the leaf node menu (drawing it from top to bottom) also looks odd because some times it's doing both - it gets halfway or full way through revealing the left node menu and then flicks to the left mode page, removing the menu it looks created. It either looks like a bug or just doesn't present well, or both.

I would present the leaf nodes consistently and again, in one way only - either as a page, or as sub-menu items but not both. I do prefer the menu myself, although not with the hover selection as explained.

Each of the demo pages appears to have what initially looks to be a slideshow of static screens with videos below. It's not actually obvious that the slideshow is a slideshow of videos and it was only on the second time I looked at the entire portfolio that I realized that wasn't the case. More important people looking at this (potential employers) might make the same mistake and not give it a second shot so I do think this is an issue because some of these 'screenshots' just look too basic* until you realize they are a video.

Part of the issue here really is that you do already have something that is obviously an embedded video and you have something that looks different, so naturally you think it is not video. The fact that does play as a slideshow and responds like one when you click on the dots doesn't help either and further adds to the idea these are not videos. It's also a little clumsy interface on that video/slideshow thing too - sometimes I click play and it just goes to the next video, which again confuses me as to what it is and how to best control it. I would do away with this control to be honest.

Either way I would make all videos look like videos in the same way - presenting them with the same control consistently even if you have to put more videos on the same page and not use the video slideshow type control (or make it a screenshot slideshow). Because this might increase the # of videos on each page I would also take some of the more basic videos off - there's no need to show solitary bouncing ball videos when you have ones with 100's in for example.

Finally, the list of features for each demo is fine but I would put paragraphs below that with more technical detail. It wouldn't look out of place and of course, reading it is optional. It therefore adds, but not takes anything away.

#4955384 virtual d-pad in game

Posted by on 03 July 2012 - 12:18 PM

How I do mine is to look for the first touch within a given area of the screen. When that occurs, I mark that as the center point of the stick. I'll draw an axis at that location from then on.

As that touch moves, I simply subtract the new coordinates from the original to figure the amount of deflection of the virtual stick. You can scale these deflection values to whatever you feel will work best for you...left as -1.0 and right as 1.0, or percentage values...whatever works best for your purposes.

I render a blob of some sort at this point where the finger is so I can see how far it is deflected. The graphics of the virtual stick are therefore an axis and a point blob showing the deflection.

There is usually a limit to how far you can deflect any stick. A physical stick, will naturally have a physical barrier and this is not present in the virtual equivalent. Therefore, you must usefully account for this lack of feedback the player would normally have.

The most important thing to take into account is not to all of a sudden 'cancel' the input just because the finger has moved beyond the maximum deflection from the origin. If you're moving a player, the player will just stop if the input is cancelled. This could be argued as feedback, but this stop moving, correct your deflection and start moving again cycle is far too frustrating for many games and players. Therefore, let the finger go beyond the stick and simply clamp the deflection only, not disable it. The deflection should also follow the finger, even if it is moving outside of the graphic representing the virtual stick. The benefit of this is that you do away with the need for a player to receive feedback from what would normally be the physical constraint imposed on moving the stick to a maximum deflection.

Ideally however, you will still give the player some feedback regarding how far they are deflecting the stick. The axis is part of this, however this is not convenient to look at. Instead, focus on providing a visible response directly where the player is looking. The most convenient example of this would be moving the virtual player proportionally according to the level of stick deflection - exactly what an analog control is for.

In full, this technique allows for a virtual controller with a floating origin (wherever your put your finger down you'll get a virtual stick). A virtual controller just doesn't have the physical feel of the origin so the advantage of this is you don't have to remember or use 'muscle memory' in order to determine where the center of the stick was. If you wish to return the control deflection to the origin you simply lift your finger and replace it. You learn this little trick very easily and it quickly becomes natural.

Some argue that fixed origin is better for a virtual controller. The implementation for a fixed origin stick is not much different to the above - just fix the origin and never move it. Personally I find these to be a little annoying if only because a lot of them don't offer any configuration with regard to the location of the stick. This will mean the location may not be ideal depending on the size of your hand - typically you use your thumb so depending on the location, your thumb will be cramped or stretched to use it which is uncomfortable.

Of course the downside of the floating origin is that you have to keep your finger on the screen or the origin will reset and your deflection is lost. Also, with your first touch defining the origin then to deflect the stick straight away you have to put your finger down and then move it. You can't just put your finger down and have the stick deflected straight away, as you can with one of fixed origin.

I still prefer floating though. Tablets are large and despite being light, they are not light enough to hold easily for playing with virtual sticks while pressing on the screen. At least for even a small duration I think this is uncomfortable. Allowing the player to therefore re-position their hands as often as necessary helps them to constantly loosen their grip and flex the hand, which I think is essential. Requiring a fixed pose for the hand for the entire duration of play, even if it is minutes can be excruciating and this is a big problem for a fixed virtual stick.

Despite my personal preference however, I actually think games should support both fixed and floating types...it's almost no effort. I also think that given the sticks are virtual, it's also correct and almost zero effort to support left handed configurations. There is no physical constraint to this, so why not?

#4955092 Android - partial transparency

Posted by on 02 July 2012 - 04:57 PM

Use the blend functions for transparency alone:

glEnable( GL_BLEND );

There are several blend functions so it might be worth reading up on them here.

If you're looking for an aura from transparency then you could also do something in the shader based around the incoming transparency value.

Bear in mind that for making the character go behind the wall, simple depth pixel tests might suffice for that. If depth fails, you could use the incoming transparency value to write your aura over the wall. You could also just use the painters algorithm (drawing in a particular order) to bring one or the other to the front.

You may also consider a render to texture pass for the wall layer. This would allow you to read that layer into your shader as a texture so that it could be taken into account along with the transparency value as you write your final image. This would certainly let you take the wall into account as you decide which pixel to write, but it really may be overkill.

For basic transparency alone though go for the basic blending above so you don't overwork the shader. The link above may lead you to a blending equation that keeps things simple.

#4949345 Singleton pattern abuse

Posted by on 14 June 2012 - 04:55 PM

Here's the official description of the 'intent' of the design pattern in question…direct from GoF:

Ensure a class only has one instance, and provide a global point of access to it.

Everyone seems to know this. I just provide that more as reference than anything but I note there are really two parts of the intent…some people get hung up about the whole global part and miss the ‘one instance’ bit, but many folk of course don’t too.

Now, one by one the so called 'consequences' as documented by GoF:

1. Controlled access to sole instance. Because the Singleton class encapsulates its sole instance, it can have strict control over how and when clients access it.

Controlling access is fine. I understand the comment on how the ‘how it is accessed’ is controlled but I don’t quite understand the comment regarding the ‘when’. According to the pattern any code that has access to this can do so when it wants. The only mechanism related to time that I am aware of is that the point of first access ‘may’ also be the initial construction. Even if you are controlling the construction to the point of first use and access, you may not know when that occurs unless of course you manually force it before any other code does.

Either way, I don’t think this is really an interesting ‘consequence’. Nothing wrong with it, but I don’t feel it helps to justify the pattern.

2. Reduced name space. The Singleton pattern is an improvement over global variables. It avoids polluting the name space with global variables that store sole instances.

Okay. Fine. At least it is an improvement over the global, but it’s very marginal one at that. One could argue it maybe feels a little better, a little cleaner…but then again the general unpopularity of the Singleton might actually suggest a global is more easily and widely acceptable for cases where there is felt to be no other option.

Personally I don’t think this really adds much justification for the existence of the Singleton.

3. Permits refinement of operations and representation. The Singleton class may be subclassed, and it's easy to configure an application with an instance of this extended class. You can configure the application with an instance of the class you need at run-time.

This is a more interesting 'consequence' which on the surface seems a little more useful than #1 and #2. I wish they'd have elaborated on this a little more in the book though because ‘as is’ I think it’s open to some interpretation. At least I think the methods where one configures an application with an instance of this extended class might generally be other unpopular techniques so I wish they’d provided an example of it. If there was a good clean option for this it might actually get around some of the dependency issues Singleton’s proliferate, which could address quite a lot of criticism.

I would question however why you might want to subclass a Singleton? I can only assume this would be to return a more specialized version of the sole instance you’re wrapping. That seems a little closer to ‘factory’ type functionality that might be focused on a single instance. Of course it could be argued that a Singleton is a single instance factory really, but then the whole topic of ‘what happens when you need more than one’ crops up still.

4. Permits a variable number of instances. The pattern makes it easy to change your mind and allow more than one instance of the Singleton class. Moreover, you can use the same approach to control the number of instances that the application uses. Only the operation that grants access to the Singleton instance needs to change.

I find this interesting to think about, if only because it appears to address some of the ‘what if you need more than one’ criticism. It’s almost as if GoF saw this coming, or at least are acknowledging the issue in some way.

Of course, they are right…if you have a Singleton it isn’t too hard to modify it to address this common criticism. Now at that point it will no longer be a Singleton of course, so this particular ‘consequence’ doesn’t justify the case for the Singleton either. After all, any code can be modified and refactored with varying effort – changed from one thing to another...so what are they really saying here - 'this has the same advantage that every other pattern has?'

On the other hand, you could argue that if you were to follow this path of multiple instances then you just lose one half of the intent. Unfortunately that half is the ‘single instance’ bit, which leaves the remainder as just a fancy way of getting at a global.

5. More flexible than class operations. Another way to package a singleton's functionality is to use class operations (that is, static member functions in C++ or class methods in Smalltalk). But both of these language techniques make it hard to change a design to allow more than one instance of a class. Moreover, static member functions in C++ are never virtual, so subclasses can't override them polymorphically.

The way I read this is one of acknowledging the alternatives to a Singleton class – getting to the same objectives by different means (i.e. not using ‘the pattern’). Again this is something that often comes up in these arguments against the Singleton. The text goes on to explain why a Singleton is a better alternative though. I do think there’s some truth and fair comment behind this ‘consequence’, but you can also say the same about the alternatives.

I thought I would post some of the official text because quite a lot of people may have never read it and could be interested. If you have read it, you’ve likely forgot it or don’t care to remember too.

Note: I really should know better than to join in any discussion of this topic.