Jump to content

  • Log In with Google      Sign In   
  • Create Account


greenvertex

Member Since 31 Jul 2012
Offline Last Active Nov 21 2012 07:12 PM
-----

#4996337 Sharing C++ object between application and plugin with C interface

Posted by greenvertex on 01 November 2012 - 04:47 PM

extern "C" __declspec(dllexport) void pluginEntryFunction(void* _theObject)
{
		 // Following is wrong and dangerous:
		 myClass* theObject=(myClass*)_theObject;
}

That seems incredibly generic to me. Maybe that's why you're running into issues? Instead maybe prefer something long the lines of:

extern "C" __declspec(dllexport) void pluginParseBuffer(char* theBuffer)
{
  //Do something...
}

It's not a good idea to define the same type in and out of your library for exactly the reasons you described. While breaking up a generic function into more specific operations is certainly more verbose on the client's end, they can always be wrapped in a function to perform the appropriate calls in order there.


#4993873 Performance issues in simple program

Posted by greenvertex on 25 October 2012 - 11:55 AM

Not really sure how much of a hint you want here but there's an abstract data type very suited to this type of search. I won't name it, but the next paragraph contains problem spoilers (if that's such a thing...):

Each number has a pair of factors that are, themselves, numbers that are either primes or smaller numbers with pairs of factors. If you keep splitting your number this way, eventually you'll have a particular type of data structure containing a bunch of numbers at the very "bottom" (my word, not the actual term typically used) that are all prime. All you have to do at that point is pick the right one...

You don't necessarily need to store factors in a file, though there's no reason not too if you really want to do it.


#4993850 Performance issues in simple program

Posted by greenvertex on 25 October 2012 - 10:59 AM

Yea that's going to be extremely slow for large numbers. You're reserving memory for num integers when really you only need memory proportional to the number of prime factors of num at the end of the day. So if you entered 1,000,000 you're looking at almost 4 megs of RAM reserved, roughly 797 pages. As you iterate through all that, your swapping pages constantly from CPU cache to memory and visa versa. That's generally a slow(ish) operation.

While your solution certainly works, it's not terribly efficient overall in terms of memory (as you've seen). My suggestion is to go back to the drawing board and see if you can figure out how to calculate the primes without requiring so much memory. You're almost there, you're just being a little overzealous with calloc...


#4993136 Lower bounds on the complexity of problems

Posted by greenvertex on 23 October 2012 - 10:39 AM

So, do you think it was naive of me to suppose I could determine the complexity bounds before discovering the actual algorithm? Or should I keep defending this as a possibility in my project?


Not necessarily naive, if you can determine the class of some undetermined algorithm you could prove some asymptotic lower bound to that class as in the sorting example above. But, barring that, I don't believe it's generally possible beyond the most generic assumption of big-omega(1).


#4991836 Handling exceptions in stl containers.

Posted by greenvertex on 19 October 2012 - 11:27 AM

Take a look at xmemory and xmemory0 if you want to see how std containers manage it in VS2012. They will throw bad_alloc if there is one (note the absence of a "throw()" on push_back), there is no error handling within the container itself.


#4991829 Lower bounds on the complexity of problems

Posted by greenvertex on 19 October 2012 - 11:11 AM

Even with your sorting example, you already partially knew the algorithm: you must iterate though all elements at least once, leading to an asymptotic lower bound of big-omega(n). Presupposing absolutely nothing about an algorithm would lead to big-omega(1) I suppose, but that's not terribly meaningful or accurate in most cases.

You could make somewhat general statements about classes of algorithms given you know at least the data it operates on (as in sort above):

Vector-based algorithms will be big-omega(n).
Matrix-based algorithms will be big-omega(n2)
etc.

Note, these are all asymptotic lower bounds. Generally the least interesting of the bounds family. You wouldn't really be able to say anything about theta or O as far as I know, as determining an upper bound on an unknown is seemingly impossible.


#4991494 Simple game

Posted by greenvertex on 18 October 2012 - 11:44 AM

Then do something more complicated than pong, the general advice still stands. The amount of material I've picked up through writing code far outweighs the amount gained by reading it...


#4991490 Simple game

Posted by greenvertex on 18 October 2012 - 11:38 AM

Everyone starts with pong... Just do that. Trust me, there's really no magic going on behind the scenes here. Rarely are there bits of arcane knowledge to be gained by looking at others' code for simple stuff. You'll learn a lot more by doing yourself than you will by watching someone else do.


#4991476 Is it acceptable to call a destructor?

Posted by greenvertex on 18 October 2012 - 10:49 AM

While you can certainly do it, don't. Calling a class destructor inside the object itself basically always leads to undefined behavior. No other part of your code is aware that you've just invalidated every reference to that object. Are you 100% sure none of those references will be used after destruction?

