Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 06 Oct 2006
Offline Last Active Today, 04:04 AM

Posts I've Made

In Topic: MonoGame and bugs/incomplete features?

24 February 2015 - 11:27 PM

You should ask this question at the monogame forums, or file a bug against them with a simple repro project.


I've definitely encountered a few issues with graphics device setup in monogame, but was able to work around them (and filed bugs so they got fixed). It's possible the current version of monogame fixes whatever issue you're running into (assuming you're running the latest official release). You can also build monogame yourself... I had to do this for an audio issue whose fix hadn't been pushed into the official source code yet.


fyi, I just tested IsFullScreen with a Monogame (v3.0) Windows OpenGL project, and it worked fine. I also don't see any issues with GraphicsAdapter.CurrentDisplayMode.

In Topic: How to disable depth write?

22 February 2015 - 06:11 PM

D3D11_DEPTH_STENCIL_DESC depth_write_enabled_desc;
depth_write_enabled_desc.DepthWriteMask = D3D11_DEPTH_WRITE_MASK_ALL;
hr = d3d11Device->CreateDepthStencilState(&depth_write_enabled_desc, &pDepthenabledStencilState);


Is this your actual code verbatim? In that snippet you're only setting one value of the D3D11_DEPTH_STENCIL_DESC structure, so the rest will be stack garbage. What's the return value of the call to CreateDepthStencilState?


If you use the directx debug runtime, is there any interesting spew?

In Topic: Easiest way to pass a 2D array?

20 February 2015 - 11:23 AM

I would just pass the 1-d vector, along with a width so you can do the math and index it as a 1d array.


Or, wrap your map information in a small class that has a GetAt(int row, int column) method and just pass that. Or you overload overload the [] operators to index it like a 2-d array. I just whipped this up (might still have bugs):

class Grid
    class Row
        friend Grid;
        Row(int width, int column, std::vector<int> &internalGrid) : internalGrid(internalGrid), column(column), width(width) {}
        int column;
        int width;
        std::vector<int> &internalGrid;

        int &operator[](int index)
            return internalGrid[column + width * index];

    Grid(int width, int height) : internalGrid(width * height, 0), width(width) {}

    Row operator[](int index)
        return Row(width, index, internalGrid);

    std::vector<int> internalGrid;
    int width;


Grid grid(100, 200);

grid[4][6] = 4; // etc...

findPath(start, end, grid);

Looking at the disassembly for the optimized code (VS 2013), using grid[4][6] is just as fast as directly indexing a raw array, so there shouldn't be any performance impact.

In Topic: Do everything through ECS? Or implement other systems?

18 February 2015 - 02:49 PM

I've shipped one game with an ECS, and built part of a much larger project with an ECS.


In the first case, I'd say roughly half the gameplay mechanics were part of systems (which operate over components or sets of components), and half were part of one-off scripts attached to an entity. Attaching scripts to an entity was kind of an "escape valve" for stuff that doesn't fit nicely within the ECS... the scripts are kind of a black box that is just told to update.


As for the buffs and modifiers you talk about, I agree with SotL that this isn't really relevant to the ECS. I don't think it gets any easier or harder or much different whether or not you're using an ECS.


To start with, I would just have a "Stats" component that includes: base stats, modifiers, and possibly "final stats". e.g.

struct Stats
    int BaseSpeed;
    int BaseAttack;
    int SpeedModifier;
    int AttackModifier;
    int Speed;
    int Attack;

A stats system would iterate over these things and ensure that Speed and Attack are kept up-to-date with the result of whatever formula calculates them from base and mod. Other code (such as the combat logic) would get the Stats component for an entity and just look at Speed and Attack. That way the combat code knows nothing about modifiers. And the stat calculation code has nothing to do with combat.


Another alternative is maybe the "FinalStats" could be a separate component, and the combat code only cares about that. The stats system would then be responsible for transforming the data from the "Stats" component to the "FinalStats" component for an entity. And if some enemies are very simple and don't have such a thing as base stats and mods, then they only need a "FinalStats" component. The combat logic continues as before (since it only cares about FinalStats), and the stats system would just ignore anything without a "Stats" component.


The ECS "pattern" makes it easy to think about decoupling code like this, but you could do essentially the same thing in a more traditional OOP way too.

In Topic: Resource objects in stl containers

17 February 2015 - 07:13 PM

fyi, in c++11, you can delete the assignment operator and copy constructors for a class (which the compiler would otherwise generate by default). This is a good idea if you don't want your class ever to be copied:

struct MyClass {
	HugeResource* r;
	MyClass() { r=new HugeResource(); }
	~MyClass() { delete r; }
	MyClass(const MyClass &src) = delete;             // Tell compiler to delete this method
	MyClass& operator=(const MyClass &src) = delete;  // Tell compiler to delete this method

// Now code like this will generate a compile error, instead of you finding
// problems at runtime:

std::vector<MyClass> list;