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 - SpacedCowboy

Pages: [1]
1
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)

2
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 ?

3
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 :)

4
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]

5
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...

6
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

7
Graphics / Newbie GLSL question
« on: February 10, 2016, 07:37:50 pm »
Hi :)

So, I'm trying to do a fog-of-war effect using GLSL shaders, and wanted some input on the best way to do it in SFML. Here's what I think I'll need:
  • Start off with a background texture of size (X,Y), alpha=0 across all pixels. Call this BG
  • Have a what-the-pc-can-see texture of size (512,512) where alpha values are 255 (= full alpha) at the center, going outwards in a circle for a bit, then tailing off to alpha=0, call this V for visible

Basic approach is to write a GLSL shader that renders the visible section of BG to the screen, where the pixel value at screen co-ords (x,y) has its alpha set to
  • if (x,y) is outside the range of V, the current {r,g,b,a} of BG(x,y)
  • if (x,y) is inside the range of V, the {r,g,b} of BG(x,y) and the max alpha of {V(x,y), BG(x,y)}

 - I also want to have any previously-visited map pixels at alpha= (say)0.5, so I was planning on subsequently rendering back into BG, vis:
  • if (x,y) is outside the range of V, the current {r,g,b,a} of BG(x,y)
  • if (x,y) is inside the range of V, the {r,g,b} of BG(x,y) and the max alpha of {0.5, V(x,y)}

... which ought to mean as I move the PC away, the residual alpha remains in BG, up to a max value of 0.5 (this is arbitrary), so if I move far enough away, it'll be outside of the domain of V, but still somewhat visible - so the player can "remember" where they've been but it also indicates it's not being actively updated.

Now BG is going to be pretty big (say 7680 x 4320), so I don't want to be running this subsequent stage over all of BG every frame if I can help it. Is there a way to render a GLSL program only over a section of the target texture ? Does setting the view do this ?

Also, I'll be using BG as both source and destination - I'm guessing this is ok because you can create an sf::Sprite out of either an sf::RenderTexture or an sf::Texture, and the shader parameters take *sprite.getTexture() as their texture arguments. It'll be two separate renders (one for the background including the alpha > 0.5 values, and one to render the clip-at-0.5 alpha back into BG).
 
If anyone has any better ideas of how to do it, I'm all ears :)

Cheers
   Simon

Pages: [1]
anything