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

Pages: [1]
1
Graphics / RenderTexture and Multi-monitor setups.
« on: August 28, 2011, 10:55:17 pm »
Quote from: "Laurent"
SFML doesn't handle multi-monitors at the moment, so maybe it is an issue with the Linux drivers. I'm pretty sure that the same program would work on Windows.


It's possible - I'll try running the test under windows when I get the chance. That said, this is the only thing I've found that doesn't work under my multi-monitor setup, other video players, games and stuff work fine.

2
Graphics / RenderTexture and Multi-monitor setups.
« on: August 28, 2011, 01:27:47 pm »
Quote from: "Groogy"
You are aware you create the render texture twice?

Anyway what happens if you do the render of the texture in the loop as well?


Ah, that was just a leftover from when I was checking that the bindings did the create automatically - they do, I checked the source in the end, it works with or without that bit, but only on the first monitor.

Rendering the texture in the loop doesn't do anything either - and if I did that, it'd kind of defy the point of using a RenderTexture.

If there is anything I can do to help isolate the issue, do let me know.

Just to show you quite how weird it is:

3
Graphics / RenderTexture and Multi-monitor setups.
« on: August 28, 2011, 02:59:21 am »
I'm using the PySFML2 bindings, but I'm pretty sure it's not an issue with the bindings.

I tried using a RenderTexture, and got no output where it was meant to be drawn. Wondering what the issue was I made a simple test script, which ran fine.

I then spent ages changing stuff around. After a lot of painful testing, I eventually went back to my test script to find out it had stopped working - despite nothing having changed.

I eventually worked out the only thing that had changed was what monitor I was using. I moved the window back to the first monitor, and it shows up fine.

Is this a bug that is fixable, or something due to my setup?

Code: [Select]
import sf


def main():
    window = sf.RenderWindow(sf.VideoMode(640, 480), b'Sprite example')
    window.framerate_limit = 60
    running = True
    image = sf.RenderTexture(300, 300)
    image.create(300, 300)
    sprite = sf.Sprite(image.texture)

    image.clear(sf.Color.BLACK)
    image.draw(sf.Shape.rectangle(10, 10, 100, 100, sf.Color.BLUE))
    image.display()

    while running:
        for event in window.iter_events():
            if event.type == sf.Event.CLOSED:
                running = False

        window.clear(sf.Color.WHITE)
        window.draw(sprite)
        window.display()
    window.close()


if __name__ == '__main__':
    main()


This shows the bug for me. On my leftmost monitor it works, the other two it doesn't. I run 3 monitors with two nVidia cards, nVidia proprietary driver, Arch Linux.

Weirdly, the device it works on is the same graphics card as the middle one, and the rightmost one is on the other card. It only works on the first. This leads me to think it's not an issue with my exact setup (the cards) and more the multi-monitor setup.[/quote]

4
Python / pysfml2-cython
« on: August 25, 2011, 05:26:09 pm »
Quote from: "bastien"
Ah, sorry. It should work now, except that it's set_texture().
I will change Sprite to keep a reference to the texture, and I will probably also change all classes where it's possible. I want to avoid problems if SFML changes the C++ object internally, but maybe I'm just paranoid. :?


Cheers for all the effort. It's entirely up to you if you want to keep the reference or not, I'd just reccomend adding a note to the docs if it doesn't, as it's not standard python behaviour, and not how the bindings used to work. It's not exactly hard to work around if you know it's there.

5
Python / pysfml2-cython
« on: August 22, 2011, 05:23:00 am »
Quote
File "sf.pyx", line 1773, in sf.Sprite.__cinit__ (sf.cpp:19704)
TypeError: Argument 'texture' has incorrect type (expected sf.Texture, got sf.Image)


Now getting this error with the updated bindings, both Linux and Windows.

Edit: I see this is an intentional change. Might want to update the docs.

I tried replacing:

Code: [Select]
self.sprite.set_image(image, True)

with:

Code: [Select]
self.sprite.texture = texture
self.sprite.resize(texture.width, texture.height)


But the resize does not appear to work.

(Just as I finish my Ludum Dare entry >.>)

Also, if you didn't see my last edit, I found it wasn't the order, but rather that the sprite doesn't act as a reference to the image. So you can't do sf.Sprite(sf.Image.load_from_file("blah.jpg")) as the image will not be kept in memory, which you could do in the 1.6 bindings.

Not a bug, but as I say, worth noting as it might catch people out.

6
Python / pysfml2-cython
« on: August 15, 2011, 08:31:13 pm »
Just as a note, I recently discovered you can't load images before the window is created, or the images show up as solid white instead of the image. Not sure if this is intentional or a bug, but it's not consistant with the old bindings, and I spend quite some time figuring out what the issue was, while porting across a project from the old bindings, so it might be worth noting this in the binding's docs.

Edit: I actually found out the problem was that if you let the images you load go out of scope, they will not be kept around by the sprite. So keep a reference to any images you want to use, besides the sprite.

7
Python / PySFML2 Cython Text under Python 3
« on: July 23, 2011, 03:59:19 pm »
Quote from: "bastien"
Thanks, it should work now.


Cheers for the quick fix!

The new bindings are a lot better, I can get rid of a lot of old code I had that was simply wrapping the old methods and stuff to make them more pythonic. It looks like it'll make the game a lot easier to work with in the long run.

8
Python / PySFML2 Cython Text under Python 3
« on: July 22, 2011, 11:42:00 pm »
I'm running PySFML2-Cython under Python 3, appears to work alright, I'm poriting across a project that was using the old library, and the Text class that replaces the old String class is causing trouble.

I try and pass it a python3 str (unicode) and I get this error:

self.text = sf.Text(value)

  File "sf.pyx", line 1591, in sf.Text.__cinit__ (sf.cpp:17293)
TypeError: expected bytes, str found

I was under the impression that the Text class should have supported unicode, unlike everything else, but I tried it the other way, encoding it to bytes:

self.text = sf.Text(bytes(value, "UTF-8"))

  File "sf.pyx", line 1614, in sf.Text.__cinit__ (sf.cpp:17503)
TypeError: Expected str or unicode for string, got <class 'bytes'>

Is this something stupid I'm missing, or a problem with the bindings?

9
Python / bug in Image.Copy ?
« on: December 31, 2010, 06:04:49 pm »
This is a problem I have had, whenever I use the sf.Image.Copy method the program crashes with a segfault. It's rather annoying to say the least.

Pages: [1]