Messages

1

Python / Respecting naming conventions & other possible changes

« on: September 17, 2010, 09:56:42 am »

Got it.

But if you go even lower, why would people keep using the graphics module of SFML instead of OpenGL or DirectX directly?

2

Python / Respecting naming conventions & other possible changes

« on: September 17, 2010, 09:02:31 am »

Yes, I agree, it's very specific
Please just see these remarks as my personal opinion, and as a brainstorming for future API changes.

If you feel like "Gee, this guy must be lazy, it's just one more line of code",
then my answer is: I've been spoiled by the Python way of coding

Saves efforts for the API user
In the Python modules, classes are often designed so that there is a shortcut for the most common use cases. (Of course there must be a balance, otherwise the API will be cluttered.)

As an example, the unittest module in Python has shortcuts for many assertions that could be done with a regular assertTrue, like assertGreater, assertIn, assertIsNone etc...

In the end, all those small bits add up, and the programmer really feels at home, not having to write the same bits everywhere.

Readability
It also helps code readability, which as we all know as programmers, is very important.

For example, if we compare these two lines that do the same thing:

Code: [Select]


sprite.SetCenter(spriteSize[0]/2, spriteSize[1]/2)
sprite.centerAtMiddle()

notice the huge saving in readability on the second line(!)
and this is out of context, therefore still easy to read, but when deep inside hundreds of lines of code, the difference becomes really noticeable, it feels almost like you're reading pseudo-code.

Again, this is just my humble opinion.
I'm already very pleased with the current state of SFML

I'll use it for my next game.

3

Python / Respecting naming conventions & other possible changes

« on: September 17, 2010, 12:44:55 am »

Thanks Laurent for your quick answer, I'm glad you've already taken those into consideration.

One more point that could be improved.

Allow centering of a Drawable (Sprite and String) around its position with a single instruction
We shouldn't write

Code: [Select]


spriteSize = sprite.GetSize()
sprite.SetCenter(spriteSize[0]/2, spriteSize[1]/2)

but something like

Code: [Select]


sprite.centerAtMiddle()

or even better, we could have acces to the middle of the Drawable at all time, automatically updated when resized.

Code: [Select]


# let's say our sprite is 30x20 pixels

# output (0,0), default center at top left corner
print sprite.center

# output (15,10)
print sprite.middle

# center sprite around its middle
sprite.center = sprite.middle


4

Python / Respecting naming conventions & other possible changes

« on: September 16, 2010, 05:45:20 am »

May I add my personal feelings about PySFML, after having used it for about 20 minutes.

So this is the point of view of a complete beginner with PySFML, but with good knowledge (not expert) in Python, and with a PyGame background.

Note: this is from a user point of view, I realize any of these may be hard / impossible to implement, or would need an update of the underlying C++ layer.

Also my goal is not to offend anyone, I find SFML and PySFML very easy to use, and efficient at the same time.
It's just, I feel that with a bit more love and polish on the Python side, PySFML could be even easier and Python friendly.

Use python naming convention.
For example use capitals for class names only,
we shouldn't write

Code: [Select]


sprite.SetPosition(10,10)

but

Code: [Select]


sprite.setPosition(10,10)
# or
sprite.setposition(10,10)
# or
sprite.set_position(10,10)



Don't use method calls for setting / getting simple attributes, use direct access.
For example, we shouldn't write

Code: [Select]


positionVariable = sprite.GetPosition(10,10)
sprite.SetPosition(10,10)

but

Code: [Select]


# get position
positionVariable = sprite.position
# set position
sprite.position = (10,10)
sprite.position.x = 20


Use tuples instead of classes that are used as simple data holders  without methods, like the Color class.
For example, we shouldn't write

Code: [Select]


window.Clear(sf.Color(100,100,100,255))

but

Code: [Select]


window.Clear((100,100,100,255))


Simpler module import.
As already pointed above, we shouldn't write

Code: [Select]


from PySFML import sf

but

Code: [Select]


import sf


Don't force us to create empty objects, just as placeholders; instead return them directly, ready to use.
For example, we shouldn't write

Code: [Select]


event = sf.Event()
while window.GetEvent(event):

but

Code: [Select]


for event in window.GetEvent():


As already pointed above, we shouldn't write

Code: [Select]


image = sf.Image()
image.LoadFromFile("imageFile.png")

but

Code: [Select]


image = sf.Image("imageFile.png")


Allow negative sprite scaling instead of the flip method
For example, we shouldn't write

Code: [Select]


sprite.FlipX(True)

but

Code: [Select]


sprite.SetScale(-1,1)
# ideally
sprite.scale.x = -1
# or
sprite.scale = (-1,1)


I will add more when I'll be more familiar with the rest of the API.

5

General / [solved] Corrupted download on SF

« on: September 15, 2010, 11:49:21 pm »

Thanks, it works now.
I was trying with gzip....

6

General / [solved] Corrupted download on SF

« on: September 15, 2010, 02:29:17 am »

Hi,

everytime I download
SFML-1.6-sdk-linux-32.tar.gz (http://sourceforge.net/projects/sfml/files/sfml/1.6/SFML-1.6-sdk-linux-32.tar.gz/download)

I got a corrupted file I can't extract.
The file I get is 12.3MB, but it should be 12.9MB ...
I used Firefox, then DownThemAll, several times: same thing.

Could someone else try if the problem is just with me or not?
Thx.