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

Pages: [1] 2
1
Feature requests / New class for SFML2: TextArea.
« on: March 13, 2010, 03:36:48 am »
This is a really useful class!

Quote from: "Cierpliwy"
Please tell me what features should I add to TextArea class! ;)

Superscript and subscript would be nice :)
(that's the <sub></sub> and <sup></sup> tags)

2
Graphics / Confusion concerning sf::Image pointers
« on: February 28, 2010, 10:11:27 pm »
No, static.

3
Graphics / Confusion concerning sf::Image pointers
« on: February 28, 2010, 02:00:25 pm »
Hmm it's magically gone away, and nothing is different.
I hate it when that happens because it might come back and until it does (if ever) we'll never know what the problem is!

Well I couldn't find any good reason for it happening so hopefully it was just a random glitch that goes away...

So whatever happens it wasn't SFML's fault. Case closed. Thanks for your help anyway.

4
Graphics / Confusion concerning sf::Image pointers
« on: February 28, 2010, 12:11:18 pm »
Quote from: "Laurent"
Make sure that you use SFML debug libraries in debug mode (and release ones in release mode).

Yep made sure of that :)

I guess my first hypothesis was wrong, but I'm having a hard time finding what's causing the problem.

A summary of what I know so far:
I have a number of objects, each has a sprite using the same image. If I manually delete either an object or the image, there  are no problems. If I do both, however, I get heap issues.

I tried to replicate this with a simple example, but it doesn't exhibit the problem.
Code: [Select]
#include <SFML/Graphics.hpp>

class testclass
{
public:
testclass(sf::Image& i)
{
sprite.SetImage(i);
}

sf::Sprite sprite;
};

int main()
{
sf::Image* Image;
Image = new sf::Image;
Image->LoadFromFile("test.png");
testclass* Sprite = new testclass(*Image);
testclass* Sprite2 = new testclass(*Image);
delete Sprite;
delete Sprite2;
delete Image;

    return 0;
}


The only thing I can think it must be is that somehow the destructor for my objects is corrupting the heap so causing sf::~Resource to crash. I've searched in my code and fiddled for hours on end and I'm coming up with nothing.
What's the best way to find out where a heap corruption might be caused?

5
Graphics / Confusion concerning sf::Image pointers
« on: February 28, 2010, 06:59:29 am »
My current project is crashing at exit, complaining about corruption of the heap.
It seems to me that the problem is my image objects are being deleted a second time on exit! The crashing/heap problem goes away if I just remove the line where I manually delete my image.

Here's some code, try it for yourself (I'm using SFML2 revision 1429, Visual C++ 2008 Express). Put a breakpoint in Image::~Image in Image.cpp, and run this code. It breaks twice: once on my delete and another at the end of the program.

Code: [Select]
#include <SFML/Graphics.hpp>

sf::Image* Image;

int main()
{
Image = new sf::Image;
delete Image;

    return 0;
}


Is this standard behaviour for SFML?

6
Graphics / Drawing Large Numbers of Shapes Efficiently
« on: February 22, 2010, 12:59:46 am »
Yes it is! Nice work.

Thanks for getting onto it so quickly.

7
Graphics / Drawing Large Numbers of Shapes Efficiently
« on: February 21, 2010, 10:45:04 pm »
I have every intention of using threads, I just want to be sure that my rendering thread is efficient :)

Quote from: "Laurent"
Yes please :)
This is not supposed to happen.

To see what I mean, watch the console window when moving the mouse around in the graphics window.
Then close and recompile with a different view size, and see the difference. Or you could zoom in and out with the scroll wheel.

Code: [Select]
#include <SFML/Graphics.hpp>
#include <iostream>

sf::RenderWindow App;
//change this to test different View sizes
sf::View View(sf::FloatRect(0.0f, 0.0f, 10000, 4001));

