Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your feedback on a survey! Each completed response supports our community and gives you a chance to win a $25 Amazon gift card!


Member Since 28 May 2011
Online Last Active Today, 07:43 AM

#5148116 My Custom Memory Pool Seems Too Slow. Need Advice.

Posted by Waterlimon on 19 April 2014 - 07:07 AM

Do I understand this correctly:

-Entity is Object<Entity>

-Instances of Object<Entity> have MemoryPool<Entity>

-Only objects of type Entity can be allocated into that specific pool


I dont see how the map works here, wont every instantiation of MemoryPool only allow a single type to be allocated anyways, which would mean that there will only every be a single key in the map? Im not very used to template code and static members so i might have misundestood something.

Anyways, I do have suggestions, assuming there is nothing fundamentally wrong in how the pool works:

-Would it be possible to use the hash_code of the type_info struct instead of the name for the map key? This way you wouldnt need to use std::string but could have an int instead which might be faster.

-Reserve some capacity into the vectors when you create them so they dont need to reallocate all the time

-You could try using an unorderer_set instead of a map, access is about O(1) I think. If the map access is a bottleneck.

-In your test code, make sure that the objects you compare are actually the same. In the code you posted, car is probably a single byte, while your Entity might even allocate memory because of the vector contained.


And of course, use a profiler to figure out what it is you are doing that is slowing down your pool.




You might want to consider a less intrusive option. Your classes probably should not know where and how they are allocated.

#5145116 Pointer trouble in entity system [Solved]

Posted by Waterlimon on 07 April 2014 - 12:14 PM

As a solution, instead of storing a pointer/reference to a specific memory location, you should store an index into the vector. As long as you dont yourself rearrange the entities within the vector, you are guaranteed that the index of the entity within the vector will remain the same regardless of what the vector does with the actual memory location.


You need to give access to the entity vector for the code that accesses the entity through the index (what before was a pointer/reference) because you now depend on the vector to hand you the entity, wherever in RAM it resides at that moment.


You can still take references/pointers to objects stored in these memory rearranging containers, but you need to be absolutely certain that no operation is done on the container that could move the objects in memory (eg. nothing should be added/removed while you access the object through a raw pointer/reference)

#5144679 DRM protection

Posted by Waterlimon on 06 April 2014 - 02:08 AM

Either move part of or all of your game to servers you control, or replace your code checking with a dialog box that politely asks the player whether the game was obtained in a moral way or not.

[exeggaration] Anything else is a waste of your time because your game will be cracked by evil pirates in 3 minutes. [/exeggaration]


edit: added tone markup :3

#5144543 help on hdr rendering

Posted by Waterlimon on 05 April 2014 - 05:59 AM

Thats exactly what downscaling does, sums the pixel values in parallel.


Every thread can sum a small amount of pixels so you can have multiple threads. It wouldnt be so fast if you had a single thread go through every pixel and sum them up sequentially.


I guess you can change the amount of pixels each thread processes (eg instead of 2x2 -> 1 pixel you could have 4x4 -> 1 pixel but i dont know how that would work out)

#5144080 Improve rendering

Posted by Waterlimon on 03 April 2014 - 06:59 AM

Do the distance check using the squares of the distances instead of actual distances to avoid square root calculations


eg. X^2 + Y^2 < 200^2


Where X,Y are difference between pixels and players position.


If you hadnt already done that it might work for a simple game but you probably should find a better algorithm if you are working on something more serious.



-Lower resolution FoW layer (eg calculate FoW for 2x2 or 4x4 pixel groups instead of for every pixel)

-Try hierarchial approach (so you can easily identify the areas which are guaranteed to be visible or guaranteed to be hidden, then do more precise calculations for the remaining areas. Quadtree?)

-Try saving results of calculations where possible.

-Dont do calculation every frame, so if the player moves the visible areas remain the same until they update again. You can adjust update rate too or update further areas at different rate than closer areas.

-Prevent the player from seeing what is behind him. This affects game play but will let you easily eliminate checking half of the map.


