Messages

61

Audio / Implementation of sf::SoundBuffer

« on: December 11, 2008, 12:05:11 pm »

Hi Laurent,

as I studied the source of the audio package of SFML I wondered why you were storing the samples in the vector myBuffer in sf::SoundBuffer. AFAIK OpenAL copies the sample data with alBufferData(..), so you just could use temporary memory and free it after the call to alBufferData(..).

Correct me if I'm wrong! If I'm right, I'd like to know why you did it this way  :wink:


Martin

62

Feature requests / non-dll runtime library

« on: October 21, 2008, 02:32:59 pm »

I would second this very zealously

In my opinion it would be sufficent to add a "Release Static MT" configuration to the solution. Only difference to the "Release static" configuration would be the switch /MT.
I don't mind the debug version because they never leave my hdd anyway :wink:

It is no big deal and definitively wouldn't hurt anyone who doesn't want to use this.  :wink:

I would even supply a ready to use sln file

63

General discussions / Libs + Dlls for Visual C++

« on: October 15, 2008, 12:16:13 pm »

Ok, as long as I am able to compile all used code (libraries, my program, ...) myself (regardless whether with static or dynamic binding), there won't be any problems, because I simply choose the same CRT for every part?
Fine.  

64

General discussions / Libs + Dlls for Visual C++

« on: October 14, 2008, 04:12:00 pm »

I'm not a huge fan of automatic linking with VC++ pragmas.

Regarding the static use of CRT, you can just change this setting and recompile SFML yourself. People (especially beginners) are already confused between debug / release / static / dynamic versions, I don't want to add more to this confusion.

But anyway, thanks for your feedback

I'm not quite sure about this whole linking thing. If I would compile SFML with static linking to the CRT and my own program also with static linking to CRT, is there a point at which I could run into problems or is it considered save practice?

65

Feature requests / sf::Clock Improvement

« on: August 01, 2008, 03:51:00 pm »

Ah, yes, Boost. Should've thought about that :!:

@Nexus:
No, no ctime
I don't like it to mix C and C++, I'm trying to stick to as clean as possible C++  :wink:

BTW: Bist du der Nexus, der im Forum von c-plusplus.de unterwegs ist?

66

Feature requests / sf::Clock Improvement

« on: July 31, 2008, 12:10:29 pm »

I'll just pick this thread up:

What's about adding a (static) method to sf::Clock which provides the current system time? Would that make sense? Are there other developers who would appreciate it?

There would be many possibilities for use, e.g. in logging, displaying current time in GUIs, add to savegames for easy identify, e.t.c...

So, Laurent, any comments? :wink:

greetings
Martin

67

General / [Win32/VS2005] Crash in Release Mode

« on: July 30, 2008, 02:55:23 pm »

Ok, tried out you suggestions:

- Unicode makes no difference
- no mix up in libraries

Then I switched to static linking, had to add sfml-system.lib and now it works without errors. But it won't work with dynamic linking though.

That is not bad, I don't care if I need to deploy the DLLs and I don't care about the file size. Nonetheless I'm curious what's the problem at this very point.

By the way: Should I link to the CRT statically or dynamically when using SFML? Or link the same way I did to SFML? Or does it make no difference whether I use dynamic or static linking?

68

General / [Win32/VS2005] Crash in Release Mode

« on: July 30, 2008, 02:35:58 pm »

Hi everybody,

today I started to make a skeleton for any applications I'm going to create. It's a very simple Application class:

Header:

Code: [Select]


#ifndef H_APPLICATION
#define H_APPLICATION

#include <SFML/Graphics.hpp>

class Application {

public:
int Run();

private:
bool InitApp();
sf::RenderWindow MainWindow;
};
#endif


Implementation:

Code: [Select]


#include "Application.h"

