Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Mar 2004
Offline Last Active Nov 28 2015 06:55 PM

#5257489 Adding some GUI to OpenGL

Posted by Dave on 16 October 2015 - 08:39 AM

I guess I'll put in a few more cents.


There is a lot of crappy RMGUIs out there, so I understand peoples frustration and need for something new.

But RMGUIs doesn't have to be that crappy, and IMGUIs, while solving some problems, overlook others.


There is no reason an RMGUI would have to have complicated observers or invalidation logic.

In the RMGUI I'm currently writing, if you change something, vertex buffers will be invalidated and rebuilt before the next draw.

If not, well, then we reuse the vertex buffers from last frame. (normal case for 99% of the frames)

Its not hard to know if a change will mean the vertex buffer it belongs to need update.

I don't care at all about regions. That was relevant in software rendering. Not so much in HW.


You do decouple creation from update/reaction, but you do it for a reason. It might not even be the same person defining it.

But even if it is, I like to have my widgets initial position and layout defined in an xml. Nice and neat and does not pollute my code with layout, and I can even edit it in runtime and reload it for quick ui tweaks. (or complete ui changes as long as the same actions exists)


Since I use lambdas, there is no problem with extreme decoupling, all my callbacks are defined right then and there, without unnecessary code.

Code should be concerned with actions, and never care about exact sizes or positions.


I don't want to rewrite logic for when and how to draw my buttons for every game I do.

It makes sense for game engines where you have complex needs for culling and handling of transparency and effects.

Not that much for UIs. 

To have higher class objects like views and popups make code brief and easy to read and modify the relevant parts of.


In my RMGUI, my UI is just another layer/pass in our graphics engine, I call "update" on it when it should be updated, and I call "draw" on it when it should be drawn. (so in a way IM, but on a higher level)

But I wouldn't want to call the equivalent of "draw" for each and every ui item each frame.

Not because I think it would be slow, but because I have no need to see and change that code, it can be completely generic for every UI.


Then of course, RMGUIs can be made overly complex... like most out there.

But it doesn't have to be like that, and I'm not sure IMGUIs really solve the problem, just moves the responsibilty


I don't want to discourage anyone from using an IMGUI though, I'm sure it can be perfect for a lot of projects.


I'll treat each paragraph as a bullet point, all are addressed:


1) Every RMGUI i've worked on (in games or otherwise) get overly complicated. It's inevitable. The most important thing in game development is iteration time, IMGUI tend to be quicker for this.


2) You can rebuild vertex buffers on invalidation sure, you should do that whether RM or IM. The topic is really about "what it takes to get my game gui done", both options have similar optimisations. I'm not sure what you mean by regions.


3) There isn't much practical need to decouple display and logic. The games ive worked on have had heavy XML driven RMGUI front ends and the artists and designers barely go near it. A well thought out IMGUI interface can produce code that is as easy to read as XML. If artists want to change the size of something they'll just look for the name and numbers wherever theyre declared.


4) Not sure about this but in my experience having callbacks registered to events etc gets very messy and it hard to track what is listening to what.


5) Surely when you call draw on your RMGUI it is fast enough that it doesn't hiccup the framerate much right? If so then just do it every frame. My IMGUI (fairly optimised) runs at around 1ms on reasonable hardware for my level editor. This is content that is much more complicated than any typical game GUI with health bars and so on. Also you don't change that code, it's completely generic for all UIs made with any given IMGUI.


6) They do move the problem to a certain degree but the fundamental benefits are that its easy to write new client UI content and you don't have application state stored in your UI widgets because they don't exist.


It's perfect for realtime applications.

#5257451 Adding some GUI to OpenGL

Posted by Dave on 16 October 2015 - 02:48 AM

I used to be a naysayer but now i am pro it after many discussions and looking at ocornuts implementation. I've converted my level editor to use my own IMGUI and there is nothing i've been unable to do with it. The original discussion never specified what happens behind the scenes but you can actually do a hell of a lot of "clever stuff". This mostly involves checking against the last frames state.

#5253981 Should I learn c++ for game dev?

Posted by Dave on 25 September 2015 - 06:49 AM

Because its still the most commonly used language and gives you the most job opportunities. Skills in C# are also useful if you intend to use Unity or write tools.

#5250423 in-engine tool vs external tool

Posted by Dave on 03 September 2015 - 09:28 AM

