Messages

1

Graphics / Re: Is it possible to store shapes into sprites?

« on: April 06, 2016, 06:24:45 am »

What is the significant difference between rectangle shape and sprite? other than rectangle shape having adjustable points.

More than likely, I will go with shapes, since "they can" achieve the projection of textures in similar ways to the sprite class and uniform with all other types of shape; single container.

Thanks.

2

Graphics / Re: Stuck in event loop when event is triggered

« on: April 06, 2016, 06:13:39 am »

Hmm, you mentioned that when the mouse is moving, the event loop is triggered somewhat-infinitely, but the event loop shown above does not test against mouse or keys pressed.

Are you implementing key and mouse movement detection?
if you are, how are you doing so?

if you are not detecting for keys and mouse movements, and then I can only suggest using the latest release of SMFL.

3

Graphics / Re: loadFromFile doesn't work but shows no error message

« on: April 06, 2016, 12:52:20 am »

With so few information, not many people will be able to help.

What is the behavior you are getting, what is the expected?

My assumption is that you're indeed clearing the screen and displaying the window. If so, it should draw, if not try changing the clear color and see if the clear method is even working, as well.

What is actually working? is it just sprites not showing? is the clear color operating correctly? Is anything else other than the sprite malfunctioning? Is the texture rect on default max size; have you altered it?

More detail will help folks help you easier.

4

Graphics / Is it possible to store shapes into sprites?

« on: April 06, 2016, 12:33:41 am »

This is probably a question that has already been asked before already, but is it possible to store shapes as sprites? (convert)

Having objects that contain sprites, I'd rather not have to contain shapes as well. Since their behaviors are similar, I'd figured there'd be some easy way to convert them.

My current understanding is that I can assign over the texture, but that isn't really what I want; I want the shape as well.

And what I'm trying not to do is: draw the shape onto a render texture, then acquiring that texture(the shape) from renderTexture and storing it into a sprite.

Any shortcuts?
Thanks.

5

Graphics / Re: Stuck in event loop when event is triggered

« on: April 06, 2016, 12:15:18 am »

I highly doubt you're stuck in the event loop.

To prove so, try printing your "i" value after window.display(), it should print the number of cycles the event loop triggered.
The event loop can trigger a great many amount of times within 200 ms, and you'd most likely wouldn't even feel a delay.

What I'm saying is that it is normal for the event loop to trigger a bunch of times. The program most likely isn't locking up from the event loop. As for the animation, not sure.

First try printing outside of the event loop and if it prints, the fault lies elsewhere.

Hope this helps.

6

Graphics / Re: Help! Regarding view and world drawing

« on: March 09, 2016, 03:26:43 am »

What about an array(vector) of sf::RenderTextures? Each render texture would represent a different layer. I'm assuming you want modification on different layers without having to redraw everything every single time to a single layer.
In this case, you would get n amount of layers, where n is equal to the number of render textures.

And then you would apply them in orderly fashion (order matters).
First to be drawn to the window would be the lowest level, last to be drawn would be the highest level.

Their is a possibility that I am not understanding the question correctly though =D.

7

Graphics / Re: Inherits: Rectangle Shape, cannot call move method?

« on: March 08, 2016, 09:14:25 pm »

Sorry, my mistake =D
Sleep deprive caused me to overlook something, a simple c++ error, thanks.

Edit: Solved.

For completeness, it was due to multiple inheritance, and me not properly removing ambiguity.
Basically sf::Rectangle Shape was inheriting the move method from sf::transformable and I from sf::Rectangle Shape.

So the call: sf::RectangleShape::move(/*stuff*/) allowed me to access the move method from sf::transformable.

8

Graphics / Inherits: Rectangle Shape, cannot call move method?

« on: March 08, 2016, 08:34:08 pm »

Hi everyone,

As the title states, I am having issues calling an inherited method "move(10.f,10.f)" from the Rectangle Shape class.
Example below:

    //What we'd could normally do:
    sf::RectangleShape aRectShape;
    aRectShape.move(10.f,10.f);//Works
   
    //In a class that inherits Rectangle Shape:
    this->move(10.f,10.f);//Does not work;

From my understanding, the Rectangle Shape class that I have inherited, also inherits a move from the transformable class. Why am I not allowed to access the move method from Rectangle Shape in its child class that I've created?

Thanks.

9

General / Re: Linux 14.04, sfml 2.3.2, and Valgrind: One tiny, mines or SFML's?

