Xelvair

Members
  • Content count

    12
  • Joined

  • Last visited

Community Reputation

267 Neutral

About Xelvair

  • Rank
    Member
  1. Yeah, that must be it, thanks kolrabi!   Guess I'll only use modulo with positives from now on...
  2. Hello everyone, I have been having an issue with the modulo implementation in GLSL   I'm running version 4.5 Core and have the following problem:   Even though mod is defined as  x - y * floor(x/y) (source: https://www.opengl.org/sdk/docs/man4/html/mod.xhtml) which, when you plot it for y = 3, looks like this:   http://fooplot.com/#W3sidHlwZSI6MCwiZXEiOiJ4LTMqZmxvb3IoeC8zKSIsImNvbG9yIjoiIzAwMDAwMCJ9LHsidHlwZSI6MTAwMH1d   I am running into an issue where the result of -1 % 3 is apparently not within the domain [0, 2].   To be precise, the reduced code causing the error message is this: vec3 barycentric; vec3 barycentric_verts_sequence[3] = vec3[](vec3(1.0, 0.0, 0.0), vec3(0.0, 1.0, 0.0), vec3(0.0, 0.0, 1.0)); barycentric = barycentric_verts_sequence[-1 % 3]; The error reads: error C1068: array index out of bounds.   If shaders were easily debuggable, I probably wouldn't be asking this question, but since there's no way to step through the shader code while it's running, I was hoping that someone more experienced with GLSL could help me out!   Thanks in advance,   Marvin
  3. Thanks for the answer, phil   After getting some sleep however, I was finally able to fix the problem.   The issue was that this line here:       if((*layerLight)(neighbors[i]) < (*layerLight)(pos)){       which should have been this instead:       if((*layerLight)(neighbors[i]) < new_light_value){   Even though I don't understand how this led to an almost infinite iteration, I'm now happy it works and that i can advance to other features :)   The reason I didn't want to go with your circular approach is that I have less control over what light level the tiles have. My idea was to have stone block more light than air... You may know the game Terraria. That's the game that inspired the lighting system.   Thanks again,   Xel
  4. Hey there,   usually I'm not the one to ask a Forum to help me with my Code-problems, but I've been trying to make this piece of code work for almost 5 hours now and I just don't see what the problem could be.   First of all, what I'm trying to do is I'm trying to generate a lightmap to lay over my tilemap. The way I go about this is i have a closed and an open list. In each iteration, every member of the open list gets his neighbors lit accordingly and is then added to the closed list, while the neighbors are added to the open list. then i reiterate until the light value for the neighbors = 0, complete darkness.   However what happens is the algorithm doesn't stop at complete darkness. Instead, it goes on to light 4 times as much tiles as there are on the map. Laglarity ensues.   I'll add a screenshot and the code that is causing the problems. However if you need additional code, just tell me!   Hope you guys can help me, you're my last resort! void insertIfNew(const LayerData<float>& layer, const std::vector<sf::Vector2i>& closed, const sf::Vector2i& position, std::vector<sf::Vector2i>* neighbors){ if(layer.isInBounds(position) && !findInVector(closed, position)){ neighbors->push_back(position); } } void LayerShader::shadeAroundTile(const sf::Vector2i& pos, const LayerData<short>& layerData, LayerData<float>* layerLight) const{ std::vector<sf::Vector2i> closed; std::vector<sf::Vector2i> open; std::vector<sf::Vector2i> open_buf; open.push_back(pos); int counter = 0; while(!open.empty()){ while(!open.empty()){ sf::Vector2i pos = open.back(); open.pop_back(); closed.push_back(pos); counter++; std::vector<sf::Vector2i> neighbors; insertIfNew(*layerLight, closed, sf::Vector2i(pos.x, pos.y + 1), &neighbors); insertIfNew(*layerLight, closed, sf::Vector2i(pos.x, pos.y - 1), &neighbors); insertIfNew(*layerLight, closed, sf::Vector2i(pos.x + 1, pos.y), &neighbors); insertIfNew(*layerLight, closed, sf::Vector2i(pos.x - 1, pos.y), &neighbors); float new_light_value = capZero((*layerLight)(pos) - 0.1f); for(int i = 0; i < neighbors.size(); i++){ if((*layerLight)(neighbors[i]) < (*layerLight)(pos)){ (*layerLight)(neighbors[i]) = new_light_value; insertIfNew(*layerLight, closed, neighbors[i], &open_buf); } } } open = open_buf; open_buf.clear(); } std::cout << counter << " tiles processed!" << std::endl; }      
  5.   . Im curious, how do you suggest writing getters and setters without writing getters and setters?
  6. From my own experience, you shouldn't go for Entity-Systems, especially if you haven't created games in C++ before. Some time ago I've made my own framework that resembled the Artemis framework for Java. But the problem with Entity-Systems is that   You'll be copy-pasting code all over the place, writing millions of getters and setters just to create your classes without any functionallity. There are a few ways to do communication between components, but all of them have drawbacks.. either you increase dependency, or you have to do some expensive tasks like message dispatching etc. You stated that you dislike the oldschool Hierarchy approach to game development, and indeed, it does have its drawbacks as well. But as long as you stick to this one important rule, you should be totally fine:   Favor composition over inheritance   Basically, whatever you can achieve through composition, do that. And if you really have to fall back on inheritance, then there's probably a very good reason for that. Remember: Just because inheritance isn't good when used all over the place, it's still a very handy tool in quite a bunch of cases!   Greetings,   Xelvair
  7. Entity VS Behaviour

    I've been thinking about this Problem, too, but I believe I've found a Way to solve ist: The Strategy Pattern. Yes, ist is a tiny violation of the Paradigm, but I don't see any disadvantages. There would be two ways to go about ist: 1. Have an AI Component that has the Fields it needs (Aggro List, ...) and additionally,it has a function pointer to the ai subroutine it uses. 2. Have an "ExtendedFunctionality" component that has a vector of std::functions that are to be executed each frame. One being the AI routine.. These functions take their entity as parameter (imagine it being the this pointer), and then do their magic without virtual functions and inheritance I'm aware this breaks the "No Logic in Components" rule, but it's the most sensible thing i can think of. Maybe someone else knows better tho...
  8. Hey there, I'm working on my own Entity Component System right now, too. Your approach looks pretty much like my first one, which i redid because i ran into some inconveniences on the way. One of them was that if you let your systems update one entity per time, you'll run into problems with the Collision and the Rendering system, because you'll have to make your own containers in order to check each Entity against each entity (for collisions), and you'll need to sort the entities for depth drawing (rendering). My (not perfect, but improving) solution to the problem was to make a WorldIterator class, which's constructor takes information on what entities it's interested in, aswell as a reference to the world's entity container. Then I overloaded the operator++ to skip to the next entity that meets the requirements, and overloading the * and -> operators made accessing a lot nicer. I'm still in the development phase and haven't tested it yet, but I believe it to be a superior approach to the "one-entity-at-a-time-paradigm" that i see a lot of people use. Another thing you should add (and that is in Artemis aswell) is the Component mapper. I saw you using a syntax like: [source lang="cpp"]TMyComponent* myComponent = static_cast{TMyComponent*}(e->getComponent("MyComponent"); myComponent->setSomeValue(5); myComponent = nullptr;[/source] //For some reason it won't show these braces: <, So I'm using these instead: { Now, while this works, it's pretty uncomfortable to type. What i suggest is to have the following syntax: [source lang="cpp"]ComponentMapper{TMyComponent} mMyComponent; mMyComponent.grab(e); mMyComponent->setSomeValue(5); mMyComponent.release(); //You don't really need this, I did it cause it's cleaner.[/source] And if you make the grab function return a bool if it succeeded or failed to retrieve the component, you can do some pretty cool things like: [source lang="cpp"]// In the rendering System // blablabla drawing sprite if (mHealth.grab(e)){ if(mHealth->drawBar){ //Draw health bar } }[/source] But overall, It's an OK approach and should be sufficient for most of what you'll set your mind to. Greets, Xelvair
  9. On a side note, if you're using the new C++0x standard and don't need to maintain backwards compatibility, a very convenient way to iterate through a list is by using the auto keyword, which automatically determines the type of the value in use, in this case [i]std::list<int>::iterator[/i]: [CODE] for(auto it = list_.begin(); it != list_.end(); it++{ // Do stuff } [/CODE]
  10. SFML with Code Blocks

    That's normal. This DLL should be in the bin directory of your MinGW compiler, copy it and paste it into your project's folder ;)
  11. Also, returning a pointer to test is very dangerous, because test was initialized for the function block only, and was copied by value, ss soon as the program exits the function, test doesn't exist anymore, and ptr points to an invalid area. This however would work, and does what you want it to do: [code]class MyClass { public: int* func(int& test); }; int* MyClass::func(int& test) { int* ptr = &test; return ptr; }[/code]
  12. C++ vector, very hard to find bug

    Hmm, never really used iterators for deletion of elements in a vector, i just access it with the [] operator. Don't know why i'd use the iterator if i can just use it like an array, honestly. For deletion of elements, as long as the order of the elements in the vector doesn't matter, you could use std::swap to swap the element you want to delete with the last element in the vector, and then just call pop_back on the vector. Because if you delete an element from the middle of the vector, it needs to move all elements behind the one you deleted one slot forward.