Problem is though there isn't really any need to separate it out. You can still write your editor totally native running inside your engine. It might be a different executable than your game.exe (and thats how some of the editing stuff is left out) but a lot of the functionality is shared. I'm primarily warning against the idea of writing your editor in C# or Qt for example. You're going to spend a hell of a lot of time writing the interop between the runtime and the editor and it becomes a complete ball ache.



Doing it all in your engine doesn't prevent you from doing the optimised per-platform stuff.


It depends what your requirements but i have always found maintaining multiple tools and programs too much work.

#5250400 Where do I start? (C++)

Posted by Dave on 03 September 2015 - 05:32 AM

cplusplus.com got me on track for using C++, I would recommend against starting with a 2d game initially. At least until you have a good grasp of the language.


If you're hellbent on doing so however, I would point you to any of the three major C++ libraries for game making.






Again, I wouldn't try a game until you're comfortable with writing basic C++ code without looking at tutorials or documentation


I disagree with not trying a game until he knows basic C++.


If you want to make a game just dive and do it. Be prepared to fail, making games is hard and you'll go through many iterations but making a game is very rewarding. You'll learn alot about C/C++ along the way. I think that writing anything else to just learn some C++, beyond basic guess a number etc, will ultimately bore you because you won't be working on what you actually want to be working on.


Get stuck in, find a few good websites like this one, ask lots of questions, read lots of articles and you'll be there in no time.

#5235034 My .OBJ Model Loader doesn't seem to output the right scanned data of cub...

Posted by Dave on 16 June 2015 - 01:29 AM

You could use tinyobjloader. It does the job well enough.



#5228336 [SlimDX]using Sound Effect in Slimdx

Posted by Dave on 11 May 2015 - 04:54 AM

You don't need to cross-post.

#5223389 An alternative to Match Engines in Football Manager game.

Posted by Dave on 15 April 2015 - 05:58 AM

It's possible, but as with any simulation the realism of the results is proportional to the realism of the simulation. For example you could have a statistic per-player that indicates how likely he is to get injured in a game, say 0.05 for 1 in every 20 games. It might turn out to look ok but there is a whole bunch of information missing from determining whether he gets injured:


- Was the other team aggressive?

- Was he playing in or out of position?

- Was he 100% fit before the game?

- How many minutes did he play?

- How aggressively was your team as a whole tackling the opposition?

- How aggressively was the opposition told to attack your team?

- How aggressively did you ask him alone to tackle other players.


The list goes on, there are tonnes of metrics by which such a decision can be made. Football Manager didn't start out analysing all of these things. Back in 97/98 it was probably much more simple and since then it has evolved into a beast of a simulation. I would suggest just starting simple and gradually introducing other factors into your AI decision making as you find your existing systems limitations. Don't set out to beat Football Manager from the start because as a one man team it is simply too much work.


Source: I was a gameplay developer on Championship Manager 2008 and 2010.


Have fun!

#5172054 Thread-safe weak pointers

Posted by Dave on 07 August 2014 - 09:51 AM

I do something quite similar to this at the moment. It's in very early developmental stages but so far i've not noticed a performance hit from my approach. Have you thought about going lock-free and having a flag on each entry that is altered with compare and swap? It might be that you just need to get the cost of your lock down.

#5166235 c++ function pointers

Posted by Dave on 11 July 2014 - 10:14 AM

Use http://www.codeproject.com/Articles/7150/Member-Function-Pointers-and-the-Fastest-Possible

#5154012 Engine architecture questions

Posted by Dave on 16 May 2014 - 08:39 AM

The topic of whether it is a good idea to have global pointers to each manager in your engine is an open one. I worked on a commercial game for PC, PS3 and Xbox that had a global static pointer to each subsystem manager, so g_pRenderer, g_pScene etc. I now currently work on a commercial engine that doesn't have subsystem managers but does have lots of static data and a few singletons dotted around for good measure. There are many ways to skin a cat.


In some regards I would say don't worry about. Don't lose sleep over unnecessary architecture that you don't require. When writing an engine its easy to fall into the trap trying to write it too perfectly but at the end of the day no engine, no matter how well written or otherwise, is any good if it isn't being used to make games.


Anyways, to give you an idea for what I do in my engine is have it broken down into to two areas and these are separate libraries. I have Kernel and Engine. Kernel contains a the main interface that Main() deals with and contains the Command, Task, Core (utilities for platform access) and threading. The kernel class allows access to each of its subsystems. The second library has the engine code in it so resource loading, gui, scene management, physics, rendering etc. The engine class provides access to those subsystems. Nothing in the kernel area depends on the engine area, only the other way around.