int main()
{
App.Create(sf::VideoMode(800,600,32), "Test App", sf::Style::Close);
App.SetView(View);

while (App.IsOpened())
    {

sf::Event Event;
while(App.GetEvent(Event))
{
if(Event.Type == sf::Event::Closed)
App.Close();
if((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Key::Escape))
App.Close();

if(Event.Type == sf::Event::MouseWheelMoved)
{
//Assume delta of 1 or -1
if (Event.MouseWheel.Delta > 0) View.Zoom(0.8f);
else if (Event.MouseWheel.Delta < 0) View.Zoom(1.25f);
App.SetView(View);
}
}

sf::Vector2f mouse = App.ConvertCoords(App.GetInput().GetMouseX(), App.GetInput().GetMouseY());
sf::Vector2f viewsize = View.GetSize();

App.Clear();
App.Display();

std::cout << "Mouse(" << mouse.x << ',' << mouse.y << ") View(" << viewsize.x << ',' << viewsize.y << ')' << std::endl;


        sf::Sleep(0.1f);
}

    return 0;
}

8
Graphics / Drawing Large Numbers of Shapes Efficiently
« on: February 21, 2010, 02:32:14 pm »
Thanks for the help guys.

Is there a forum section for SFML2 issues? Or documentation? Had a quick look and couldn't find anything (could be just bad at looking).

Apparently there's a size limit for Views? As soon as the total area gets above 40 million square units (see below for examples) the ConvertCoords method returns incorrect results (small negative numbers).

I can post source if you want?

In SFML1.5, Views with an area over 40 million worked fine.

Example tests I ran:
10000x4000 (40,000,000 square units) works fine, 10000x4001 (40010000 square units) is broken.
6324x6324 (39,992,976 square units) works fine, 6325x6325 (40005625 square units) is broken.

9
Graphics / Drawing Large Numbers of Shapes Efficiently
« on: February 21, 2010, 12:38:35 pm »
I figure that if SFML2 is working for basic things I can probably use it (instead of SFML1.5) for my project since it's real simple.

But Views aren't working? Or am I doing something wrong? All I did was recompile with SFML2  (for the above issue) and it seems that although Views compile fine they don't function. I'm still using SFML shapes, not OpenGL calls.

Is that because they're not implemented yet?

To be specific, the methods I'm using are View.Zoom and View.Move. They compile fine but calling them doesn't affect the View?

I noticed that App.SetView isn't in the autocomplete list that VC2008 drops down. It does compile though if I type it in manually. Is that related somehow too?

10
Graphics / Drawing Large Numbers of Shapes Efficiently
« on: February 21, 2010, 12:09:18 pm »
You were right about SFML2, I'm getting 11 fps instead of 2!

I'd still like to see if I can get it even faster again, I'll try those things you suggested.

Thanks!

11
Graphics / Drawing Large Numbers of Shapes Efficiently
« on: February 21, 2010, 11:19:17 am »
Ok I will try SFML 2.

I did actually try straight OpenGL using points and glPointWidth (no display lists or anything like that) and it's only a tiny bit faster.
 
They're squares. I tried circles at first but they were a lot worse (understandably now that I know there are 40 points per shape).

12
Graphics / Drawing Large Numbers of Shapes Efficiently
« on: February 21, 2010, 11:10:15 am »
Yes I am running in release mode.

Mobile Intel 945GM Express: 2 fps
Nvidia GeForce 7600GT: 3 fps
Nvidia GeForce GTX 260: 6 fps

13
Graphics / Drawing Large Numbers of Shapes Efficiently
« on: February 21, 2010, 09:44:10 am »
I have approximately 100,000 shapes, each with its own color and size.
They are going to be moving objects, so I must redraw them all each frame. They are all visible on the screen every frame.

Currently I'm rendering like this each loop:
Code: [Select]
App.Clear();
for (std::vector<sf::Shape>::iterator i = shapes.begin(); i != shapes.end(); i++)
{
App.Draw(*i);
}
App.Display();


I'm getting around 2 frames per second, which is obviously no good.
How can I significantly improve my rendering speed?

14
SFML projects / cpGUI - A new object oriented GUI toolkit based on SFML 1.5
« on: November 29, 2009, 11:21:03 am »
In case anyone else has the same problem as me:

I suspect it was being caused by the notorious default font bug. Since there's no way to avoid the default font being loaded by cpGUI I'd assumed the author(s) would have accounted for it.

The only other way to avoid the crash as far as I know is to use static linking, so I did that.[/i]

15
SFML projects / cpGUI - A new object oriented GUI toolkit based on SFML 1.5
« on: November 27, 2009, 04:29:51 pm »
Ok, thanks.

More important at the moment is that access violation; I can't really have a program that crashes every time it exits. And I'd really like to use cpGUI, so I need to figure out how to fix it.

Any suggestions?

Pages: [1] 2