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.


Topics - Glocke

Pages: 1 [2]
16
Graphics / [SOLVED] Error when drawing with Shader and BlendMode to RenderTexture
« on: February 20, 2015, 01:14:31 pm »
Hi, I'm currently working on my lighting system. I use a simple shader to draw a light gradient, draw those light sources via sf::BlendAdd to a render texture and finally fetch the texture and draw it to the actual screen using sf::BlendMultiply. This works great - if I don't resize the view by zooming. When zoomed, the render texture is recreated in order to fill the entire screen.

If resizing, the program crashs with an assertion error... But first, here's a minimal example which causes the problem on my machine.
(click to show/hide)

Here's the report from gdb
(click to show/hide)

In my opinion I need to draw to the render texture in order to guarantee those different blending modes. Drawing without the render texture isn't working correctly (from the result's point of view).

What I've tested:
  • Drawing with a shader to a render texture without resizing the view works fine.
  • Drawing with a shader to the render window with resizing the view works fine, as well.
  • Drawing without a shader to a render texture or render window with resizing the view works fine.

So finally, it seems to be a problem with zoom + shader + render texture, but I don't know what's wrong with my code!
Just in case: The machine is a netbook with Linux Ubuntu (32 bit) with a no-name Intel graphics chip. I'm using clang and C++11 for building the application.

Kind regards
Glocke

17
Graphics / [SOLVED] Sprite Transformation Batching
« on: January 30, 2015, 03:30:04 pm »
Hi, I'm currently using simple shapes (colored, without textures) as sprites. To speed up drawing I add all objects' vertices to a single vertex array while culling. So the actual drawing is pretty fast ;D

Unfortunately, I need to transform the vertices referring sprite's position and orientation, so I apply translate() and rotate() to the corresponding sf::Transformation and use transformPoint on each object's vertices. Because each object has individual transformations, I need to calculate those transformations per object. So I cannot use the transformation object/matrix as part of sf::RenderStates.
I'm using a dirty flag, yet, to determine whether a transformation needs to be recalculated. So the entire process runs smoothly in most cases. But if many transformations need to be done, it takes a lot more time.

Do you have any suggestions how to speed up those transformations? .. except multi-threading, I am trying to work single-threaded as long as possible to reduce unnecessary complexity ^^

Kind regards
Glocke

/EDIT: Some more details: Each sprites holds two sets of vertices: the original, untransformed and the currently transformed vertices. On each recalculation, the sf::Transformation object is created and applied to each vertices' position. The resulting vertices are stored as "currently transformed" vertices, which are used for drawing.
/EDIT 2: About the number of object... I'm currently testing with around 5k object, which runs smootly with clang's -O2 on my netbook (in contrast: in debug mode only up to 1.3-1.4k can be handled smoothly.. But using around 10k object is just another frame show ^^ Of course a netbook isn't fast but good to face performance problems early :) So I'm trying to get as much performance as I can  ;D

18
Graphics / Distributed Rendering
« on: January 30, 2015, 11:29:31 am »
Hi, I am experimenting with distributed rendering. Fortunately it works ;D But I'm not quite sure whether my approach is "right" or as any downsides.

Basic Idea: Rendering multiple views in parallel by drawing an array of sf::Drawables to a sf::RenderTexture. So I created a Camera-class holding the used view, a render texture and a C++11 Thread to perform drawing. On each frame the drawing-threads are restarted, the main thread is waiting for them and then it applies the render texture to the actual rendering target.

I know some basic stuff about concurrency, but I lack of experience about using in "real life". So I'm not sure whether..
  • .. there is something about concurrency I forgot considering
  • .. the entire idea is useful/efficient or not

It's just a theoretical aspect, but drawing in parallel should be more efficient. But I don't know how expensive the "merge" (getting texture from the render texture and applying it to window) is. :-\
Of course the scenes need to be much more complex ^^ Distributed rendering of two shapes seems overkill .. well, just some kind of minimal-code ^^

Well, here's my current code (btw using linux, so XInitThreads is used) :) (inside the spoiler)
(click to show/hide)

Kind regards
Glocke

19
System / [SOLVED] Multiple conversions between sf::Vector2<T>
« on: January 26, 2015, 04:29:26 pm »
Hi, I'm building a grid-based game with discrete movement. So I use sf::Vector2u as grid coordinates - because they're always positive - and sf::Vector2i to express "normalized" movement directions. Of course they're not normalized in the typical sense of vectors but each component is either -1, 0 or +1, which makes it easy to calculate movement targets.

My "problem" is that calculating such targets implies some typecasting and I'm not sure what's the "best" way to do it:

1st approach:
sf::Vector2u target = static_cast<sf::Vector2u>(static_cast<sf::Vector2i>(source) + direction);
This makes use of two explicit conversions (per component) which is .. very explicit ^^ .. but not really beautiful from my point of view.

2nd approach:
sf::Vector2u target;
target.x = static_cast<unsigned int>(target.x + direction.x);
target.y = static_cast<unsigned int>(target.y + direction.y);
This uses two explicit conversion and two implicit (unsigned int + int), which isn't that explicit anymore :S

Other approaches might be overloading operator+ / operator+= which I'd like to avoid, because it might cause errors when using the + operator without absolute care referring to the used types in the expression.
Another solution might be a free function such as sf::Vector2u applyDirection(sf::Vector2u const &, sf::Vector2i const &). But I'm not quite sure how to implement it (or the operator overload) correctly: using the explicit approach (1st) or the semi-explicit approach (2nd) or a different way?

Kind regards
Glocke :)

