Messages

1

Graphics / Re: Maybe found a bug on the r-pi, or doing something stupid

« on: August 30, 2023, 11:32:41 pm »

Thanks for the help The thing is that I have two primary constraints.

1) The Pi has limited bandwidth on its internal memory bus, and the GPU shares the bus with the CPU, it doesn't have separate memory. I can't go copying HD-sized textures around so manually double-buffering doesn't sound workable due to the copying requirement. I can get one (1) of these copies per frame and still keep a 60fps frame rate, so that has to be the "update the display from the frame-buffer" pass.

2) I want to try and stick with the same paradigm that the GEM routines were designed for - ideally I'd like to link this up to an emulator later on, and having things work "like they should" will make it easier. GEM didn't double-buffer the screen, it just sent a list of dirty-rects to the application and expected drawing to happen in the primary frame-buffer.

I was drawn to SFML because it has a lot of the low-level graphic API calls with options already built in (eg: draw a rectangle, in a colour, with a fill and a specific line-thickness). It doesn't do dash-patterned lines, but I think I could probably do that in a shader - it may just be that this isn't a good match, and that's ok too, that's sort of what I'm trying to find out...

2

Graphics / Re: Maybe found a bug on the r-pi, or doing something stupid

« on: August 30, 2023, 09:14:58 pm »

replying to my own post here, but I had the chance to test it on a newer (pre-release) version of the Pi OS ("bookworm", not "bullseye") and it worked just like it did on the Mac, so maybe there's a problem with bullseye. Th bookwork version was a lot slower than the bullseye one though and makes it pretty much unusable - I need 60fps not 30fps, on the other hand I need it to, you know, work as well

3

Graphics / Re: Maybe found a bug on the r-pi, or doing something stupid

« on: August 30, 2023, 06:16:00 pm »

Ok, it's been a while since I used SFML and I'd forgotten they were double-buffered

The actual use-case here is to implement a new version of the old GEM desktop / user interface for a retro project. The AES in GEM maintains a dirty-rect list, so the plan was to have an off-screen texture which persists the areas that don't need to be redrawn, and then just copy that offscreen texture to the window to "render the UI".

I've seen all the repeated warnings about making sure to clear the RenderWindow, which doesn't mesh well with a "only redraw this bit", so wasn't planning on drawing directly into the window itself. The code is just a quick-and-dirty test to see if assumptions held...

I still think something is off here, though. Files are too big to attach, so I put up a video of the Mac running the code above and it did pretty much what I expect.

Here is the same code (with the rs.setFillColor() call commented out to make things clearer) running on the Pi. I only get a small number of rectangles before it's somehow reset (and I don't see how that can happen). It's as if it is drawing rectangles to the screen, not the backing texture and every now and then putting the backing texture to the screen as well (thus resetting the rectangles shown).

4

Graphics / Maybe found a bug on the r-pi, or doing something stupid

« on: August 30, 2023, 06:59:58 am »

I'm trying to figure out if the raspberry Pi has the GPU to run an application at 1080p, and I started off just setting up a 1080x1920 texture (my monitor is rotated and drawing it. All well and good - takes about 9ms, which is glacial in desktop terms but perfectly adequate for my purposes.

Then I tried setting up a background texture - with the idea that in the real world, I'd update just parts of the background texture as they change, and then blit the background to the window. Figures were still good, but I wasn't seeing the effect I was expecting on the raspberry Pi. Here's the code:

#include <SFML/Graphics.hpp>

