Juliean

i just couldn't imagine such a simple thing to be that complicated.

 

And you didn't do it as simple as:

 

std::wstring s2ws(const std::string& s)
{   
	return std::wstring(s.begin(), s.end());
}

#ifdef UNICODE
std::wstring stemp = s2ws(filename); // Temporary buffer is required
#else
std::Wstring stemp = s;
#endif
	
D3DX11CreateShaderResourceViewFromFile(device, stemp.c_str(), NULL, NULL, &texture, NULL);

 

like suggested because of... ?

std::string multi("Test");
std::wstring unicode(multi.begin(), multi.end());

This is the easiest form of multibyte to unicode conversion I know, won't even throw a compiler warning, unlike some solutions like std::copy. Then you can access the single characters of the wstring to get your WCHAR. Though given the little information and SiCranes answer which makes me a bit unsure, so please don't hit me if I misunderstood the actual problem ;)

 

EDIT:

 

Well given your next post it seems like it, but you can't simple do WCHAR = wstring eigther, as you can't do char = string. You rather want to do something amongst those lines, right?

 

std::wstring unicode; // suppose you used the method mentioned above to convert from string towstring
WCHAR w[256] = unicode.c_str() // you can only assign a (w)string to a (w)char array, not a single (w)char

Also, you should use

int x;

if( x == 0)
{
}
else if(x == 1)
{
}

for mutually exclusive conditions. Or better yet:

 

int x;

switch(x)
{
case 0:
// ...
break;
case 1:
// ...
break;
}

as long as you have an enumarable variable (which you should have with the SDL-event, just change "x" with Event.type and use "SDL_KEYDOWN" etc... in the "case" statement). Both of these will not only help performance, but also make your code more understandable.

