Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Glocke

Pages: 1 2 [3] 4 5 ... 20
31
General discussions / Module membership for sf::Packet
« on: June 27, 2016, 04:01:06 pm »
Hi, I've been using sf::Packet quite a while to prepare game data for being written to binary files (because of the builtin byte order handling). This makes e.g. savegames easily cross-platform. I understand that this functionality is also used while networking. But is it really necessary to attach the class to the networking module?

It isn't a big deal .. but more a question of grouping. Personally, I'd expect such things within the system module of SFML. Any thoughts on that?

Glocke

32
Sounds interesting! Keep it running :)

33
SFML projects / Re: Rage - a coop dungeon crawler
« on: June 22, 2016, 12:19:17 pm »
I just finished the game's debugging/test mode.. hopefully a good foundation for all further development! :)



/EDIT: Just added an animated spider sprite.. after cheating on the savegame I've got this... Enjoy watching!

34
Graphics / Re: Broken TexCoords when zooming sf::View
« on: June 21, 2016, 08:33:05 am »
Inspired by the fact, that google let this problem seem a general one, I thought about that "adding pixels to each tile"-solution and came up with this: let the game add the pixels when loading the tileset. It seems to work perfectly ;D

Also the code for preparing the tile changed. Here's my solution:
void scale(sf::Vector2f& v, sf::Vector2u const & tile_size) {
        v.x *= tile_size.x;
        v.y *= tile_size.y;
}

void prepare(sf::Vector2f& tl, sf::Vector2f& tr, sf::Vector2f& br, sf::Vector2f& bl, sf::Vector2u const & offset, sf::Vector2u const & tile_size) {
        tl = sf::Vector2f(offset.x,                     offset.y);
        tr = sf::Vector2f(offset.x + 1.f,       offset.y);
        br = sf::Vector2f(offset.x + 1.f,       offset.y + 1.f);
        bl = sf::Vector2f(offset.x,                     offset.y + 1.f);
        scale(tl, tile_size);
        scale(tr, tile_size);
        scale(br, tile_size);
        scale(bl, tile_size);
}

void add(sf::VertexArray& array, sf::Vector2u const & world_pos, sf::Vector2u const & tile_offset, sf::Vector2u const & tile_size) {
        sf::Vertex tl, tr, br, bl; // [t]op[r]ight etc.
        // setup positions and texture coords
        prepare(tl.position, tr.position, br.position, bl.position, world_pos, tile_size);
        prepare(tl.texCoords, tr.texCoords, br.texCoords, bl.texCoords, tile_offset, tile_size);
        // fix tex coords to suit the modified atlas
        sf::Vector2f delta{1.f, 1.f};
        delta.x += tile_offset.x * 2;
        delta.y += tile_offset.y * 2;
        tl.texCoords += delta;
        tr.texCoords += delta;
        br.texCoords += delta;
        bl.texCoords += delta;
        // add tiles
        array.append(tl);
        array.append(tr);
        array.append(br);
        array.append(bl);
}

sf::Image rebuildAtlas(sf::Image const & source, sf::Vector2u const & tilesize) {
        // determine new size
        auto size = source.getSize();
        assert(size.x % tilesize.x == 0);
        assert(size.y % tilesize.y == 0);
        auto num_x = size.x / tilesize.x;
        auto num_y = size.y / tilesize.y;
        size.x += num_x * 2;
        size.y += num_y * 2;
        sf::Image atlas;
        atlas.create(size.x, size.y);
       
        // create atlas
        sf::Vector2u offset;
        for (offset.y = 0u; offset.y < num_y; ++offset.y) {
                for (offset.x = 0u; offset.x < num_x; ++offset.x) {
                        // copy frame
                        auto destX = 1 + offset.x * (tilesize.x + 2);
                        auto destY = 1 + offset.y * (tilesize.y + 2);
                        sf::IntRect sourceRect;
                        sourceRect.left = offset.x * tilesize.x;
                        sourceRect.top = offset.y * tilesize.y;
                        sourceRect.width = tilesize.x;
                        sourceRect.height = tilesize.y;
                        atlas.copy(source, destX, destY, sourceRect);
                       
                        // create left border
                        --destX;
                        sourceRect.width = 1;
                        atlas.copy(source, destX, destY, sourceRect);
                       
                        // create right border
                        destX += tilesize.x + 1;
                        sourceRect.left += tilesize.x - 1;
                        atlas.copy(source, destX, destY, sourceRect);
                       
                        // create top border (copying from source to source!)
                        destX -= tilesize.x + 1;
                        sourceRect.left = destX;
                        sourceRect.top = destY;
                        sourceRect.width = tilesize.x + 2;
                        sourceRect.height = 1;
                        --destY;
                        atlas.copy(atlas, destX, destY, sourceRect);
                       
                        // create bottom border (copying from source to source!)
                        destY += tilesize.x;
                        sourceRect.top = destY;
                        ++destY;
                        atlas.copy(atlas, destX, destY, sourceRect);
                }
        }
        return atlas;
};
 

