Messages

1

General / [SOLVED] Inherit Drawable or implement Draw() in SFML.net 2?

« on: November 21, 2011, 10:42:58 am »

It's not what I'd planned on originally, but this has led me to thinking about other ways to accomplish what I want, and I think I will adopt a component based approach, with another small class managing the drawables for each game object.

I now see what you meant by weak couplings, Nexus.

Thank you both, this has been a learning experience!  I will mark the topic as solved.

Summary for future visitors searching for information on this topic:  In SFML.net 2, you cannot inherit from Drawable (or Sprite, Shape, or Text).  And while you can probably do it in the C++ version, it might not be a good idea.

2

General / [SOLVED] Inherit Drawable or implement Draw() in SFML.net 2?

« on: November 21, 2011, 06:40:54 am »

So, apparently it's impossible to inherit drawable if using SFML.net?

Code: [Select]

internal abstract void Render(RenderWindow target, Shader shader);

Since it's internal, nothing outside the SFML.Graphics assembly can inherit from Drawable, or any of its children.  Is this intended?  It appears that if it weren't marked internal, my overrides would work.  I didn't discover that Render was internal (or even know what internal meant) until I'd gone through overriding all the rest of the Drawable functions and it still didn't work.

Now I find this:  http://www.sfml-dev.org/forum/viewtopic.php?t=4569

I guess I'll have to do everything a different way after all?

3

General / [SOLVED] Inherit Drawable or implement Draw() in SFML.net 2?

« on: November 20, 2011, 05:45:00 am »

Thanks for your replies, Laurent and Nexus.  Especially your very speedy one, Laurent!

To a less experienced programmer as myself, it doesn't seem like there's a clear and simple answer to the problem of handling the drawing of a compound object within SFML.  After Laurent's answer made me question my assumptions, I thought inheriting drawable was clearly a good choice.  Now you make me question that again!

The LSP article goes over my head a bit, but I can see where my example of a button - or an even more complex game object such as a vehicle - would probably not violate the LSP if inheriting from drawable.  Inheriting from either sprite or shape would violate the LSP.  Buttons and vehicles are both inherently drawable objects to my thinking, and at least make sense with the other functions Laurent mentioned above.

However, after my first response, I did spend some time to think about other ways a compound object could be handled.  The other method I could see working would be to have the object manage its simple drawable parts in a list of everything to be drawn in a given frame, completely separating the drawing responsibility from the object itself.  A button could add a Shape and a Text to a list of all things to be drawn, updating via reference as necessary, or removing its drawables when it is destroyed.  Is this what is meant by separating model and view logic?  Would that be considered weak coupling?  It seems like it would create more chances for things to go wrong, like having difficulty managing draw order.

Would the weakest coupling in this case be having each compound object draw its own component parts when asked?

4

General / [SOLVED] Inherit Drawable or implement Draw() in SFML.net 2?

« on: November 18, 2011, 09:45:03 pm »

Probably not in all - likely no need to rotate a menu button, for example - but for game objects, everything but blend mode would probably be beneficial for my purposes.  If I implemented Draw(window) I'd have to handle all that slightly differently, but it'd still be possible.

I was wondering if there was an advantage to doing them all one way or the other.

edit: I guess that somewhat answers my question - if I did them all with Drawable, I'd have more standardized access to position, rotation, etc. rather than implementing everything all differently.

5

General / [SOLVED] Inherit Drawable or implement Draw() in SFML.net 2?

« on: November 18, 2011, 09:32:47 pm »

Edit for future readers:  I was initially unclear, and should have mentioned that I was using SFML.net 2.  Inheriting from Drawable is not possible in SFML.net 2.  This thread explains why. -end edit-

I've seen people ask how to do this one way or another, but I'm not experienced enough to know if there are any big problems with doing it either way (I'm a SFML neophyte).

I want to be able to render a list of simple and compound objects easily, which seems to mean choosing one of these two options.  Ignore bad syntax:

Code: [Select]

for each (object in objectlist) {
    window.Draw(object);
}

for each (object in objectlist) {
    object.Draw(window);
}

So either I build all of my compound objects (e.g. a button consisting of a background shape and a text label) as inheriting drawable, and throw those objects into a list with other basic drawable objects like sprites... or I implement my compound objects with a Draw(window) method, along with giving simpler objects like sprites a wrapper, so I can use sprite.Draw(window) as well.

I suppose different lists could be kept for simple and compound objects, depending on what was being drawn (and I will no doubt have multiple lists anyway), but switching between drawing methods depending on the object type seems kludgy.

Does anyone have any suggestions on why one method might be better?

6

General discussions / The new graphics API in SFML 2

« on: October 08, 2011, 03:40:08 am »

However, Vertex and VertexArray could suggest 3D as well. In fact the perfect name would be something that implies 2D. But I don't think it exists.

I realise you may be a bit beyond this, and I agree with the usage of vertex, but the only word I can think of that implies 2D would be net or network - but that also implies hollow.

I'm concerned about conflating an array or list of vertexes with something that's displayable as flat or textured polygons.  If I wanted a cloud of points, I'd use a vertex list, but there is none of the inherent grouping needed for face display in the concept of a vertex list, particularly if you intend to allow both tris and quads.  I've only ever seen a straight list of vertexes used to define a triangle strip, because then there is no ambiguity of order.

As a relative newbie, what I'd expect is a "face" object, which could be either a tri or quad, and essentially a tuple (is this the right word?) of several vertexes, perhaps with additional information that the vertexes alone wouldn't encode, like texture.  Would this be too much like a sprite?  Would this -be- a sprite?

I would also expect something like a "shape" object that could hold more complex geometry, but I can think of two ways to go about this.  One would be not much more than a "faceList".  The vertexes, texture coordinates, and textures would already be defined.  I realise this could be very inefficient with multiple textures referenced.  Alternatively "face" objects could leave out the texture, and texture could be a property of the "shape" or "geometry".

The other would be a "vertexList" along with an "indexFaceList", which would be the more traditional approach of referring to indexes in a vertex array for each polygon, so polygons can have shared vertexes (including texture coordinates).  Again, texture and such would be a property of the "shape".

Am I sort of on the right page?

Disclaimer:  I'm pretty new to this.