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 - Mörkö

Pages: [1] 2 3 ... 7
Graphics / segfault when copying pixels
« on: June 28, 2019, 08:32:38 pm »
In the following code, the resulting texture is garbled when drawn:

    sf::Image img = texture.copyToImage();
    const sf::Vector2u img_size = texture.getSize();
    const sf::Uint8 * pixels = img.getPixelsPtr();
    const std::size_t array_size = img_size.x * img_size.y;
    sf::Uint8 * _pixels = new sf::Uint8[array_size];
    for (std::size_t i = 0; i < array_size; i++) {
        _pixels[i] = pixels[i];
    texture.update(_pixels, 256, 256, 0, 0);

but using the orignal pixels array is no problem. Valgrind reports the following:

==16020== Invalid read of size 8
==16020==    at 0x4C3416E: memcpy@GLIBC_2.2.5 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16020==    by 0xB98CDA2: ??? (in /usr/lib/x86_64-linux-gnu/dri/r600_dri.so)
==16020==    by 0xB991D90: ??? (in /usr/lib/x86_64-linux-gnu/dri/r600_dri.so)
==16020==    by 0xB6E91D4: ??? (in /usr/lib/x86_64-linux-gnu/dri/r600_dri.so)
==16020==    by 0xB6673B4: ??? (in /usr/lib/x86_64-linux-gnu/dri/r600_dri.so)
==16020==    by 0xB669F5F: ??? (in /usr/lib/x86_64-linux-gnu/dri/r600_dri.so)
==16020==    by 0xB66D3C7: ??? (in /usr/lib/x86_64-linux-gnu/dri/r600_dri.so)
==16020==    by 0x5294FCF: sf::Texture::update(unsigned char const*, unsigned int, unsigned int, unsigned int, unsigned int) (in /usr/lib/x86_64-linux-gnu/libsfml-graphics.so.2.4.2)

What am I doing wrong?

Does it make a difference if you change the order of the linking?

ie system, then window, then graphics

General discussions / Re: SDL2 Speed vs SFML?
« on: March 23, 2016, 06:02:33 pm »
What about CSFML?

You could demo the mechanic without any artwork before committing to it. Then if it turns out not to be an improvement you just delete the branch from your git or whatever you use. Without having seen your engine, I bet that implementing the such a change wouldn't take very long.

But I didn't come here to tell you how to do your game :D just wanted to post my reaction to the awesome content you've shown. Really good job!

The art style is just perfect, love the palette.

The only thing that doesn't make sense to me is that the player can only shoot in cardinal directions, especially since enemies seem to have full 360 degree freedom. I think it would be more fun if you aimed with the mouse and could shoot in all directions, eg Hotline Miami mechanics.

SFML projects / Re: AW: Re: How to make a release?
« on: March 18, 2016, 11:53:15 am »
Once you understand what DLLs are, what the runtime libraries are, how working directory and relative paths work, it's completely obvious.
I understand what those things are, and how they work. It is still not completely obvious to me how to share programs with other people in a hassle free way. I'm able to do it, but it's a hassle every time, mostly because of cross-platform compatibility related issues going from linux to windows.

Also note that all these concepts are not directly related to SFML, but are general things a programmer just has to learn and it's not SFML's job or purpose to teach people, how to become a programmer. ;)
Who said it's SFML's job to teach people how to become a programmer? I didn't, so that reply to my post is a non sequitur. If you disagree, then clarify why you believe my post somehow implies that it's SFML's job to teach programmers how to share programs.

SFML projects / Re: How to make a release?
« on: March 18, 2016, 03:45:24 am »
It really sucks that it is not completely obvious and a 100% solved and documented way how to share programs with other people. Some super clean and just totally reliable mechanism for doing it should exist by now.

I don't understand why the extra step is necessary:
private bool IsMaxDepth
          if (CurrentDepth == MaxDepth)
               return true;
               return false;

Why not just?
return CurrentDepth == MaxDepth

General / Re: Initial draw call slow
« on: March 09, 2016, 05:18:01 am »
Yes that's what I was trying to show, that it doesn't lag on the empty draw call, then it does lag on the first, and only on the first rectangleshape draw call. More generally, the first call to draw some vertices.

I haven't looked into the source to see what happens when drawing a default rectangleshape, but I conjecture it draws some vertices because that would be consistent with how the lag appears in all other circumstances, I discovered it not by using rectangleshape but by using vertexarray.

