Rick

Seriously, isn't that just insane.

I didn't mean yours Roland, just meant in general, creating a skinable gui library is a pain with all the little positioning of all the little pieces. Coding that sucks, and it's very boring.

Honestly I really feel like I have a great back-end structure for a GUI, but I'm not a fan of the drawing part. I used a 3x3 image system, but messing around with text positioning and image positioning is just kind of a pain. That's generally where I lose interest. Then you have to worry about text clipping (which seems like we have to do it manually really) and all of that. The basic controls are easy enough, but when you get into more advanced controls it gets to just be a pain.

I would use C++, but if you really want to keep it C, I would use function callbacks for the event handlers. Inside CreateX() functions accept a function pointer that will be called when the event is fired.

You lost me on how you handle events. Making the user poll for events is just not the way to do a GUI. Otherwise it seems ok, although I'm not a fan of just getting ID's for things but if you were going to match how LE does things then that seems valid. But seriously polling for events is so 1990's

An action is basically a function that you must call in your chain. Think of something like CreateCube(). An event is something that gets called by the game or engine. Think of something like on a collision. LE will call a function callback. This is an event. In the terms of the flowgraph system your "main" function is called automatically and you chain actions together to start your program. Since events get called at random times nothing has to proceed and event. It's the starting point that can happen at any given time when it gets fired.

All I could say is please make the editor very flexible and dynamic. Give us the ability to add our own stuff like menu's and such. Let us launch our own UI panels for our own functionality. A good example for that would be pathfinding stuff. Being able to add our own UI panel to control pathfinding settings to an object would be ideal. The more flexible the better.

I've never done it but maybe look into TVec4 GetVertexColor(TSurface surface, int vertex=1), passing the surface that was picked? If it returns a certain color then ignore it? Would be cool to be able to ignore transparent areas with the pick directly though.

Yeah, been coding as a profession for about 9 years now. At work I use .NET but I prefer C++.

To add more design styles to your bag of tricks check out this thread on C++ events http://leadwerks.com/werkspace/index.php?/topic/255-c-events/page__p__1991__hl__event__fromsearch__1#entry1991 My examples are GUI oriented but event systems can be used in many situations besides GUI's. You can fire events when certain variables in a class change so that other classes can be informed when that happens so they can do certain things. Let's say for some reason you want your enemies to know when the health of your player changes. You can either loop through each enemy and tell them the players health value each frame, or at the start of the game you can have enemies bind to the players OnHurt event. Then in the players Hurt() function fire this event so all enemies get it called. There are many different things you can do with events as far as game design goes and it's another technique you can use.

Love the feel to this! This really draws you in.

My thoughts on design from a technical aspect since that's mostly what I think about. 1. Should be OO Button* cmdExit = new PushButton(); 2. Should be event drive and handle either normal C functions AND class member functions (non static) as event callbacks. Should also be able to chain events to multiple callback functions. class MyScreen { private: Button* cmdExit; void cmdExit_onClick(EventArgs& e) {} public: MyScreen() { cmdExit = new PushButton(); cmdExit->onClick.Bind(this, &MyScreen::cmdExit_onClick); } }; 3. Should just be one update method to run the main GUI loop. 4. The definition should be able to be stored in XML files so an editor can be created.

You would have to define HOW you want it done though (not just the commands). Would you do just 1 image per control, would you draw it with drawing commands, would you combine 9 image to make the controls (3 rows of 3), etc etc. It has to be fully skinable so I would think the 3x3 images would be ideal, but I thought you said you liked the drawing version (like steam). That sounds like it would require coding to customize vs art to customize.

I feel like you'd be better off manipulating the verts in code. If the blocks are all the same size I would think this wouldn't be an issue.

You were saying it was a problem because not every language supports it. You are right, you would have to do something like Buffer* b = new OpenGLBuffer(); But you don't want to do that because changing to use DX would require changing all those statements to some DX class. It does seem that if you want to support multiple libraries you would have to create different graphics devices and then have each of those have CreateX() methods to them. Then at that point there is no point to use try/catch because you can check for null. I can't really think of a way to do it otherwise. The factory design might help but it's pretty much the same idea as just using a normal function (for the most part)

Would be interesting to see if there is any difference if that was in C++. I would assume there would be.

In that case it seems valid then. Most of the cubes seem to be on top of other cubes that aren't visible anyway. Although I wouldn't put it past you to consider that 700+ fps only looking at a handful of cubes Aggro, when you move around even with CreateCube() and not CopyEntity() what kind of FPS do you get?

Very interesting. Still doesn't seem like it helps all that much. 62 FPS with 10k cubes still isn't good. Once you start factoring in all the other gameplay stuff, characters, physics I think using cubes isn't viable to make the game. Taking shadows out I assume would help.

Lua will be slower than C++. I didn't compare it to C#. Wouldn't you be rendering the same amount of triangles no matter how you create them? CopyEntity() would save memory but the drawing of all those cubes still has to be done. You move the instance to position z, draw it, then move it to position y, draw it. Same thing if you create new cubes right? It's just that the mesh data isn't shared, but has it's own memory storage. You still have to draw all the triangles.

Does that say 10fps? I can hardly read it. That's from Lua also, so slight overhead. I would be shocked if CopyEntity really made it much faster. Isn't that the goal of every game? Also, since the boxes are all the same size you could most likely manipulate 1 giant cube via adding/removing verts dynamically to simulate the shape of boxes from within one cube mesh.That would get better performance, but be more code to get it to work.

I think callbacks would get messy. The implementation of them would probably be use and most likely a big switch statement to figure out what made the calling error. The only other thing I've seen libraries do is have a GetLastError() function, but I'm not thrilled about that approach either.

I have to wonder why would you get a speed boost from that? If anything it just takes up less memory. You still have to draw all those triangles on screen at different positions.

ctors are very useful. It just so happens you want to target languages that don't handle try/catch and possibly other advanced OO concepts. If the scripting was C# it would be all good. You want to create a library in an OO fashion but still be able to use it with non OO languages. If that's what you are after then there is almost no point in using C++ in an OO fashion because you have to do everything in the lowest common denominator. In that respect you should just keep the C syntax that exists as there is little point in making it OO.

It's "easy" in C++ also, but yeah it's easier in C# as most of the stuff is done already for you. I was just saying any GUI should be event driven and not polled.

It would save memory probably, but even instanced models need to be drawn at each position so you would be drawing the same amount of triangles.