Strewya

Also, this isn’t what you asked, but it is something you should know anyway.
 
Do not cast pointers to “uint”, “unsigned int”, “unsigned long”, “int”, “long”, “__int32”, “u32”, “DWORD”, or any variation thereof.
Pointers are not 32 bits.
Pointers are not 64 bits.
 
Pointers are 32 bits on some architectures, 64 bits on others, and 16 bits in still others, so it doesn’t make sense to cast them to “uint” or any other type that is not always exactly the same size as a pointer.
The Windows® SDK exposes a type called UINT_PTR.  Other platforms define uintptr_t (in <cstdint>).
They exist for a reason.  Never cast pointers to “uint”.

 

 

L. Spiro

Does this apply to all pointers, or just function pointers?

I thought that the pointer size is always 4 bytes on 32bit systems (8bytes on 64bit, all depending on the target build settings), but what you're saying is that this is wrong?

Thanks.
I'd like to just ask some questions about this, i don't think i'll actually use this

The idea was to use that ID only for the purpose of distinguishing different systems in runtime (so no persistance), where two instances of the same systems should have the same ID (not that you'd have two instances of a system, but...)

But i didn't know you can't take the address of a virtual functions implementation. Does that mean you can't pass the Update method of a derived class around as a pointer to member function neither?

dunno if it's just me, but that picture link is broken.

also, why not use Git from console? more control that way.

just set the scale negative in the dimension you want?

i.e. setting the scale to 1, -1 flips the sprite upside down (vertically?), and -1, 1 flips it left-right (horizontally?).

 

edit: now that i've actually read your post... (dumb me)... maybe try using D3DXMatrixTransformation2D and passing in all the required values, and set the matrix before the call to sprite->Draw()? in that case, you dont need to pass the center nor position to the draw method, only the color tint.

Hm, true about vector locality...
I know i should probably test the performance first, and this is part of my problem, that i'm doing premature optimizations.

At any rate, i'm also willing to scrap part of this concept in favour for something better. I just don't know what that would be

The only thing i would really like to have is a way to hold individual data types in a non-template class, and have the non-template class take care of the cleanup.

I'm also juggling an idea where i ask a data store to make me a state, something like this:

State DataStore<T>::MakeState()
{
    return State(this, &GetAddressFromPool(), hashOfType);
//the GetAddressFromPool would be a dataStore<T> method
}

State(IDataStore* store, void* ptrToData, size_t hash) {}

~State() 
{
    store->Release(ptrToData);
}

T& State::as<T>()
{
    if(hash == typeof(T).hash_code())
    {
	return *static_cast<T*>(ptrToData));
    }
    throw exception;
}

Is this something in the lines of your 2) option?
I'm not really planning to go multithreaded any time soon, so i could get away with no thread safety, but the concept of having any data type in a non-template class is really appealing to me, and would like to pursue it.