Elysian Shadows

eatcomics wrote:

GyroVorbis wrote:

xXStillAVirgin69Xx wrote:And people thought I was a fucking dumbass.

Goddamn, did I ever mention how ridiculously good looking you are?

I lol'd

as per singletons... I never bothered to use them... I always felt that it was better to keep things more seperate and independent of each other and unable to touch each other like cheap whores....

LOL. Nice analogy eatcomics.

Haha if we keep up with this discussion, Falco will propably explode

So since my question is so related to the topic at hand, I might as well just post it:

So, we've talked about this in how it relates to systems that control things such as levels and such... But what about objects that control rendering, audio, etc?

Like, in the past, I'd have an object that contained a bunch of different methods for rendering... Like rendering with/without a clip, rendering different types of text, etc. And then other objects to handle other stuff (resources, audio, etc)...

But, each of these should definitely only have one instance, and each of them needs to be accessed by nearly everything... So I typically made them singletons...

I never liked the idea of singletons, I just never found a better alternative...

So my question is, what IS a better alternative in that case? I'm not exactly sure about how Falco handles it, but I think the stuff that's at that low of a level is written in straight C? And it'd all just be global functions? I don't know... haha. But any help is appreciated

XianForce wrote:So since my question is so related to the topic at hand, I might as well just post it:

So, we've talked about this in how it relates to systems that control things such as levels and such... But what about objects that control rendering, audio, etc?

Like, in the past, I'd have an object that contained a bunch of different methods for rendering... Like rendering with/without a clip, rendering different types of text, etc. And then other objects to handle other stuff (resources, audio, etc)...

But, each of these should definitely only have one instance, and each of them needs to be accessed by nearly everything... So I typically made them singletons...

I never liked the idea of singletons, I just never found a better alternative...

So my question is, what IS a better alternative in that case? I'm not exactly sure about how Falco handles it, but I think the stuff that's at that low of a level is written in straight C? And it'd all just be global functions? I don't know... haha. But any help is appreciated

One approach would be to have all entities just be data and have no functions, and have the different objects access them in turn and do what they do on them (logic, physics, rendering and so on) . Then have some sort of messaging/event system, so the systems can broadcast events/messages(KEY_PRESSED, OBJECT_MOVED and so on) Then other systems ie. The audio system could respond by playing sound.
This might also make it easier to use multithreading, but i'm not really sure since the whole game state is shared data...

GyroVorbis wrote:

n64vsnes wrote:Yes I admit they are not the object oriented way

n64vsnes wrote:blah blah blah

n64vsnes wrote:I really fail to see the problem here.

Wheeeeeeeeeell!

xXStillAVirgin69Xx wrote:And people thought I was a fucking dumbass.

Goddamn, did I ever mention how ridiculously good looking you are?

Falco your turning into a right OO whore.

If you only ever need one instance of that class then whats the big problem? I've shown how using pointers and refrences work just as well but why risk having another instance created?

I'm not going to start a war with the object oriented nerds but I really fail to see the problem with approaching a problem with a C method when instead over complicating it with the C++ approach? Its like that time you had a go at me for dissing virtual members. I'm not saying virtual members are "a waste of time" but I am saying sometimes you can easily over complicate a very simple task.

N64vSNES wrote: I'm not going to start a war with the object oriented nerds but I really fail to see the problem with approaching a problem with a C method when instead over complicating it with the C++ approach?

How in the world is using the singleton pattern "approaching a problem with a C method"? Please correct me if that's not what you were implying. You need to keep in mind this discussion is about large-scale projects requiring real design phases more so than a 200-line physics engine for pong. As the size of the project grows, so does the amount of hell bought forth by choosing to implement all of your managers as singletons.

XianForce wrote:So since my question is so related to the topic at hand, I might as well just post it:

So, we've talked about this in how it relates to systems that control things such as levels and such... But what about objects that control rendering, audio, etc?

Like, in the past, I'd have an object that contained a bunch of different methods for rendering... Like rendering with/without a clip, rendering different types of text, etc. And then other objects to handle other stuff (resources, audio, etc)...

But, each of these should definitely only have one instance, and each of them needs to be accessed by nearly everything... So I typically made them singletons...

I never liked the idea of singletons, I just never found a better alternative...

