Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - SirJulio

Pages: 1 2 3 [4] 5
D / DSFML (a port to the D language)
« on: July 19, 2008, 09:37:08 pm »
Hi Fredreichbier,

no it's not.

Do you use the release or the svn ? Which sample need to be linked with OpenAL ?

Graphics / "Draw Sprites into a single Image" or "Stress
« on: July 17, 2008, 08:23:41 pm »
Hi Martin,

image rendering is planned for the next release (actually, it's already available with the svn, don't know if it's already usable).

For system capabilities, there is a benchmark thread in the french forum. Users have posted some tests maybe this could help. Tests are :


1/ Displaying 2000 static sprites.
2/ Displaying 2000 transparent static sprites.
3/ Displaying 2000 rotating sprites.
4/ Displaying 20 static text.
5/ Displaying 20 dynamic text.

PS : SFML version is 1.1 I think, so maybe results will be different now.

Graphics / Draw(Text) performance issue
« on: July 17, 2008, 02:59:41 pm »
Quote from: "dabo"
So we who love visual studio will be forced to use something else in order to get great performance out of sfml? I'm currently experiencing the same performance issue as the one above.

Quote from: "SirJulio"
Another workaround is to use only std::wstring and not std::string to prevent call to String::SetText(std::string) (actually the bottleneck into this method is conversion between string and wstring because SFML String handle only wstring) and use String::SetText(std::wstring) instead.

You missed that too. =p

Graphics / Draw(Text) performance issue
« on: July 16, 2008, 11:59:01 pm »
Yep !

From string.cpp :

Code: [Select]
void String::SetText(const std::string& Text)
    myNeedRectUpdate = true;

    if (!Text.empty())
        std::vector<wchar_t> Buffer(Text.size());

        #if defined(__MINGW32__)
                // MinGW has a bad support for wstring conversions (and wchar_t based standard classes in general)
                mbstowcs(&Buffer[0], Text.c_str(), Text.size());
                std::locale Locale("");
                std::use_facet<std::ctype<wchar_t> >(Locale).widen(Text.data(), Text.data() + Text.size(), &Buffer[0]);

        myText.assign(&Buffer[0], Buffer.size());
        myText = L"";

Actually the specific Mingw part is a lot faster (by a factor of 100, maybe a little less) for all compiler I have tested (MinGW, VS9 and DMC).

Here's a test comparing the two methods, using svn, VC9 express and with SetText customized version (which doesn't use std stuff) and SetTextOriginal the actual SetText method :

Code: [Select]

int main()
    sf::String myString("Test");
    __int64 l;
    for(int i = 0; i < 10; i++)
        l = __rdtsc();
        printf("New SetText : %d\n", __rdtsc() - l);

    for(int i = 0; i < 10; i++)
        l = __rdtsc();
        printf("Original SetText : %d\n", __rdtsc() - l);

    return EXIT_SUCCESS;

New SetText : 7051
New SetText : 27200
New SetText : 13952
New SetText : 10928
New SetText : 7979
New SetText : 11511
New SetText : 10730
New SetText : 11259
New SetText : 10047
New SetText : 10761
Original SetText : 1839609
Original SetText : 1165118
Original SetText : 813238
Original SetText : 783113
Original SetText : 801104
Original SetText : 774272
Original SetText : 806911
Original SetText : 775008
Original SetText : 784999
Original SetText : 718220

So, it's not an issue with Visual itself, but with String implementation when you compile with visual. =)[/code]

Graphics / Draw(Text) performance issue
« on: July 16, 2008, 06:27:04 pm »
Hi dreimalbla,

it's a known issue with String. Problem is not the String display, but SetText method which is very slow with visual studio (you use VS, right ?). Try to comment the 3 others SetText methods, and you'll have your ~600 fps back.

Another workaround is to use only std::wstring and not std::string to prevent call to String::SetText(std::string) (actually the bottleneck into this method is conversion between string and wstring because SFML String handle only wstring) and use String::SetText(std::wstring) instead.

I've already mentioned this problem to Laurent on the french forum, and he's working on it. =)

Graphics / From Window to RenderWindow with OpenGL
« on: July 08, 2008, 04:35:28 pm »
For the second question, yes event matching is needed. Event is a big union, so Key.Code will only be relevant if the event is a keypressed one. Behavior is undefined if you check Event.Key.Code but the event is something else (as your Key.Code could be a mouse position, a window size, or anything).

General / Anoying problem
« on: July 08, 2008, 04:28:53 pm »
Damn ! though one !

Forgot to ask but did you use static or dynamic libs ? Have you tried both ?

You said that debug config works but not the release. Try to deactivate all optimisations (C/C++ => optimisation) of release cfg to see if that changes something.

General / Anoying problem
« on: July 08, 2008, 02:45:39 pm »
Ok, some things :

- Could you try to compile your code with MinGW or another C++ compiler to see if you can reproduce the problem ?

- Make sure you use VS2008 library (and not the VS2005).

- Could you compile a very simple windows in WinApi

Code: [Select]
#include <windows.h>

LRESULT CALLBACK mainCallback(HWND mainWin, UINT message, WPARAM wParam, LPARAM lParam)
    switch (message)
        case WM_DESTROY:
            return 0;

            return DefWindowProc(mainWin, message, wParam, lParam);