if (Event.key.keysym.sym)
{
if (SDL_KEYDOWN == SDLK_UP)
{

 

I'm not familiar with SDL, but that just looks wrong. Shouldn't it be more along those lines?

 

 

if (Event.key.keysym.sym == SDLK_UP)
{

 

Right now you are appearantly comparing the event-constant with the key-constant in the latter if, and as for the first one, I don't think that is necessary - is "Event.key.keysym.sym" a pointer? You are basically checking if this variable is any other value than 0, can't tell if this is what you intended or not.

Again, I have a thing against duplication/caching of state. So instead of having an active unit counter that is added to when a unit is created and subtracted from (via UnitDied message) when a unit dies, I might instead have logic in the spawn system to calculate the current number of active units each frame (or possibly this could be done in another system that is already enumerating through all active entities anyway). That way if I ever added new places in the code where units could be added/killed I wouldn't need to worry/think about updating this number (also coming back to the (irrelevant) save game thing here, I wouldn't need to write any special code to set the "active unit counter" on loading a saved game).

 

I somehow start to see this asa very convenient. I actually tried my solution with the polling approach you suggest, and while it still worked, I did think it was a bit "ugly", as in non-engine-conformant (this also holds true for my old signal-based query solution, just to clarify). So I actually went ahead and implemented a system similar to what you described you did with your messages, just aside from my regular messaging system. I now have an additional struct called "Query", and I can issue such a query to the manager (currently the system manager, think I'm going to implement a "QueryManager" later). One system can respond to this via overloading the "RecieveQuery"-function. Only real difference is that only one system can respond to a query, and "RecieveQuery" being const, can't be used to transfer information into the system.

 

What do you say to this? I like this solution, as it offers a way to implement the "interface" into the engine itself rather than the game (reusable code is what, at least I, want, but I quess I'm not alone on this ;) ), plus it won't matter now for the game whether I cache or create state on demand. Only downside I see is that my actual implemented gui is now more depending on the entity-system as it was before with my IGameQuery - interface, but since I'm building the game on this entity/component-system anyway, this shouldn't matter, should it? Here is the code I've got now:

 

void StateCtrl::Update(void)
{
    ecs::GoldQuery query;
    if( m_pSystems->Query(query) )
    {
        m_goldLabel->SetText( conv::ToText(query.gold) );
    }
}

bool PlayerSystem::RecieveQuery(ecs::BaseQuery& query) const
{
    if(GoldQuery* pGold = query.Convert<GoldQuery>() )
    {
        if(m_pPlayer)
        {
            pGold->gold = m_pPlayer->GetComponent<Player>()->m_gold;
            return true;
        }

        return false;
    }

    assert(false); // should never reach this line
}

Any more thoughts on how to possibly improve this?

Hello,

 

I've been employing a component and system based entity system (much like EntityX) for my engine, and been using it in my latest study project to develop game logic. Things work well when everything can go encapulsated inside of the systems, but I'm a bit concerned about how to handle information that needs to be delivered outside of the systems. For example, I handle the game-state via a state machine, which sets up the systems and also the game gui. What if I now need to share deliver information from the systems to the gui? For example (since I'm developing a tower defense game) I want to disable the "send wave" button when clicking it, and re-enable it when the wave is over. The wave-game-logic itself is handled by this systems update method:

 

SpawnSystem::SpawnSystem(const std::wstring& stLevel): m_time(0.0), m_currentSpawn(0), m_numAlive(0), m_currentWave(0), m_bActiveWave(false)
{
    // load level data from file
    LevelLoader levelLoader(m_units, m_paths, m_waves);
    levelLoader.Load(L"Game/Level/" + stLevel + L"/Level.axm");

    m_maxWaves = m_waves.Size();
    m_pWave = m_waves.Get(0);
}

void SpawnSystem::Init(ecs::MessageManager& messageManager)
{
    // subscribe to messages
    messageManager.Subscribe<UnitDied>(*this);
    messageManager.Subscribe<UnitReachedGoal>(*this);
    messageManager.Subscribe<StartWave>(*this);
}

void SpawnSystem::Update(ecs::EntityManager& entityManager, ecs::MessageManager& messageManager, double dt)
{
    // check if wave is active
    if(m_bActiveWave)
    {
        m_time += dt;

        // are there units left to spawn?
        if( m_currentSpawn < m_pWave->spawns.size() )
        {
            // iteratively spawn units ...
            for(Wave::Spawns::const_iterator ii = m_pWave->spawns.begin() + m_currentSpawn; ii != m_pWave->spawns.end(); ++ii)
            {
                // ... until there is one that will be spawned at a later time
                // it is assumed unit containers is orderered
                if(ii->time > m_time)
                    break;
                else
                {
                    // spawn unit
                    ecs::Entity& unit = entityManager.CreateEntity();
	                unit.AttachComponent<ecs::Actor>();
                    unit.AttachComponent<ecs::ModelComponent>(L"Game/Meshes/Cube.x", 0);
                    unit.AttachComponent<ecs::Direction>(0.0f, 0.0f, 0.0f);
                    unit.AttachComponent<Movement>(2.0f, ii->path.vStartPos);
                    unit.AttachComponent<Unit>(ii->unit);
                    ecs::Position* pPos = unit.AttachComponent<ecs::Position>(ii->path.vStartPos);

                    // create offset bounding box
                    math::AABB* pBox = new math::AABB(.0f, .5f, .0f, 0.5f, 0.5f, 0.5f);
	                pBox->m_vCenter += pPos->m_v;
	                unit.AttachComponent<ecs::Bounding>(*pBox);

                    unit.AttachComponent<Pathfind>(ii->path);

                    // increment spawn and alive counter
                    m_currentSpawn++;
                    m_numAlive++;

                }
            }
        }
        else
        {
            // check if there are no more units alive
            if(!m_numAlive)
            {
                // deactive and reset
                m_bActiveWave = false;
                m_time = 0.0f;
                m_currentSpawn = 0;
                   
                // increment wave counter
                m_currentWave++;

                // inform other systems that wave is over
                messageManager.DeliverMessage<FinishedWave>(m_currentWave, m_maxWaves);

                // check whether this was the last wave
                if(m_currentWave >= m_maxWaves)
                    SigWinGame(); // ???
                else
                {
                    // aquire next wave
                    m_pWave = m_waves.Get(m_currentWave);
                    SigWaveOver(); // ???
                }
            }
        }
    }
}

void SpawnSystem::ReceiveMessage(const ecs::BaseMessage& message)
{
    // reduce alive counter if unit died or reached its goal
    if(message.Convert<UnitDied>() || message.Convert<UnitReachedGoal>())
        m_numAlive--;
    // set active if wave start is requestes
    else if(message.Convert<StartWave>())
        m_bActiveWave = true;
}

 

My first idea, as you can see in the "???" marked lines, I've been using signals to tranfer this information to the main game state. However, I've been wondering if there were any better ideas on how to do this. How are you dealing with this kind of "system out" information? In is obviously no problem, I'd just use the message manager to send a message. But out appears more complicated, since I can't just use the message manager to inform any possible class, therefore I'd need to tie it to a certain implementation (which is obviously not a good thing). Any input from you guys?

Ah, I see, that makes it a bit more complicated. From what I get you basically need an order-independant transparecy rendering technique.

 

http://publications.lib.chalmers.se/records/fulltext/173349/local_173349.pdf seems to be about that, didn't read it in-depth though, but you might give it a look.

"How do you get a deal with sony?"

You simply need to reduce the amount of !? in your headlines.

Sorry, i just had to :/ Seriously though, formality is a requiremet too, if you contant Sony with a title like "I can haz dev kit?!?!?!", chances are they won't even read what you wrote, even if you got ten well-established games on the market.

so far you guys are only pointing me to libraries. are there really no tutorials / discussions on how to go about creating your own GUI system? id rather learn the basic idea on how they work and then design around that because if i ever decide to use another language for a project and need a GUI system, i can have enough knowledge to create a fairly basic one, then if i need more advanced features that i cannot create myself, then id use a GUI library. i just need an understanding of how a system would be structured, so i could add on the individual tools such as the buttons, checkboxes,sliders etc. myself.

 

A gui system is, depending on the degree of functionality, eigther far too complicated and broad for a tutorial, or so simplistic that anyone with the knowledge of how to display an image and check if mouse coordinates are within a given rectangle can figure it out himself. Additionally, you'll learn the basics by using any existing libary. Qt e.g. uses signal/slots and events for gui functionallity. If you've used that a while, implementing your own such system is trivial. But if you really want to design an own gui libary, why don't you just start out? Sorry to be a downer here, but if you can't get the start here yourself, you should definately not be making a gui libary, but start out by studying and using an existing one. There is no reasong for you to reinvent the wheel, let alone the "square wheel". Thrust me, unless you really badly want to learn how gui systems work internally, just are wasting your time. The time it will take you to write most elements any complete gui libary supports, you could have learnt how to use existing libaries in ten different langueges and would have ended up with something far more usefull, I'm not even kidding.

 

If you still want to roll your own, look for "sigal/slots", "event driven programming", "composition". Those are the tools you are going to need to design a good gui libary. Then start by adding your own basic gui elements. Start with something simple as a text label or buttons, using composition. Use signals and slots to bind functionallity to those elements. Delegate input via events. Don't care if you get it right. Just write how it works best for your current needs, just can still post code here and ask questions if you get stuck on specifiy parts. Way better to help you than just asking for a guide/tutorial on how to make a gui itself.

there are different managers, let's say CollisionManager and HealthManager(more like a general gameplay object manager, just for the simplicity) and you have a object that inherits from 2 interfaces ICollidable and IHealth. This object subscribes to the managers to have its respective states updated each frame. Now, if a collision happens between 2 objects (that both inherit from ICollidable) how should the HealthManager be informed?

 

Messaging. As in my example code, you have a message system that you use to send out a "collided(left, right)" - message. Each manager can subscribe to messages, and so will the health manager subscribe to the collided-message. The message manager will delegate that message to the health manager, which will translate it and respond accordingly. Once again, you might be way better of using components, not inheritance, but thats in the end up to you.

So each frame you must build/extract list of entities based on system?

How do you do that with minimal performance loss?

 

Good catch, thats the one part I havn't gotten right now. It would be way faster to just iterate through all entities directly since this is what happens in EntitiesWithComponents anyway, so its a double performance loss. I think about caching entities by often used combinations of components, this should speed it up a bit. There are many other possible ways to handle this though, just havn't found the motivation to tackle this, CPU Performance isn't a real problem right now too

In a component based system I have solid objects (which can collide) and gameplay type objects (which have various stats like damage...) which are combined (inherited).

 

I'm not 100% sure about the actual definition, but I doubt that even counts still as a component system. Composition, thats what its all about, as the name suggest. So to solve all your problems, simply don't inherit from your components, but compositie them into a generic entity object. Then one option was to use systems to manage this:

 

class CollisionSystem
{
    void Update(EntityManager& entityManager, MessageManager& messageManager)
    {
        EntityManager::entityVector vEntities;
	    entityManager.EntitiesWithComponents<BoundingVolume>(vEntities);
    
        for(Entity* pLeftEntity : vEntities)
        {
            for(Entity* pRightEntity : vEntities)
            {
                // ...

                if(collision)
                    messageManager.Send<CollidedEntities>(pLeftEntity, pRightEntity);
            }
        }
    }
};

Systems just act upon entities with specific components, bounding volume it is in that case. It doesn' matter what else is attached - it got a bounding volume, it can collide (of course this can be extended). Note how I'm using a messaging system to notify about the collision - each system registered to this specifiy message will recieve it, so for example the damage-system, which can then look if the entities have the needed components (stats, weapon ...) and then performance damage calculation.
 

For a good libary for C++11, just google EntityX. Free to use, appearently easy to implement (preferred my own variation though), should be more what you are looking for.

 

Note that collision detection shouldn't be even part of the entity/components at all eigther. It will do for small uses, but really you should rather put that into a special physics module, with the component approach you finally use just taking care of registering and dispatching collisons, and so on.

This seems tough, but I'll consider it as my second option.

 

Thats not really that tough, and it also is something that applies to "everyday" game programming in general, so you better get used to that.The concept of having a plain list of objects, but still organizing those objects in some other datastruct for different uses should appeal naturally. Just imagine a scene graph, or space partitioning data structure like an octree or quadtree. One would never store objects directly and only in such a structure - unless you feel cool with traversing the whole tree for simple tasks as Update()-ing those objects.

 

Just think about it as one place where the objects are stored and truley belong. Then there are theoretically unlimited other containers that might store those objects, specially laid out for a certain processing task - be it frustum culling, collision, ... . Just as you need it.

One thing that surprisingly hasn't been mentioned before: What you do inside your own four walls is your own buisness. Which in this case means that if you make such a game using someones IP just for yourself, while (probably) still illegal, you won't get into legal issues with anyone. But since you are posting this here, I'm assuming you want to at least show the game off somewhere in the web, so that might be out of the question.

 

Now here comes the more opinionated part. Having finished and released a sequel to a quite old game some time ago, without having recieved a C&D from the IP owners (first announcement and demo was up around 2008), I wouldn't as strongly discourage you from creating the fan-game you want to make. As there has already been established, there are usually only two possible ways for this to end: Eigther Nintendo will silently endource your game, or they will C&D you. To get a permission is very unlikely, and from what I've heard actually getting sued is very unlikely, too. So if you really feel the urge to make that game - then I'd say, go ahead and make it. As you said, give proper credit, don't make any money of it - and be prepared to be shut down any time. If you still feel it would be worth the time, more the power to you. Whats better to use your time with, then a project you really enjoy making?

 

And just to clarify, I do respect intellectual property, I just feel that creating a fan game isn't a denial of that propery. No doubt about the legal state, which makes sense to give power to control that property. I just belive that making a "serious" fan game is just another way to show that respect - if we didn't like or even love that game, we wouldn't make a sincere fan game about it, would we?

Hello,

 

after refactoring some of my old gui code by removing the "Gui" - prefixes and instead putting them into a gui-namespace, plus putting the file into a seperate folder, I've come across a problem. Now I've got some classes that share the same name, and also the same file-name:

 

// in "Gui/Window.h"
namespace gui
{
class Window {};
}

// in "Core/Window.h"
namespace core
{
class Window {};
}

Those two classes doesn't have anything in common. Before starting, I supposed this was safe, since both files are in different locations, and both classes are in different namespaces. However, when compiling the libary I get a compiler warning about multiple object-files with the same name, and upon compiling the actual game project, I get a lot of unresolved symbol linker errors.

 

Now I ask, is there any way to solve this, without adding some provisorical pre/postfix to the class?