So my question is, what IS a better alternative in that case? I'm not exactly sure about how Falco handles it, but I think the stuff that's at that low of a level is written in straight C? And it'd all just be global functions? I don't know... haha. But any help is appreciated

I literally handle it the same way as my previous post. Engine "subystems" are allowed to inherit static pointers to my renderer, audiomanager, etc.

n64vsnes wrote:Falco your turning into a right OO whore.

You're right. Not supporting an extremely shitty design pattern that has various other alternatives that are 100x more effective makes me a whore.

n64vsnes wrote:If you only ever need one instance of that class then whats the big problem? I've shown how using pointers and refrences work just as well but why risk having another instance created?

Your own argument is for ensuring something is only instantiated once. This is a PISS POOR argument. Make the constructor private, friend the factory class that WILL be instantiating it, and BAM! You have just ensured only one instance can ever be created without taking a reasting shit on object-oriented C++.

n64vsnes wrote: I'm not going to start a war with the object oriented nerds but I really fail to see the problem with approaching a problem with a C method when instead over complicating it with the C++ approach?

Orly? What does that have to do with anything? You aren't using C, you're using OBJECT ORIENTED C++ and suggesting a TERRIBLE OBJECT ORIENTED design. There is absolutely nothing wrong with calling global methods in C--then stop bitching for singletons, change all of your extensions to .c, and stop using classes. The truth is that you are not arguing for the "procedural approach." You're arguing for a STUPID object-oriented approach.

n64vsnes wrote:Its like that time you had a go at me for dissing virtual members. I'm not saying virtual members are "a waste of time" but I am saying sometimes you can easily over complicate a very simple task.

Really? Who here with ANY real C++ experience (or even a little bit of background knowledge) can honestly say that virtual methods are a waste of time? That's sheer idiocy.

I get the impression that you are one of the guys who support singletons because they take away the hard part of actually having to "think" about design.

N64vSNES wrote:If you only ever need one instance of that class then whats the big problem?

This is what I have the most issue with. I have never come across a situation where I want only one instance of the class. Why? Because whenever I do, it means that I have a serious design problem. Anything you make should be capable of having more than one instance, especially if they interact with the rest of the program. For example, an Engine class. Yes, you usually wouldn't want more than one Engine, but let's say there is a specific instance where you do; if anything Engine depends upon is a singleton, but the singleton is designed with the assumption that only one Engine will exist, and only one of that class would be needed for an Engine (which would be the whole justification for having a singleton in the first place), then you're fucked, because now you have 2 Engines trying to use the same instance of something that is designed for a situation where only 1 Engine would exist. This is especially true for libraries; never assume that anyone would only ever need one of a certain class.

tl;dr singletons <<<<<<< object communication

EccentricDuck wrote: [I've certainly had some initial frustration with the examples I've seen for XNA developers. They work, but for someone who's uninitiated to the details of the system it can be a major pain to navigate. What seems implicit and intuitive when you start out with a concept of the structure winds up being incredibly complex until you get a good sense of that structure. As the guy developing a framework using singletons I can understand why I might have a bias toward them since I have a pre-built model in my head where they fit in incredibly nicely (I don't really have to deal with what it's like to navigate through and build that mental model from scratch). Perhaps this is part of the double edged sword of singletons - they are intuitive when you have a strong mental model from the get-go, but they're not as intuitive when it's not fresh in your mind.]

Now, aside from being narcissistic, I'm quoting myself for a reason. This line of logic was going through my head as I recounted my experience of going through some robust XNA code examples that were initially, difficult to follow, but eventually worked fairly well (although bugs kept cropping up from things that were missing - but I assumed that was just a part of learning and working with the complexities of what I was looking at). Seems that a similar line of thought has been echoed here, only more explicitly:
http://misko.hevery.com/2008/08/17/sing ... cal-liars/

The problem is not that they don't work (they do, that's why I have used them and why I genuinely was wondering how it would look to design a system without them), it's that they're hard to follow when you don't know exactly what is going on. I know that, as a programmer, I personally really suck at dealing with ill-defined problems. It's hard for me to take the "next step" when there's 15 possible next steps and I don't know how some of those steps will interact with others. I sort of intuitively got that singletons could be problematic that from my previous experiences, but they worked (and I had 15 other things to do) so I didn't really look for another solution since I thought that what I was doing WAS the solution (and it was relatively powerful as far as I was concerned - it has a kind of quick and dirty power to it that lets you write a quick hack to something). It helps for me to see something tangible as an alternative though. Honestly, that post by Falco was incredibly insightful. It's like the definition of "plug'n'play" - pop a new level in and the thing looks, design wise, like it would just run. I love that.

