Messages

16

Graphics / Question on setColor

« on: October 01, 2015, 02:42:15 am »

Hi, it currently seems that setColor on a sprite works so that the colour argument is multiplied against the original colour of the sprite texture.

Would it somehow be possible to make this additive instead?
(In which case setColour would need to take in rgb arguments of the range -255~255 to cover all colours possible)

17

Window / Question on Views

« on: April 06, 2015, 01:48:28 am »

Hi,

 I was just wondering if for example I have 2 views, 1 overlapped over the other, then if the up-most view draws a sprite with a transparent background, then will the result come up as the bottom layer + the sprite on a transparent background (hence the lower layer contents showing in the background of the sprite), or will I get the sprite on a black background?

18

General / Re: Implementing InputStreams

« on: February 04, 2015, 11:22:36 pm »

Thank you for all the replies, I managed to fix the problem by using a stringstream instead of istream.

19

General / Implementing InputStreams

« on: February 04, 2015, 03:42:26 am »

Hi, I'm trying to implement a custom InputStream but I'm having trouble doing so.
I seem to be opening the zip file just fine, and the library I'm using (https://bitbucket.org/wbenny/ziplib/wiki/Home) automatically gives me an istream* to the
data.

Yet I keep failing when I try to load the texture with the stream through:
texture.loadFromStream

Any ideas as to what I'm doing incorrectly?

P.S. I'm currently trying to develop this to be able to open password protected zip files.
This is code for a game engine I'm currently building and my users seem to want the
added security - hence I can't just use physfs or some other pre-existing library.

Here's my implementation:

Header)

Code: [Select]

#include <ZipFile.h>

namespace lvn
{
class NStream : public sf::InputStream
{
private:
ZipArchiveEntry::Ptr m_entry;
std::shared_ptr<std::istream> m_File = nullptr;
std::string m_filename;
//bool m_file_is_open = false;

public:
static bool ReadTxtFile( std::string filepath, tstring& textbuffer );

NStream( std::string pathName="" );

virtual ~NStream();

bool isOpen() const;

bool open( std::string pathName );

void close();

virtual sf::Int64 read( void* data, sf::Int64 size );

virtual sf::Int64 seek( sf::Int64 position );

virtual sf::Int64 tell();

virtual sf::Int64 getSize();

};
}

CPP)

Code: [Select]

#include <ZipFile.h>
#include "NStream.h"

namespace lvn
{
NStream::NStream( std::string pathName )
//: m_File( 0x00 )
{
using namespace std;
open( pathName );
}

NStream::~NStream( )
{
close( );
}

bool NStream::isOpen( ) const
{
//return (m_File != 0x0);
return ( m_File != nullptr );
}

//Ex. Images//albert.png
bool NStream::open( std::string pathName )
{
using namespace std;
close( );
auto archive_name = pathName.substr( 0, pathName.find( "/" ) ) + (".vndat"); //need to add the archive extension to the name

ZipArchive::Ptr archive = ZipFile::Open( archive_name );
m_entry = archive->GetEntry( pathName );
if ( m_entry == nullptr )
return false;

m_File = make_shared<istream>( nullptr );
m_File->rdbuf( m_entry->GetDecompressionStream()->rdbuf() );
m_filename = pathName;

return isOpen( );
}

void NStream::close( )
{
m_File.reset( );
}

sf::Int64 NStream::read( void* data, sf::Int64 size )
{
if ( !isOpen( ) )
return -1;

auto posPrev = tell();
m_File->read( static_cast<char *>( data ), size );
auto cur = tell();

return tell() - posPrev;
}

sf::Int64 NStream::seek( sf::Int64 position )
{
if ( !isOpen( ) )
return -1;

m_File->seekg( position );
return tell( );
}

sf::Int64 NStream::tell( )
{
if ( !isOpen( ) )
return -1;

// istream returns the offset in bytes or -1 on error just like SFML wants.
return m_File->tellg( );
}

sf::Int64 NStream::getSize( )
{
if ( !isOpen( ) )
return -1;

//get length of file (by seeking to end), then restore original offset
const auto originalIdx = tell( );
m_File->seekg( 0, m_File->end );
const sf::Int64 length = tell( );
seek( originalIdx );

// tell returns length of file or -1 on error just like SFML wants.
return length;
}
}


20

General / Zip file solution for Streams

« on: January 17, 2015, 08:25:49 pm »

Hi, I was wondering if anyone new of any zip file InputStream implementations (that also work with password encryption) for SFML.

21

Feature requests / Re: sf::Text and line spacing

« on: November 07, 2014, 09:44:01 pm »

Although SFML doesn't provide this, it uses the line spacing defined by the font, so modifying the font file should be an option.

While possible, I feel doing that is terribly inconvenient. Especially if you want to make small adjustments, check how it looks like on screen, and iterate the process until you feel it's just right.

http://en.sfml-dev.org/forums/index.php?topic=16451.0

Since we already more or less agreed on letter spacing, I think we can get line spacing done as well

Thanks, this is great to hear! 

22

Feature requests / sf::Text and line spacing

« on: November 07, 2014, 04:40:12 am »

Hi, I'm seeing that SFML currently doesn't have an option to
specifically set the spacing between lines in pixels for text.

This would be great for making small adjustments to text
to make it display better on screen.
(Instead of perhaps the lines too far apart, or too cramped up
top-bottom to each other)

23

Audio / Playing sound at volume above 100

« on: October 04, 2014, 07:59:53 pm »

The current implementation of sounds seems to limit
the volume at 100(%). It would be nice if sounds could
be played at higher volumes than they're original file volumes.

(ex. 250%, 500%, etc.)

24

