Messages

1

SFML projects / Zeven

« on: December 03, 2010, 01:14:46 am »

I have to say that this doesn't look very useful to someone who is not looking for a robust and flexible structure to their code, which may be why Ceylo doesn't get the point in it.

Or it may be the fact that the need to append your event structure with every event received and the update methods, as he pointed out, make the solution slightly less robust.

What exactly do these update functions do?

2

General discussions / Extended API for sf::Thread in SFML 2

« on: November 20, 2010, 05:19:52 pm »

This will be a great convenience. Thanks.

3

General discussions / Re: SFML 2.0

« on: November 12, 2010, 07:46:36 pm »

- Generalization of data access for loading resources (from files, from memory, ...) with a DataStream framework

Excellent. This is something I miss from SDL.
It may be wise to include FIFOs and sockets as well, if they weren't already planned. Maybe over the HTTP and FTP protocols as well.

- Rewrite of OpenGL contexts handling to make it more elegant, more robust and easier to use

While you're at it, it would be advisable to expose all GL functions through GL contexts rather than direct GL calls. Sounds weird, but it will allow for supporting non-GL backends (perhaps software rendering, DirectX, GDI, XRender, etc) in the future.

- Unlink sf::Input from sf::Window, make it use direct OS calls rather than relying on windows events

Would be useful for some applications, but not terribly many.

4

General discussions / SFML Firefox Plugin like Flash Plugin

« on: November 07, 2010, 03:43:26 pm »

To let the user play a game through a browser?
Btw, i thought about my idea, and it will probably be better to learn flash instead. I want to make a game, and make a standalone and a browser client for it.

This would work if you fix it, and save you a ton of effort in the long run. If you released it into the wild, it'd also help other SFML users with similar goals.

5

Feature requests / Enabling/Disabling config file

« on: November 04, 2010, 08:46:25 pm »

It mays be because of the locks, and sf::Sprite::Render() seems to take much time too.

Windows will use a software implementation of OpenGL included by Microsoft unless you install your graphics card's OpenGL drivers. Since these aren't your personal computer, it may be why sf::Sprite::Render(...) is taking too long.

6

Feature requests / N900 port

« on: November 04, 2010, 08:42:15 pm »

I'm also interested in a N900 port ( also android and iphone of course), i might be able to give a hand at porting it. Having sfml on all our (company) target platforms would help immensely , my other alternative is to implement all sfml functionality I'm using myself. but that seems like a huge waste of time :S

I'm not familiar with OpenGL ES, but judging from the wikipedia article it seems like a ton of work would be involved in supporting version 2.0. It seems like it would be worth investigating the devices using version 2.0 and seeing if they also support 1.0 or 1.1 (or is that how it works anyway, with the wikipedia article being misleading?)

I can tell you that most of the OpenGL function calls are located in the Graphics library (duh), so that would be the portion of the code to check out first. There's also a little use in the Window library, but only initialization code.

7

Feature requests / Enabling/Disabling config file

« on: November 03, 2010, 11:40:55 pm »

So by creating a separate instance of sf::Image for each frame, you decrease the amount of transfer between CPU and GPU during video play, but increase it while loading.

Oookay, I understood. But do you really think it's a good idea to load the whole movie pictures at the beginning ?

Well, actually it would indeed avoid later GPU transfers but... if the transfer is already too slow to be done while playing, how long do you think it'll take if you want to do the whole loading BEFORE starting to play ? Logically.. more than the duration of the whole movie :/. By the way, keeping a whole decoded movie (especially with high definition) in the RAM may not be a good idea.

Consider a 1920x1080 definition with 30 FPS (which is the definition being discussed here). 4 bytes per pixels (RGBA pixel format). It would mean almost 15 GB of decoded data stored in your GPU for an only 1 minute long movie (and as the image is also keeped in the RAM, it would mean as much data for it). Still a good idea ?

Of course not. You'd probably want to cache maybe a second worth of video (that'd be roughly 240MB), and load more as you advance in the video.
Splitting the frame into quarters and loading each quarter separately may also be a good idea, since this will separate loading periods (any apparent lag caused by transfer time is likely due to the fact that it happens all at once -- the human eye sees frames at about 60fps, so if it takes more than 1/60 of a second to convert it to RGBA and upload to the GPU, there may be a "skip" in the video).

8

Feature requests / Enabling/Disabling config file

« on: November 03, 2010, 10:28:30 pm »

@nfries88: I don't really understand your explanation... actually, as the image changes every frame, you'll always need to send the new data to the GPU. But well... with a definition of 1280x800 and 30 FPS there are only 120 MB of data sent each second, which is really small compared to the maximum transfer rate (several GB/s).

Unless I am misunderstanding that sf::Image is a wrapper around a GLint that refers to a texture, then the image's pixels are sent to the GPU only during construction and a call to sf::Image::UpdatePixels().
So by creating a separate instance of sf::Image for each frame, you decrease the amount of transfer between CPU and GPU during video play, but increase it while loading.

IE:

Code: [Select]


std::vector<sf::Image> frames;
load_frames(frames);

std::vector<sf::Image>::iterator frame = frames.begin();
sf::Sprite sprite = sf::Sprite((*frame));
while(frame != frames.end())
{
     if(m_Movie->IsUpdated()){
          ++frame;
          sprite((*frame));
     }
     window.Draw(sprite);
     window.Display();
}


or... are you suggesting that transfer time is not the issue?

9

Feature requests / Enabling/Disabling config file

« on: November 03, 2010, 09:16:00 pm »

I’m currently using sf::Image:UpdatePixels to update each frame and I’m looking at a more direct way to access the frame buffer. If that is possible.

