Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 Oct 2013
Offline Last Active Today, 07:29 PM

#5306321 XNA Projectiles

Posted by on 17 August 2016 - 04:31 AM

You could have some sort of list of bullets, and remove them from the list once they've collided with something or gone off-screen.


If you want to limit how quickly you can fire (so you can't fire 3 shots in 0.05 seconds, you might have a timer somewhere (e.g. inside the player).

Decrement the timer with the frame duration every tick, and only allow the player to shoot if the timer isn't already running. Then when you shoot, set the timer running.


You could also have a combination of the two -- you can only have x bullets active at the same time, and they have to be fired with at least y delay.

#5305155 Which Way Would Have Better Performance?

Posted by on 10 August 2016 - 01:23 PM

I read it as an example of micro-optimization (which you don't need to care about for the vast vast majority of the time, if ever), not as a "do this for better performance".


Like I said -- there are times when knowledge of the domain area (i.e. the events and flow in your game) can allow you to make highly specialized code which outperforms the code which is fastest overall/in the generic case. For example knowing that objects only collide from the right, or that a unit can never go backwards, or that there can be only 15 dolphin soldiers in a given map.


A generic solution might be better in the case where we have 1000+ dolphin soldiers, but with out intimate knowledge of our game we can perform domain specific optimizations which would otherwise not be the most fruitful.


Again, don't worry about this stuff. At most, make a comment or note saying "this might be a hot-spot we can improve later!", and move on.

Profilers are infinitely better than you (and all of us) at gauging where our bottlenecks are, and trying to optimize everything from the start is a total shot in the dark, which might end up with a slower application in the end.


TL;DR: Don't worry until it's a problem. If it becomes a problem, use a profiler, make changes and verify improvements. Repeat until fast enough.

#5305112 Which Way Would Have Better Performance?

Posted by on 10 August 2016 - 07:41 AM

You mentioned something about what if the objects being tested always come from the right. What did you mean by always come from the right?

If you know specifics of your game, you can make assumptions that make your code perform better in your case than in a general case.


If 90% of the time, collision occurs from a specific side, testing the relevant sides first might end up with a better performance compared to testing the other sides first.

(If collisions are usually left/right, testing up/down first might be slower.)


This is something a profiler would help highlight and pinpoint, and is not likely to be an issue for most cases.

Worrying about this now sounds premature. I would suggest working on the actual game first. Once it's up and running, make changes if necessary, and let those changes be guided by profilers, to meet performance criteria.

#5305104 How To Fix This Ugly Code Here?

Posted by on 10 August 2016 - 07:04 AM

Instead of all the ifs, you can do the following (using BitMaster's suggestion).

setKeyState(event.key.keysym.sym, true);

#5305097 How To Fix This Ugly Code Here?

Posted by on 10 August 2016 - 06:45 AM

I'm wondering which map is better: or <int, bool> or <string, bool>


"Better" depends on what you need, there is no universal answer.


The SDLK things are constants from an enum, using ints here is appropriate. In this case, you can think of an enum entry as being essentially just a nickname for an integer value.

#5304415 Next Step

Posted by on 06 August 2016 - 03:32 PM

There's a good list of games here to progress through:


#5304413 Please Help Me Find The Bugs

Posted by on 06 August 2016 - 03:28 PM

This also, means, that if Soldier does not have any reference to MapManager, then I could leave out the forward declaration of the Soldier class in MapManager, and I could just include Soldier.h


#5304384 Please Help Me Find The Bugs

Posted by on 06 August 2016 - 01:07 PM

It would be different if I didn't use pointers?


Let's say you add an instance of class Soldier to your class MapManager:

class MapManager
    Soldier mySoldier;
    int myMagicInt;

In order to know how large MapManager is (how much memory has to be set aside every time an instance of MapManager is created), we need to know all the details of Soldier. Does it just have an int for HP? Does it have 50 floats with all kinds of stats?


In this case, MapManager would need to know both that Soldier exists, and the details of it.



In the case where you have a pointer to it, all you need to know is that it exists (so it understands that "Soldier" is the name of a class and not just random letters). We still need to know how much memory to set aside for the pointer, however, since all pointers are the same size, it doesn't need to know the details of the class. If the class is huge or tiny, the pointer to it will remain the same size.


The reason why you still need to include Soldier.h in the MapManager.cpp file, is because now you're wanting to access the Soldier details -- mySoldier->someFunction().

To access those details, you need to know they exists, hence the reason for the include here.



This also means you can't have 2 classes which have instances of each other inside each other.

In this case, you would need to split things up somehow, so that either 1 class contains a pointer to the other, or to create a new class which contains both of them.

#5304378 Please Help Me Find The Bugs

Posted by on 06 August 2016 - 12:29 PM

Seems alright on its own. However, looking more closely at your error messages it seems like Soldier has a pointer to MapManager, and MapManager has a pointer to Soldier.


This is most likely causing a circular reference (to know what a MapManager is, you need to know what a Soldier is, which needs to know what a MapManager is, etc).


Since you're only using pointers (at least in MapManager), you can forward declare the Soldier class inside MapManager.h. This basically says "somewhere, there is a class called Soldier. You don't need to worry about the details here, because all we currently want is to have a pointer to it".


Before class MapManager, add

class Soldier;

In MapManager.cpp you will need to include the Solider.h file to get the proper contents available to you.


Also of note, I would recommend not putting "using namespace std;" in a header. This can cause namespace pollution -- every file that includes MapManager will now suddenly also inherit the using declaration.

If you need to use using declarations, it's best to put them locally -- in the .cpp file.

#5304376 Please Help Me Find The Bugs

Posted by on 06 August 2016 - 12:18 PM

Post mapmanager.h


You can put code in the code tags (the symbol in the text editor that looks like   <>     )

#5304370 Please Help Me Find The Bugs

Posted by on 06 August 2016 - 12:03 PM

What do you mean you can't run it?

Does it fail to compile or link?

Does it compile and link correctly, but crash on start-up or at any other specific time?


You mentioned error codes -- what are they? Don't make us work for things you can easily provide.

#5303886 Best Way To Comment Code Without Cluttering

Posted by on 03 August 2016 - 06:47 PM

What I try to follow for my own code:


Write code that, for the most part, does not require comments. This includes proper names for things, keeping functions small & contained, dealing with as little code as it makes sense to do, keeping with the style of surrounding code, etc.


For algorithms or math heavy stuff I sometimes add a link in a comment, or copy the formula and information directly in comments if it doesn't take too much space.


Comment things that are out of the ordinary, or where the intuitive solution is not the correct solution.

#5303692 Only 12 Enemies, And My Fps Drops To 30, Why Is That?

Posted by on 02 August 2016 - 12:59 PM

Alvaro, but this is kind of what it does, because it gets the location of my gBones[] array in the vertex shader.

"get" usually implies that the function returns something. In this case, I would expect it to return an index/pointer or something. Actually this logic is what glGetUniformLocation follows -- it returns a location which you can store and use for something.


I'm not too fond of imposing guidelines on others, but I agree with Álvaro that the name is misleading.

#5303640 Only 12 Enemies, And My Fps Drops To 30, Why Is That?

Posted by on 02 August 2016 - 07:07 AM

Also, "losing/dropping" x frames per second is a relative thing.

If you're at 100 FPS normally, and drop 20 FPS, your frametime goes from 10ms to 12.5ms (2.5ms increase).

However, if you're at 40 FPS normally and drop 20 FPS, your frametime goes from 25ms to 50ms (25ms increase).


While for the end product the frame rate is probably a more important metric, while developing and finding bottlenecks it's mostly useless.

#5303357 How Can I Create A Successful Game In Unreal Engine

Posted by on 31 July 2016 - 01:47 PM

One step at a time.


Game development is hard.

There is no tutorial or step-by-step guide to making a successful game, in any editor or language.


There's also the issue of defining "successful". Released? Sold 10 copies? 100? 1 million?