Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Jul 2003
Offline Last Active Today, 08:55 AM

#5130393 Determining how sharply curved a mesh is at each point

Posted by JTippetts on 10 February 2014 - 04:31 PM

A quick google turned up this paper: http://gfx.cs.princeton.edu/pubs/_2004_ECA/curvpaper.pdf

#5129063 Cannot allocate a decent amount of memory glBufferData()

Posted by JTippetts on 05 February 2014 - 10:44 AM

Post your code. That's a segfault, not an out-of-memory exception.

#5124403 building luabind for gcc 4.8.1

Posted by JTippetts on 17 January 2014 - 08:23 AM

Ah ok, maybe it was a good thing it didn't work out then ;)


I think I got that error because I was using the wrong boost version, or that there were some errors when building boost.

I got past that later though, and actually managed to compile everything, but when trying to include luabind in my project it was complaining about missing references and all other sorts of things. And that was when I gave up on luabind smile.png


Good thing I didn't have to introduce boost in my project too.. there's no need for it now with C++11 (nor has there been for a while... for me anyways)


There's really nothing wrong with boost. It's just that it's 1) complex and 2) frequently changing to reflect the current state of the language and the usage patterns of the higher level users that drive it. But Boost sometimes contributes to the C++ standard, and even aside from that it is a fairly useful piece of software, so it doesn't hurt to try to become familiar with it.

#5124306 Ugh! Your shorthand is too short!

Posted by JTippetts on 16 January 2014 - 11:21 PM

It's not really off, nor is it even particularly ugly, once you look past the heavy use of complex macros. It's just code from a different time. Looking at the copyright dates, you can see that original versions of it date back to 1997. 1997 was eons ago, in terms of language development. It was written in C first of all, and even if they'd have used C++, template support in C++ compilers of the day was nowhere near what it is now. Like Apoch said, it was just someone trying to write a generic tree type in the C language. To achieve that type of genericity in C took some arcane contortions, as you can see, but in many cases it was well worth the effort; and in fact, an old-school C programmer would not in any way be all that intimidated by that code, being more accustomed to that style of programming. Remember that in C, macros were not the pariahs they are now; in fact, they were quite integral to advanced usage of the language.

#5124248 building luabind for gcc 4.8.1

Posted by JTippetts on 16 January 2014 - 04:56 PM

Luabind is basically obsolete. With some searching you can find personal repos maintained by individual users (often with their own "fixes") but the official is essentially dead and, given its reliance on Boost (and the accompanying relatively complex code that Boost uses) it's not really a surprise to me that it's starting to rot. 


I've never seen that error before.

#5124061 Ugh! Your shorthand is too short!

Posted by JTippetts on 15 January 2014 - 11:13 PM

Well, if you are having to decipher the usage of i in the context of 1,000,000 lines, or even 1,000 lines, then you ought to refactor that function a bit since that's just a tad too long. Unless you're trying to say that i is a global, in which case then yes, that's wrong.

#5122632 To aspiring indie devs

Posted by JTippetts on 10 January 2014 - 11:10 AM

You want to know what all those lists (including the one being discussed) have in common? They were all made by somebody who just shut the hell up and made a game. It's the same in pretty much every walk of life. There are people who make games (or who make movies, or who write novels) and then there are people that sit around on the Internet all day, browsing reddit, checking gd.net, looking up 1001 inspirational articles to help them get all fired up and thinking "f yeah, I'm gonna make a game and these guys that made this list totally told me that it's possible!" and pretty much doing everything except making a game.
You don't need some list maker to tell you it's totally possible for you, yes you, to make a game.
I have this sneaking feeling that somewhere along the way, people have gotten lost. Once upon a time, just getting together the right tools to make a game was a challenging proposition. At some point, though, compilers and art tools became readily available for free, APIs sprang up that made it a veritable dream to make games, and yet it didn't seem to actually get easier to make a game for a lot of people. I think the problem is now that there is such a glut of information and time-wasting. You get on the net with the intention of making a game, and you end up instead reading a list of 15 awesome things you just totally have to not fucking give a shit about, because you are not here to read about that stupid crap, you're here to make a game. So download your tools, shut your browser, and make a game.
I know, I know, I need to practice what I preach.

