Messages

1

SFML projects / Re: Sprite Sheet Manipulator

« on: May 26, 2016, 08:57:09 am »

By the way, I have bench marked opening the same sprite sheet on my computer using my program and another similar program. Using mine it took around 2 seconds and in the other one around 50 seconds. Someone knows if it's legal and ethical to mention which is the other program?

This has been puzzling me since before i posted my project here.

Edit: On second thought, it doesn't really matter. I'm just proud of the performance of my program and wanted to say that being fast is a feature. I have nothing but respect for the other program, since it tried to solve the same problem as mine. I had considered helping his project instead but i found out about it way too late, and after realizing of it's existence, i bench marked both programs and reached the conclusion it would be more fruitful to continue developing mine.

2

SFML projects / Re: Sprite Sheet Manipulator

« on: May 24, 2016, 01:24:58 am »

Sorry for the delay. This is my first released project, therefore it was very nerve-wrecking putting it online. I'm still waiting for someone to rip apart my code, and call me a dumbass.

About texture packing, i think you've misunderstood the purpose of the project. I could even go about writing something to pack the sprites together later, but the main goal was to do the opposite, unpacking them. Why? Because there are many sprite sheets out there without any clear pattern so using them would be extremely painful, and cutting them manually is just not worth the time-investment. With this program, you can remove the sprites into separate files so you can handle them better. I also intend to implement a button to generate a json/xml so that you may still use the sprite sheet without splitting.

Sorry if I've no smart solution or anything, this is just my own implementation on the flood fill algorithm to figure out sprites' boundaries.

3

SFML projects / Sprite Sheet Manipulator

« on: April 27, 2016, 11:30:31 pm »

Hello,

I have developed a program that detects sprites' boundaries inside a sprite sheet, and then splits them into separate files. This is particularly useful for fighting games' sprite sheets since they may have no clear pattern to how they are laid out.

It was done using SFML(of course) and TGUI. It currently only works on windows, but I intend to implement Linux support soon. It utilizes the GPL license.

The reason i've decided to do this is because i couldn't find anything like it at the time i needed this. Not too long ago though, I discovered there are other programs like mine in the internet. I've compared another free solution, and could see that mine has considerably better performance with faster loading times, so i guess there's still a reason to keep this project going.

Link to the github page: https://github.com/kharyus/Sprite-Sheet-Manipulator
If you want to download it, go to the releases tab. There are only the 64 bit binaries right now.

I hope people find this useful.

Screenshot:

4

Python / Re: SFML + GUI Issue

« on: August 14, 2015, 01:25:49 pm »

Managed to make it work. 

It's frustrating and embarassing , the solution was what i was trying to do, but in a way that actually works. I was trying to change the "_HandledWindow" by its size, height, width and view proprierties, passing coordinates, but what i was actually supposed to do is

_HandledWindow.view.size = (x,y)

Did not even need this in the end, just needed to use the solution below.

To make it work, every time that the window is resized, you must pass a new viewport to the sfml window so it knows it's new dimensions. This also fix the "growing upwards instead of downwards" problem.

# Main Frame
class MainFrame(QMainWindow):
    def __init__(self):
        QMainWindow.__init__(self)
        #The reason this is here is to avoid instanciating too many objects
        self.view = sf.View()

    def resizeEvent(self,resizeEvent):
        print("resized")
        #The line below makes the visible area expand/retract instead of zooming in/out
        self.view.reset(sf.Rectangle((0,0),(sfmlwidgetpointer.width(),sfmlwidget.height())))
        self.view.viewport = sf.Rectangle((0,0),(1,1))
        sfmlwidget._HandledWindow.view = self.view

mainframe = MainFrame()
...
sfmlwidget = SFMLCanvas(mainframe, position, size)
...

The problem was the programmer today, who could've known? Nobody.

5

Python / Re: SFML + GUI Issue

« on: August 03, 2015, 04:49:36 pm »

Hi Tank, thanks for taking the time to reply.

I'm currently getting these issues using PySFML 1.3.0, Windows 7 64-bit, Python 3.3, PyQt4.
Got those same issues before using SFML-2.1, Windows 7 64-bit, WxWidgets and also trying it on my Debian laptop.
I have tried to delete and recreate again the window on the resize event, the paintable area would then be the size of the new window but it was an awful solution with many other issues.

The main reason i'm trying to integrate a GUI with SFML is because i want a multi-platform file browser on that "Open File" button. I'd not mind switching to yet another GUI library if it has the feature i need and it works.

6

Python / SFML + GUI Issue

« on: July 30, 2015, 05:56:48 pm »

Hello.
I'm having trouble using SFML with PyQt. I assume this is not something specific to the integration with PyQt since i had the same problem when i was trying to use SFML + WxWidgets.

Basically the problem is that when i resize my 'SFML + GUI' window the paintable area does not follow the new dimensions and a part of the window just stays black. Another issue is that when i resize the window, it grows upwards instead of downwards.
http://www.tiikoni.com/tis/view/?id=ad30d78
http://www.tiikoni.com/tis/view/?id=ea4d499
(the koala is rotating)

I wanted to know if there are some flags i need to adjust, if anyone had this problem before, or if anyone has any lead towards the issue. Thanks for your time.

7

Python / PyQt4 + PySFML feedback

« on: July 17, 2015, 02:21:27 pm »

Hello. I have found a little problem in the PyQt4 example in PySFML and thought i'd share just in case. I do not know if this is the suited place so feel free to delete this.

In the PyQt example that can be found here there seems to be a minor issue in the initialization order of things.

# let the derived class do its specific stuff
        self.onInit()

Is inside def showEvent(self, event):, which caused the onUpdate method of the derived class to run once before the onInit step, which in turn caused some errors because things had not been initialized yet. In c++ this would be a bigger problem, but i still thought it was a bother having those errors showing so i found the solution. The onInit call must be inside the base class' constructor, i put mine after

self.__dict__['display'] = self._HandledWindow.display

and things started to run smoothly.

Since i'm already writing this, in the example it was still required for me to figure how to start the program on my own. I suggest that it would be interesting having some code like this available in the example so the user could have a running application from the start

# Main part
app = QApplication(sys.argv)

# Qt Frame
mainframe = QFrame()
mainframe.setWindowTitle("QtPySFML")
mainframe.resize(500, 500)
mainframe.show()

# QSFML Canvas
position = QPoint()
position.setX(0)
position.setY(0)
size = QSize()
size.setHeight(400)
size.setWidth(400)
# this SFMLCanvas class is the derived class that the user must create basing on QSFMLCanvas
sfmlwidget = SFMLCanvas(mainframe, position, size)
sfmlwidget .show()

sys.exit(app.exec_())

I'm not really used to giving feedback so i don't know if i'm being a bother, but thought i'd share this stuff.