Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 May 2012
Offline Last Active Mar 05 2015 08:15 AM

#4996655 How to store the objects in my world

Posted by on 02 November 2012 - 02:24 PM

If you're using C++, and not using the STL, you're doing something wrong. Yes yes, there are exceptions to this rule, but if you're in a position to ask a question like this, you are not the

Anyway, as zacaj said, use an std::vector. Or, perhaps an std::map if you want more convenient and potentially faster lookup.

#4995431 What does it mean to "be creative"? And how does one "be creative...

Posted by on 30 October 2012 - 08:41 AM

Welcome to your first dose of politics. The rest of your life will be spent dealing with people; best you learn how.

Sure, if you sorround yourself with dickheads. It doesn't have to be this way.

#4995422 Resizing a UI element (Best practice)

Posted by on 30 October 2012 - 08:22 AM

I guess our major concern is really scaling of the images when you increase or reduce the resolution size. For the most part, that is.

Unless you generate the graphics on the fly, you're not going to be able to scale them infinitely. What Xanather mentioned is the standard way of achieving scalability for rasterized rectangles. Other than that, I would render to an OpenGL surface or image file using Cairo (or similar):

So why would you want to mix vector-graphics rendering, provided by cairo, with OpenGL in the first place?...

- Create pristine texture-maps, which are resolution-independent and combine those with your custom mip-mapping.
- Have animated vector-graphics as head-up-displays or overlays in your OpenGL-program.

#4993491 Game objects in a 2D game - sprites that contain sprites or sprites and scenes?

Posted by on 24 October 2012 - 12:12 PM

You're right, I could just rename Sprite to Widget and my object hierarchy would suddenly make sense. In Qt for example, widgets can be nested. But I just thought it felt wrong to call it Widget, since I'm after all working on a game here... There is a lot of UI, but there's more, and I don't want the UI to dominate the terminology in my code base. When I add characters moving around, they would probably end up deriving from Widget...

What is a Widget? What inextricable properties does Widget possess? If it's synonymous with Entity, like Sprite was, then the answer is probably "nothing." A Widget on its own carries no inherent properties. You're almost always going to end up having an invisible Widget, or a Widget that doesn't care about input, or that can't move, or has no position, or has a position in 2-space instead of 3-space, etc. etc. To me, this just says that trying to fit your game objects into a hierarchy is a bad idea, they're not concrete enough. That's why the component based approach has caught on so well, it fits the problem space much better than a more vanilla approach to OOP.

If you broke your current mental concept of Widget out into a class that could be contained and used by any game "Entity", then you could share the provided functionality between both typical "game entities" and GUI elements with none of the troubles of making this work via inheritance. For instance, an in game character and a button could both be Entities that contain a "Clickable" or "Inputtable" component. Some InputDispatcher class is aware of these components, and dispatches input events to them, possibly after filtering the input into some nice format or sending only events that a particular component has said that its interested in.

I think I'm mainly struggling with how I can have my UI (screens and widgets) fit into the same object system as my entities and scenes.

I've faced the same problem. What I did is model Button as an entity that contains Drawable, Inputtable, and Positionable. Some properties set in Inputtable say that it's only interested in hearing about click events, and some properties set in Drawable say that it should be drawn relative to the screen, rather than the world, and some properties in Positionable give it a greater z coordinate than anything else in the scene (so that its always drawn on top.)

FWIW, I wrote a little about component based entity systems years ago, which might help to point you in the right direction.

#4993424 Game objects in a 2D game - sprites that contain sprites or sprites and scenes?

Posted by on 24 October 2012 - 07:43 AM

Your problem is that you're abusing inheritance. You should favor composition over inheritance unless you have reason to do otherwise. You don't have true IS-A relationships in your hierarchy. Button is not a Sprite, it just contains a sprite. Likewise for Label and Scene. These are all things that CONTAIN sprites, and if your hierarchy were flattened to reflect that truth, you wouldn't have a problem with button, or anything else, containing any arbitrary number of sprites.

In the latter case, how would I be able to reuse the code for drawing and forwarding input to all children of a sprite?