#5121801 Deconstructing roguelikes: what makes them addicting?

Posted by JTippetts on 06 January 2014 - 08:35 PM

Looking honestly at my own rogue-like addiction phases, I'd say the gambling comparison is only partly accurate. The randomized nature of the dungeon is a lot like the toss of the dice, it's true. However, for me the big thing about rogue-likes is how they are akin to untying a complex knot or untangling a ball of yarn, something I do for my wife during quiet moments at home. Each game is like that knot, where you have to pick at it and poke at it, to find the way the knot unravels. Sometimes you pull the wrong thread and make the knot worse. Sometimes you find just the right steps and the threads fall neatly into place. Sometimes the knot just sort of falls apart in your hands, and other times it just pulls tighter and more snarled the more you tease it until finally you hurl it across the room in anger. But each new knot is a whole new experience, unlike in its details to any other knot that came before.

#5119303 Build UI in OpenGL for my 3D game world?

Posted by JTippetts on 26 December 2013 - 09:32 AM

What you're looking for is called an orthographic projection. This is a 3D projection that does not include any perspective "shrinking" as objects get further away. Older versions of GL included the now-deprecated glOrtho function to accomplish this, but you should be able to duplicate the effects easily enough using a matrix math library such as GLM.

Essentially, an orthographic projection maps the screen to some range of coordinates, X and Y, so that you can draw objects on the X/Y grid and have them appear in the correct location on-screen.

The typical drawing order is to draw the game view using the game camera and projection, then switch the projection to an orthographic matrix and draw the UI elements as a series of quads. These quads will technically be 3D, in that they are drawn using the same exact types of function calls as drawing the game objects (binding vertex buffers, shaders and textures, rendering triangles) but the geometry is configured so that the shapes are flat quads on the X/Y plane. The Z coordinate is typically set to 0; or, if desired, you can use the Z coordinate to determine the visible ordering of the objects as necessary.

#5118030 How to install GCC

Posted by JTippetts on 18 December 2013 - 11:47 PM

Cygwin and MinGW are both attempts at providing GCC plus standard libraries and build environments for Windows. Cygwin attempts to provide a POSIX environment, whereas MinGW does not. You can get modern builds of MinGW (which seems be more widely used than Cygwin these days) from the Mingw-w64 project.

Additionally, despite what the book says, you don't need to install GCC to use C/C++ on Windows. Microsoft provides their own solution in Visual Studio (link is to the free Express version.)

One final addendum: C is hardly used in games anymore; it tends to be the language of the lower-level kernel hackers. C++, however, is still widely used. C# also is making a strong showing, and if you go that route then Visual Studio is a good choice as it supports both C++ and C#.

#5117480 Programs going way too slow since moving to a new computer...

Posted by JTippetts on 16 December 2013 - 08:35 PM

Did you update to the latest GPU drivers?

#5117354 Different A* paths for different entities: Question on Path Node Management

Posted by JTippetts on 16 December 2013 - 11:19 AM

I just generate one path, hand it off to the unit that requested it, generate another for the next one, hand it off. If there are collisions along the route, it's not really the responsibility of the pathfinder to handle them. The pathfinder just finds a path. The path execution system that actually moves units is where the responsibility lies to resolve collisions, either by having one unit delay while another paths through, or by calling a local path solver (not a full path-find) to try to find a local solution to a blocked path.


Now, I suppose you could include fields in your nodes to mark them as blocked at a certain time, t. I'd probably implement this as a vector per node and incorporate the time-stamped block as part of the heuristic, to steer units around the blocked node. After a path executes a node step it would be responsible for clearing out any time blocks. Going this route just seems a bit overly complex to me, given that local collision resolution typically works well enough.


Pathfinding is plagued with the same kinds of temporal simulation complexities that physics are, with the additional burden of prediction. You probably aren't going to ever build the "perfect" pathfinder; about the best you can hope for is one that works "good enough" for your particular scenario.

#5116861 Which will be better for gui?

Posted by JTippetts on 14 December 2013 - 08:39 AM

There are a number of different ways you can approach the UI problem for a game.