int Application::Run(){
if (!InitApp()){
return -1;
}

while (MainWindow.IsOpened()){
        // Process events
        sf::Event Event;
        while (MainWindow.GetEvent(Event))
        {
            // Close window : exit
            if (Event.Type == sf::Event::Closed)
                MainWindow.Close();
        }

        // Display window contents on screen
        MainWindow.Display();
}

return 0;
};

bool Application::InitApp() {
MainWindow.Create(sf::VideoMode(640, 480), "TheEye");

return true;
};


main.cpp

Code: [Select]


#include "Application.h"

int main() {
Application TheApp;
return TheApp.Run();
}


As you see, I'd like to seperate initialisation, event handling etc in seperate methods of my class Application. Straight OOP.

My Problem now is a exception that occurs just after closing the window in Release mode.

Error message is

A buffer overrun has occurred in TheEye.exe which has corrupted the program's internal state. Press Break to debug the program or Continue to terminate the program.

The program breaks at line 298 in the file gs_report.c from Microsoft.

Any ideas how to solve this? CRT is dynamically linked, Unicode enabled, I'm using sfml-main-d.lib, sfml-window-d.lib and sfml-graphics-d.lib in Debug mode and sfml-main.lib, sfml-window.lib and sfml-graphics.lib in Release mode.

greetings
Martin

69

Graphics / "Draw Sprites into a single Image" or "Stress

« on: July 17, 2008, 07:24:15 pm »

Hi there,

just another question:
Is there a way to draw sprites to maybe an Image? Following situation:
My GUI is constructed of many parts. The process of construction (filling in the right numbers for sprite's positions) is only done at startup and window resize. The Sprites of the GUI are then rendered one by one. I'd like to know if it would make sense to render it en bloc (if the requirement of drawing to an Image would be fulfilled) or to render Sprite by Sprite?

I didn't make a stress test yet, thus I'm not sure what number of Sprites is regarded as "normal" or suitable. I know it'd be depending on the used system, just take a normal, 2-3 years old single core with medium 3d capabilities. At which amount of Sprites would the FPS go down under 30fps? Resolution about 1024x768, 32bpp. I know, it is a rather imprecise question depending on multiple values, but I'm just interested in your experiences.


greets
Martin

70

Window / Mouse cursor enter/leave

« on: July 17, 2008, 11:30:24 am »

Ah, ok, just thought this information would be interesting for you :wink:

71

Graphics / Accessing Unicode Codepoints

« on: July 17, 2008, 11:30:00 am »

Ah, for sure, that's what I missed. Thanks for the hint.
I'm looking forward to see your improvements on the unicode topic :wink:

72

Window / Mouse cursor enter/leave

« on: July 17, 2008, 11:05:16 am »

Ever heard of TrackMouseEvent and WM_MOUSELEAVE? I've never tried it, but I think it could be capable enough. When the mouse reenters the window, it probably just would be a WM_MOUSEMOVE.

So far for the Windows part...

73

Graphics / Accessing Unicode Codepoints

« on: July 17, 2008, 10:52:56 am »

Hi there,

today I decided to fiddle around with Unicode and to try out if I'm able to bring some cyrillic oder japanese glyphs on the screen.

Tried the following:

Code: [Select]


sf::String UnicodeString;
std::wstring sfmlrocks(L"SFML ROCKS with \u0426!"); // the u0426 should be the cyrillic letter Tse...
UnicodeString.SetText(sfmlrocks);

The font I used with "UnicodeString" knows this letter Tse, proofed in the Windows app "charmap.exe". But when I draw the string, nothing appears, only an additional space before the "!". Has anyone got some hints what to do now?


greets
Martin

PS:
It's a VS2005-Project with Unicode enabled...

74

Window / Mouse cursor enter/leave

« on: July 17, 2008, 10:08:19 am »

Hi Laurent,

any news on this topic? Don't want to hurry you, I'm just curious  :wink:

Btw I also switched from HGE for the same reasons dewyatt mentioned. Its nice and well designed, but I like the design behind SFML even more. Is marvellous! Just wanted to say that...

greets
Martin