Oh, and if your game is tile based you should do the FoW on the tile grid not per pixel probably.

#5143261 what scale? metric or other

Posted by Waterlimon on 30 March 2014 - 10:55 AM

Yeah, if you dont have any performance or other implementation dependent reason to not use 1 engine unit = 1 meter such as:

-You are simulating very small or big things (atomic level/universe), might be better to use another scale

-You have some very important element which is some specific size, might make sense to make that size equal 1.0 (eg in tile based game you might want 1 tile = 1.0 units even if the tile would not be 1 meter)


You should probably use meters. If you think 1 cm is better as 1 unit instead of 0.01, might as well use it for aesthetic reasons.


Of course, you can always use multiple different scales for different systems but that would probably overcomplicate it.

#5143246 what scale? metric or other

Posted by Waterlimon on 30 March 2014 - 08:55 AM

Unless your application somehow interacts with the real world, there is no reason to have any units at all - let the user decide what they want 1.0 units correspond to.


But if you need to be 'compatible' with the real world (eg. you want your values to be same as in the real world) I would use metric because it seems to be the most universal when it comes to more scientific stuff, however I would only do that internally. The interface might benefit from a conversion factor which you can change to get IO in whatever units you want.


Often applications let you choose what unit system is used for display - I dont know if they internally use one of them or if they use custom units.

#5143241 Problems with 2d steering in SFML

Posted by Waterlimon on 30 March 2014 - 07:39 AM

Define "weird movement"

#5143235 Problems with 2d steering in SFML

Posted by Waterlimon on 30 March 2014 - 07:13 AM

What exactly does not work?


Do you get errors or is it broken in some other way?


Might want to make sure you are initializing your variables (the floats), i dont know if you are.


If you dont get errors, try debugging it to isolate the problem (find the location where you get wrong values, use your IDEs debugger or some other way eg. print values to some kind of output)

#5143226 Need help with 2D oscillation

Posted by Waterlimon on 30 March 2014 - 05:02 AM

Speed = scalar quantity (eg not a vector) usually, like 5 units/time

Unit vector = vector of length 1, a direction

Velocity = speed*direction where direction is an unit vector

Time = seconds, milliseconds, ticks, whatever

Delta time, dt = time passed since last update (eg, how much time passed since the previous update of this value)

Position = (x,y) vector here


1. You want to make your object go to a direction at a constant speed.

newPos = prevPos + velocity*dt

velocity*dt  gives you the displacement of the object from the previous update, dt being time passed since the previous update.

Run this in a loop and you have a moving object.


2. You want to add the oscillation. You should probably implement this as an offset, so that the linear movement and oscillation are separate and dont mess with each other.

offset is a vector, just like position.

normal = perpendicular(normalize(velocity))

offset = normal * amplitude*sin(t*frequency)


3. Combine them to get a final position for the object (where you display the object)

displayPos = newPos + offset


Something like that. I suggest not working with x,y coordinates but only use vectors. If you need to normalize or get the perpendicular vector, find those functions from somewhere or make your own, but keep the logic as vector only so its simpler and easier to see whats going on.

#5142817 smoth fog of war

Posted by Waterlimon on 28 March 2014 - 05:34 AM

You might also want to reconsider your fog as shadows, and implement a lighting system instead, since the example you provided uses the "fog of war" as sort of shadows.

#5142584 draw 2d line with clipping

Posted by Waterlimon on 27 March 2014 - 08:30 AM

The idea is essentially that you take the original plotting loop (PASSING INTEGER COORDS + range of x where to draw).


Then you split it into two parts:

1. Advance but no draw

2. Advance and draw every pixel

where the first part is applied over the non-drawn outside screen range and the second for the area inside screen. The rest is just ignored.


Now, you should be able to express (1) in a non-loop form, simplifying it down to very simple arithmetic. Try to do something like that with whatever algorithm you use.



