Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Jul 2007
Offline Last Active Oct 18 2013 02:40 PM

#5021910 Skinning Problem

Posted by on 15 January 2013 - 02:01 PM

I might be completely off, but these are things that seem dubious to me:

1. Is it necessary to multiply bone matrix with bone offset matrix? I would probably simply multiply with offset matrix assuming that before passing to glsl it is already multiplied with parent offset matrix (that is in turn multiplied with its parent offset matrix and so on).

2. Is that the sum of aVertexWeights 0 to 1 guaranteed to be 1.0? If not, maybe divide finalVertex with sum of aVertexWeights.

#5020628 which side of my shooter

Posted by on 12 January 2013 - 03:45 AM

Are these actually position vectors, I mean vectors representing positions of shooter and target? Or do you mean that vectorA is the direction of the shooter and vectorB is a vector from the shooter's position to the target? I'm assuming the second case, because direction of the shooter must be known to make the decision of turning either left or right. In that case, I would use cross product. If cross product of vectorA and vectorB is less than 0, it's on one side and if greater than 0, it's on the other side. See http://www.gamedev.net/topic/289972-cross-product-of-2d-vectors/

#4982030 Starting a Game Company

Posted by on 20 September 2012 - 08:10 AM

I don't really live in America, but I believe in general the rules should be similar in most countries. A company has to be registered to a physical address. Usually the rooms must be rented or owned by the company or there must be a written and signed agreement from the owner of rooms about letting you run the business there.

About taxes I'd probably try asking from accountant forums (such as http://www.accountantforums.com/). They could probably give you a lot better advice about accounting.

#4968981 Pretty advanced pointer problem

Posted by on 13 August 2012 - 02:42 AM

So pointers and references can be used differently? I've always thought that a pointer of an variable returns it's memory position. A reference of that pointer returns the normal value. I didn't know i could use references by themselves, just thought i used them to kind of dissemble a pointer.

I'm going to try to give an explanation that I use for myself when coding and while it's not pure, it's easier to understand and it works. However, you'd do well to look up other sources that probably explain it better and more correctly than I do.

First the declaration of a different variables:
int value=0;          // Integer value (takes up 32 bits on 32 bit system). Should be initialized almost always.
int* pointer=&value;  // Pointer value (takes also up 32 bits on 32 bit system, but used differently). Should also be initialized almost always.
int& reference=value; // Reference must always be initialized! Compiler checks against it and won't let simple int& reference; pass

The first is obvious, it reserves 32bits for the value. The pointer is also 32 bits and points to memory location of value. The reference acts pretty similarly to pointer. The main differences are that reference can not be reassigned. When assigning new value to it, it is assigned to value, not to itself. The only bad things that can happen with a reference is that value goes out of scope or is destroyed before the reference goes out of scope. With a pointer one can accidentally reassign its value and it will point to something that is no longer there.

About references to pointers.
int value=0;
int& referenceToValue=value;       // References value
int* pointer=&value;               // Pointer to value
int*& referenceToPointer=pointer;  // References pointer, so it technically acts as pointer to pointer

// All these operations store 10 in value

There's a lot of material on the subject and it usually takes a while to wrap ones head around it, so just search for pointer vs reference.

If you don't mind i'd like to hear what you had to say about the rendering code. Since if i do decide to rewrite it all i'd hate to make the same mistakes again

It's better to separate the base-logic and rendering code except in some borderline scenarios. This is a simple example on how I might set it up for a game similar to yours that has inventory and loot. And it doesn't have any explicit pointers at all:
#include <vector>

// The logical part
/** Item component is the baseclass for WeaponComponent and other possible components.
  It exists, because enable/disable functionality is shared */
class ItemComponent {
    bool enabled;   ///< For enabling/disabling component

    ItemComponent() : enabled(false) {}

    void enable() { enabled=true; }

/** A weapon component is item component */
class WeaponComponent : public ItemComponent {
    double damage;    ///< Damage that the weapon might cause