1) Use a large toolkit of general-purpose 'widgets' for users to use, and remove from the users any responsibility for implementing the actual widgets or having to deal with them in any way outside of usage. Users only wire up various pre-determined widgets together to build a UI. This is the approach that toolkits such as Qt use. They often do provide the ability of allowing the user to build custom widgets via plug-in. The problem with this approach is how heavyweight it is. There may be a lot of features and tasks going on that you just don't need in your game engine. Also, many of these toolkits want to handle everything, including rendering using their own rendering process that stands outside your game pipeline. In the case of Qt, I believe that is where a lot of the performance hit comes from. These general-case UI frameworks tend to be mostly designed for standard document and UI models such as you see in non-game applications, in order to give users a familar-feeling interface; think "File Edit View" menu bars and docking toolbars.


2) Use a general-purpose widget toolkit as above, but impose on the user the requirement of supplying a front-end for the toolkit to use to handle some jobs, such as rendering and input handling. I believe this is how CEGUI works. The user must provide functionality to allow CEGUI to render itself, using the user's own rendering framework; additionally, the user must gather inputs from their own input system and inject those into CEGUI. This can provide performance bonuses, since the user can ensure that the UI rendering routines are optimized for their particular framework, rather than relying on whatever rendering engine the UI framework developer wants to use.


3) Write your own. General-purpose toolkits, I've noticed, tend to include lots of the "standard" types of widgets: radio buttons, list views, etc... Lots of things that games don't necessarily need. Additionally, they often don't have direct analogues for things like Skill Icons with a cooldown sweep, drag-and-drop inventory slots, health globes with swirly, multi-layered animated textures and perhaps a custom shader (think Diablo 3 health globes here; for all the flaws of that game, those health and resource globes are awesome; but you won't find a widget for them in Qt, no sir).



There needs to be a difference between the UI that you use for the game proper, and the UI that you use for editor and tools. There is no reason your editor needs to have a swirly layered health globe widget in the interface, and there is no reason that your game needs to have a listview box rendered in default Windows style. Game UI and tool UI are just too different.


My personal preference is to use 1 for tools. When your task is to build a tool, you don't want to get bogged down in the messy details of implementing UI from scratch. At worst, I would go with 2 and use CEGUI, if Qt just wasn't going to work for me. For the game, I almost always go with 3.


Now, many engines provide UI capabilities themselves, and if the engine was built with games in mind then a few of the widgets might be suitable for game use. But even so, I typically expect to have to do a lot of work implementing the things like swirly health globes, things that it just isn't practical to expect the engine developer to provide, since such widgets are so dependent upon the style and feel of the game itself.


As far as a Blender-like interface, you're not going to find such a thing built into many engines, since Blender's interface was tuned and tooled with Blender's needs in mind. Games typically require other styles. You might conceivably find game tools built with such an interface in mind; and, in fact, Blender itself is both a game engine and a game tool. But as far as standalone engines go, you might have your work cut out for you trying to find an engine whose packaged editor tools use an interface like Blender's. You might end up having to write that UI yourself.


The take-home message here is that everything is so highly dependent upon the engine framework that you choose. Also, expect to have to do a lot of tedious work to tweak any pre-built UI libraries to your needs, since flexibility equates to complexity, and no framework can possibly take everyone's needs into account.

#5114775 Can a "PvP arena" based game have a good story?

Posted by JTippetts on 05 December 2013 - 10:11 PM

In my experience, the intersection between PvPers and people who play for story is rather small. I'd say you probably could build some story elements into it somehow, but you need to be aware that many players will see them as an impediment to their real reason for playing (the PvP) if you don't give them some way to skip past them. The further in the background you can put the story, the happier they will be.

#5114335 How much it cost to develop a game similar like Clash of Clan, Friendly fire?

Posted by JTippetts on 04 December 2013 - 09:52 AM

" Clash of Clans and Hay Day were created by teams of only half a dozen developers each."
"Supercell started developing games for mobile devices in 2011"

So, estimate the salaries you would pay for half a dozen developer (make them generous, to attract the good ones) and multiply by about 2 years. Double that at least, because running a business has other costs besides just salaries, including taxes and the employment of the "overhead" positions that aren't active developers. Add in the costs of infrastructure (servers to run the game, development rigs for the programmers, tablets and software for the artists, licensing for any used technologies and software, etc...) and there you go; a pretty decent estimate for how much it cost to develop Clash of Clans.