« on: February 27, 2016, 05:07:59 am »

Thank you, appreciate the information.

10

General / Linux 14.04, sfml 2.3.2, and Valgrind: One tiny, mines or SFML's?

« on: February 26, 2016, 02:18:13 pm »

The memory leaked is very little, but I'm trying to determine if it's my portion of the code that is leaking or if it is the SFML; I don't mind if SFML leaks 1 block of 60 bytes, especially to prevent crashing, but I never target the tools for blame unless I've gone several hours/days at it.

After cleaning and researching for a while, I interpreted some of the information provided by Valgrind, and want to come to the assumption that it is a SFML leak. I have my doubts, so I am asking for confirmation if anyone understands the report and or SFML.

I've cleaned a lot and narrowed the Valgrind errors down to 1 block containing 60 bytes:
Valgrind Result:

==2672==
==2672== HEAP SUMMARY:
==2672==     in use at exit: 45,551 bytes in 417 blocks
==2672==   total heap usage: 39,234 allocs, 38,817 frees, 218,985,603 bytes allocated
==2672==
==2672== 60 bytes in 1 blocks are definitely lost in loss record 41 of 65
==2672==    at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2672==    by 0x44577DF: ??? (in /usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0)
==2672==    by 0x442BEB5: ??? (in /usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0)
==2672==    by 0x44282EC: ??? (in /usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0)
==2672==    by 0x4428379: glXGetConfig (in /usr/lib/i386-linux-gnu/mesa/libGL.so.1.2.0)
==2672==    by 0x409301C: sf::priv::GlxContext::selectBestVisual(_XDisplay*, unsigned int, sf::ContextSettings const&) (in /home/.../libsfml-window.so.2.3.2)
==2672==    by 0x4093D90: sf::priv::GlxContext::GlxContext(sf::priv::GlxContext*) (in /home/.../libsfml-window.so.2.3.2)
==2672==    by 0x4084269: sf::priv::GlContext::globalInit() (in /home/.../libsfml-window.so.2.3.2)
==2672==    by 0x4084B9F: sf::GlResource::GlResource() (in /home/.../libsfml-window.so.2.3.2)
==2672==    by 0x4086E4C: sf::Window::Window() (in /home/.../libsfml-window.so.2.3.2)
==2672==    by 0x405F8FC: sf::RenderWindow::RenderWindow() (in /home/.../libsfml-graphics.so.2.3.2)
==2672==    by 0x804B1AB: App::App() (app.cpp:20)
==2672==
==2672== LEAK SUMMARY:
==2672==    definitely lost: 60 bytes in 1 blocks
==2672==    indirectly lost: 0 bytes in 0 blocks
==2672==      possibly lost: 0 bytes in 0 blocks
==2672==    still reachable: 45,491 bytes in 416 blocks
==2672==         suppressed: 0 bytes in 0 blocks
==2672== Reachable blocks (those to which a pointer was found) are not shown.
==2672== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==2672==
==2672== For counts of detected and suppressed errors, rerun with: -v
==2672== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
 

There was another post back in 2010 about opengl context, hopefully that is relative to this leak as well.
http://en.sfml-dev.org/forums/index.php?topic=3354.0

Is this an SFML context leak?
Thanks.

11

Network / Advice, properly using/stopping a tcp listener.

« on: February 23, 2016, 08:31:13 am »

As we all know, the tcplistener, while accepting new sockets, go into a long wait mode.

I've gotten around this using sf::Thread, allowing me to work while the thread continuously acquire more clients.

Problem is, when I'm done with the app, I am unable to close the app properly because the other thread is still running.(thread.wait() with sfml's sf::thread and thread.join with std::thread)

What could I do to forcefully close a listen operation?

If not close it, how would I go around not allowing it to accept sockets when in fact, I may still be including more clients.

Say for example, a 12 player game that allows players to join and leave the game whenever they feel.

It would be easier to just queue up 12 players, then start with the network no longer listening for players connecting, but that isn't the path that I am designing. Any ideas?

