Messages

46

System / Threadlimit?

« on: October 01, 2008, 11:46:01 pm »

The absolute maximum for threads is (on normal workstations) given by Hardware, and approximately 8192 (but a little less) because of the limited amount of LDT entries in the GDT (I dont know if this value is increased e.g. for 64-bit-CPUsor Multicore CPUs).
But I think most OS prevent you from creating more than approx 800 threads/processes because of performance reasons. Not only that they need much time to switch, but they also use a big amount of memory, since they have own stacks and so on...

47

General / Crashes when exiting?

« on: October 01, 2008, 11:12:00 pm »

Hey, I just discovered "Fixing crashes on exit" (or something like that) on the Roadmap... I do not encounter crashes anymore since I am deleting all Images and Fonts, stored in a manager class, before exiting...
Maybe this will help someone here...

48

General / Windows in Linux

« on: August 13, 2008, 10:54:59 pm »

I also know this issue from other games (for example Nexius). I think it is a compiz problem, because after uninstalling compiz, everything works fine.

49

Graphics / Draw Missing!?

« on: August 13, 2008, 09:47:42 pm »

For unicode support, most of the Windows API Functions have a "W" version (W like Wide Character)... Just use "GetModuleFileNameExW"... it should take 16-bit WCHAR strings as arguments...

50

Graphics / Appending text

« on: August 10, 2008, 04:01:44 pm »

Try:

Code: [Select]


std::wstring w = L"TEXT1";
sf::String smsg(w);
smsg.SetText(w+std::wstring(L"TEXT2"));

The unicode stuff is working very well and is indeed making sense for multilingual applications...

51

Graphics / Draw Missing!?

« on: August 10, 2008, 03:50:58 pm »

Getting the working dir in Windows uses the function "GetCurrentDirectory". The description of this function will be at msdn.microsoft.com .
In Linux, you have to usw getcwd() (take google/view die-linux manpages)...
by the way, you could use relative paths...

To get the real directory of your executable file in Windows, you use first:
GetCurrentProcess() to a call to GetModuleFileNameEx.
Again, both functions are described at msdn.microsoft.com .

52

Window / KeyCodes missing...

« on: August 10, 2008, 02:35:56 pm »

I have, for myself, a fitting solution (including key-mapping files and so on), but I do not think this could be a solution for SFML in General.
The font seems not to support the €-Sign. Is that correct, or is that an problem with the encoding? The encoding (de-UTF8/other locales to C++-intern UCS-2) is realized via mbstowcs.
All other keys seem to work, including things like <,>,µ, ², ³, {, [, ], }, \,|,~,^,°,´,`, Ü,Ö,Ä,ß and so on...

The thing is OS-dependent (I will have to edit SFML for every locale I support, and I will have to add this functionality for both Windows and Linux), and I also need a key-mapping file for every language/locale I support.

53

Window / KeyCodes missing...

« on: August 05, 2008, 12:28:00 am »

Okay, I found a place in SFML where I can install my own keymapping class... since my program is working with different localisations, including a language-file interpreter and c-locales (it is getting quite complex by now) this should be okay.

54

Window / KeyCodes missing...

« on: August 05, 2008, 12:05:56 am »

Could you possibly offer a way to get the real raw scancodes/virtual key codes with flags like shift, alt, ctrl and so on, without further processing them to sf::Key::Codes? I am asking because shift+1 and all other numbers (expect 7 and 0) give me 0 as key code, and so do the german Umlauts and a lot of other keys with shift or ctrl pressed...

55

Window / Transperancy of RenderWindow

« on: August 04, 2008, 11:56:54 pm »

Okay (this is what I thought, too), it is not THAT bad, by the way

56

Window / Memory Leaks in sf::RenderWindow

« on: August 04, 2008, 11:19:18 pm »

Hi again,
because of (minor) memory leaks in my program I started to test sf::RenderWindow (I wanted to see if it leaks memory).
I am using Linux (Ubuntu 64-bit)...

Code: [Select]


int main()
{
while(1)
{
VideoMode v(100,100);
RenderWindow* rw = new RenderWindow(v,"blllaaaaa",Style::Close|Style::Resize,4);
delete rw;
}
}


The memory this code commits is increasing slowly, but steadily.
Is there any way to avoid that? I'm working on a GUI project where in some cases, new RenderWindows are created (like e.g. for a Message Box).
Without spawning windows very fast (it takes a rather long time, you can count the windows manually^^), the program takes 11.0 MB RAM (starting with 5.5 MB RAM) after 7 Minutes.
By the way, the memory leaked per Window seems to increase depending on the size of the window.
I can only estimate the amout of memory leaked per Window, but I think it is between 1 K and 2 K... 270 Windows are something like 250 KB.

It might be a problem with the OS (global GL context or something similar), but the OS does not seem to deallocate the memory, even after half an hour (when the memory the program uses is about 40 MB)...

57

Window / Transperancy of RenderWindow

« on: June 04, 2008, 08:35:07 pm »

Is there any way to make the background color of an RenderWindow invisible?

58

System / Sf::Thread

« on: June 04, 2008, 05:23:58 pm »

A little piece of code?

Code: [Select]


secureDelete *newInstance = new secureDelete;
*newInstance = *this;
if(newInstancePtr)
{
*newInstancePtr = newInstance;
}
sf::Thread shredThread((shredPtr)(gutmann),newInstance);
shredThread.Launch();
return true;

gutmann(secureDelete* newInstance) is the function I am calling. It works fine but the call shredThread.Launch() does not return before the shredding operation has finished.

I tried to use different priorities (a feature that would be nice in sf::Thread), but even with parent-priority 15 and child priority 0 it did not work...
I dont think it is a bug, I think this is because Linux uses kind of globally I/O block preventing the whole process and all of its threads to execute code while in I/O operations.
This is a difference between Linux and Windows.
I am just wondering if there is a possibility to turn this off.
If you want to experience this problem first-hand you could try to write some 100 Megs into a file using a thread to perform the operation (on Linux platform).
Using unbuffered, direct IO (like a shredder HAS to do, thus avoiding the risk that a file might be only once overwritten by buffering) increases the problem.

59

System / Sf::Thread

« on: June 04, 2008, 12:31:02 pm »

I am writing a little file shredding program (Linux and Windows).
The file shred class sets up a thread to do the work, while the main thread still should be able to display the main window (updating the status information and so on).

Now I am encountering a problem with threads:
Thread.Launch() does not even return before the shredding thread finished, though I even use Sleep() in the shredding function to force a task switch thus making other Threads possible to work. This is surely not the purpose of threads, is it?

I have often enough implemented threads by CreateThread in Windows to know it should be working (at least in Windows) like I planned...
The shredding functions are all working properly (in Windows I even reversed my own code to check if it works correctly).

60

Graphics / sf::Sprite::GetWidth/sf::Sprite::GetHeight

« on: May 06, 2008, 06:46:34 pm »

Why on earth have these functions been deleted?
In one situation, I really need those functions, otherwise I had to save the values globally, and this would be far more work.
I would even prefer a "GetRect()" as it exists for sf::String...