function line(x0, x1, y0, y1, xmin, xmax)
     int deltax := x1 - x0
     int deltay := y1 - y0
     real error := 0
     real deltaerr := abs (deltay / deltax)
     int y := y0
     for x from max(x0,xmin) to min(x1,xmax)
         error := error + deltaerr
         if error ≥ 0.5 then
             y := y + 1
             error := error - 1.0

function line(x0, x1, y0, y1, xmin, xmax)
     int deltax := x1 - x0
     int deltay := y1 - y0
     real error := 0
     real deltaerr := abs (deltay / deltax)
     int y := y0
     for x from x0 to xmin //no draw
         error := error + deltaerr
         if error ≥ 0.5 then
             y := y + 1
             error := error - 1.0
     for x from max(x0,xmin) to min(x1,xmax) //draw
         error := error + deltaerr
         if error ≥ 0.5 then
             y := y + 1
             error := error - 1.0

function line(x0, x1, y0, y1, xmin, xmax)
     int deltax := x1 - x0
     int deltay := y1 - y0
     real error := 0
     real deltaerr := abs (deltay / deltax)
     int y := y0

         error := error + deltaerr*(xmin-x)
             y := y + (how many times u can negate 1 out of error so that error>=0.5)
             error := error - (how many times u can negate 1 out of error so that error>=0.5)

     for x from max(x0,xmin) to min(x1,xmax) //draw
         error := error + deltaerr
         if error ≥ 0.5 then
             y := y + 1
             error := error - 1.0

Something like that.

You basically need to:

1) Pretend that the algorithm draws the actual long line

2) Optimize the parts that dont actually draw, which means a loop becomes some simple math operations on variables

#5142565 Tickrate, Game Loop, FPS

Posted by Waterlimon on 27 March 2014 - 07:40 AM

I havent done networking but:


-What does your walking speed have to do with the packet send rate? You should implement it so that you can send any number of packets and dont need to change walk speed etc. You could do this by either making the packets carry velocity instead of displacement, or by making the packets send the displacement since the last position sent.


-Im fairly sure that the common practise is to gather all your data to a single packet (multiple messages in a single packet) so you always send a single packet at a time. Of course there might be reasons not to eg. if you want to run something completely independent of your other networking or if there is a packet size limit or if there is some reliability benefit in sending multiple packets instead of a single one.


-The rate at which you send packets, well, im certain that the best answer is that it depends. Do whatever works. 20 packets per seconds sounds familiar, but for a simple game I dont see anything wrong with 60 packets per second, since it would be simpler to implement. Might as well make it manually adjustable to some degree if it doesnt hurt gameplay so people can adjust the default rate if it for some obscure reason doesnt work for them.



I suggest two things:

1. Make it possible to adjust the rate without having to change anything else (so the game will work at 1 packet/s or 60 packets/s)

2. Set it to whatever value gives smooth gameplay after some testing.

#5141717 Best way of volume selection

Posted by Waterlimon on 24 March 2014 - 09:58 AM

You can allow selecting a single axis at a time and resizing/moving on that axis. These tasks can be done by pressing a key, scrolling the mouse wheel, clicking, dragging, whatever.


For rotation you usually have some hard to comprehend system where you can rotate using keys. The user then hits the keys randomly until the object ends up with the correct orientation. You can make this easier by having the keys be fixed to global axes (instead of tied to local object axes). You can also add indicators to tell which key rotates on what axis (hovering thing with the key shown for each axis).


You can also have rotation by dragging the object or some GUI surrounding the object with the mouse but you should also have the keyboard version because the mouse tends get slow and annoying after you become a pro.


And last, you can implement some automatic detection of optimal positioning based on surroundings, but make sure it doesnt get in the way and randomly change the positioning while the user is trying to manually adjust it.

#5139421 DrawLine args name confusion

Posted by Waterlimon on 16 March 2014 - 06:14 AM

You can think of


x0 y0 x1 y1


as if they were array indices


x[0] y[0] x[1] y[1]


But you have 2 arrays one for x values and one for y values.


If you want it the other way around you must have an array of points





But this changes data layout so you might want to make your choice based on what the optimal data layout is, not what looks the nicest.