Circular dependancies do happen and these are more easily identifable if each subsystem requires a pointer to its subsystem dependancies upon construction, for example:


GuiManager* guiManager = new GuiManager(pSceneManager, pRenderManager, pInputManager, pDataManager);


Being forced to pass in pointers rather than just using globals makes you realise something might be wrong more easily.



In short, it sounds like you're on the right track but just focus on it meeting your needs and not some unattainable goal of perfection that noone ever really achieves.

#4999480 The Singleton Pattern: To be or not to be [used]?

Posted by Dave on 09 November 2012 - 05:05 PM

I don't see that singletons or globals are particularly bad. I've worked on commercial games where singletons and globals have been used. One used them wisely and was the easiest codebase that i've ever worked on and one used it badly and it was extremely complicated and hard to ramp up on. I have also worked on commerical projects where "correct" OOP has been used and overused and this was also one of the hardest codebases i've worked on.

You can write bad code with "correct" practices. You can write great code with "bad" practices.

Writing tight OOP code in studios where iteration time is important and year on year you're rewriting large portions of code is common because of new platforms and new titles is a complete waste of time and it is important that you make simple architectural decisions that:

a) Allow new programmers to get on with things easily.
b) Make it easy to add features to.

It is argued that you can screw things up if you start touching global variables that you shouldn't. If you hire programmers with an ounce of common sense they generally won't do that and no matter what "barriers" you put in place to protect programmers from themselves, if a shortcut is really desired then it will be found. The friend keyword comes out in no time.

Stop worrying about writing perfect OOP and just get on with writing cool stuff for your game/engine.

#4994118 Create a Game Engine

Posted by Dave on 26 October 2012 - 06:21 AM

I had no intention of discouraging you, i actually encourage you to make a game engine. Apologies if it appeared otherwise.

The issue people bring up is how do you write an engine without a game to give you a set of requirements. Well, make up your requirements. Is there something you have seen in a game you'd like to emulate? Such as path finding, deferred shading, deformable terrain, destructable objects, gui ideas. Built up a set of demos, each their own executable, that do something different with your engine. As you develop more of those your engine code will mature, you might start again a few times because you realise you could have done something better.

At no point did i state that the article suggests Unity.

#4993801 Create a Game Engine

Posted by Dave on 25 October 2012 - 08:24 AM

It's just bad insta-advice.

The guy has expressed an interest in writing an engine and there is a hell of a lot he can learn from writing that technology himself. He expressed no intention of making a game in his OP and so an insta-reply with a link to that article serves very little purpose and it is of practically no help.

I have never made a single worthwhile game in my personal time, i have always worked on various pieces of technology and still do today and that has served me extremely well in the games industry. Using Unity to make games however is only going to get you as far (in terms of your skillset) as writing games with Unity. I have worked on a commercial product with Unity and you don't learn shit about making games when using it. You just learn to use Unity and how to cobble stuff together.

If you really want to learn to make games you need to have a good understanding of how the stuff your game code depends on actually works. Game programming is not easy, its very technical. You have to be aware of all the same technical considerations as engine programmers do in order to do it well.

Since the OP asked about engines specifically (albeit it turns out to be a bit misguided in later posts) its important to just point him in the right direction with regards to developing that kind of tech.

However, in light of more recent posts in this thread it is clear that the OP is a bit misguided with his need to write an engine and if his intention is just to make a game then there is no better solution than Unity. I just object to that article being banded about as if its THE answer to every thread similar to this one Posted Image.

#4993785 Create a Game Engine

Posted by Dave on 25 October 2012 - 07:27 AM

Why do you think it'd be more easy to create a game with your own engine instead of with a highly polished and proven solution like CE3 or UE3? Building something which can compete with those engines would require loads of time, money and expertise from you and your co-workers.

I know that my engine can't compete their engine but my game would be more prefect if i create my own game engine.

Yes and no.

What you would end up with is an engine that does exactly what you want. Often though this is alot more complicated that tweaking an existing solution to meet your needs. For a hobbyist who has the intention of making a game for production and making money it is often best to use a third party solution if what you want to do is fairly standard stuff.

In time you will know when you need your own solution. I've worked at studios that have exclusively rolled their own stuff and it was alright, you feel in control and licencing etc is less complicated. It comes at a cost of time though.