Messages

1

Window / Re: SFML windowing system on Android, anyone?

« on: December 28, 2012, 10:22:16 pm »

Well stoke, huuuh... Maybe not, I'm not working on it at all right now.

You are speaking about tablet with 1 to several gig of ram, but what about smaller smartphones with 256/512mo ram, without speaking about the video memory not that huge? We need to unload what we can on those, or else the user will not even be able to load its phone application. :p

2

Window / Re: SFML windowing system on Android, anyone?

« on: December 26, 2012, 06:30:49 pm »

Oh well, I looked the topics you were talking about, and my conclusion is, I can't adapt SFML as is for Android. The sfml contexts are made so that GL resources are not deleted while the window is closed, but on Android, it is specified that a closed or sleeping app must free the memory to avoid hindering the other running apps, meaning the display and context must be destroyed any time the activity is not visible.

Thus I'll just create my own context managing, with one main context linked to the activity, and other contexts sharing the main one to allow threaded resource loading.

Honnestly, from what I saw, it would need to make a special SFML Window module specificaly for mobile devices, not just adapt the existing one, as managing a mobile app is really different from managing a desktop program.

3

Window / SFML windowing system on Android, anyone?

« on: December 26, 2012, 02:28:09 am »

Hello there.

I'm doing a game for Android, and I'm using SFML architecture to implement an "Android port" of the system in C++. I did some changes as we can have only one display on a mobile device (for now), so I simplified it a bit, but I'm trying to keep the Context system as is.

But right now, I'm having difficulties properly implementing Context with EGL, even understanding how the Context, GlContext and WGlContext class operate together.

Did anyone already ported a bit of the SFML windowing module to native Android?

4

SFML projects / Re: [Utility] Stroke

« on: November 13, 2012, 03:21:19 am »

Well sorry about the "soon", but it takes a bit more time that planned, due to real life priorities.

I'm still working on it, and I can say this for sure :

- All the naming of the class is rewrited to be more in a well made way. (no more this everywhere.)
- Added an Radomizer class with the stroke, that way stroke with randomize themselves even after the disapearance of SFML randomizer.
- No more draw modes, only 2 draw is supported : textured and non textured. I don't think the Line rendering is used for games, more for my own debugging.
- No more sweep attributes, the way the stroke is shaped will be replaced by another more flexible mean, allowing you to shape the Stroke anyway you like from its start to its end.
- No more stippling, as in fact, a little texture trick can do the work.
- A stroke can now be "closed", meaning you can draw perfect circle with it, the start and end point will join themselves nicely.
- You will have to call for an "update" function each frame before rendering to ensure the stroke is correctly computed, except if you don't add any joint or the stroke is not self-animated.

Well I still have the texturing and the shaping system to work on before releasing.

5

Graphics / Re: Image Deformation in SFML

« on: October 24, 2012, 11:11:52 pm »

Roger (bis)

6

Graphics / Re: Image Deformation in SFML

« on: October 24, 2012, 10:54:00 pm »

Roger

7

Graphics / Re: Image Deformation in SFML

« on: October 24, 2012, 10:35:12 pm »

Someone really wanted to use the Stroke class, so I'm working on it to port it to SFML 2.0 and give it a few enhancements.

And regarding this, what would be the faster way to display dynamic mesh? Directly calling glVertex3, like the old renderer.AddVertex(), or using a vertex array we clear and rebuild each frame?

8

General discussions / New naming convention

« on: January 24, 2012, 08:30:48 pm »

Well, let's not start a debate here, but do you know why it's called English? Because it came from England/Britain.

It's called English, because the people among whom it emerged were called Angles, after the region they came from, namely Angeln, which lies in Schleswig-Holstein, northern Germany. It's hardly England, you know

* Did learn something interresting today. *

9

General discussions / Switched times to Uint32 milliseconds in SFML 2

« on: November 06, 2011, 03:37:02 pm »

I kept the old version of sf::clock (in millisecond) because it is really more easy to use. No need for additionnal conversion or reflexion. I don't use the network so I don't need precisely timed clock, and having to do some tricks to have a decent FPS counter or whatever don't have its place in the S of SFML.

BTW, the clock mechanism are easy to change or use. And the wiki exist.

10

SFML projects / Excellence (previously Eve Shooter)

« on: September 27, 2011, 02:00:27 pm »

Hi!

Well, I did some class with looooots of parameters that do the work for me.

I'll do a post on the devblog some day, but I'm laking time because of my wonderful work.

11

General discussions / The new graphics API in SFML 2

« on: September 20, 2011, 02:50:10 pm »

Do you have something in mind like I did here, but in one class, maybe sf::Transformable?

I can see that you have no function to set X or Y alone (in Positionable and Scalable). I was thinking about removing these functions in SFML, what do you think about it?

And also... Point/Mesh or Vertex/VertexArray?

Function to set X and Y alone are a nice mean to shorten the code. I mean, I prefer doing a little SetX(val); instead of SetPosition(sf::Vector2(value, GetPosition().Y));

Also, Mesh and Vertex. Thoses are names used in 3D design and creation. Even in a 2D space, a vertex is a vertex. You could add a typename Point for thoses unfamiliar with Vertex, but for the beginners, I think it is a good thing to initiate them with standard naming. Same reasoning with sf::Transform instead of sf::Spatial.

12

General discussions / The new graphics API in SFML 2

« on: September 19, 2011, 07:22:55 pm »

A detail about "origin": I don't think that it was used a lot as the origin of translation and scaling, therefore I was thinking about changing it to "rotation center", which would remove all the confusion about it.

I think it is often used for the scale, particularly to center the scaling of the text in scaling effects. Origin is still the best name for me.

13

Graphics / Best way to do a game menu, or main menu, pause menu, etc

« on: August 06, 2011, 11:10:37 pm »

Don't draw objects that are not supposed to be displayed.

First choice.

14

SFML projects / Excellence (previously Eve Shooter)

« on: July 07, 2011, 04:46:49 am »

Hoy!

A short post to anounce the opening of our new devBlog about Excellence Here : http://excellenceteam.wordpress.com/

I'll discuss about programming choice, issue and solutions, but also arts and graphics and sound design. :]

15

Graphics / Health bar?

« on: May 23, 2011, 01:09:44 am »

For a Torus shape, you'll have to create your own Torus class, inheriting sf::Drawable.