int main()
{
    // Create the main window
    sf::RenderWindow window(sf::VideoMode(1080, 1920), "SFML window");
    // Load a sprite to display
    sf::Texture texture;
    if (!texture.loadFromFile("/users/simon/Downloads/bg.jpg"))
        return EXIT_FAILURE;
    sf::Sprite sprite(texture);

        sf::RenderTexture backing;
        if (!backing.create(1080,1920))
                return EXIT_FAILURE;
               
        backing.draw(sprite);
       
        sf::Clock cron;
        int msecs = 0;
        int frames = 0;
       
    // Start the game loop
    while (window.isOpen())
    {
                msecs += cron.restart().asMilliseconds();
       
        // Process events
        sf::Event event;
        while (window.pollEvent(event))
        {
            // Close window: exit
            if (event.type == sf::Event::Closed)
                window.close();
        }
       
        int w = random() % 320 + 320;
        int h = random() % 200 + 200;
        int x = random() % (1080-w);
        int y = random() % (1920-h);
       
        sf::RectangleShape rs(sf::Vector2f(w,h));
        rs.setPosition(sf::Vector2f(x,y));
        rs.setOutlineColor(sf::Color(255, 0, 0, 255));
        rs.setFillColor(sf::Color(0,0,0,0));
        rs.setOutlineThickness(1);
               
                backing.draw(rs);
                backing.display();
       
                const sf::Texture& backingTexture = backing.getTexture();
                sf::Sprite BG(backingTexture);

        // Clear screen
        window.clear();
       
        // Draw the backing-texture sprite
        window.draw(BG);
       
        // Update the window
        window.display();
       
        // Aggregate/calculate frame rate
        frames ++;
        if (frames == 100)
                {
                fprintf(stderr, "Frame time: %d.%02d msecs = %5.3f fps\n", msecs/100, msecs%100, (100000.0f/msecs));
                frames = 0;
                msecs = 0;
                }
    }
    return EXIT_SUCCESS;
}
 

... and since I'm not clearing the background texture at all, I'd expect this to steadily turn red as time went by. On the Mac, this is what happens. On the Pi, I only ever see about 50 (?) rectangles drawn (this is more obvious when you remove the setFillColor() call) - and they're frequently the same rectangles as well...

It's not just a crappy random number generator on the Pi because there's a flickering effect as rectangles are drawn then erased then redrawn ad infinitum. What I'm seeing would be what you expect if

(a) there was a call to srandom() at the start of every render loop.   
(b) the backing texture was being cleared at the start of every render loop

So am I "holding this wrong" or is this a bug ?

FYI: this is self-compiled SFML 2.6.0 on an up-to-date r-pi bullseye...

@raspberrypi:~/src/SFML-2.6.0 $ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
 

... (without DRM, which I couldn't get to work, it just complained about permissions whenever I ran a compiled app), and without warnings=errors (because there's a few of those regarding tests being the same on both branches with gcc10, as well as the occasional type mismatch between variable and method/function signature)

5

Graphics / Re: Simple ? question about handling multiple textures

« on: December 02, 2021, 02:41:22 am »

So I got this working in the end by changing the code around a bit. I now render a section of the global mask to an intermediate RenderTexture of the same size as the scaled-down texture.

There aren't any calculations to do wrt locating the global co-ordinate space in that instance, so it's relatively straightforward to get my global mask to tile correctly with the shrunk-down textures - at least once I'd figured out that the default render-state setting was add-alpha...

So now, with a shrunk-down texture I can render a global mask, and it looks like the attached I'm still a little curious as to where I was going wrong, but at least it's not a blocker any more

6

Graphics / Simple ? question about handling multiple textures

« on: December 02, 2021, 12:27:16 am »