35
Graphics / Re: Broken TexCoords when zooming sf::View
« on: June 19, 2016, 08:22:07 am »
By changing the size by less than a half pixel? ???
If the current resolution is 800x600 and the zoom factor is 1.013525, the resulting size is 810.82x608.115; rounding results to 811x608. gcd(800,600)=200, hence 800/200=4, 600/200=3, thus 4:3 ratio. gcd(811,608)=1, hence 811:608 ratio. Doing this repeated will break the ratio more and more.

I tried the following:
float zoom(sf::View& view, float factor) {
        if (factor == 1.f) {
                return 1.f;
        }
        auto size = sf::Vector2i{view.getSize()};
        auto prev = size;
        int step = factor > 1.f ? 1 : -1;
        // calculate ratio and reduce fraction
        auto ratio = size;
        auto gcd = boost::math::gcd(ratio.x, ratio.y);
        ratio.x /= gcd;
        ratio.y /= gcd;
        // resize until factor exceeded
        float done{1.f};
        do {
                size += ratio * step;
                done = (1.f * size.x) / prev.x;
        } while ((factor > 1.f && done < factor) ||
                         (factor < 1.f && done > factor));
        // fix size
        if (size.x <= 0 || size.y <= 0) {
                size = ratio;
        }
        // apply size
        view.setSize(sf::Vector2f{size});
        return done;
}
 

But this doesn't fix the "render feature"... any thoughts about that?

/EDIT: Optimized version for larger zooming steps (without loop)
(click to show/hide)

/EDIT: Updated program code that will zoom to a factor which causes the lines on my machine
(click to show/hide)

36
Graphics / Re: Broken TexCoords when zooming sf::View
« on: June 18, 2016, 02:59:14 pm »
zoom is just a shortcut to setSize. So all you have to do is to round the size after zooming.

Ok, ... but doesn't this break the aspect ratio between width and height?

37
Graphics / Re: Broken TexCoords when zooming sf::View
« on: June 18, 2016, 01:18:32 pm »
Thx, Laurent. I guess you refer to this, right?
Quote
In order to render a sf::Drawable object pixel-perfectly, make sure the involved coordinates allow a 1:1 mapping of pixels in the window to texels (pixels in the texture). More specifically, this means:

    The object's position, origin and scale have no fractional part
    The object's and the view's rotation are a multiple of 90 degrees
    The view's center and size have no fractional part
From my point of view:
  • The objects (vertices) have positions, origin and scale without fractional part
  • Neither the object nor the view are rotated anyhow.
  • The view's center is modified by integer steps. Hence the center shouldn't have a fractional part
Refers "size" to the original (pre zoom) or final (post zoom) size? If second, how to avoid? Calculate the view's final size before zooming and adjusting the zoom to hit an integer size?

38
Graphics / Broken TexCoords when zooming sf::View
« on: June 18, 2016, 11:59:40 am »
Hi, I use a tileset texture with multiple tiles on it and sometimes - when the view is zoomed - a line from the next tile is drawn. So I expect the tex coords to be broken somehow ... but why?

Minimal example code:
#include <iostream>
#include <SFML/Graphics.hpp>

void add(sf::VertexArray& array, sf::Vector2u const & world_pos, unsigned int tile_offset, unsigned int tile_size) {
        sf::Vertex tl, tr, br, bl; // [t]op[r]ight etc.
        // setup positions
        tl.position = sf::Vector2f(             world_pos.x             * tile_size,             world_pos.y    * tile_size);
        tr.position = sf::Vector2f((1 + world_pos.x)    * tile_size,             world_pos.y    * tile_size);
        br.position = sf::Vector2f((1 + world_pos.x)    * tile_size,    (1 + world_pos.y)       * tile_size);
        bl.position = sf::Vector2f(             world_pos.x             * tile_size,    (1 + world_pos.y)       * tile_size);
        // setup texture coords
        tl.texCoords = sf::Vector2f(0.f,                tile_offset                     * tile_size);
        tr.texCoords = sf::Vector2f(tile_size,  tile_offset                     * tile_size);
        br.texCoords = sf::Vector2f(tile_size,  (tile_offset + 1)       * tile_size);
        bl.texCoords = sf::Vector2f(0.f,                (tile_offset + 1)       * tile_size);
        // add tiles
        array.append(tl);
        array.append(tr);
        array.append(br);
        array.append(bl);
}