int WINAPI WinMain (HINSTANCE current, HINSTANCE previous, LPSTR comm, int mode)
    HWND mainWin;
    MSG message;
    WNDCLASS windowClass;

    windowClass.style = 0;
    windowClass.lpfnWndProc = mainCallback;
    windowClass.cbClsExtra = 0;
    windowClass.cbWndExtra = 0;
    windowClass.hInstance = NULL;
    windowClass.hIcon = NULL;
    windowClass.hCursor = LoadCursor(NULL, IDC_ARROW);
    windowClass.hbrBackground = (HBRUSH)(1 + COLOR_BTNFACE);
    windowClass.lpszMenuName =  NULL;
    windowClass.lpszClassName = "test";

    // On prévoit quand même le cas où ça échoue
    if(!RegisterClass(&windowClass)) return FALSE;

    mainWin = CreateWindow( "test", "SFML test", WS_OVERLAPPEDWINDOW,
                            NULL, NULL, current, NULL);

    if (!mainWin) return FALSE;

    ShowWindow(mainWin, mode);

    while (GetMessage(&message, NULL, 0, 0))
    return message.wParam;

Finally, if nothing worked, maybe you can try that. =D

General / Anoying problem
« on: July 07, 2008, 04:26:20 pm »
I see that you don't use project properties to specify your library and include paths (additional lib and include paths are empty). Try to erase all paths related to SFML you have specified in visual studio global options (tools => options => project and solutions => vc++ directories), and fill, in your project settings, "C/C++ => General => other include directories" ([SFML_1.3_path]/include/), "Linker => general => other libraries directories" ([SFML_1.3_path]/lib/).

My point is ,maybe, you link against old version of SFML and use 1.3 DLL which could cause the bug.

Anyway, i tried your project, and i couldn't reproduce your problem.

PS : Not sure about settings name, I use VS in french. =p

General / Anoying problem
« on: July 07, 2008, 03:28:18 pm »
For runtime lib, see in your project properties (C/C++ => code generation), debug config must be /MDd (multithread debug DLL) and release /MD (multithread DLL).

Can you upload somewhere an archive with your project to see if we can reproduce the bug ? =)

General / Anoying problem
« on: July 07, 2008, 02:34:41 pm »
Hi Regen,

do you use SVN versions or the 1.3 ? Some threading stuffs in your app ? If you use visual, make you use the crt corresponding to your config (/MDd => debug, /MD else).

SFML wiki / German wiki?
« on: July 03, 2008, 08:43:57 pm »
Quote from: "Xylankant"
Well, there's no mean to "split" community, however, there definitely *are* people who don't speak french or english.

And it's no problem to switch between french/english(/german) wiki and forum if one wishes ;)

Sometimes, it's just easier to use one's mother tongue.

Easier, yeah for sure, but interresting contributions (forum and wiki) will be split over X languages. ATM, we have two forums and two wikis and  keeping those "synchronized" is already difficult (translation of the french wiki FAQ and other cool stuffs is planned), just imagine with X forums and wikis, it will be a nightmare. =p

But, translation of the official tutorials in others languages could be a good idea, for people who want to learn SFML but doesn't speak (actually read) neither English or French.

So good idea, but i think that splits the community over several different forum and wikis isn't really efficient. =)

Window / Sfml 1.3 Visual studio express 2008 error
« on: June 30, 2008, 10:10:43 am »

i don't get the message, but your code is not correct. You don't check incoming events : your application freezes (I'm pretty sure that's the reason of your problem).

Add an event loop in your main loop (while (app.GetEvent(...) etc ...).

Window / [Solved] Input Problem!
« on: June 27, 2008, 05:40:14 pm »

yeap it's intentional. If you don't call GetEvent, Input array (mouse position, keys states etc) will never be updated, so whether you use or not Event structure, you must call GetEvent in your game loop. =)

Window / mouse coord out until resize by any amount
« on: June 27, 2008, 03:24:50 pm »
Yeap, i think we have our problems too.

I made some tests with wininspector and apparently on my comp, 1292x1036 seems to be the larger size I can use for any window (notepad for the test). This values is exactly what GetSystemMetricsSM_C[X|Y]MAXTRACK) returns. After some querying, Caption bar vertical size of sizable window is 26 (SM_CYCAPTION), and border of the window is 4 (SM_CYBORDER), so we found our magical number. Window cannot be higher than 1036 (always on my res : 1024) and for sizable window we must count caption and border size (26 + 2 * 4 = 34), so we cannot have a client area higher than 1002 (1036 - 34), which is equivalent to prior results. If your window is created with sfNone (noborder no caption), you don't have the problem because resulting window will be at the correct size (no need to count border and caption).

According to MSDN, you can override this behavior by processing WM_GETMINMAXINFO notif.

But, IMHO, creating a window higher than the screen vertical resolution (which seems possible) is not a good thing, dev request a VideoMode, but uses GetWidth and GetHeight to keep all calculs relative. If GetDesketopMode, create a client area smaller than the requested one, this is not a problem but GetWidth and GetHeigth return by Window must be correct.

So, i think that "post-calculate" the real Width and Height would be the best methods for this kind of situation. =)

Pages: 1 2 3 [4] 5