I have a much-larger-than-the-screen map, on which is being tiled many layers of individually scaled textures. So for one of these scaled textures, it looks a little like the below (where the textures are actually drawn next to each other in the map, but that looks odd in ascii

┌──────────────────────────┐                                  
│                          │                                  
│                          │                                  
│      Map-sized mask      │─┐                                
│                          │ │                                
│                          │ │                                
└──────────────────────────┘ │                                
                             │                                
                             │     ┌──────────────────────────┐
┌───────────┐       Scaled   │     │┌ ─ ─   ┌ ─ ─    ┌ ─ ─    │
│           │      Texture   │     │     │       │        │   │
│Texture at │       ┌────┐   │     ││       │        │        │
│ full size │ ────▶ │    │ ──┴─▶   │ ─ ─ ┘   ─ ─ ┘    ─ ─ ┘   │
│           │       │    │         │           Map            │
└───────────┘       └────┘         └──────────────────────────┘                              
 

So I was reading up on how shaders work, since they're new to me. It seems I need two sets of co-ordinate space (one for the global mask, one for the scaled-down texture), so I'm passing in enough uniforms to work that out.

The shader code looks like:

uniform sampler2D texture;              // Scaled-down texture to tile over the map
uniform sampler2D mask;                 // Map-sized global mask
uniform float maskX;                    // x pixel of where to pull the mask data from
uniform float maskY;                    // y pixel of where to pull the mask data from
uniform float maskW;                    // total mask width in pixels
uniform float maskH;                    // total mask height in pixels
uniform float scaledW;                  // width of the scaled-down texture in pixels
uniform float scaledH;                  // height of the scaled-down texture in pixels

void main()
        {
        // lookup the pixel in the mask texture
        float mx        = maskX / maskW + gl_TexCoord[0].x * scaledW / maskW;
        float my        = maskY / maskH + gl_TexCoord[0].y * scaledH / maskH;
        vec4 maskPixel  = texture2D(mask, vec2(mx, my));
       
        // lookup the pixel in the drawing texture
        vec4 pixel = texture2D(texture, gl_TexCoord[0].xy);

        // set it to scaled:rgb, mask:alpha
        gl_FragColor = vec4(pixel.rgb, maskPixel.a);
        }
 

.. and the drawing code looks like:

        sf::Sprite scaledSprite;
        scaledSprite.setTexture(_scaled->getTexture());
       
        int x = 0;
        int y = 0;
        int w = scaledW;
        int h = scaledH;

        while (y < maskH)
                {
                h = (y + scaledH > maskH) ? maskH - y : scaledH;
                while (x < maskW)
                        {
                        w = (x + scaledW > maskW) ? maskW - x : scaledH;
                       
                        scaledSprite.setPosition(x, y);
                       
                        sf::Shader *shader = [[Shaders sharedInstance] paintWithMaskShader];
                        shader->setUniform("texture", sf::Shader::CurrentTexture);
                        shader->setUniform("mask", _mask->getTexture());
                        shader->setUniform("maskX", x);
                        shader->setUniform("maskY", y);
                        shader->setUniform("maskW", maskW);
                        shader->setUniform("maskH", maskH);
                        shader->setUniform("scaledW", scaledW);
                        shader->setUniform("scaledH", scaledH);
                        _result->draw(scaledSprite, shader);
                        x += w;
                        }
                x = 0;
                y += h;
                }
 

So basically just iterating over the map-sized RenderTexture '_result', using the shader to tile the scaled-down version of a texture, modulated by the corresponding area in the map-sized mask. the problem is that I'm not seeing the alpha value (supposed to come from the mask) work correctly, it's always the same value across the image.

I created a mask texture by calling clear(0,0,0,64) and then drawing a filled circle at (70,70) with colour (255,255,255,255). If I dump that texture to a file, it looks totally reasonable (see attached, scaled down) so when I apply it, I'd expect a circle of the drawn texture to be brighter than the surrounds, but they're all being set to alpha 0.25 (and if I change the (0,0,0,64) color to (0,0,0,128) it's drawn at intensity 0.5)

So, the shader is providing data, the texture is there, but it's not mapping in the correct alpha co-ordinates. I thought the texture co-ords were supposed to range from 0...1, so the calculation for the mask co-ords (based on the scaled-down texture being drawn) is:

• Figure out the offset in the global map (mx = maskX / maskW) in 0...1 co-ords
• Take the fraction across the scaled image, and multiply by the ratio (scaledWidth / maskWidth)
• Add them together

The idea was to get 0...1 co-ords in the mask texture, but clearly I'm not doing that. Does anyone have any idea what I'm doing wrong ?

7

Graphics / Re: Is it possible to get a ::renderTarget to point to a section of a window ?

« on: November 28, 2021, 04:03:09 am »

Thanks  I'll maybe give it a go once I've got past this next bit. Redoing the render-pipeline at the moment...

8

Graphics / Is it possible to get a ::renderTarget to point to a section of a window ?

« on: November 26, 2021, 01:26:18 am »

So basically I'm trying to have my cake and eat it. I'm putting together a dev-tool (on OSX) for creating maps, and I want SFML for the texture-brushing and so on - all the heavy lifting...

BUT I want a fairly complex UI for the configuration of the options for each of the layers - masks, tables, nested outline views etc. So I'm currently using it by setting up an SFML window, and then just creating another NSWindow, into which I can put my UI stuff. So far so good.

What would be *great* though, is if I could have an NSView rather than an NSWindow as the base render target. Then I could have one window, and I wouldn't "lose" a click when mousing from config-window to render-window.

One way I've though of doing it is to grab the native window handle, then add another view to its contentView and use that NSView as the base for my UI. Maybe that's the best way to go, but before I dive in, I wanted to make sure I hadn't missed some "handle" that was available or anything like that. I'm also a bit concerned that performance might drop if the window is "mixed use" like this, but maybe that's not going to be a problem.

Any info gratefully received

9

Graphics / glGenVertexArrays on the Mac

« on: September 12, 2020, 12:53:02 am »

Not sure if this is an SFML thing or not, but on the Mac I needed to alter <SFML/OpenGL.hpp> to read as

#elif defined(SFML_SYSTEM_MACOS)

    #include <OpenGL/gl3.h>
 

... note the 'gl3.h' part, not the original 'gl.h'. Without this, Xcode won't find glGenVertexArrays() it gives instead:

Use of undeclared identifier 'glGenVertexArrays'; did you mean 'glGenVertexArraysAPPLE'?
 

This is using the SFML install from homebrew (2.5.1)


[edit: never mind. I hadn't realized that GLEW was pretty much essential for the extensions etc., and GLEW wants to include <OpenGL/gl.h>, and it's not a good idea to include both...

So, once GLEW is included and init'd, the call to glGenVertexArrays works fine.

I tried to delete this post, but I can't, hence the edit]

10

DotNet / Re: Xamarin mono crashing on exit with SFML

« on: April 05, 2016, 07:19:26 am »

Yes.

So I had a bit of trouble with this, but finally figured it out. I've used 64-bit mode for what seems like forever on the Mac, but mono is apparently compiled to be 32-bit as shipped from Xamarin, so it needs 32-bit shared libraries, and by default cmake compiles the 64-bit ones.

Once I'd set CMAKE_OSX_ARCHITECTURES to 'i386' and re-run cmake, run make, and done the remove-the-rpath step, it all actually works - I can now launch the test app, the red window comes up, and mono doesn't crash on exit. Looks as though the top-of-tree version has fixed whatever ails the 3.2 download

Now to see if my own C++ code ports over well. If so, managed runtime here I come

11

DotNet / Re: Xamarin mono crashing on exit with SFML

« on: April 03, 2016, 11:46:41 pm »

Also, you're using CSFML 2.3.0 and SFML 2.3.2. Try not mixing versions.

And since I see in your stack trace this

9   libsfml-window.2.3.2.dylib      0x01999a42 sf::priv::SFContext::~SFContext()

try SFML's master version. Some stuff were fixed regarding multithreading memory management on OS X.

I guess I just took the latest version of everything. By "master version", do you mean the latest code from the SFML github at https://github.com/SFML/SFML ?

Cheers
   Simon

12

DotNet / Re: AW: Xamarin mono crashing on exit with SFML

« on: April 03, 2016, 11:43:24 pm »

And what's your code?

It's the code from the tutorial I linked to ...

using System;
using SFML;
using SFML.Graphics;
using SFML.Window;

namespace TestSFML
{
    class MainClass
    {
        private static RenderWindow _window;

        public static void Main(string[] args)
        {
            _window = new RenderWindow(new VideoMode(800, 600), "SFML window");
            _window.SetVisible(true);
            _window.Closed += new EventHandler(OnClosed);
            while (_window.IsOpen)
            {
                _window.DispatchEvents();
                _window.Clear(Color.Red);
                _window.Display();
            }
        }

        private static void OnClosed(object sender, EventArgs e)
        {
            _window.Close();
        }
    }
}
 

13

DotNet / Xamarin mono crashing on exit with SFML

« on: April 03, 2016, 12:03:46 am »

Hi there,

So I followed the tutorial posted in this forum for setting up OSX to use mono and the SFML bindings, and it works fine until I quit the app, at which point mono crashes. Is anyone else seeing this ?

This is what I see in the console when the red window is up:

[atlantis:test2/bin/Debug] simon% mono test2.exe
Mono: DllImport attempting to load: 'libcsfml-graphics.2.3.0.dylib'.
Mono: DllImport loaded library '/Volumes/home/simon/src/c#/test2/test2/bin/Debug/libcsfml-graphics.2.3.0.dylib'.
Mono: DllImport searching in: 'libcsfml-graphics.2.3.0.dylib' ('/Volumes/home/simon/src/c#/test2/test2/bin/Debug/libcsfml-graphics.2.3.0.dylib').
Mono: Searching for 'sfRenderWindow_clear'.
Mono: Probing 'sfRenderWindow_clear'.
Mono: Found as 'sfRenderWindow_clear'.
Mono: DllImport searching in: 'libcsfml-graphics.2.3.0.dylib' ('/Volumes/home/simon/src/c#/test2/test2/bin/Debug/libcsfml-graphics.2.3.0.dylib').
Mono: Searching for 'sfRenderWindow_createUnicode'.
Mono: Probing 'sfRenderWindow_createUnicode'.
Mono: Found as 'sfRenderWindow_createUnicode'.
Warning: The created OpenGL context does not fully meet the settings that were requested
Requested: version = 2.0 ; depth bits = 0 ; stencil bits = 0 ; AA level = 0 ; core = false ; debug = false
Created: version = 2.1 ; depth bits = 0 ; stencil bits = 0 ; AA level = 0 ; core = false ; debug = false
Mono: DllImport searching in: 'libcsfml-graphics.2.3.0.dylib' ('/Volumes/home/simon/src/c#/test2/test2/bin/Debug/libcsfml-graphics.2.3.0.dylib').
Mono: Searching for 'sfRenderWindow_getDefaultView'.
Mono: Probing 'sfRenderWindow_getDefaultView'.
Mono: Found as 'sfRenderWindow_getDefaultView'.
Mono: DllImport searching in: 'libcsfml-graphics.2.3.0.dylib' ('/Volumes/home/simon/src/c#/test2/test2/bin/Debug/libcsfml-graphics.2.3.0.dylib').
Mono: Searching for 'sfRenderWindow_setVisible'.
Mono: Probing 'sfRenderWindow_setVisible'.
Mono: Found as 'sfRenderWindow_setVisible'.
Mono: DllImport searching in: 'libcsfml-graphics.2.3.0.dylib' ('/Volumes/home/simon/src/c#/test2/test2/bin/Debug/libcsfml-graphics.2.3.0.dylib').
Mono: Searching for 'sfRenderWindow_isOpen'.
Mono: Probing 'sfRenderWindow_isOpen'.
Mono: Found as 'sfRenderWindow_isOpen'.
Mono: DllImport searching in: 'libcsfml-graphics.2.3.0.dylib' ('/Volumes/home/simon/src/c#/test2/test2/bin/Debug/libcsfml-graphics.2.3.0.dylib').
Mono: Searching for 'sfRenderWindow_pollEvent'.
Mono: Probing 'sfRenderWindow_pollEvent'.
Mono: Found as 'sfRenderWindow_pollEvent'.
Mono: DllImport searching in: 'libcsfml-graphics.2.3.0.dylib' ('/Volumes/home/simon/src/c#/test2/test2/bin/Debug/libcsfml-graphics.2.3.0.dylib').
Mono: Searching for 'sfRenderWindow_display'.
Mono: Probing 'sfRenderWindow_display'.
Mono: Found as 'sfRenderWindow_display'.
 

and as soon as I click on the window-close button, I see:

Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) SFML.Graphics.RenderWindow.sfRenderWindow_destroy (intptr) <0xffffffff>
  at SFML.Graphics.RenderWindow.Destroy (bool) <0x00013>
  at SFML.ObjectBase.Dispose (bool) <0x00036>
  at SFML.ObjectBase.Finalize () <0x0001b>
  at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:


Debug info from gdb:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/__init__.py", line 98, in <module>
    import six
ImportError: No module named six
(lldb) command source -s 0 '/tmp/mono-gdb-commands.kELe7C'
Executing commands in '/tmp/mono-gdb-commands.kELe7C'.
(lldb) process attach --pid 44924
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
[repeats many many times]

Eventually, mono posts a crash-screen asking me if I want to report the bug.

Process:               mono-sgen [44965]
Path:                  /Library/Frameworks/Mono.framework/Versions/4.2.3/bin/mono
Identifier:            mono-sgen
Version:               ???
Code Type:             X86 (Native)
Parent Process:        tcsh [44961]
Responsible:           Terminal [2373]
User ID:               501

Date/Time:             2016-04-02 15:02:01.231 -0700
OS Version:            Mac OS X 10.11.4 (15E65)
Report Version:        11
Anonymous UUID:        50D2B39F-C928-3EF5-AF31-B6669F6D0248


Time Awake Since Boot: 330000 seconds

System Integrity Protection: disabled

Crashed Thread:        2

Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
-->
    __TEXT                 000000000003c000-0000000000359000 [ 3188K] r-x/rwx SM=COW  /Library/Frameworks/Mono.framework/Versions/4.2.3/bin/mono-sgen

Application Specific Information:
abort() called

Thread 0:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib              0x9ba893ea __psynch_cvwait + 10
1   libsystem_pthread.dylib             0x93e8b538 _pthread_cond_wait + 757
2   libsystem_pthread.dylib             0x93e8ed0b pthread_cond_timedwait$UNIX2003 + 71
3   mono                                0x0028f3a7 mono_cond_timedwait_ms + 135 (mono-mutex.c:181)
4   mono                                0x0020ef64 mono_gc_cleanup + 180 (gc.c:1234)
5   mono                                0x00206990 mono_runtime_cleanup + 16 (appdomain.c:362)
6   mono                                0x0004c552 mini_cleanup + 786 (mini-runtime.c:3461)
7   mono                                0x000c6f41 mono_main + 8001 (driver.c:2086)
8   mono                                0x0003ea80 main + 768 (.main.c:125)
9   mono                                0x0003e775 start + 53

Thread 1:
0   libsystem_kernel.dylib              0x9ba893ea __psynch_cvwait + 10
1   libsystem_pthread.dylib             0x93e8b538 _pthread_cond_wait + 757
2   libsystem_pthread.dylib             0x93e8d276 pthread_cond_wait$UNIX2003 + 71
3   mono                                0x0026f7d2 thread_func + 466 (sgen-thread-pool.c:118)
4   libsystem_pthread.dylib             0x93e8a780 _pthread_body + 138
5   libsystem_pthread.dylib             0x93e8a6f6 _pthread_start + 155
6   libsystem_pthread.dylib             0x93e87f7a thread_start + 34

Thread 2 Crashed:
0   libsystem_kernel.dylib              0x9ba89572 __pthread_kill + 10
1   libsystem_pthread.dylib             0x93e8d654 pthread_kill + 101
2   libsystem_c.dylib                   0x9a87dc34 abort + 156
3   mono                                0x000fbfe5 mono_handle_native_sigsegv + 757
4   mono                                0x00148462 mono_arch_handle_altstack_exception + 162 (exceptions-x86.c:1097)
5   mono                                0x0004933e mono_sigsegv_signal_handler + 446 (mini-runtime.c:2489)
6   libsystem_platform.dylib            0x927e679b _sigtramp + 43
7   ???                                 0xffffffff 0 + 4294967295
8   mono                                0x00049180 mono_sigill_signal_handler + 48 (mini-runtime.c:2398)
9   libsfml-window.2.3.2.dylib          0x01999a42 sf::priv::SFContext::~SFContext() + 114
10  libsfml-window.2.3.2.dylib          0x0198d208 sf::priv::GlContext::globalCleanup() + 56
11  libsfml-window.2.3.2.dylib          0x0198e5d0 sf::GlResource::~GlResource() + 48
12  libcsfml-graphics.2.3.0.dylib       0x007d7d17 sfRenderWindow_destroy + 23
13  ???                                 0x006f431c 0 + 7291676
14  ???                                 0x006f4248 0 + 7291464
15  ???                                 0x006f4188 0 + 7291272
16  ???                                 0x006f40bc 0 + 7291068
17  ???                                 0x006f3ebe 0 + 7290558
18  mono                                0x0020db1a mono_gc_run_finalize + 810 (gc.c:240)
19  mono                                0x0020f4d2 finalizer_thread + 370 (gc.c:1118)
20  mono                                0x001e9441 start_wrapper + 545 (threads.c:725)
21  mono                                0x00299e60 inner_start_thread + 240 (mono-threads-posix.c:97)
22  libsystem_pthread.dylib             0x93e8a780 _pthread_body + 138
23  libsystem_pthread.dylib             0x93e8a6f6 _pthread_start + 155
24  libsystem_pthread.dylib             0x93e87f7a thread_start + 34

Thread 3:
0   libsystem_kernel.dylib              0x9ba89d5e __workq_kernreturn + 10
1   libsystem_pthread.dylib             0x93e8a34b _pthread_wqthread + 1289
2   libsystem_pthread.dylib             0x93e87f56 start_wqthread + 34

Thread 4:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib              0x9ba8a7fa kevent_qos + 10
1   libdispatch.dylib                   0x927427ea _dispatch_mgr_invoke + 234
2   libdispatch.dylib                   0x927423be _dispatch_mgr_thread + 52

Thread 5:: OGL Profiler
0   libsystem_kernel.dylib              0x9ba8249a mach_msg_trap + 10
1   libsystem_kernel.dylib              0x9ba81884 mach_msg + 68
2   com.apple.opengl                    0x9ba91995 glcDebugListener + 434
3   libsystem_pthread.dylib             0x93e8a780 _pthread_body + 138
4   libsystem_pthread.dylib             0x93e8a6f6 _pthread_start + 155
5   libsystem_pthread.dylib             0x93e87f7a thread_start + 34

Thread 6:
0   libsystem_kernel.dylib              0x9ba89d5e __workq_kernreturn + 10
1   libsystem_pthread.dylib             0x93e8a34b _pthread_wqthread + 1289
2   libsystem_pthread.dylib             0x93e87f56 start_wqthread + 34

Thread 7:
0   libsystem_kernel.dylib              0x9ba89d5e __workq_kernreturn + 10
1   libsystem_pthread.dylib             0x93e8a34b _pthread_wqthread + 1289
2   libsystem_pthread.dylib             0x93e87f56 start_wqthread + 34

Thread 8:
0   libsystem_kernel.dylib              0x9ba89d5e __workq_kernreturn + 10
1   libsystem_pthread.dylib             0x93e8a34b _pthread_wqthread + 1289
2   libsystem_pthread.dylib             0x93e87f56 start_wqthread + 34

Thread 9:

Thread 10:: com.apple.NSEventThread
0   libsystem_kernel.dylib              0x9ba8249a mach_msg_trap + 10
1   libsystem_kernel.dylib              0x9ba81884 mach_msg + 68
2   com.apple.CoreFoundation            0x98075dc6 __CFRunLoopServiceMachPort + 214
3   com.apple.CoreFoundation            0x980751d1 __CFRunLoopRun + 1521
4   com.apple.CoreFoundation            0x98074976 CFRunLoopRunSpecific + 390
5   com.apple.CoreFoundation            0x980747db CFRunLoopRunInMode + 123
6   com.apple.AppKit                    0x9898ef76 _NSEventThread + 291
7   libsystem_pthread.dylib             0x93e8a780 _pthread_body + 138
8   libsystem_pthread.dylib             0x93e8a6f6 _pthread_start + 155
9   libsystem_pthread.dylib             0x93e87f7a thread_start + 34

Thread 2 crashed with X86 Thread State (32-bit):
  eax: 0x00000000  ebx: 0xa3f406b0  ecx: 0x007af70c  edx: 0x00000000
  edi: 0xb0183000  esi: 0x00000006  ebp: 0x007af728  esp: 0x007af70c
   ss: 0x00000023  efl: 0x00000206  eip: 0x9ba89572   cs: 0x0000000b
   ds: 0x00000023   es: 0x00000023   fs: 0x00000000   gs: 0x0000000f
  cr2: 0xb05a3058
 
Logical CPU:     0
Error Code:      0x00080148
Trap Number:     132

 

It's 100% reproducible for me, just wanted to see if anyone had a workaround or if it's only happening for me...

14

Graphics / Re: Flipped RenderTextures

« on: February 20, 2016, 03:16:25 am »

Do you call sf::RenderTexture::display()?

Well, if you're going to go and point out perfectly reasonable and logical things to do, that actually *fix* the problem, I'm going to look pretty stupid

Seriously, thanks. Works as expected now

Simon.

15

Graphics / Flipped RenderTextures

« on: February 19, 2016, 07:33:50 am »

Hi,

So I'm trying to do a fair number of renders into various buffers to get my fog-of-war working, along the lines of:

 + load texture BG @ 7680,4320, RGBA
 + load sprite V with vision-fog @ 512,512, RGBA. See attachment for what this looks like.
 + create 'screen' renderTexture S @ 1920,1080 RGBA
 + create 'copy' renderTexture C @ 512,512, RGBA
   
// Copy the current background map to an offscreen render-texture
 + create sprite from BG call it sBG
 + set texture rect of sBG to be (x,y,1920,1080)
 * draw sBG to S

// Render a mask (V) into the alpha-component of the 'screen' texture, and also render a capped-to-0x80
// version of the mask into the actual map of the area. That way we permanently know where we've been
// with the "shaded area" being explored-but-not-visible, and the "bright area" being currently-visible.
- [n times]
   + copy area of S around player [pc.x, pc.y, 512, 512] to C
   - render V into S @ (pc.x,pc.y,512,512)
      - use shader: resulting alpha must be MAX (V.a,C.a), resulting RGB = C.rgb
   - render V into BG @ (pc.x,pc.y,512,512)
      - use shader: resulting alpha must be MAX (V.a,C.a,0x80), resulting RGB = C.rgb

 + finally render S to screen.

The '-' bits I still have to do, the '+' bits I've done, and the '*' bit is drawing inverted! My fingers are twitching with the desire to just scrap this and do it in OpenCL instead, but it seems to me that OpenGL ought to be faster at drawing images, so I'm still here... Any clues why it's inverted, anyone ? As far as I can tell, I'm not setting any matrix on the render-texture or its sprite...

Should I be calling move(0,1)/scale(1,-1) on the sprite ? Are those co-ordinates in normalised space or measured in pixels ?

Cheers