20
SFML projects / SfmlExt: An extension to SFML using Thor and C++11
« on: January 06, 2015, 09:49:31 am »
Hi there,

during the last months, I was working on my Isometric Coop Rogue-like Game Rage, which is currently paused because of too less spare time. So I started reworking/refactoring the entier codebase. During this process I found some pieces of code which are solving several problems I faced during development. So I started to isolate those solutions to make them reusable. Finally, I decided to put those solutions on github and call this repository "SfmlExt" - because it seems like an extension - at least to me.

It requires C++11 (which should be wide-spread by now), works with SFML 2.2 and can be found here: https://github.com/cgloeckner/SfmlExt

Briefly, it's a set of functionality which is distinct from the current SFML release as well as from Thor. Currently, there the following "sub-projects" are included:
This list is outdated. View README on github for further details.
(click to show/hide)

So, stay tuned for future commits :o For updated examples view the GitHub repository!

Thanks for reading! I'm looking forward to your feedback.

Kind regards
Glocke

/EDIT: (10.01.15) Major API Update (removed outdated examples from this post)
/EDIT: (21.01.15) Moved outdated feature-list (see spoiler)

21
SFML projects / Image Atlas Generator
« on: December 20, 2014, 01:10:07 pm »
This thread is out-dated. Please use this one.

Hi there :)

Introduction:
we already know that using few, large textures with multiple sprite animation frames is more efficient than using many small textures with single frames. I was looking - I guess as most other hobby developers, too - for suitable sprite graphics. Some assets are using the frameset-approach (multiple frames within a larger texture), some are using single files per frame. But if you want to avoid using a mixture of both approaches, you are forced to convert all graphics to one format either used by the first or used by the second approach.
But simple merging (potentially diffently sized!) frames to a set of uniform sized frames isn't great. It implies some wasted memory (because of many empty/transparent pixels inside the image). On the other hand, merging them memory-efficient by hand isn't great either. To solve this, I wrote some piece of code ;)

How it's working:
The idea is straight-forward: try to find an empty spot for your images. But this implies some more work! The basic idea is to add lots of images to some kind of container. On each insertion the container (with a fixed size) returns whether it had free space. If yes, the image was added and it's offset (topleft position within the container) will be returned call-by-reference to the second argument given to add.

Here's a small (runnable) example code.. It's creating some random single-colored images with randomized size, sorting it by the images' size (desceding) and adding largest images first. After that, the final image is written to disk as example usage.

#include <algorithm>
#include <iostream>
#include <cstdlib>
#include <ctime>

#include <utils/image_atlas.hpp> // <-- see below