That's what I liked about singletons, except it was the wrong plug'n'play. It allowed you to plug pieces of a partial solution into some "idea" (level or project) in this case) to make it work. That's cool, but even better is to plug your one "idea" into a design and just have that idea work.

It's like building a tower out of odd shaped blocks (singleton approach) versus sticking a square block into a mostly complete tower. I'd much rather do the latter. The former is appealing, relative to reconstituting all the particles that make up every single one of those blocks into one structure (no pieces to plug together), but it's definitely not the same as the latter.

That's my narcissistic 2 cents.

If the is a reason why singletons are a bad design then fine, I'll certainly won't be using them in the future but you can't just say "this caused me to rewrite our engine" and "I spent to days fixing the toolkit because of a singleton". I'll accept they are bad design when I see a reason why they are.

Yes not having the ability to declare as many objects of that class as you like isn't the object oriented way but it works does it not? Feel free to give some reason to why this is such a bad design otherwise how are we supposed to know it really is a bad design?

N64vSNES wrote:If the is a reason why singletons are a bad design then fine, I'll certainly won't be using them in the future but you can't just say "this caused me to rewrite our engine" and "I spent to days fixing the toolkit because of a singleton". I'll accept they are bad design when I see a reason why they are.

Yes not having the ability to declare as many objects of that class as you like isn't the object oriented way but it works does it not? Feel free to give some reason to why this is such a bad design otherwise how are we supposed to know it really is a bad design?

When the justification for doing something is "it works," this usually means that the person designing it made bad design choices and made their code difficult to maintain. This is something that, as a developer, you want to avoid at all costs, because there is no job worse than having to maintain a poorly-written code base.

I wouldn't say that "just works" is a bad thing. I'm the biggest fan of "just works". The #1 thing that you should do as a programmer is make it "just work". That is job numero uno, always. Debugging, refining, and profiling all come subsequently.

It's difficult to attempt to make the point clear to a programmer who is relatively new because the breadth of their experience is not yet very wide. The traps and pitfalls of singletons will most likely NOT be evident to you if you're working on a minimalistic codebase, or if you're confined to one system, or if you are the sole programmer, and what have you. The major pitfalls have pretty much already been covered here. The two MAJOR issues in play there deal with concurrency and testing/debugging. These truly become nightmarish.

Ew, no one wants to read through code that "just works"... We want well structured well defined, highly configurable code... Its like building your own house where the wiring "just works" until you realize that its not up to code and the next time you take a shower you'll be dead....

Offtopic Edit: I just realized that google ad blocker blocks my seganet banner xD I just installed ad blocker because I'm sick of youtube ads... I didn't think about that banner being an ad...

Writing code that does as it is intended to do does not preclude code that presents itself in such a manner as you have described.

Many times the code will undergo multiple metamorphoses before presenting itself as an extensible and elegant API. Each time this process presents new problems, but each time through you should focus on making it work as opposed to getting hung up on extraneous details. ALL details are completely extraneous if the code does not do as it is intended to do.

In a nut: Your code can be an extensible and elegant looking pile of non-functional shit (The "shiny shit" debacle). This is of no use to anyone.

Make it work first.

N64vSNES wrote:If the is a reason why singletons are a bad design then fine, I'll certainly won't be using them in the future but you can't just say "this caused me to rewrite our engine" and "I spent to days fixing the toolkit because of a singleton". I'll accept they are bad design when I see a reason why they are.

Yes not having the ability to declare as many objects of that class as you like isn't the object oriented way but it works does it not? Feel free to give some reason to why this is such a bad design otherwise how are we supposed to know it really is a bad design?

A problem with singletons is that they prevent the use of interfaces (meant in a generic sense, not a language-specific thing). Since singletons are globally accessible, it is impossible for a piece of code to step in and decide to provide a different implementation of the class to a particular part of your program.