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 - dewyatt

Pages: 1 2 [3] 4 5
31
Feature requests / C++ (And others too) aliases for functions
« on: September 03, 2008, 09:14:13 pm »
You shouldn't care so much about naming conventions.
What matters is that the name gives you a hint about what something does or is.
Obsessing over a naming scheme just shows that you haven't been coding very long.

I don't understand how you can insult Laurent on his own forum about his own software.
Quote

// SFML - Simple and Fast Multimedia Library
// Copyright (C) 2007 Laurent Gomila (laurent.gom@gmail.com)
//
// This software is provided 'as-is', without any express or implied warranty.


I very much appreciate Laurent's hard work and have no problem with his naming scheme.
I've even adopted the "my" prefix in my own code (though I still maintain a lowercase first character in function names, etc).

32
Window / SVN DestroyWindow Crash
« on: August 26, 2008, 01:18:36 am »
Well I did discover a bit more information.
It seems my windows virtual desktop manager, Virtual Dimension, launches at least a few threads through its hook.
I'm going to be running it without Virtual Dimension to see if it ever crashes.

33
Window / SVN DestroyWindow Crash
« on: August 26, 2008, 12:50:22 am »
Well, I had it crash on me again.
If I can get it to a point where it's easily reproducable, I'll let you know.

Also, for additional information:
Quote

Unhandled exception at 0x6d1812e0 in Game_Debug.exe: 0xC0000005: Access violation reading location 0x6d1812e0

34
Window / SVN DestroyWindow Crash
« on: August 25, 2008, 11:38:15 pm »
Well I can't reproduce this anymore.
My original RenderWindow was a boost::scoped_ptr heap variable.
I changed it to a stack variable and it won't crash anymore.
I changed it back to a boost::scoped_ptr and it still won't crash anymore.

I've run it over 300 times.
I just don't know what's up with this.
But if it crashes again, I'll post here.

35
Window / SVN DestroyWindow Crash
« on: August 25, 2008, 10:19:27 pm »
Darn, I was afraid of that.
It probably is on my side but I can't imagine what is causing it.
I just rewrote my entire app recently and was very careful in doing so.
I thought that might take care of it but I guess not.

It is pretty rare.
I tested just now and had to run it at least 30 times for it to crash once.
The fact that it's happening sporadically makes me think it could be a threading issue.
I see there are 2 threads running (Besides the main app thread. I don't explicitly create any).
What are these for? I don't use any audio yet, only graphics.
So what is SFML using the 2 threads for?
Also, one thread always exits with code 1 (which indicates failure by convention).

My hardware is:
OS: Windows XP SP2 (32-bit)
CPU: AMD Sempron 2600+
Video: GeForce4 MX 4000

I haven't tested with the simplest programs yet.
I will do that now.
I suspect this may be caused by CEGUI.

36
Window / SVN DestroyWindow Crash
« on: August 25, 2008, 12:46:21 am »
Alright, I've been avoiding this.
My app has been crashing on exit randomly, maybe 1/100 times.
I just upgraded to the most recent SVN, hoping the crash would disappear, but it just crashed again.

It's always, always, on this line 224 in WindowImplWin32.cpp:
Code: [Select]

if (myHandle)
    DestroyWindow(myHandle); //Crash


Call stack:
Quote

    6d1812e0()   
    user32.dll!7e418734()    
    [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]   
    user32.dll!7e418816()    
    nvoglnt.dll!69710e86()    
    user32.dll!7e41b50c()    
    ntdll.dll!7c90eae3()    
    user32.dll!7e41daf6()    
>   Game_Debug.exe!sf::priv::WindowImplWin32::~WindowImplWin32()  Line 224 + 0x12 bytes   C++
    90909090()   


Hopefully the cause of this can be unearthed as it's been driving me crazy.
It seems to happen regardless of video mode (resolution/fullscreen/etc).
IIRC it happens in Debug as well as Release modes.

37
General / Something strange... (Mouse click)
« on: August 01, 2008, 03:20:16 pm »
Quote from: "dabo"
It would be really interesting to know what causes it.

Indeed.

38
General / Something strange... (Mouse click)
« on: August 01, 2008, 03:12:36 am »
Sorry to revive a slightly old thread but...

I've actually experienced this in my game recently.
In debug mode I've had it happen a few times.
In release mode I've had it happen at least once.
Just putting that out there.
I feel like this has to be a bug in SFML.
I mean, you don't see any other windows games/apps having this problem.
Anyways, it's been pretty rare so I'm not too concerned about it.

39
Quote from: "Avency"
If you decide to switch, the source of the Squirrel standard library also turned out to be helpful (+ some japanese site :P).

Oh nice! I hadn't thought of looking through that!
Oh and do you have a link for this Japanese site?

40
Quote from: "Avency"
Quote
I love Squirrel. Such fun  :D

I agree. Squirrel is quite nice.
I started to embed it just a few days ago. :wink:
It lacks documentation though.

Yeah I really wish it had more documentation/tutorials.
It even says on the front page "The documentation has to be improoved." (improved...).
I'm using SqPlus but I'm considering just using straight Squirrel.
If I do switch, I found Ogre3D bindings (OgreSq) that could serve as documentation a little.

41
Quote from: "Avency"
If it's only for the binding purpose you could load the file into memory and then use sf::Image::LoadFromMemory.

I realize that, but thank you anyways. :)
I didn't want to work around the problem like that.
I've already changed SFML+SOIL to allow Unicode Image::LoadFromFile though, so all is working now.
I love Squirrel. Such fun  :D

42
Feature requests / Outlined text
« on: July 28, 2008, 08:07:18 pm »
I've used the stroker feature of FT previously and it looks great.
So I vote for that.

43
Quote from: "Laurent"
Well, as you said it's a quick change and if I do it the author will certainly integrate it into SOIL next release.

I'm not going to change the underlying image library, because SOIL is lightweight and do almost all the job (with the help of stb_image) in only 3 source files which can be included directly into SFML source code. All other libraries need to link with libjpeg, libpng, libtga, ligtiff, etc... for which I need to get the libraries for every version of every target compiler for static link.

Anyway, just for my personal information, who's using Unicode filenames ?

I figured you wouldn't want to change the library, just thought I'd suggest it.
I do like that SOIL is lightweight.
I'll just make the necessary changes to SOIL.

As far as who's using Unicode filenames...
People with a non-english OS really expect support for it (and they have every right to).
I probably won't use it personally but my game is extensible and will allow for it.

44
I ran into another problem with all this Unicode stuff.

I need to bind sf::Image to Squirrel (in Unicode mode).
But LoadFromFile takes a std::string not a std::wstring.
I see that SFML uses SOIL which does not seem to support Unicode filenames.
Looking through SOILs code, it looks like these two functions would need to be overloaded/changed:
SOIL_load_image
stbi_load

It's a quick change.
But this would mean whenever SFML updates to a new release of SOIL, the SOIL code would have to be patched each time.

I was wondering if SOIL is the best choice for the image library behind SFML.
I don't know how heavily it is used but there are certainly alternatives that directly support Unicode filenames.
FreeImage supports it.
DevIL has it on the TODO list I believe.

45
Graphics / [Solved] Loading Images Inside a Thread
« on: July 15, 2008, 08:04:22 am »
I'm happy to contribute.  :)

Updated the tutorial and code.
Also added a download.

Pages: 1 2 [3] 4 5