Sprite shouldn't have children. Sprite is sprite, it's singular. It also does not have means for collecting input--that's far beyond its purview. What you may want instead is some base-class GUIElement. This class could provide default implementations for listening to and forwarding input, as well as adding and removing children. The classes that you derive from GUIElement can hold as many sprites as is appropriate for whatever particular element they are representing.

#4993194 Lua troubles

Posted by on 23 October 2012 - 02:29 PM

In static int spTrWra(lua_State *L) you return 0, indicating that you pushed 0 items on the stack. However the three incoming parameters are still there. You need to pop them off the stack.

No, you don't need to pop them off the stack. Anything below the results is automatically discarded by Lua.

I found a section about lua in one of my books and it seems I'm going the wrong way with this and combines calling a lua function in c++ while at the same time trying to call a c++ function in lua so I'm currently reading up on the subject.

Your code in spTrWra looks reasonable. However, in the cMap constructor, you call cMap::init, before any Lua code has been run. Therefore, lua_getglobal(L, "init") just pushes nil to the stack. Furthermore, when you call lua_call, you're saying that there are 3 arguments to some function on the top of the stack, presumably the global "init" (which is actually nil here,) but you only push one argument onto the stack, "this."

You probably intend to call luaL_dofile(L, "map.lua") before you call cMap::init, assuming that that is where you define the lua function "init."

I find it helpful to annotate my Lua C API usage, like this:

void cMap::init()
    lua_getglobal(L,"init"); // nil
    lua_pushlightuserdata(L,this); // this nil
    const int s = -1;
	    //another buggy cout
    const int a = 3;
    const int r = 0;
    lua_call(L,a,r); //

I track the state of the stack in comments next to any functions that modify the stack.

Also, I've found this site to be an invaluable reference.

#4993171 Favorite little known or underused C++ features

Posted by on 23 October 2012 - 01:30 PM

Variadic templates are ridiculously powerful, and antiquate a lot of redundant C++03 template metaprogramming.

Initializer lists are a much needed addition to the language. They add the ability to make classes feel more like POD's, even when they aren't.

std::vector<int> ivec = {1, 2, 3, 4};
std::vector<int> ivec;

#4993063 How/Who create the GameObjects?

Posted by on 23 October 2012 - 05:43 AM

What about game objects that need to persist across scenes? Like puzzle logic state that spans levels? Or the main player character + all of his stats/score/whatever?

Segregate your shared data, so that you can better identify the character of it--what it means and where it comes from. Then, you don't need to expose it globally in your Game class, you can just pass it between scenes that need it (as parameters.) Yes, it's more work, but it's also more explicit, and ultimately much safer.

Is this poor design?

Yes, for a variety of reasons. What Servant of the Lord said is true, and will work well if you want to carry on with your design, but the design is flawed. Think to yourself, will a virtual Update method always be enough to fully achieve the purpose of a particular GameObject? The answer is no. Which means that you will unavoidably have to pluck GameObjects out of wherever they polymorphically reside, and cast them to their proper types. This is folly. How can you be sure of the types, except by experimentation with dynamic_cast or divine knowledge? Don't store heterogeneous types homogeneously. You might think that they're homogeneous types, because they derive from the same base class, but they're nearly useless if they're never casted.

It can seem messier to deal only with concrete types in this instance, but it's really only being more honest about what is actually happening. Furthermore, there should be a strict separation between GAME code and ENGINE code. This looks like Game code to me, so it doesn't really matter if it's directly oriented toward your game, and concretely references your derived GameObjects. If you've got too many derived GameObjects for this to be feasible, that's merely an indicator that something else is wrong.

#4992781 Problem animating sprite in SFML 2

Posted by on 22 October 2012 - 08:40 AM

You're controlling the speed of the ball, but you aren't controlling the speed of the animation. In the same way that you calculate "amount" in PongBall::move, you need to calculate what frame of the animation you should be on based upon what fps you would like your animation to play at. Only increment mImageIndex when you've accumulated enough time for a frame.

Something like this, following the pattern of your code:

mAnimationAccum += ANIMATION_SPEED * pElapsedTime.AsSeconds();

