vbGore Free Online RPG Engine

I was thinking instead of getting one render function to list through all possible renderable instances.

Instead, once you create a renderable instance, it creates a listener and listens for the render event and then asynchronously renders itself.

For instance in Java + OpenGL. I create a listener class for Render() and I create a textbox which implements that listener class. So any render code will be coded inside the textbox class and not in the OpenGL class. The upside to this is less management. Once i add a textbox, thats it, i don't have to go through the render code and tell it to render that particular instance.

My question is. Would there be a performance increase (from multithreading), or a performance decrease (from so many listeners)? Or is there any other things of concern when applying this?

So you want to make an async call to every object that can render to render itself? Sounds like a bad idea to me. Even if the calling order isn't a problem, you'd end up spawning a bunch of threads just to wait for them all to finish before you can refresh the screen.

Now if you wanted to just do them synchronously, that would be fine. Though it would make more sense if it was just a method call instead of an event hook. A lot of people add an interface, like IRenderable, to everything that can be rendered or contains stuff that can be rendered. I just have an instance to my World class which I call Draw on, which calls draw on the Map, which enumerates through every Entity I have on the map, checks if it implements IDrawableEntity, then draws it.

For multithreading, when it comes to rendering, it generally isn't a good idea. Things may have changed in the past few years, but last I remember, the GPU no likely them threads.

poor gpu

Ill try doing it synchroniously using an interface somehow. And if that fails then just enumeration and iterating using your singleton method.

Thanks

Singleton? There's no singletons involved in my method...? It is just each object calls Draw() on every child it has that can draw, creating a chain-event of drawing. A singleton would imply that you could only create one instance of the object.

Yeah I'm talking about the singleton pattern. Where every instance is held inside or can be referred to via a single super instance. You have a list of every single instance which you iterate through and check for renderability.

Non-singleton would be if you have multiple/separate lists. Such as GUI, Players or Renderable, Non-Renderable etc. And you iterate through each one irrespective of each other. Unless you put all those lists in a single list called "world" again, then it would be singleton.

umm sorry to butt in ....
but is there a good resource to learn more
about what you guys are talking about? X_X

It isnt all chinese to me,
but I never heard of this stuff before
and would like to inform myself.

I think you are a bit confused on the singleton pattern. A singleton does not mean "it only has one instance", it means "you can only create one instance". In C#, this would look like:



There can only be one instance of MySingleton, ever. Since the constructor is private, you can not create another instance. All you can do is grab the existing instance and use it. It is like having a static class in the sense that you always refer to the same instance no matter what, but you can still do stuff like inheritance.

The pattern I was referring to is more of just basic abstraction. The world contains the map, the map contains the entities, and each entity contains their own logic. I can have as many world, map, or entity instances as I want. Just because I only USE one world, that does not make it a singleton. I could, if I wanted, run two worlds at the same time. In fact, this could be done to handle multiple instances of the same world on the same server.

Dammit I gotta start thinking before i say anything from now on lol.

Strictly yes, if it wasn't static you could have multiple instances of "world", i was just generalising by assuming that you would only have one "world" anyway therefore using one instance to hold everything, therefore introducing a global state for instanced items, would be like using the singleton approach.

But how could you use multiple worlds to handle multiple instances of the same world???

The only way that's possible is if you make them public or send a pointer reference to each other, however there would be no logic in either.

EDIT: Make that, i can't see the logic in either

If I want to handle another world on the server, I'd just create another World class and populate it. All it would take is a little bit of tweaking on the Server class maybe, since I don't have it set up perfectly, but yeah, it would be pretty simple. Again, its all about abstraction.
Just to clarify, it would be, like you said, multiple instances. The world is constructed the same, but the dynamic entities that define it (NPCs, users, generated items, etc) are different. Its just like choosing a server on WoW or a channel on Maple Story - same world, different dynamic population.

Also, whats wrong with having "one instance to hold everything"? The World contains everything that is part of it, just like it should. It doesn't mean other parts can't use a reference to the World - each Map knows about what World it is attached to, and each Character knows about what map it is attached to. Of course, with some refactoring, I could break these dependencies apart and make them even more independent.

It sounds like you just need to practice more with your OOP.

Whaaa? when did i say there was anything wrong with it?

I just wanted to do it my way first. Found out Java can use synchronous event handling, so depending on the overhead of the listener will determine whether ill use mine or your method.

Sorry, by your wording it just sounded like you thought there was something wrong with it.

Either way, I don't see events being the way to go here. Sure, it is a way to go, but it doesn't seem like it offers enough in terms of order of execution. When invoking events, at least in C#, I don't think you are given any guarantees on which listener will be invoked first. Even if you are, it is a horrible idea to rely on it. I believe a .NET event is nothing more than a multi-cast delegate, so the performance will be slower than if you were to use an interface I believe, along with you will have increased memory consumption due to all the extra references.

Just seems overly complicated, too. For example, with my map, I have a list of all entities. When an entity is added or removed on the client, or the draw order changes, the corresponding list for the background, sprite layer, or foreground is updated with the entity. When I want to draw, I just call draw on every element in background, sprite layer, then foreground list.

Even easier is my GUI system. The GUIManager contains a Draw(). Each Control in the GUIManager, which will be the root-level controls, are in an array. To draw, I call iterate through the list and call Draw() on them. In the Control's Draw(), they draw their self, then call Draw() on their children in order. As a result, everything is drawn, and drawn in the proper order.

Okay ill do your way then

Ill create an iRenderable interface with just the method render and implement it into all the renderable classes. And ill create a static "renderable" collection in Java which has its own retardedly complex foreach iterator (it has its pros i guess).

for (Iterator it=collection.iterator(); it.hasNext(); ) {
Object element = it.next();
//code
}

Which will only house references to renderable instances. And ill have seperate collection for data and other things, and actually holding the instances.

Why do that? Again, you will loose the ability of layering (unless you create a collection for each layer or define the layer in the interface, which would be l*O(n) iterations, where l is the number of layers). You should already have a reference to stuff that needs to be drawn. Your map contains all the entities, and a character is a derived class of an entity, so just check which entity implements IRenderable and render it. As a result, your map is now renderable. Since your World houses the map(s), it too is renderable. So to render the whole world, you just start it by calling world.Draw(). No public static stuff needed.

I think we are thinking of two separate things here, since it isn't exactly the easiest thing to explain without code. If you want, I can write a quick C# mock-up of what I am talking about.

I said static not public static

Layering can be much more easily achieved using the 3d Z position.

Also im confused by what you mean by "world" and "maps" because you are never going to render more than one map. So why need a world?

Ok do a quick c# mockup so i know what you are talking about thanks