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

Pages: [1] 2
1
Graphics / Re: RenderWindow::draw not working on different thread?
« on: January 02, 2013, 08:59:10 pm »
cool, thanks!

2
Graphics / Re: RenderWindow::draw not working on different thread?
« on: January 02, 2013, 07:27:27 pm »
Ah, interesting, it's not the thread at all. I have some buffers stored in vram and some code that looks like this:
...
glDeleteBuffers(1, &vbo);
glGenBuffers(1, &vbo);
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, numVerts * sizeof(sVertexData), NULL, GL_DYNAMIC_DRAW);
...
glDeleteBuffers(1, &ibo);
glGenBuffers(1, &ibo);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ibo);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, numIndices * sizeof(u32), NULL, GL_STATIC_DRAW);
...

if I remove/bypass this code the font rendering works just fine.

edit: to be more specific, it's just the vertex buffer causing the issue, the index array can be allocated just fine without breaking font rendering.

3
Graphics / Re: RenderWindow::draw not working on different thread?
« on: January 02, 2013, 05:57:17 pm »
For what it's worth, I can confirm the internal RenderTarget::draw call is made with the vertex list, and the glDrawArray happens with no error.

4
Graphics / Re: RenderWindow::draw not working on different thread?
« on: January 02, 2013, 05:45:11 pm »
Thanks for the quick reply guys...

It all happens on the drawing thread (which is set to active). I've tried adding the glFlush as well but no change. This seems to affect any calls to renderWindow::draw, shapes and text, etc.

5
Graphics / RenderWindow::draw not working on different thread?
« on: January 02, 2013, 05:12:11 pm »
So I have my main thread set up to create the window and poll the event queue. I set the window to inactive on this thread, launch a second thread and do most of the logic and rendering there.

I use mostly ogl calls but I wanted to add some text rendering utilizing what is available in sfml. I quickly found out that text doesn't render. After investigating a bit, it seems any calls to RenderWindow::draw have no effect when they happen on this second thread. If I do them on the main thread where I created the window every works just fine.

Any ideas what I might be missing? I'm resetting the ogl states, everything else works just fine, no errors, or artifacts, no nothing.

Thanks!

EDIT: I just synced an built latest from the github repo, for what it's worth

6
System / Handle events in different thread
« on: July 27, 2010, 02:05:19 am »
Ok my bad, I actually created the renderWindow on a different thread. So in conclusion: create the window on the main thread, handle events on main thread, have party on many other threads.

I'll get my coat now, thanks for your time!

7
System / Handle events in different thread
« on: July 27, 2010, 01:14:36 am »
So I read that you can't handle the input on a different thread. Fair enough, what I do is this:

Code: [Select]

void main() {
Thread mainThread( &GameManager::Init, GetGameManager() );

sf::Event evt;
bool running = true;
while( running ) {
if( renderWindow == NULL ) {
ThreadSleep( PTimeMS( 25 ) );
continue;
}

while( renderWindow->GetEvent( evt ) ) {
if( evt.Type == sf::Event::Closed ) {
GetGameManager()->StopGame();
running = false;
}
}

ThreadSleep( PTimeMS( 10 ) );
}

mainThread.join();
}


renderWindow is an extern which is set up in GameManager::Init. Everything works render wise and "mainThread" executes as expected. Only it seems that GetEvent never returns true as all input actions are ignored.

8
System / Handle events in different thread
« on: July 27, 2010, 12:33:54 am »
I'm having some trouble handling events in a second thread. I do the rendering and the logic on the main thread but I spawn off a second thread for the event loop. This loop basically calls GetEvent() on the render window but it never seems to catch any events.

I have the window activated on the main thread and deactivated on the event thread, does that matter? Do I need something specific set up for the input to work on this second thread?

Thanks for any help

9
Window / Question on window tutorial
« on: January 21, 2010, 11:46:28 pm »
You're linking only to window and main, not system. Add sfml-system-d.lib to the list.

10
General / issue deciding on gui and issues using win32 and cpGUI!!!
« on: January 20, 2010, 04:52:23 pm »
Same goes for CEGUI, very flexible gui and if you check the wiki there's a step by step guide to get it running.

11
General / Overloaded global operator new
« on: January 20, 2010, 10:58:26 am »
I had a quick look at the SFML code (kudos on the standard by the way, very clean!) but I couldn't see anything strange happening.

I have a call to sf::Shape::Circle that returns a Shape by value. The shape contains the std::vector with all the points, which is copied with its operator=. The problem lies with the call to deallocate() which seems to trigger my operator delete. This is because I have the following code:

Code: [Select]

class A {
    A();
    sf::Shape s;
};

A() {
    s = sf::Shape::Circle( ... );
}


The deallocate on the std::vector inside sf::Shape is called on s, since the operator= from above will have to delete the old vector which contains the point added to sf::Shape in its constructor (representing the center of the shape). The only thing I can think of is that the sf::Shape constructor is called before my operator new is linked into the translation unit, but that doesn't make sense.

12
General / Overloaded global operator new
« on: January 19, 2010, 11:58:43 pm »
Right, I'm using the dynamic runtime library with VS2008.

13
General / Overloaded global operator new
« on: January 19, 2010, 11:43:38 pm »
I'm linking to the static sfml libs. I don't understand what you mean with a shared runtime library or a static one?

14
General / Overloaded global operator new
« on: January 19, 2010, 11:33:47 pm »
Quote from: "Laurent"
SFML (in this context) just uses a std::vector with its default allocator. In fact I think that you should be able to reproduce the problem without SFML.


That's a good idea. I did a quick test and managed to create somewhat the same behavior (obviously not the exact same) but everything worked, it both allocated and deallocated using my overloads. I'll look through the SFML code and see if I can find anything.

15
General / Overloaded global operator new
« on: January 19, 2010, 10:59:39 pm »
I'd have a look at the allocators used in SFML and make sure they really are consistent with how they allocate/deallocate.

Pages: [1] 2