General discussions / Re: SFML 3 - What is your vision?

« on: August 10, 2014, 03:53:07 am »

Manual Context Management:

- It would be great if something along the lines of allowing the user to create an external sf::Context, and passing in a pointer to SFML for it to use for all its context related operations could be added as a new feature.

I feel that allowing the user to manage their own contexts is a much more safer and reassuring method (to the user) of going about context management than SFML internally creating and holding sole access to its context(s).

25

Graphics / Re: SFML Context Management

« on: July 04, 2014, 06:08:44 am »

If you want, you can go down the masochistic route and create a second sf::Context which you will always activate after every window operation. Remember: the window will almost always activate its own context when you make it do something. So after every single window.someMethod() call, there would have to be a myContext.setActive(true) call. This second context would need to be declared right after the window to guarantee the destruction order and it would the one that you create all other objects in.

Thanks again for the reply,

I'll go with your advice and see how the masochistic route goes. I can confirm that the following code works without problem:

#include <SFML\Graphics.hpp>

int main()
{
        sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );

        sf::Context context;

        sf::Texture texture;
        texture.create( 2, 2 );

        renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
        renderWindow.display();

        context.setActive( true );
        renderWindow.close();

}
 

But if something like creating a second sf::Context and activating it after every window operation will get the job done, then wouldn't something along the lines of
1. create a function to pass the pointer to a manually managed sf::Context to sf::RenderWindow
2. create a private inline void function within sf::RenderWindow that
'if (m_pUniqueContext != nullptr) m_pUniqueContext->setActive(true)'
3. place the function at the end of every window function (except .close() which will need this at the start)

allow sfml to support both the current shared opengl context implementation and also all use cases requiring a unique opengl context? This seems like a method to get both done with minimum overhead and with barely any change to the current sfml code.

26

Graphics / Re: SFML Context Management

« on: July 03, 2014, 04:46:42 pm »

You remember those good old days where games used to say something like: "To apply these settings, a game restart is required."

Yeah... those days

Haha.... those good old days;

I don't know if this would be feasible, but would something along the lines of getting the opengl context from the current window, and managing its lifetime myself be possible? (and would that help solve this)

27

Graphics / Re: SFML Context Management

« on: July 03, 2014, 04:27:36 pm »

Sorry to say this, but you're out of luck. We know what the problem is, but the assumption that context sharing works properly is so deeply rooted into the SFML code that it isn't feasible to code a workaround just for people who have this problem, even if they are not that small of a user base.

What you can do however, in your own code, is prevent this case from happening. Now that you understand what triggers the crash, you can take steps to avoid getting into this situation. As should be obvious from the example, make sure you always only have one context active, from the start to the end of the application. The first thing you should do is create the window and set its context active. Do not create new contexts or deactivate it after that. This means, no access to anything graphics related in secondary threads as well. The last thing your application should do is let the window go out of scope after all other resources have already been destroyed. Do not manually close it, it will close itself on destruction.

If you follow those instructions, chances are good that you will end up only working in a single context. I already do this myself, because I constantly work with unsharable resources like VAOs, and this strategy works for me. You have to be very strict on yourself, but if that is the only option you have, I don't think there is anything else you can do.

Thanks for the reply - how should I then handle things like needing to change the window resolution during play? (ex. switching in and out of full screen)

From what I understand of the problem, using RenderWindow.create() to recreate the window may cause a context switch. (or does it not?)

28

Graphics / Re: SFML Context Management

« on: July 03, 2014, 02:46:56 pm »

What should I be doing then - is there something that can be done on my side?

Update graphics drivers as already said, or buy newer hardware which come with better drivers. It isn't feasible for us to work around stupid driver bugs like this.

Thanks for the opinion,

 But as I've already mentioned, that isn't something I'd really like to be telling my users. If the problem only affected me, sure, that's what I would be doing, but this isn't the case.

I'd like to know if there are any workarounds that can be implemented on my side. I don't mind any excess boilerplate code if that will work.

29

Graphics / Re: SFML Context Management

« on: July 03, 2014, 02:42:26 pm »

On second glance, I think it has something to do with context sharing. Perhaps the Intel driver (from back then) doesn't like it when a resource is deleted in a different context than the one it was created in. This is something that works on all current desktop systems and as AlexAUT said, it also works for him with an up-to-date notebook driver. Coding a workaround to make sure that resources are destroyed within the context they were created would become very very complex and is probably not even currently feasible. If it was, it would certainly hamper people that don't have a problem with the current implementation.

You can check if this is the case with this code:

#include <SFML/Graphics.hpp>

int main()
{
    sf::Context context;

    {
        sf::Texture texture;
        texture.create(2, 2);

        // Comment this line to see if it prevents the crash
        context.setActive(false);
    }
}

Thanks for the reply,

I've just checked the code: as it is, it produces a 'Invalid address specified to RtlFreeHeap( 003F0000, 044EFF30 )' error.
With the 'context.setActive(false)' commented out, the program produces no error.

The code works both without and with the comment with the ATI driver.

What should I be doing then - is there something that can be done on my side?

30

Graphics / Re: SFML Context Management

« on: July 03, 2014, 01:58:26 pm »

Telling my users with laptops to update their drivers hoping that it doesn't break something on theirs, isn't really an option either..;

Huh, why not?

I was somewhat referring to my experience with hp laptops and their lack of support for continuous intel graphic card driver updates - grabbing in an intel graphic driver update from the intel site and just manually installing it to laptops with ex. dual graphic cards, seems many a time to cause a variety of crashes to a finely working machine.

I don't think asking my users to take this risk, especially if my current target audience is one that lacks computer knowledge, is really something I'd like to be doing.