I am still trying non-blocking, but am receiving random behavior (sometimes it'll stop at accepting, other times, not), will update if I figure it out.

Edit:
Ha.. just thought of something funny, maybe I can attempt to reconnect to it, allowing it to pass the accepting socket stage (of course my socket would be thrown away since I am already registered) and thus allowing it to complete the cycle, and exiting the loop due to running = false. Trying it.

Edit 2:
Solved, I was able to exit the listener and program by attempting a final connection to the server, allowing it to pass the listening method and complete the loop, joining up with main, then exiting. Strange approach, but it works.

12

Graphics / Re: sfml rendertexture with intel gpu

« on: February 18, 2016, 02:27:40 am »

Yes like that   
Never knew that was available!

Should've mentioned it from the start! ha ha.

I read someone about it being in the header and saw that line of code, itself, in the header but never thought to had printed it through the console.

Thanks again.
Inquiry it next time if someone doesn't know their version please!

13

Graphics / Re: sfml rendertexture with intel gpu

« on: February 18, 2016, 02:06:47 am »

You were both right, that I did not have the newest version; I wasn't aware myself and did not know that the command line installation wasn't up to date. I couldn't even determine what version I was on even though I had all the files ha ha.

Sorry for all the trouble, everything is working great now.

I'm still learning my way into linux, so I have a question... Does newer versions of (L)ubuntu provide different versions of SFML or are they all being distributed versions  < 2.2? Are all the repositories the same?

If they're all being distributed lower versions of SFML, this problem might occur again in the future because the SFML linux installation tutorial may be suggesting a not up to date version through the method of CLI installation.
http://www.sfml-dev.org/tutorials/2.3/start-linux.php

Choice #1: command line installation was preferred by the tutorial, for ease I understand.

Everything is fine now.
But, it'd be nice if the tutorial leaves a note stating which version should be expected, or heck, maybe have a builtin variable somewhere in the header that allows the user to print the value.

Example:

std::cout<<"The SFML version number is: "<<sf::Version::VALUE<<std::endl

A version number in the header, within the namespace Version and being a global const static variable called VALUE.

Thanks a lot everyone.

Edit:
Ubuntu Package Search
Interesting, it shows the version number on the Ubuntu Package Search.
I installed it using the tutorials from SFML so I was never aware of the version.
Knowing the version number would've helped a lot.

14

Graphics / Re: sfml rendertexture with intel gpu

« on: February 17, 2016, 03:31:22 am »

Alright Hapax, thanks for the support!

I've got a pattern identified! thanks to the link you provided, I was able to cross test many of the code provided there (the ones without quick sprite).

It would seem that the behavior only occurs with renderTextures of sizes below 256*256; my 100*100200*200 illustration above created this phenomenon. SO as long as the renderTextures are above size 256*256, it works (Not sure why).

As to the version of SFML I am using and how I downloaded it: it was installed using the linux command line interface (cli) with the linux command line provided by SFML's website:

sudo apt-get install libsfml-dev

So, I think it should be up to date.
Now for the more interesting aspect, why does it not allow renderTextures of size smaller than 256 by 256(Update: one side can be smaller than 256, not both)?
I will be testing more..

Edit 1:
It would seem that atleast one dimension of the two, for renderTexture, must be atleast 256.
Have a renderTexture of 10*256 causes me no strange behavior, however if any of the sides were less than 256, say 255, then unknown behavior occurs.
Edit 2:
The size of the shape is irrelevant, if the shape is larger than the renderTexture, it just gets drawn out of the renderTexture like normal.
Edit 3:
The clear method of renderTexture still works at lower sizes, clearing with a color of red will produce a red clearance like normal, but the shape will be missing or distorted; I've only seen missing and single vertical line so far.
Edit 4:
Sprites on renderTextures smaller than 256 also do not behave like normal.

Does this apply to you as well? if not, is there any difference between sfml's implementation of renderTextures dependent on size and OpenGL version? If not then, worst case, it's probably just an OpenGL 1.3 issue.

Maybe I can use larger renderTextures (not saying I can't) and simply use sprites to subRect smaller images from the renderTextures, haha.

My reason for using small renderTextures:
I was using smaller renderWindows originally so I complemented it with smaller renderTextures; but I can work around it with sprites and subRects of the larger renderTexture to fit my needs.

It is interesting though, that small renderTextures behave differently on OpenGL 1.3 or is it for all OpenGL? And that larger renderTextures are no effected at all.

15

Graphics / Re: sfml rendertexture with intel gpu

« on: February 17, 2016, 02:30:36 am »

I installed SFML a few weeks ago, using the instructions on the sfml/linux tutorial on the lubuntu cli.

sudo apt-get install libsfml-dev

I believe it should be a new-enough version.

Else, where can I determine the version value? I've read on google that it would be in the config.hpp file but I didn't see any version numbers.