Messages

16

General / Re: android build c++11 features

« on: January 26, 2016, 10:19:47 pm »

This has nothing to do with the android port of SFML. You need a compiler that supports C++11 and you may need to add a compiler flag to enable that support.

17

SFML projects / Re: First game

« on: January 26, 2016, 01:19:30 pm »

May be for a month Pathfinder & parser for isometric map will transform into library.
Is it expedient for other SFML users?

You should read this link: Write Games, not Engines. Don't set out and try to write a generic library that anyone can use, instead focus on making a game with your code.

18

General discussions / Re: SFML Game Development by Example - 4th SFML book

« on: January 26, 2016, 02:15:23 am »

Didn't the first SFML book cover this in the last chapter? Either way the book looks great and interesting!

Yes.

19

General / Re: SFML on VC++ 2015 (x64)

« on: January 25, 2016, 01:52:36 pm »

Or just use -d.dll's

-d indicates debug libs, not dynamic.

20

Graphics / Re: .net change from Close to Fullscreen

« on: January 21, 2016, 03:12:56 pm »

No there isn't, but its easy to solve, just put all your event hookups in a function that takes a reference to the window.

21

General / Re: Global Hotkeys on OS X

« on: January 19, 2016, 11:50:32 pm »

What exactly are you trying to accomplish? A keylogger? Anyways, without looking into it - it is probably an intentional limitation of OSX.

22

Feature requests / Re: copy constructor?

« on: January 19, 2016, 09:56:10 pm »

Huh? sf::Sprite and sf::Text are copyable.

23

General / Re: pollEvent in Fullscreen mode clears the screen

« on: January 13, 2016, 04:18:12 pm »

I think you are looking at this the wrong way, you shouldn't be caring what is drawn on the screen after 1 frame. If you follow the tutorial and write your game loop the proper way this is a non issue. Just do as the tutorial says: handle all of the events every frame and redraw your entire scene every frame (clear/draw/display).

As for what is actually causing the screen to turn white is probably due to you not polling/handling the internal events sent by the OS. Also whenever you call pollEvent(...) it needs to be in a loop as there can be multiple events generated.

24

General / Re: SFML And Emulator

« on: January 13, 2016, 03:46:22 pm »

If you want to make emulators then sfml and sdl are bad choice you need some low-level graphics api like pure opengl to make emulator, vecause you need to "translate" the bute code to of executable. To translate it you need to provide an alternative to functions that it calls. For exmaple on original platform we have a call to procedure graphics_create_texture, how will you handle it with sfm? You need normal Opengl function - glCreateTexture. If you still misunderstood this then you should understand how wine emulator works.

What? Huh?

He is asking about a Gameboy emulator. As for needing 'pure opengl' you still need a windowing library to use OpenGL. Even if he wanted to write pure gl code he still needs SFML/SDL/GLFW. Next time please understand the question before writing stuff that doesn't make much sense. SFML will be fine for what the OP wants to do.

25

General / Re: SFML And Emulators?

« on: January 13, 2016, 03:24:46 pm »

Why wouldn't it work? SFML doesn't care at all about what you are drawing.

26

Graphics / Re: image to multipart texture

« on: January 12, 2016, 10:42:41 pm »

Load you image into 1 texture and use sf::Sprite::setTextureRect(...). There is no need for you to split your image into 16 textures.

27

Window / Re: Start Screen

« on: January 12, 2016, 10:38:48 pm »

Don't pause the rendering, your drawing code should be separate from your logic code. Every frame redraw everything and handle events. When an event occurs simply update what you are drawing.

28

General / Re: Best way to handle events and drawing with separate threads or functions?

« on: January 12, 2016, 02:23:07 pm »

Don't use threads - make your code single threaded. It is highly unlikely that that you will gain anything from using threads, most likely you will just lose performance. Once you have an actual application use a profiler to see where the hot spots are and then optimize that code. Mulithreading is a very advanced concept and it is very easy to do it wrong and much harder to get right.

29

SFML game jam / Re: Wanna another? (early 2016 edition)

« on: January 12, 2016, 12:26:44 am »

I will gladly support another jam. However, I really don't want to see it like the last time where only 4 games were submitted. To me planning a jam and then only having 4 games is more of a disgrace (congrats to those who did participate) than a real showcase and competition. If people are willing to support it and turn out (this is the key) then another jam is a great idea.

With regards to rule changes, I'm fine with having some changes - the website already supports jams with different time lengths (was part of what I built into the website rewrite in-case we wanted something like this). Just keep my above point in mind, if there isn't really a good turnout I'm not sure if splitting an already small pool into smaller pools would be a very good idea.

Jebbs: If you read this, when does the web server have to be renewed?

30

Graphics / Re: sf::Sprite is not a drawable?

« on: January 11, 2016, 07:54:41 pm »

Also, new to this forum, do you know how accepting/marking an answer works?

This forum doesn't have that option, but if you want you can put '[SOLVED]' in the title of the thread (edit the first post).