You might want to review your collision code in general. While it might be "easier" to explicitly invoke a destructor it's probably a sign of code smell and should be dealt with sooner rather than later. If you post the code, we might be able to offer some advice on how better to do your collision.


#4988804 Enemy is dead, now what?

Posted by greenvertex on 10 October 2012 - 12:44 PM

Basically, remove all reference to the object you wish to disappear. It will then do so... eventually.

See Garbage Collector Basics.

For something like enemies, however, you might want to consider a different solution. I don't mean to add to the pile of answers you've already gotten but I'm going to go ahead and add to the pile of answers you've already gotten:

If you find yourself creating and destroying enemies pretty rapidly (conceptually not hard to imagine on my part). Consider creating a pool of enemies of some large-enough size to hold all the enemies that can be on the screen at one time + some margin of error. Then, any time you need an enemy, grab something from that pool, initialize it as a new enemy, and use it until you no longer need it. Once it is killed, return it to the enemy pool to be used again. These don't depend on the garbage collector so you don't find yourself in this strange position of wondering if they're "truly" dead. They're not, but that ends up being a good thing.


#4988166 __stdcall Class Constructor

Posted by greenvertex on 08 October 2012 - 06:49 PM

I've seen forms of this around here and there and I don't get it:

class Test {
public:
__stdcall Test()
{
  int x = 0;
  ++x;
}
};
int main(int argc, char** argv)
{
Test t;
return 0;
}

Why is the constructor declared to use the stdcall convention as opposed to thiscall? It doesn't actually seem to affect the assembly in debug mode (the following appears to be thiscall convention):

	12:  Test t;
0108143E  lea		 ecx,[t]
01081441  call		Test::Test (010810E1h)
	13:
	14:  return 0;
01081446  xor		 eax,eax

And Microsoft seems to confirm:

When you use the __stdcall keyword on a non-static member function, such as a constructor, the compiler will use the thiscall calling convention."


This was only tested in VS2012 so maybe this stdcall->thiscall behavior is implementation specific?


#4988158 2D Animation Scripting

Posted by greenvertex on 08 October 2012 - 06:05 PM

1) Are scripting languages faster than C# for animations? Is that why we would want to use them?


Mainly because they don't require two things: a deep knowledge of underlying game code in order to design and implement cut scenes (i.e. more designer friendly), and scripts do not require a recompile of all the game code in order to test a change.

2) Is this only for time/movie like animations and not animations that require input (such as pressing up to animate my sprite to move up compared to a cut scene that plays regardless of input).


You can technically go as crazy as you want. That doesn't mean you should (reading a script to decide how to handle a particular player input, for example). Things that you can see changing or being added to frequently during development are good targets: level layout, cut scenes, puzzle interactions, etc. Good rule of thumb: if you see the work as more design-oriented, make it script-able.

3) Good, possible, and best scripting lanuage to use for animation?


Anything that has an interpreter for the language your game code is in. Beyond that, I don't know... Lua? Python? JavaScript? Your own (with an implementation of an interpreter of course)?

4) Any other reason to use scripts in a game?


Pretty much as above, anything that basically dictates behavior, can be read once and only once (not executed every update), and is subject to change is a good target.


#4986457 Trouble resolving dependency properly

Posted by greenvertex on 03 October 2012 - 11:17 AM

I recently came across this design problem myself and found that creating a factory responsible for the creation of game assets (shaders, textures, etc.) was a good way to go. The factory ends up maintaining the ID3D11Device creation/destruction, and you can add methods for whatever resources you need with whatever arguments you need. It's no different than the original interface for ID3D11Device really, but it ends up doing away with some creation options you don't think you'll need.

class ResourceManager {
public:
  Mesh* createMesh(const char* file);
  Texture* createTexture(const char* file);
  VShader* createVertexShader(const char* file);
  PShader* createPixelShader(const char* file);
private:
  ID3D11Device* m_device;
  ID3D11DeviceContext* m_context;
};



#4981856 C++ Relative Paths

Posted by greenvertex on 19 September 2012 - 04:45 PM

Under the properties for your VStudio project: Configuration Properties->General->Output Directory is where your project will ultimately compile to. Then just make sure all your assets exist in that directory and you can use relative paths as you were.


#4981401 Actionscript 3 and Flashbuilder;

Posted by greenvertex on 18 September 2012 - 02:37 PM

Can I create a 2d sidescrolling game using actionscript3?


Of course.

How do I get sprites onto the stage using Flashbuilder? Do I add my character sprites to a folder?


See Embedding Metadata with Flash for a description of how to handle asset management in AS3 without resorting to Flash (they really need a better set of terms IMO...)




PARTNERS