    /** Constructor with default being a weapon that does nothing */
    WeaponComponent(double _damage=0.0) : damage(_damage) {}

/** It does not matter whether the item is in the world as a loot or in inventory. We won't put anything here that is world specific (eg position). */
class Item {
    WeaponComponent weapon; ///< Weapon component. Enable the component, if the item is a weapon.
	                    // If memory consumption is a problem, Weapon* could be used instead, but then copy
			    // constructor and assignment operator must be overloaded to create copies of all components.
		            // At the moment it is not needed, because ItemComponent holds entire copy of weapon anyway.

    void enableWeaponComponent() { weapon.enable(); }///< For convenience

    /** Get weapon component reference as constant reference */
    const WeaponComponent& getWeaponComponent() const { return weapon; }  	

    /** Set weapon component. An assigment is made and contents of passed const 
      reference to some other weapon are copied to weapon component of this item */
    void setWeaponComponent(const WeaponComponent& _weapon) { weapon=_weapon; }

/** Provide separate loot item to give it world position */
class LootItem {
    int x, y;
    Item item;   // Easier to have the item here

    LootItem(int _x=0, int _y=0, Item _item=Item()) : x(_x), y(_y), item(_item) {}

    const Item& getItem() const { return item; }

typedef std::vector< Item > Inventory;  // Inventory now becomes a simple vector where we can put items and take them back out again. Also note that we are not keeping pointers, but entire items
typedef std::vector< LootItem > Loot;   // Same with loot

// User-interface and rendering.
// I'm leaving out a lot from here, because the example has already grown beyond the complexity I intended.
/** Rendering and user interface handling. The reason why this is provided separately, is because there can be different views on inventory.
  For example we might want to render inventory of enemies differently over the head of enemy and so on. */
class InventoryUserInterface {
    /** No need to hide rendering of items */
    void renderItem(Item item) {
      // Render item however you want

    /** Render inventory */
    void render(Inventory& inventory) {
      for(Inventory::const_iterator item=inventory.begin(); item!=inventory.end(); ++item) {
        // Render the item however you want. You might have components provide the information about which
        // images to use or item itself or just render text about which components are enabled and which are not.

    // Omitted handling user events etc completely

// Setting up
int main() {
  Loot loot;
  Inventory inventory;	// Create inventory

  { // We can for example place initial items to inventory inside this scope. As soon as 
    // the scope ends weaponToGoToInventory will be automagically gone, but its copies will remain in inventory
    Item weaponToGoToInventory;
    weaponToGoToInventory.enableWeaponComponent();  // Make the item into actual weapon
    inventory.push_back(weaponToGoToInventory);     // Push a weapon to inventory
    // We can push more than one of the same weapon to inventory and it won't crash!
    // A full copy will be made each time and since weaponToGoToInventory only exists in this scope, we can just forget about it

    Item genericItem; // Create a generic item
    LootItem lootItem(10, 25, genericItem);	// Create loot item that is now positioned at (10, 25) 
                                                // and holds weapon as it's item
    loot.push_back(lootItem);  // Push it to loot

  // Taking last item from loot and placing to inventory. 
  // A separate class that keeps track of both loot and inventory should normally provide a method for it
  // that looks something like this: void lastFromLootToInventory();
  Item item=loot.back().getItem();  // We take the item from LootItem
  inventory.push_back(item);        // And we place it to inventory

  InventoryUserInterface inventoryUserInterface; // Create userinterface for displaying inventor(y|ies)
  inventoryUserInterface.render(inventory);      // Render items in inventory

  return 0;

Also, don't scrap your code. Even if you decide to rewrite it, it is very useful to have the old code and you can still use large portions of it.

#4968851 Pretty advanced pointer problem

Posted by on 12 August 2012 - 03:54 PM

I didn't locate the crash and didn't run the code because I didn't have SDL development libraries installed (only SDL2), but I have some general recommendations that might help. These are really quite general and you have probably of them, but I'll reiterate them anyway.

First of all, the class inheritance is a bit of a mess and memory seems to be leaking. The worst is that almost everything seems to derive from LoadFiles and its constructor loads all images, fonts etc. Each time anything derived from LoadFiles is created, and these classes seem to be many in number, all images and fonts probably get loaded again and again. I'm not 100% sure given that I've only taken a glance at the code, but it really seems to be so.

Secondly, there seems to be lot of inheritance. It is better to use composition in most cases. Try looking up composition vs inheritance. There was a good post about it on GameDev, but I can't find it at the moment.

There also seems to be a bit of duplicate code. For example Item::setDead(). Item could just as easily have boolean dead member and set it instead of it being marked abstract. All the child classes are just doing the same. Just try to find code that duplicates itself and remove it. It's a slow process at first and it's often easier to just copy-paste, but it will hurt a lot later even when trying to make sense of your own code that is months or years old. Also, the less code you have to read the more obvious the errors will become. I don't mean shortening the names of variables, but the logical duplicates where a new function could be used in more than one place or even when it makes logically more sense to keep it separately.

Now, the pointer-hell. There are a lot of pointers, so many I lost track. Whenever possible, try to use references, full memory copies and stack allocated variables. In my experience pointers are almost always bad unless you need to optimize something. And even then the pointers should be local.

There are also many references to pointers. A reference is technically a pointer anyway, with the restriction that it can not be reassigned to point to another location. For example instead of Cursor* &cursor it makes sense to use either Cursor* cursor or preferably Cursor& cursor since the pointer value is not reassigned and it would be a bad idea to do so anyway.

Then there is the problem with rendering code being mixed with the game state. Usually it is best to have the underlying structure separately and provide different views for it, but it's already way out of scope of what I planned to say at first and there's plenty said about it elsewhere.

I hope you get something out of my recommendations. Overall it's not bad for a first project at all. I wish I could be more thorough, but architecture and pointers are a huge subject and unfortunately without running the code seeking crash is like searching random uninitialized pointer from heap of bees.

Edit: Sorry as I am probably repeating much said above as I started writing when no other posts were made. I'm slow.

#4957924 What's wrong with my C++ code?

Posted by on 11 July 2012 - 01:58 AM

A note about noizex's recommendations:

Checking whether pointers are NULL before calling delete on them is unnecessary. Calling delete on a NULL pointer has no effect by definition. Although not initializing pointers to NULL in constructor(s) in current code is a problem.

#4955558 Making the wilderness interesting

Posted by on 04 July 2012 - 02:21 AM

Add bugs and plants. Make them react to player. Scaring butterflies off flowers can sometimes amuse me for hours. Joking aside, it really adds a lot to have other interactive elements in wilderness than just animals that try to attack you.

#4954949 How do you create your 2D art?

Posted by on 02 July 2012 - 10:11 AM

I generate my 2D art programmatically. What I don't generate I order from artists :)

That said, there are many possibilities for creating 2D art. It depends on what you want your game to look like. Possibilities are already mentioned pencil-paper-scanner, pixel art, vector graphics (Inkscape), 3D graphics rendered to 2D (Blender), photography etc. I can't say which is easiest or best method. In my opinion it largely depends on what you are most familiar with. You can also use tablets (Wacom tablets are good) when drawing in Gimp or some other raster graphics program. It's easier to use than mouse, if you are good at drawing/painting on paper.

#4953685 Learning SDL, need help to draw an object on screen between classes

Posted by on 28 June 2012 - 09:35 AM

There is a problem with the solution you found. You are loading image each frame. It's very slow!

A better way might be:
class Player {
    SDL_Surface* image;

    Player() {
      SLD_Surface *image = IMG_load("hello.png");  // Load image when creating the player

    ~Player() {
      SDL_FreeSurface(image);                     // Free the image when destroying the player 

    void draw(SDL_Surface* screen) {
      SDL_BlitSurface(image, NULL, screen, NULL); // Draw the player image on screen

// in main loop
// ...
SDL_Flip(screen)// to update the scene
// ...

Even better would be to store all images in an image loader class that would free all of them automatically when it is destroyed. Then destroying the image in Player destructor wouldn't be necessary.

#4953622 Them Bones them Bones them Dry Bones

Posted by on 28 June 2012 - 05:04 AM

It sounds about right. Although technically you could get away with only 2 matrices. One for the first bone and another for the second bone. That is if the vertices of bone meshes form a unit length mesh that's starting tip is at 0,0,0 and end tip is where the first bone would end if its matrix were a unit matrix. Though matrices for bone meshes might make things more convenient.

#4944610 How to detect abnormal user disconnection almost immediately

Posted by on 30 May 2012 - 03:36 AM

Technically server can't know that a client has died until an expected message from client doesn't arrive. If that message is sent with set frequency then it is called heartbeat.

Let's say Client sends a message to Server each second. Suddenly Server notices that messages from Client haven't arrived for longer than second. Server now has reason to suspect that Client has died. Still, Server can only guess that it's dead. Sometimes packets get lost, so listening to single missed heartbeat is not a good idea, but still a warning sign. More than 5 missed heartbeats and the Client is likely dead.

About your second question. Since you are using win32 then you could use WSAAccept that has callback function. It is called before accepting a connection with connection data and you can return CF_REJECT to indicate that you don't want that connection.

#4942839 Linker errors when using templates.

Posted by on 24 May 2012 - 02:51 AM

Templates are sort-of header only. Meaning that compiler can't resolve template in linking phase and all method definitions must be available during compilation. This means that you should either put everything in your source file to header file and remove the source file or do some hack like this:
// LinkedList.h
... class declaration etc ...

// Do something that's generally a really bad idea
#include "LinkedList.cpp"


// LinkedList.cpp
// Add ifdef, such that contents of this file are only compiled, if it is included from LinkedList.h

... Methods and everything else typically in a .cpp file...


#4938629 Custom cout formatting using /tags

Posted by on 09 May 2012 - 04:28 AM

Anything is possible. Maybe something like this would work for you? Example is without formatting and without colors output.

std::ostream& operator<<(std::ostream& str, const char* c);

int main() {

    cout << "/fgCyan" << endl;

void setColor(unsigned char color) {
    if(handle)    SetConsoleTextAttribute(handle, color);

std::ostream& operator<<(std::ostream& str, const char* c) {

    // Do formatting and output text in your own colors
    str.write(c, strlen(c));
    return str;

#4932035 Tool suggestion for creating game data

Posted by on 17 April 2012 - 12:22 AM

I've used jEdit http://www.jedit.org/ for editing XML. It has plug-ins for autocompletion and grammar checking by used schema, XML syntax checking and spell checking. All these plug-ins can be installed from inside jEdit itself. It downloads and installs what you pick, so you won't have to search all around. It's the only XML capable tool I haven't had much trouble with so far.

#4928182 Getting error C2819. Need some help.

Posted by on 04 April 2012 - 06:29 AM

I doubt this is STL problem. Perhaps I'm wrong, but it seems to me that accessing GameObjects[i] gives you a GameObject instance that is not a pointer. So this should be correct instead:
if(GameObjects[i].shader == j+1) ...
In short, GameObjects is a pointer in your code, but GameObjects[i] is not:
CGameObject * GameObjects;	  // Pointer to GameObject instances
// ...
// Initialize GameObjects etc
// ...
GameObject& go=GameObjects[i]; // go is reference to GameObject, not a pointer
This would give you a pointer at i:
CGameObject ** GameObjects; // Pointer to pointers of GameObject instances
// ...
// Initialize GameObjects etc
// ...
GameObject* go=GameObjects[i]; // go is pointer to GameObject

Note: all the above is assuming that CGameObject is a class, not a pointer type.