Other example:
int main() {
    sf::RenderWindow window{sf::VideoMode{640, 480}, "SFML"};
    sf::VertexArray vs{sf::Points};
    vs.append(sf::Vertex{sf::Vector2f{0, 0}});
    for (auto n : {1, 2, 3}) {
        Timer p{"Draw"};
        if (n > 1)  window.draw(vs); // lag once on first call
        else        window.draw(sf::VertexArray{sf::Points}); // no lag

General / Initial draw call slow
« on: March 09, 2016, 01:12:06 am »
Why does the first call to draw with some vertices cause a huge lag?

int main() {
    sf::RenderWindow window{sf::VideoMode{640, 480}, "SFML"};
    for (auto n : {1, 2, 3}) {
        Timer p{"Draw"};
        if (n > 1)  window.draw(sf::RectangleShape{});
        else        window.draw(sf::VertexArray{sf::Triangles});

Typical output:
Draw 0.031ms
Draw 167.891ms
Draw 0.006ms

Graphics / Re: View move when zoomed
« on: March 06, 2016, 10:52:31 am »
Is it possible to derive this factor from sf::Window? Preferably I would not separately keep track of a separate such variable, but rather assign a zoom (in response to scroll) and calculate the factor when needed.

Graphics / Re: Collision
« on: March 06, 2016, 07:55:40 am »
This is a problem that is specific to your own code (which you didn't include), not generally solved by SFML.

However, as a babbys first demo you could start by doing some collision tests on the bounds of your sprites, like this:

if sprite_a.getGlobalBounds().intersects(sprite_b.getGlobalBounds()) {
    // do your collision logic

Very soon though, you will want to decouple your rendering from your physics system. You should have some kind of game entity which interacts with the world, collides with other entities etc, but that doesn't know anything about rendering at all. Only as the last step in your update cycle does the "rendering system" kick in and draw all entities based on some chosen characteristics.

You should internalize the mantra of separating concerns. For example, collision detection doesn't need to know anything about sprites, and sprites also don't need to know about physics, sprites only need to know how to draw something. Ideally, the physics system would be a function which takes a static reference to the world and returns a new copy in which one frame's worth of movements and collisions have been resolved, then the rendering system would take reference to the array of game entities and return a frame buffer. But usually that's impractical and you will end up having some global mutable state that is modified frame by frame.

Graphics / View move when zoomed
« on: March 06, 2016, 07:33:45 am »
How can I make a view move the same amount regardless of zoom? For example, if I zoom out and move, the view then moves by the same amount it would by default, but I want to make it move by the greater amount relative to the zoom instead.

I hope the question is clear, otherwise I can elaborate if needed.

General / Re: Yet another RAII discussion
« on: February 14, 2016, 07:23:17 pm »
There are enough messy memory leaking C++ programs, and enough perfectly leak free C programs and RAII-less C++ programs to prove that smart pointers are not the definite solution to this set of problems.

And I suppose I have to mention the obvious: There are enough of the vice-versa case too that there is no question whether memory leaks are a problem for all levels of programmer. The C++ committee tried to fix it but the solution is nowhere near perfect and as has been shown to create its own new set of issues. It's up to everyone to decide whether the benefits of RAII outweigh the introduced downsides and there is no clear answer to that question as evidenced by the mere fact of debates of this nature.

Ultimately I think the issue is more of taste and style than of actual real practical importance. In my opinion, if you are going to use C++ then you might as well go all the way with templates, classes, RAII, OO paradigm etc. C++ is sold as being multi-paradigm, which might be technically true, but at the same time the language is hinting, implying, and seductively inviting you to write OO code. I'd say that limiting oneself to only a subset of C++ as some people advocate is a bad idea, because it's designed so that if you use one of the "nice" features then eventually you will want (need) to use all of them anyway and trying to resist that process will make your code a mess. If you don't want to use everything in C++, then just use C!

SFML projects / Re:creation - a top down action adventure about undeads
« on: February 10, 2016, 02:54:47 pm »

As I understand you are using an entity component system in your engine right? Could you please summarize how it works, just the broad strokes, most important aspects, etc. What I'm mostly interested in is, for example, does the components have logic or just data? Is there a container `entity` object or are they just connected by ID? How is message passing done? Things like that.

I'm interested in this because I'm currently considering trying ecs for an engine I'm planning, so I'm gathering data on successful implementations of the concept. I could read the whole thread instead of asking but it's very long and thus difficult to get a good overview ^^ thanks.

Pages: [1] 2 3 ... 7