As Laurent said, that is the most direct way possible.

Are you using a single instance of sf::Image throughout the entire video? This could make it slower because it needs to continually upload each new frame to the GPU before it can be drawn. Instead, use a separate instance of sf::Image for each frame.

10

Feature requests / Joystick names and other information

« on: November 02, 2010, 02:35:38 am »

The way joysticks are supported in SFML is still quite basic, I plan to improve it in SFML 2.

That is good to read. I was going to recommend this myself.

While we're on the topic of input devices, are there any plans for supporting multiple mice or touchscreen interfaces in the near future?

11

Feature requests / cross platform clipboard support?

« on: November 02, 2010, 02:31:31 am »

QtCore does not appear to contain QClipboard, however. Probably because the clipboard is bound to the windowing system on most systems; and QtCore is for things not dealing with the GUI.

12

Feature requests / cross platform clipboard support?

« on: October 30, 2010, 09:47:33 pm »

Sorry for bumping a rather old topic, but how is clipboard access outside the scope of a multimedia application?

Some media players make use of drag'n'drop for rearranging media library.
Image editing programs make use of clipboard (and sometimes drag'n'drop) for copying images.
Online games frequently make use of text clipboard access for copy/pasting text.

I at least see the merits of exposing a cross-platform clipboard API to multimedia applications, even if you don't.

13

SFML projects / cpGUI - Anyone interested in developing?

« on: October 29, 2010, 09:17:14 pm »

So it isn't. But I do know it works on Win32, Win64, Linux 32-bit, and Mac 32-bit. O_o

14

SFML projects / cpGUI - Anyone interested in developing?

« on: October 28, 2010, 10:51:00 pm »

Okay then, I'm checking out github now.

Check out recruit0's branch for something reasonably up-to-date; mine is supposed to be the "master", but I haven't given it the attention it deserves.

I did after posting (I've never used github before, so I didn't realize it was like that) and all criticisms stick.

Can't say I'm a fan of the boost dependency. Boost is an awfully large library to have to download for such a comparatively small one.

Boost is not a library so much as a collection of much smaller libraries. Frankly, it's nearly as close to standard and portable as the STL itself. Unless there is a known issue, I make a point of taking advantage of Boost's facilities whenever appropriate; development time is a premium. Looking at the amount of boost usage currently in the repo, I assume recruit0 agrees.

Boost.Threads, Boost.ASIO, Boost.Function, and Boost.Date_Time are the most useful libraries in boost. Nearly everything else is not very useful for 99% of computer applications (ie Boost.Graph, Boost.Spirit) or provide a wrapping over something that already exists in common form on most/all C implementations (ie Boost.Integer, Boost.Python).

I think a custom implementation (or just including the header for boost::reference_wrapper<> in the repository, since the boost license is fairly permissive) would be better, and realistically such a thing is very unnecessary anyway.

It is always preferable to use existing, well-tested code rather than reimplementing it yourself.

Generally, I would agree. In the case of things as simple as functors, reference wrappers, containers, and strings; I would disagree. The advantage to using those is primarily in saving a handful of hours of development time, not in probability of flaws existing in your implementation.

The dependency on boost::gil for colors and on boost int types is just unnecessary, #include <cstdint>.

There might be some merit to your suggestion for boost::gil, but <cstdint> is not included in all modern C++ distributions. As we depend on Boost anyway, it is safer to make use of Boost.Integer. If I recall correctly, when the compiler provides it, Boost merely wraps around <cstdint> anyway.

Allow me.

Code: [Select]

typedef unsigned char uint8_t;
typedef signed char sint8_t;
typedef unsigned short uint16_t;
typedef signed short sint16_t;
typedef unsigned long uint32_t;
typedef signed long sint32_t;

typedef struct {
    uint8_t red;
    uint8_t green;
    uint8_t blue;
    uint8_t alpha;
}Color_RGBA32;

Less than 20 lines of code to remove a dependency; it's well worth it.

I also see you're using boost-style naming conventions for classes and functions now, as opposed to the SFML naming conventions. Although it's your call, I would recommend using SFML naming conventions because it makes life easier on the developer using your library. Personally, though, I prefer the naming convention you're using; it's what I use myself.

Recruit0 and I discussed this at length when we took over the project. My position is that language libraries should try to adhere to the conventions of the language standard; Boost uses the same naming conventions as the STL, and we adhere to that as well. By my reckoning, it is libraries such as SFML that make life more difficult by using conventions that do not adhere to C++ styling (although their technical merits alone more than make up for it).

At least you've got a good reason for it. I won't pester you about this anymore.

15

SFML projects / cpGUI - Anyone interested in developing?

« on: October 28, 2010, 03:22:33 am »

Okay then, I'm checking out github now.

Can't say I'm a fan of the boost dependency. Boost is an awfully large library to have to download for such a comparatively small one. Boost's build system is also prone to issues with MinGW, at least in my experience; although IIRC boost::reference_wrapper<> is implemented in header files.
I think a custom implementation (or just including the header for boost::reference_wrapper<> in the repository, since the boost license is fairly permissive) would be better, and realistically such a thing is very unnecessary anyway.
The dependency on boost::gil for colors and on boost int types is just unnecessary, #include <cstdint>.

I also see you're using boost-style naming conventions for classes and functions now, as opposed to the SFML naming conventions. Although it's your call, I would recommend using SFML naming conventions because it makes life easier on the developer using your library. Personally, though, I prefer the naming convention you're using; it's what I use myself.

Of course, this is what's in the repository right now. You said your local copy is more complete, so who knows what changes you've made.