int main() {
        std::srand(std::time(0));

        // create images --- ugly - feel free to skip while reading^^
        std::size_t num = 40;
        std::vector<sf::Image> images{num};
        sf::Uint8 k = 0;
        int i = 0;
        for (auto& img: images) {
                sf::Color c;
                if (i < num/3) {
                        c = sf::Color{k, 0, 0};
                } else if (i < 2*num/3) {
                        c = sf::Color{0, k, 0};
                } else {
                        c = sf::Color{0, 0, k};
                }
                img.create(40 * (std::rand() % 10 + 1), 40 * (std::rand() % 10 + 1), c);
                k += (255/(num/3));
                ++i;
                if (k > 200) {
                        k = 40;
                }
        }

        // sort by size (descending)
        // --> helps to achieve a (at least nearly) well-constructed atlas
        std::sort(images.begin(), images.end(), [&](sf::Image const & a, sf::Image const & b) {
                auto size_a = a.getSize();
                auto size_b = b.getSize();
                return size_a.x * size_a.y > size_b.x * size_b.y;
        });
       
        // add to ImageAtlas -- here the actual work starts
        ImageAtlas target{1024u}; // or use default ctor for max size
        for (auto const & img: images) {
                sf::Vector2u pos;
                if (target.add(img, pos)) {    
                        auto size = img.getSize();
                        std::cout << "Added image sized " << size.x << "x" << size.y
                                << " added at (" << pos.x << "|" << pos.y << ")\n";
                }
        }
       
        // generate final image
        auto result = target.generate();
        result.saveToFile("out.png");
}
 

By the way: The included header for the image_atlas can be found here: https://github.com/cgloeckner/SfmlExt

What to do with?
The image atlas can be create once for the current machine (atlas' size might depend on the hardware's limitations), write it to disk and load it when starting the game. Of course you'll also need to store those initial-image-and-its-offset-relations to keep atlas and mapping consistent.
Possibly, the (resulting) texture and rectangles (computed offset with initial frame's size) could be used by Thor's animation handling system ;)

About the code:
It poorly documented, yet. Also some approaches (e.g. searching a free spot) are not that great... But it's working in the first place ;)

Please feel free to feedback!

Kind regards
Glocke

/EDIT: Some productive example: These offsets should be stored (mapping!) for the example frameset (graphics taken from "Battle for Wesnoth")
(click to show/hide)

22
Feature requests / Interface for "loadFromFile" (and others)
« on: November 28, 2014, 03:25:13 pm »
Hi, an interface for all SFML-classes providing loadFromFile() (and similar) would be great. I'd like to store multiple "Loadables" inside a nested std::map: First key: RTTI using std::type_index(typeid(...)), second key: actual identifier to the resource (e.g. std::string). Because those resources have no common parent class, the final type (which to embedd in the inner std::map) needs to be void* which isn't great for polymorphic stuff.

Btw my map looks currently like this:
std::map<std::type_index,
    std::map<std::string, void*>
>
because I store pointers to different resources. The desired map would look like this:
std::map<std::type_index,
    std::map<std::string, std::unique_ptr<sf::Loadable>>
>

Also this would allow to dynamic_cast instead of static_cast. Casting statically is not helpfull if you're using polymorphism. Else, dynamically casting provides this - but void is not a base class for any of the used types ^^

Why not using a single std::map per resource type? I wrote a private template-based get/set for this entire map. The public interface calls this methods with a concrete type (e.g. sf::Texture). But I don't want to copy'n'paste the entire mechanisms for each new resource type. A "Loadable" interface would help, because I could derive my own resources (such as file streams) from Loadable and use them (just as sf::Texture if implementing Loadable^^) as polymorphic loadables.

Does anyone like this idea?

23
System / [SOLVED] Input handling: detect holding two keys
« on: October 08, 2014, 10:27:25 am »
Hi, since I introduced diagonal movement to my game, I encountered problems while detecting. Input handling works currently this way: The mainloop forwards the sf::Event (if type is KeyPressed or KeyReleased) to the GameObject's input component. At this component, I store this press/release in a (as map<Key, State>). On each cycle, my component is updated to move all previously pressed keys to currently hold - and previously released keys to currently "free" keys.

