Jump to content

  • Log In with Google      Sign In   
  • Create Account


doeme

Member Since 08 Sep 2011
Offline Last Active Today, 12:55 AM

#5128686 Alternative library to graphviz for layouting directed/undirected graphs?

Posted by doeme on 04 February 2014 - 04:16 AM

So I finally found the Open Graph Drawing Framework (http://www.ogdf.net/doku.php) which does the job nicely.

 

It compiles out of the box and is easy to integrate in an existing project




#5127469 Alternative library to graphviz for layouting directed/undirected graphs?

Posted by doeme on 30 January 2014 - 09:34 AM

Hi all,

 

I'm looking for an alternative library to graphviz for layouting directed and undirected graphs similar to this one (http://ostatic.com/files/images/3_6_1.png) to be displayed in a Qt app.

 

Essentially the same concept as this article: http://www.mupuf.org/blog/2010/07/08/how_to_use_graphviz_to_draw_graphs_in_a_qt_graphics_scene/

 

The tool lets the user interactively move the nodes around and I currently use graphviz as a C++ library to do the layouting. Everything works as it should. Unfortunately the product this viewer is in evolved to 64bit and there is no 64 bit package of the graphviz-DLLs provided.

 

I tried to compile graphviz myself, but after three days of fiddling I'm still not able to even build it.

 

Does anybody know a library for layouting diagrams that has roughly the same functionality as graphviz?

 

I'm currently trying out boost graph, which works fine for placing the nodes, but I didn't find any help in computing the connecting edges as splines or angled connector in a way that they don't go through an existing node.

 

Any idea on another library or help with either compiling graphviz or using boost would be highly welcome.




#5040733 Task and Timeline management tools?

Posted by doeme on 08 March 2013 - 03:07 AM

The company I work for recently made the switch from Trac (free)to Jira (Paid; hosted or downloadable) which both can do what you describe in the OP. Trac needs a bit of customizing and some plugins and macros which can be a bit time-consuming until you get it right while Jira has it all inbuilt.

Trac was good for us for quite some time and it did the job until the dev-team got bigger, more projects came aboard and we generally needed to work and rely more on the issue-tracking and planning.

Jira is generally easier to use (especially for non-techies) as well as i has a already integrated "agile" mode which makes working with it easier and more fun. The close integration with the documentation-system "confluence" is also a pro. Said that Jira has its drawbacks most of all being slow and some quirks in the UI.

 

Considering the monthly fee one has to pay versus free software that is hosted inhouse a rough estimate of the ToC might be worth it. A free software package might be even more expensive in the end if you need to buy extra hardware to run it on and if you do the server maintenance yourself (getting less time on your projects) or hire somebody to do it for you.




#5038983 What experience do you have in terms of programming?

Posted by doeme on 04 March 2013 - 03:33 AM

When I think of the pro's, the experienced, the people who use their incredible skills of math and programming to make video games, I sometimes wonder, just how did they make it there? And knowing how they've made it there, just how good are they?

Most good programmers/software engineers I know are good in what they do, because they are very experienced in what they do. Which means, they have been doing it over and over again for a very long time, most of them can be considered professional programmers for at least 10 years. Also most of them started out at a young age with coding and did a lot of hobby-projects to constantly learn new things. But no matter how good they are, none of them started out without making bad mistakes and producing ugly software in their early years.

How good they are?

  • They get complex software of high quality done and shipped in time on a regular basis.
  • They can come up with good solutions in reasonable time for even the quirkiest problem.
  • They hunt down bugs with fearsome accuracy and speed before breakfast, more often they spot said bugs before they take their toll.
  • They write articles and books to teach other people on regular basis

I think I could go on quite a while on how good some of the guys are smile.png




#5036663 File Management: Best Practices?

Posted by doeme on 26 February 2013 - 05:25 AM

If your biggest interest is to prevent players from mucking with your data or steal it or break their game, don't bother. They'll do that no matter what.

I agree with this, given enough time and effort all of your assets can be stolen. Despite since your tilemap will be visible on the screen nothing will prevent the user from taking screenshots anyways.

 

Also installing measures to prevent this soon will limit the ease of access to your product, which for relatively cheap mass-market products (like games) is generally a bad idea. Needing to enter a key, which is prone to be lost somewhere in your house soon gets to be a nuisance.

I develop surgical simulators for a living, and we encrypt some of our assets when creating an installer and our customers get a USB-Key (produced by a 3rd-Party vendor) which has to be plugged in to be able to decrypt and run the system. However this is far away from the cheap, mass-market product so the acceptance of the user is a bit better for stuff like this, as this also acts as a security, so there is little point in stealing the system.

 

Compiling your assets to a binary might still be a first step in preventing the users from just copying them, but I would set the primary goal there towards faster loading speed and not towards security. Consider discouraging the lazy and casual thief more as a nice side effect than anything else.




#5030967 Debug .exe differs from compiled run

Posted by doeme on 11 February 2013 - 02:33 AM

This might be caused by variables or objects that are not initialized properly. These kind of bugs can be very hard to find if you do not have a clue where to start.

I'm guessing you are if running the exe from Visual Studio you are running it with the debugger enabled and in debug mode which might cause uninitialized memory to be set to a certain value. Check if the program behaves the same if run from VS without the debugger (CTRL+F5) or if your army goes missing as well.

 

As C0lumbo said, late attaching the debugger might help, as well as some logging.

 

 

I can't easily go back to a last saved version (I keep many) as I didn't notice this until about 2 weeks or more of work has been added... I just didn't notice, didn't run this test, was working on menus and other stuff...

This sounds like you don't use any versioning software like SVN, my advice here is  to start using something to track your changes better. Even if it's only running locally on your machine.




#5022814 Rendering system for a "rogue-like" game.

Posted by doeme on 18 January 2013 - 03:05 AM

Rogue-like games are a perfect example to implement the MVC-Pattern (Google it there is a ton of information around), in fact during my early days of programming I coded a very simple nethack-like game as a way to get familiar with the MVC-Pattern.

 

Define abstract data containers and interfaces for the map-representation, dialogs and user-interaction and write custom frontend that interact with these interfaces. The very simplest representation of a map could be a 2D-vector/array where every index correspondents to a tile of the map. Create a tile struct with the needed information in it. For example you put in information if it is an empty space, a wall or a trap, plus a list of items or creatures that are on this tile.

 

From the rendering-side you now write a frontend that reads this vector from the game and draw the appropriate portion of the map on the screen. So the game-mechanics itself does not know hot to represent the information to the user at all.




#5021409 How long until you start planning new game?

Posted by doeme on 14 January 2013 - 08:49 AM

The planning of the next project should usually start way before the current project is done. At the place I work, we usually have the next few projects already in a planning stage, with a very rough draft for the requirement specifications, an approximate release date and a general project outline. And while one project winds down you gradually define more and more of the next project.




#5011969 content creation: increasing productivity

Posted by doeme on 18 December 2012 - 03:28 AM

Apart from reducing the complexity and choosing the right tool, I like to stress the importance of a short and fast asset-pipeline to speed up the cycle of designing and testing. Being able to quickly check out the results of your last edit to the model will help a lot in saving time. If you waste 5 minutes per weapon only just to get your testing running, you already wasted 5 hours of work.
Another thing that greatly enhances the speed is to be able to change & save the objects during testing, so you can tune while testing and quickly apply the results.


#4994060 What's the deal with IDE's?

Posted by doeme on 26 October 2012 - 01:35 AM

Every (major) IDE has its pros and cons. Said that either Visual Studio, Code::Blocks and even Eclipse (with CDT) are able to handle larger projects. I have used Eclipse quite a bit under linux and i quite like it. However under windows I prefer Visual Studio mainly because of the debugger, because IMO having a good and easy to use debugger can save you a lot of nerves.

If you just start out with coding choose the IDE that feels the easiest to use for you. VS is quite beginner-friendly because it works out of the box, while eclipse needs some tweaking to get it running for C++-Development.


#4993037 Favorite little known or underused C++ features

Posted by doeme on 23 October 2012 - 03:10 AM

I personally love quite a bit of the newish C++11 functionality, which is still not used by a lot of C++ developers I know, simply because they do not know of the existence of said features and because not all the features are supported by all the compilers.
Especially std::function, auto built-in smart-pointers are some of my new friends Posted Image

I think a lot of features are just not known to many developers and the STL contains a huge load of stuff that comes in very handy quite often, but one has to know that it is there in the first place


#4991422 Experiences with continous integration anyone?

Posted by doeme on 18 October 2012 - 07:29 AM

Hey all,

I'm currently reading into continuous integration (Wikipedia) and generally it sounds very nice. However as a lot of such things I am afraid, that it sounds nice, but may have some pitfalls when used in practice. I'm especially concerned that the setup and maintenance of such a system could consume quite a bit of energy and time.
So has anyone experience with a this?

What would also be interesting, if you're using automatic builds and testing, what are the metrics you use to find out progress?


#4989402 Reading wrong values from Joystick for the first few milliseconds

Posted by doeme on 12 October 2012 - 03:19 AM

Thank you all for the help and the hints. We've ruled bad soldering-connections almost out, by creating a few more devices of the same type and the all behave the exact same. On the average we're now down to waiting 20ms per joystick (even with multiple connected joysticks) until we get useful signals, by modifiying the code in a way that it only waits until we get something other than 0.

Further modifications by enumerating all joysticks first and then querying them in a separate loop yielded even better results with no need to sleep at all. (modified code below). So our guess is now that the microcontroller has a few ms to get ready to deliver the signals over usb. We will check this next week more in depth, but for now the solution is satisfying for our needs, even without being 100% sure of the cause. Again, thanks for all the help and input from you guys.

JOYINFOEX structtmp;
structtmp.dwSize = sizeof(JOYINFOEX);
structtmp.dwFlags = JOY_RETURNALL;
std::vector<int> connectedJoysticks;
// first enumerate all joysticks
for (int i = JOYSTICKID1; i < (JOYSTICKID1 +16); i++)
{
	if (joyGetPosEx(i, &structtmp) == JOYERR_NOERROR) {
		connectedJoysticks.push_back(i);
	}
}
// then read the buttons only for the connected ones
for(unsigned int i = 0; i < connectedJoysticks.size(); i++)
{
	JOYINFOEX actualPos;
	actualPos.dwSize = sizeof(JOYINFOEX);
	actualPos.dwFlags = JOY_RETURNALL;
	int type = 0;
	while(type == 0)
	{
		//get button states
		if (joyGetPosEx(connectedJoysticks[i], &actualPos) != JOYERR_NOERROR) {
			std::cout << "Error reading joystick " << i << std::endl;
			continue;;
		}
		DWORD jb = actualPos.dwButtons;
		int button[32];
		//get button bit of the 32 buttons
		for (unsigned int i = 0; i < 32; i++) {
			button[i] = (DWORD)powf(2.0f, i);
			if (jb & button[i]) button[i]=1; else button[i]=0;
		}
		type = button[31] + button[30] * 2 + button[29] * 4 + button[28] * 8 + button[27] * 16 + button[26] * 32 + button[25] * 64 + button[24] * 128;
	}
	std::cout << "Got Joystick: " << i << " of type " << type << std::endl;
}




#4987037 Smart way to count positive entries in bitset

Posted by doeme on 05 October 2012 - 01:23 AM

Aside from comparing every entry to 0 and then adding it, I don't see a better way unless you are able to store the entries sorted, so you only need to know where the first 0 is and then only iterate over a part of the array.


#4983491 Is this really Test Driven Development or am I barking up the wrong tree?

Posted by doeme on 25 September 2012 - 01:17 AM

In practice there is almost no one that uses it, but people like to talk about it. It drives your attention away from good code structure and logic, you begin to cheat in order to make the test pass and that is not good at all.


This is just not true. Granted there is a lot of talking about TDD and it's thrown around a lot in managment-circles, but TDD is used in real life. Maybe not so much in the gaming industry, but in b2b market it's alive and kicking. Designing and writing tests is hard work and needs a lot of skill, but once you and your team is used to it it enhances the quality of your code. "Cheating" around a good set of tests can be almost as hard as writing clean code that fulfills all the tests. On the other hand the creed of TDD is that once you pass all the tests your task succeeded, so there is technically no cheating possible. Since you will extend your test set in the future your cheats will fail to pass all the tests at some point which will force you to fix your hacks.
TDD is all about getting correct behavior of a program, it doesn't prevent any kind of ugly code or design.




PARTNERS