Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 26 Feb 2009
Offline Last Active Today, 04:13 PM

Topics I've Started

Memory overwrite after allocating 4k ints

02 March 2014 - 02:00 AM

After debugging some really weird behaviors, like vectors going from size 0 to negative values out of nowhere, I realized this was happening after allocating 4000 ints with new. I dont understand, 4k ints (~15KB) is not that huge, and even if it was, why its messing with my mem?



struct TileMap{

		int * pTileMap; // indexes on m_vTiles
		int mapW, mapH;
		float hSpacing, vSpacing;

		sprite::InstancedSprites m_tileInstSprites;
		sprite::InstancesVertexBuffer m_IVB;

		~TileMap(){ if(pTileMap) delete [] pTileMap; }
	std::vector<TileMap> m_vTileMaps;

This is the structure you see in the vid. 

Both InstancedSprites and  InstancesVertexBuffer hold vectors on its internals, those are getting screwed..that doesnt make any sense, theres a memory constrain Idont know about? Dx

Im hopping is something really stupid, but the vid pretty much shows Im not overwriting stuff myself right?

ubiart engine pretty impressive

17 January 2014 - 05:44 PM



The link is at a point in the vid that the guy seems to be able to distort the images at his will, and some filling thing (I really dont get whats happening there) happens.


After thinking about it for a while, I think theres a real time "puppet warping" thing going on.

Puppet warping is a tool in photoshop, it basically triangulates a image (ignoring 100% transparency) so you can apply pin points and work on it as a skelletal hierarchy:




You can see on theyr engine things distorts a bit, until it goes too much and then another image (the 90 degrees cliff) takes place.


How they got such level of automatization? they have an image for lots of possible angles? not to mention this is one "forest tileset".


And then the hole magically gets filled leaving absolutely none discontinuity..(probably due the warping again..I suppose?)


Theres a tiny bit of info on the blog:



"If you’re into the technical stuff, we use 2D patches to contort sections of the image with a level of complexity that can adapt to the potential needs of the final rendering and the target machine. This technique adapts remarkably well to this type of animation and gives excellent performances in a real-time context."


Not sure if the patchs are different from the photoshop puppet warp.. If its just a curve (the hell is a path) how it influences the pixels?


Any insights?

Fixed Step - Interpolating positions, trafo hierarchies and snapping to position

11 December 2013 - 01:08 PM

Say you have a fixed step game loop, and youre interpolating positions just like that "Fix your time step" article.


Now say you have a transform hierarchy (world transforms that are computed from parent transforms and local transforms).


What I do Is interpolate previous world with current world (when current world != render world ). Works like a charm.


So I keep local, world and previous world, the render world is separated, with the render stuff.


What do I do if I want to snap to a position, with no interpolation? I cant set previous world by hand, because I only mess with the local transform (what if the parent change?)  I cant even think on what Id need to do to achieve that..Its confuse.


What should I do?

Treatment of 2D temporary animations, how to?

24 November 2013 - 11:59 AM

Instead of particles, say you have simply a 2D animation, i.e. an explosion, or those boosts like effects applied to a character when its stats raised, for example (there may be particles playing together or at the end of the animation).


I dont see those as particles, theyre just temporary 2D animations but I feel they should be treated just like..Not sure. How do you deal with those?


Are each of those a game entity that is created and destroyed after its animation is over?(this is easier I believe, they do feel like independent events spawned by other entities)

Or treat like particles, the component is an emitter that controls a bunch of 2d sprite animations pre configured?

Or the object that creates those have a component for each animation (2dAnimationComponent), and then it plays/activates and stop/deactivates it as need?


I dont know how to deal with it.

homogeneous pools accessed trough pointers-> still good?

15 November 2013 - 06:22 AM

So if you have a contiguous and homogeneous pool of objects, aiming cache coherence / un-fragmented memory, should you access it directly to keep those memory friendly features?


I created a pool class, but the pool (fixed array) is private, and I want my systems to iterate over the allocated elements (elements on the pool that are in use).


I dont want to make the pool public for obvious reasons (or perhaps I should?), and I cant make it friend of my systems, cause its a templated pool, Id need to put friends declaration for every system..


So after some thinking I come with something like PoolAccess class, which have pointers to the pool data, so it can access pool elements with a function T* GetAllocated(int index). So in the pool class I have a GetAccess that returns PoolAccess that the systems can get.

//basic structure

template<typename T, uint SIZE>
class Pool{


   class PoolAccess{

    PoolAccess(T pool[], Roster * roster );

    T* GetAllocated(uint index);



   PoolAccess GetAccess(){

       return PoolAccess(&m_pool, &m_roster);

   void Free(T*);


   Roster m_roster; // the dude that controls the free list(raped from insomniac gdc canada presentation)
   T m_pool[SIZE];

But than I realized, doesnt that send the cache friendly goal to space?

GetAllocated basically will go trough the m_pRosterRef pointer, go to the given index on the "list" of allocated (also a contiguous array), get the index on the pool, go trough pPoolRef pointer to return the pool element address at the index.. 


My drawablesQueue have similar access, I have a vector of drawables and a sorted vector of indexes to the drawables, but I remember Hodgman and Spiro saying it was still better accessing that way instead of sorting the drawables itself, so I guess its the same..?almost? Not really?


link to the insomniac presentation in the case you curious