if(mAnimationAccum >= 1){
    mAnimationAccum = 0;

Say ANIMATION_SPEED is 30, for 30 fps. Then everytime mAnimationAccum == 1, 1/30 of a second has passed, so we increment the frame we're on and reset the accumulator. You'll probably want ANIMATION_SPEED to be 5-10 fps, but I suppose it depends on how fast the ball is moving on screen.

#4982016 Representing an iso map in a 2d array?

Posted by on 20 September 2012 - 07:31 AM

As I said originally, I require the entire visible map to be covered with tiles. Using a traditional square grid on a tilted on a 30 degree angle means that there are going to be tiles with negative array indices, shown in black.

How about storing the active area in one array, and the inactive area in another? Store the active area in a square grid that is later rotated, using whatever coordinates you want. Store the inactive but visible area in another array that has a hole cut out of its middle (where the active area fits.) Superimpose them...now you have 2 sets of coordinates, none of them are negative, and as long as you aren't pathfinding between the two areas, it's OK.

If you weren't stuck on using an array, this wouldn't be a problem at all. I don't know what language you're using, but in C++ you could use an std::map in any number of ways.

std::map<std::pair<int, int>, Tile> tiled_map;
std::map<int, std::map<int, Tile>> tiled_map;

#4977662 Keeping Recourse Collection Entertaining

Posted by on 07 September 2012 - 09:13 AM

Does it need to be fun? Resource collection is in general a means to an end, and not an end in itself. It's something that you have to do, but not something that you want to put too much effort into doing. With it being such a repetitive task, there's no way around it eventually becoming boring. Most games just jump right past that eventuality, and try to make resource collection as unobtrusive and simple as possible.

#4976909 understanding return by value.

Posted by on 05 September 2012 - 11:37 AM

still, it's very confusing, and the memory overhead of what's going on is what scares me into only doing this sort of stuff via passing by reference, and using new/delete instead of ever using stack memory to hold the object.

Don't be scared. Until you've profiled your code, and determined that it runs too slowly as a direct result of passing by value, always pass by value (where possible.) There are two sides to the argument. Heap allocated memory comes with its own set of difficulties, and they're rather more unpleasant than the problems associated with pass by value.

I've never been more productive since I virtually eliminated heap allocations from my own code: http://purplepwny.co...s_by_value.html

#4976878 What is the easiest text pattern for a text file, in use of a text parser for...

Posted by on 05 September 2012 - 10:24 AM

I would use an already established format, like XML. Then you won't have to write a parser, and you get lots of other goodies for free.

	 <title>This is a title</title>
	 <text>This is a message</text>

You can structure your data however you'd like really:

<conversation title="foo_meets_bar">
	 <message from="foo">
		   Argh ye scurvy scallawags.
	 <message from="bar">
		  Pleasure to make your acquaintance.

#4976031 Website Design ( for the game community )

Posted by on 03 September 2012 - 06:00 AM

Because it's true, and a well-established best practice amongst web designers. All text and navigational elements should be provided as actual text rather than as images or Flash content. This better allows search engines to access and read your content, and makes your website more friendly to users with disabilities (such as those using a screen reader). Thankfully the use of web fonts or solutions such as Typekit or Fontdeck means this need not limit your choice of fonts.

Exactly right. The problem with a more semantic/accessible web design in general though, is that you do lose some control of how your site will appear to the end user. You can account for this with sane fallbacks, but still, if someone views your site on a console or obscure mobile device, it's likely to not look as nice as you would like. It's a tug of war between form and function -- you can strongly control the appearance by using images/flash content in place of your text, but you lose the benefits of accesibility and indexability.

I have been making sites for some time and while I know that making text based is generally better I have never heard of anybody vehemently disregarding their use.

FWIW, I've been a web developer for 10 years, and I've seen the drastic effect that favoring function over form can have on rankings. You do, and this was more true pre-CSS3, sometimes have to compromise on your "ideal" image of the site, but it's very much worth it in the end.

#4975867 Website Design ( for the game community )

Posted by on 02 September 2012 - 05:00 PM

The layout is quite nice, but if you're about to put a slideshow in that big empty spot, that's too cliche for my taste. I don't know what font you're using for the top navigation, but make sure that you do not ever use images instead of raw text, or your Google rank will suffer (without hacky workarounds.)