int main() {
        sf::RenderWindow window{{800u, 600u}, "test"};
        sf::Texture tileset;
        tileset.loadFromFile("tileset.png");
        unsigned int tile_size{16u};
       
        sf::VertexArray array{sf::Quads};
        for (auto y = 0u; y < 20; ++y) {
                for (auto x = 0u; x < 20; ++x) {
                        unsigned int offset{0u};
                        if (y == 0 || y == 19 || x == 0 || x == 19) {
                                offset = 1u;
                        }
                        add(array, {x, y}, offset, tile_size);
                }
        }
       
        auto view = window.getDefaultView();
        float zoom{1.f};
       
        while (window.isOpen()) {
                sf::Event event;
                while (window.pollEvent(event)) {
                        if (event.type == sf::Event::Closed) {
                                window.close();
                        }
                }
               
                window.clear(sf::Color::Black);
               
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Up)) { view.move(0, -1); }
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Down)) { view.move(0, 1); }
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Left)) { view.move(-1, 0); }
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Right)) { view.move(1, 0); }
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Q)) { view.zoom(1.01f); zoom *= 1.01f; std::cout << "zoom: " << zoom << "\n"; }
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::E)) { view.zoom(0.99f); zoom *= 0.99f; std::cout << "zoom: " << zoom << "\n"; }
               
                window.setView(view);
                window.draw(array, &tileset);
                window.display();
        }
}
 

Tileset png and screenshots are attached. Any ideas what's wrong with my implementation? (btw using SFML 2.3 from ubuntu wily repos)

39
SFML projects / Re: Rage - a coop dungeon crawler
« on: June 16, 2016, 11:23:17 am »
Thx Recoil!

Meanwhile, more stuff has been finished. The most useful is transforming predefined rooms while the actual dungeon generation. The rooms are not just filled with ambience stuff (plants, corpses etc.) but also rotated (by multiples of 90 degree) and can be flipped along x- and/or y-axis.

Editor:


Ingame:







40
SFML projects / Re: Rage - a coop dungeon crawler
« on: June 08, 2016, 10:10:21 am »
Hey guys!

atm I'm working on a room editor (based on ImGui within SFML). Here are some WIP screenshots of the editor and the rooms loaded to the game:


41
SFML projects / Re: Rage - a coop dungeon crawler
« on: June 02, 2016, 09:19:44 am »
While heading to better dungeon generation, I added some ambience stuff to rooms to make them look more interesting - even without lighting. So I added some simple vegetation.



42
SFML projects / Re: Rage - a coop dungeon crawler
« on: May 31, 2016, 05:50:29 pm »
Another step towards playable alpha demo was implementing powerups, that are dropped by killed enemies.. they can be used to regenerate life and/or mana! Implementing the complete UI for looting and inventory management would be too much to add, because I want to release the alpha demo more soon than later ^^ So ... having less (features) is more :)



Next changes:
- improved dungeon randomization (especially room generation)
- improved game mechanics (base for simple puzzles)
- more graphics (mostly enemies)
- audio implementation (background music, simple sound effects)
- better AI scripting

Stay tuned!

43
SFML projects / Re: Rage - a coop dungeon crawler
« on: May 28, 2016, 07:19:23 pm »
Meanwhile, more progress happened!
- new HUD: small tubes show the amount of life, mana and stamina. also the experience is shown
- camera decoration: since camera borders can be hard to figured out, they are now decorated :)
- player colors: to have a better overview, players now have colors which represent them (lighting, player name).

Enjoy watching!


44
Graphics / Re: Performance on Drawing Lightened Scene
« on: May 27, 2016, 05:44:22 pm »
Yes, if not already done, you should use space partitionning to limit useless computations (edges not in range of lights, for example).
Thx, but this is already done :) Except not culling edges that are hidden by other edges but still visible in the scene.

But anyway: My problem also occures if I have lots of lights and few edges .. extreme case: 50 lights and 1 edge (assuming space partitioning is already applied). Then getFarPoint() will be called 50x (like 1 Light and 50 Edges which runs perfectly fine). The profiler tells me nothing (see spoiler above).

45
Graphics / Re: AW: Performance on Drawing Lightened Scene
« on: May 27, 2016, 05:20:33 pm »
Well think about it. Do you need to call prepareLight or getFarPoint 7200 times per (not sure how long that was sampled over)?
prepareLight() is called twice per light per frame (could be reduced to once maybe). But calling it once is minimum because I don't want to have one sprite per light.. it's unnecessary from my point of view.
getFarPoint() is called once each pair of lights and edges, because each light could hit each edge. As mentioned: num_lights x num_edges is just an upper bound and not necessary in each case. I think that's the best way to go for me atm.

Pages: 1 2 [3] 4 5 ... 20
anything