This system works great, unless one fact: When querying my input component, all predefined keys (the bindings for left,right,up,down and some additional ones - doesn't matter here) are checked. Key detection works this way:

if (keys.at(binding.up) == PRESS || keys.at(binding.up) == HOLD) {
    move.y = -1;
}
Left, down and right are handled in the same way. So the move var (btw sf::Vector2i) finally has values such es (0,1), (-1,1) etc. This works well, IF the keys are pressed EXACTLY at the same time. But often pressing A and W (as left and up) doesn't happen at the same time, because the program is even faster than the user.

Well, so I started delaying each of those queries to the input state for some milliseconds (so they aren't queried on each frame if a user is allowed to). But the effect isn't that great: Sometimes the movement looks delayed to the player (because of the delay ;D ) - and sometimes the previous effect (first walk left, than diagonally left-up) occures (because the up-key is pressed slitely after the first query).

What am I doing wrong referring to my input design? :-\

BTW: The first "left-only" movement is completly executed, because my systems avoids query input while an action (walking to the left tile) isn't completed. This system achieves some kind of discrete movement and simplifies collision detection etc.

24
System / Loading resources using thread
« on: October 02, 2014, 04:02:16 pm »
Hi, I'm trying to load my resources using a thread. But it isn't working yet. Here's my error output at the console:
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 88 requests (88 known processed) with 0 events remaining.

I'm using Linux laptop 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:01 UTC 2014 i686 athlon i686 GNU/Linux, C++11, SFML2.1 and this as my example program:

#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>

sf::Texture tex;

void loadResources() {
    tex.loadFromFile("tile.png");
}

int main() {
    sf::RenderWindow window(sf::VideoMode(640, 480), "Demo");
    sf::Thread thread(&loadResources);
    thread.launch();

    while (window.isOpen()) {
        sf::Event event;
        while (window.pollEvent(event)) {
            if (event.type == sf::Event::Closed) {
                window.close();
            }
        }
    }
   
    return 0;
};
 

Porting to C++11's std::thread causes:
Failed to use the XRandR extension while trying to get the desktop video modes
X Error of failed request:  BadRequest (invalid request code or no such operation)
  Major opcode of failed request:  186 ()
  Minor opcode of failed request:  0
  Serial number of failed request:  89
  Current serial number in output stream:  90
 

Any ideas?

/EDIT: The output seems to vary from each start to another. Here is another one (using sf::Thread again)
X Error of failed request:  BadIDChoice (invalid resource ID chosen for this connection)
  Major opcode of failed request:  1 (X_CreateWindow)
  Resource id in failed request:  0x3c0000b
  Serial number of failed request:  88
  Current serial number in output stream:  88
 
An yet another one:
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
main: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

25
Graphics / [SOLVED] Unexpected behavior when coloring sf::Vertex
« on: October 01, 2014, 06:40:54 pm »
Hi, I was working with sf::Vertex and sf::VertexArray to achieve lineare gradients over tile graphics diagonals. But I was facing something ... imho "strange behavior".

Here's my code (demo code providing my "problem"):
(click to show/hide)

I attached the tile-graphic to this post and it's original taken from http://opengameart.org/content/fancy-dungeon-tileset.

Well, the result renders "correct" for topleft and bottomright situation. But the situations at topright and bottomleft doesn't make sense to me. I want to achieve the same lineare gradient "around" the tile's diagonal - but with another direction.

Any idea what's wrong with my approach?

Kind regards & thanks in advance!

26
System / [SOLVED] Save/Load keybindings
« on: September 30, 2014, 09:59:18 am »
Hi,

I'm using ini-files to save and load keybindings. Using sf::Joystick is quite easy: I read/write the buttons' uint's. Handling axis is nearly the same, but I'm using a small function mapping "x" to sf::Joystick::Axis::X and so on. But doing this for keyboard (e.g. "w" to sf::Keyboard::W) isn't fun at all. Is there a clever way to do this? I want to avoid a large switch considering the entire sf::Keyboard enum. Maybe there's a way?

27
SFML projects / [WIP] Racod's Lair - a coop dungeon crawler [Demo Released]
« on: September 20, 2014, 06:36:11 pm »

Racod, scourge for mankind, escaped to its lair to regenerate for his next decade of terror.
You and your brave fellows are willed to find and defeat Racod.


Genre: Coop Dungeon Crawler / Hack'n'Slash RPG

Target platforms: Windows, Linux


Core features:
  • Procedurally generated dungeons, enemies and loot
  • Cooperative gameplay via splitscreen and/or shared camera
  • Mod-friendly through XML-based content and Lua-based AI scripting

What is used: C++11, SFML, Thor, Boost, Sol2


28
System / [SOLVED] sf::Event vs. sf::Keyboard/sf::Mouse/sf::Joystick
« on: September 18, 2014, 10:11:11 am »
Hey guys,

I'm using an instance of my GameObject class holding an instance of an InputComponent class, whichs checks sf::Keyboard/sf::Mouse/sf::Joystick to detect user input. So the input component can trigger further actions of the GameObject on each case. But I'm not sure whether this is the right solution for me.

Using this "oldschool" way (means: querying the entire input set on each frame) might cause additional overhead because of checking the entire set on each frame ^^ This seems not so great to me in case of detecting whether the key was pressed/released in this frame, because I need to do this on my self. This isn't a problem to me, but it might be not necessary at all, because SFML provides an event-driven API using sf::Event.

But pulling all events and calling all GameObject's InputComponent's handle()-method might also be not so clever, because each GameObject will be addressed on each event - even if the object would ignore it completly. But (but but but xD) ... but introducing some more intelligent pattern - like registering an object for a limited set of events - seems to be architectural overhead.

Am I wrong in any of this cases? Well, I'm not sure what's the right way for me.. And because this seems an architectural problem I'm gonna solve it now, before writing further input code using "the wrong" design.

Any suggestions? :)

Kind regards
Glocke

29
SFML projects / TCP-Based Server-Client Framework - based on SFML 2.0 and C++11
« on: June 16, 2013, 07:01:49 pm »
Hi guys,

I started focusing on SFML. So I plan to migrate my Game Engine Project (some kind of multiplayer, isometric hack'n'slay roleplaying) by using SFML. And this means to migrate my networking framework from SDL to SFML.

I made this during today - including deals with the questions "how to install SFML2.0 on my ubuntu 12.04 via suitable PPA" and "how does networking works with SFML 2.0". Now my framework looks even clearer and hopefully more stable.

What's that framework about: It is a TCP-based Server-Client-Framework, based on SFML 2.0 and C++11, as the title already said. You can find the code my GitHub repository https://github.com/cgloeckner/networking - feel free to use, share and fork it. It's open source!

To avoid writing a large article, I'd just like to point out some features. You can find even more information in the README-file at the repository.

  • Multithreaded Server-Client architecture
  • TCP-based communication
  • Multi-Plattform by modern C++11 and SFML features
  • Limit number of clients (or keep open-end)
  • Block / Unlock clients based on their IP-address
  • Grouping clients to logical partitions
  • Easy-to-use: it's header-only!
  • Flexible: Use your own protocol workflow

I hope you like it. Feel free to comment on this framework (praise, criticism, questions etc.)

Finally I'd like to say: SFML is great! Today's absolute highlight was getting to know about sf::Packet - it's f*cking godlike ;)

Kind regards
Glocke

30
Graphics / Looking for 2D, non-native Widget-Framework
« on: June 15, 2013, 02:12:41 pm »
Hey guys,

until know I was working with SDL, because I was focused on learning basics. By the time I built some stuff using SDL which is easily provided by SFML (e.g. Sprite class). Now I'm going to migrate my game project SFML 2.0, so I hope to make my code clearer, faster and even more powerful, because SFML seems to be a well-developed, "mighty" framework :)

I was writing some own widget classes based on SDL, yet. The main purpose of this process was learning and understanding how GUIs might work. I think I just got it, but my current solution seems "non-modern" to me. And because I am going to use SFML now, I am looking for some kind of framework providing widget classes (buttons, listboxes etc.) using SFML. I don't know "where to start". Googleing for "sfml widget library" offers me a huge set of libraries.

Can you advise such a widget library? I am looking for plain 2D widgets based on graphics. That meens I don't want to get "native styled" widgets (referring to the systems main gui toolkit). So I don't know where to start. Working "through" a huge set of possibilities seems too much work, so I am asking for some tips based on your exprience :)

By the way: If you ask yourself "what's that game project this guy is talking about": it's going to be a multiplayer hack'n'slay roleplaying game, based on a fixed isometric perspective like Diablo 1/2.

Because I am new to this forum, I maybe postet this in the wrong sub-section. In this case I apologize  ;)

King regards
Glocke

Pages: 1 [2]
anything