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 - Austin J

Pages: [1] 2
1
Feature requests / Re: Vulkan Support
« on: February 18, 2016, 05:23:52 am »
What benefit would Vulkan bring to SFML?

One benefit that Vulkan has is that its API doesn't have 20 years of cruft. This is mostly irrelevant for SFML however, since SFML abstracts the details of the rendering process away.

There are some other benefits that would be good however.

1.)One benefit Vulkan brings is that it inherently reduces CPU workload for rendering. A Vulkan powered app will likely require less time for the CPU to spend handling the overhead than an OpenGL counterpart.

2.) Vulkan is better designed for multi-threaded applications. Unlike OpenGL, Vulkan has been born in a time of multi-threading computing, and is better designed for multi-threading.

The cons of Vulkan vs Opengl is essentially just that Vulkan is obviously much less mature, and that Vulkan is much more complex and verbose. The maturity is an issue. The complexity and verbosity is why would want libraries like SFML to wrap Vulkan in the first place.

2
Feature requests / Vulkan Support
« on: February 18, 2016, 02:54:01 am »
I would have opened this discussion before posting the github issue if I had read the contribution guideline first. I apologize for not doing that.

Obviously this would be a pretty long term goal, but I think it's important to think about for the future.

I haven't read much of the Vulkan specification, but despite some of its structural differences, I haven't seen any reason SFML's current public API couldn't wrap it well. Perhaps there would be a need to add some namespacing to seperate OpenGL and Vulkan details. Parts of the API like
sf::Texture::bind
that edge closer to more direct OpenGL control might need to be reconsidered if adding Vulkan, just a thought.

How SFML would theoretically support rendering in Vulkan in the public API I feel could be taken in two obvious approaches. ( And some others I haven't thought of I'm sure)

The first approach could be two different versions of SFML being developed(vGL and vVulkan), and users choosing which one they want to use. Personally I wouldn't go with this approach, but I wouldn't know better than the team.

The second approach could take after Irrlicht. In the public API, somehow the user could have to specify whether they wish to render using OpenGL or Vulkan. Some sort of render device selection.

It might be wise to let Vulkan gain a little maturity before seriously considering this, but I feel it's not to early to discuss.

3
Window / Re: Window::setIcon(...) documentation
« on: November 13, 2015, 02:55:18 am »
Apologies, I assumed Linux was probably not targetted.

So you're saying that setting an icon with an array containing RGBA data did not change the icon at runtime?

Indeed, it has no effect. It doesn't cause any ill effects either, essentially using Window::setIcon() causes my program to run no differently than if I left it out completely.

The first way I tried using it was by exporting it as a C structure from Gimp. I did make sure for it to export as RGBA by telling it to also save the alpha channel. Naturally I'll exclude the majority of this source as the actual pixel data exported is massive. The first small section is what is important anyway.

Code: [Select]

static const struct {
unsigned int width; // = 64
unsigned int height; // = 64
unsigned int bytes_per_pixel; // = 4 I'd say this makes it fairly certain it's RGBA
unsigned char pixel_data[width * height * bytes_per_pixel + 1]; // u8 array
} feudal_forge_icon = { 64, 64, 4,
// afterwards pixel_data gets defined by a giant exported array also generated by Gimp

};

After including the header file,

Code: [Select]
// Note there are exclusions
Engine::Engine()
{
    m_window.create(sf::VideoMode(800, 600, 32), "Feudal Forge", sf::Style::Default, initContextSettings());
   
    m_window.setIcon( feudal_forge_icon.width, feudal_forge_icon.height, feudal_forge_icon.pixel_data);
}

After seeing this didn't work ( and note I have gotten this to work before on Windows) I decided to try loading the icon from memory.

Code: [Select]
// Note there are exclusions
bool Engine::init(...)
{
    m_icon.loadFromFile("icon.png");

    // The window has already been created in the constructor
    m_window.setIcon(m_icon.getSize().x, m_icon.getSize().y, m_icon.getPixelsPtr());
}

Using this method led to the exact same thing. The icon didn't change, but there wasn't any crash, error message, etc.

Really to replicate my situation you can throw out 99% of my program.

If you'd like to try to compile my first example, you'll need the header file with the embedded image. I'll go ahead and link that. After you have it, it should work with this ( to save you time )

Code: [Select]

#include<SFML/Graphics.hpp>
#include<FeudalForgeIcon.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(640, 480, 32), "Icon Test");

    window.setIcon( feudal_forge_icon.width, feudal_forge_icon.height, feudal_forge_icon.pixel_data );

   while(window.isOpen())
    {
        sf::Event evt;
        while(window.pollEvent(evt))
        {
            if(evt.type == sf::Event::Closed) { window.close(); }
        }

        window.clear();

        window.display();
    }
}


For the second method I tried, I'm sure you can make some minor change to the above code.

I'd include the image directly but it's too large to just throw in the thread, so please look at the attachment.

You can see my icon at the bottom there.

As for the other method, it looks exactly the same.

Other Info:

Ubuntu 15.04 - Unity

Intel i5 - 2.4 ghz
Intel HD Integrated graphics Sandybridge Mobile
(I'm using the latest graphics drivers I can get from the Intel Graphics Installer)
RAM 6gb

4
Window / Re: Window::setIcon(...) documentation
« on: November 13, 2015, 01:08:20 am »
"it didn't work" is not a problem description. What are you expectations and what happened or didn't happen?

Did you actually read what I wrote, or is your only interest being condescending and aggressive? I'm not trying to troubleshoot anything.

My expectation was that it would not work as a matter of fact. Like I said, setting a window icon on Linux is quite different from Windows. There is no standard for reading from an embedded image to set the icon. I don't see how SFML could be expected to get around this. I tested it on Linux anyways to see if my expectation would be wrong, but like I expected it had no result.

sf::Window::setIcon(...) is presented like it's a standard working feature for any platform. If it has platform limitations it should probably documented.

5
Window / Window::setIcon(...) documentation
« on: November 12, 2015, 09:11:02 pm »
Currently the documentation plainly states "Change the window's icon." This has worked great for me on Windows before to easily set a window's icon, even make the icon embedded in the executable if I want to. SFML aims to support other OS's however.

I decided to try to use setIcon() on Ubuntu 15.04 two ways. First using an imported C - struct from Gimp, then using a loaded image
Code: [Select]
window.setIcon(img.width, img.height, img.pixel_data) // pseudo code and unsurprisingly it didn't work, to get my own window icon I had to create a .desktop file for it to use. I don't develop on OSX, but from what I can tell it doesn't support embedded icons either.

Now don't think I'm stating "SFML needs to make setIcon() work on these other platforms." I don't think that's feasible at least for Linux as if I'm not mistaken, there's no standard way to handle it.

To be honest, I don't think I would have ever even added Window::setIcon(...) personally. It's already implemented, and to me that's fine. I do find it a niche user feature for Windows however. The documentation makes no mention about any of this.

In a nutshell, I'm not suggesting a change in the implementation of Window::setIcon(..) or that it be removed. I'm suggesting that maybe the documentation should in some way acknowledge the platform limitations of the method instead. 

6
General / Re: Unresolved externals
« on: October 08, 2015, 08:32:48 pm »
I know it, in fact SFML uses STB for its image loading ;)

But I didn't see anything special with this library, that's why I asked. I think the author just wants to keep everything as self-contained and minimal as possible, without tons of external configuration scripts. Every makefile and meta-build system incurs another dependency for those who want to use the library.

Many libraries use #define and #ifdef for conditional compilation and linkage, that's perfectly fine. But when using libraries in your project, it's usually easier to set configurations globally and not in code. Of course, there are no hard borders, in the end it's a matter of achieving the right things with minimal effort.

With that friend I can't disagree with anything you say there. Interesting to learn that SFML actually uses STB though, I had no idea! I don't know about stb's image loading, but I remember that stb_tilemap had a lot of configuring done through #define in its source. This was understandable in my opinion because he had to create a whole UI and tilemap system without knowing for sure what settings the user wanted (i.e the max tilemap size) and without any of his own rendering implementation. That's a very niche scenario though.

7
General / Re: Unresolved externals
« on: October 08, 2015, 08:12:08 pm »
Forgive me, maybe you haven't heard of stb  :P

https://github.com/nothings/stb

If you haven't come across stb before and you're interested in what is go ahead and check out that git repo.

I myself have never made serious use of his "libraries", but in many of his header files he makes use of #define in the source directly for settings etc.

I understand this is an odd example, and that's precisely why I'm saying I agree not using preprocessor settings in what ever form of project manager you have is a bad idea, but I'm not convinced that 100% of people out there don't have a good reason to make use of #define directly in their source. I feel there's bound to be the rare exception.

I'm dragging this a bit out of scope though I apologize. In SFML's case where it's simply SFML_STATIC in mind, I can't imagine a reason to define it in source and you're right I shouldn't have even mentioned it in my original post. When I say I believe there's a rare exception I mean with using #define in general not specifically for SFML.

8
General / Re: Unresolved externals
« on: October 08, 2015, 08:03:01 pm »
Quote
You define it in your CMake script with possibly an option to enable/disable static linking.
Actually if you use the FindSFML.cmake module script and define SFML_STATIC_LIBRARIES (as explained in the FindSFML.cmake file itself), SFML_STATIC will be set automatically.

There's always some sort of "project settings", be it a makefile, a CMake file, an IDE project file or even just the raw command line that will allow you to define the SFML_STATIC project wide and as such there's (in my opinion) no use case where #define SFML_STATIC is valid.

Haha, I suppose I should've expected that answer. Yes and as a matter of fact I already use FindSFML.cmake in any SFML project I use. Sometimes when using Boost libraries one must #define <something here> and indeed I always do it in the "project settings" of cmake, qmake, IDE settings, whatever. I gag a little at the Irrlicht site when they use #pragma to link their library in the tutorial programs.

Where I'm disagreeing is when you say "never". I myself indeed never need to use #define directly in the source. The only exception I can think of for myself is using some of the stb libraries. STB libraries to me are actually examples where not using some form of a project setting for preprocessor defines is understandable. So I do think that using #define in your source is very rarely appropriate, but I won't say it's never appropriate in my honest opinion.

9
General / Re: Unresolved externals
« on: October 08, 2015, 06:30:57 pm »
Quote
Never define SFML_STATIC in the code itself with #define.

For his circumstance I agree, I suppose I should clarify I just meant it's possible to do that not that you should. I'm curious however, what would you propose if someone was using a development environment more like mine? I don't use an IDE, I use Vim, cmake, and make and that's about it. Obviously I'm not statically linking on Linux, but some people on Windows believe it or not don't use IDE's like VS or QtCreator either.

10
General / Re: Unresolved externals
« on: October 08, 2015, 03:25:08 am »
I wouldn't call this enough information. In a nutshell I believe with VS though the steps are -

1.) Add include directories
2.) Add lib directories ( make sure you have appropriate version for your build)
3.) Also add to your linker " sfml-system-x-x.lib etc. " (appropiate to versions for your build)
4.) Since you're going with static, I believe you need to define SFML_STATIC. You should be able to add this to your preproccesor settings or you can add it into your source directly
Code: [Select]
#define SFML_STATIC
Assuming I have these steps right ( someone correct me if I'm wrong, I haven't used VS in ages) , are you sure you went through those steps?

If you're really having much trouble, someone here might be kind of enough to look at your project file themselves. I'd be willing but I don't have a Windows machine, so sorry but I cannot.

11
Feature requests / Re: Object Loader (similar to AssImp)
« on: February 08, 2015, 07:27:21 pm »
Anyways IMO if you want to mix 3d with 2d much at all, you're a lot better off just picking a 3d lib, whether it's OGRE, Irrlicht, Horde, whatever, the fact is these libraries aren't exclusively 3d, they have 2d features, and I think it makes better sense to go with them than to make a Christmas list for Laurent to look at.

12
Feature requests / Re: Object Loader (similar to AssImp)
« on: February 08, 2015, 07:23:18 pm »
From assimp site:
Quote
No external dependencies except boost
No dependencies... oh, yeah, just boost.

1. SFML doesn't deal with 3D

2. I know something similar to ASSIMP that works very well: ASSIMP

I love the sass in this thread!  ;D

13
Graphics / Re: sf::Texture load from memory
« on: January 22, 2015, 06:18:52 am »
Yeah, the only time I've seen the call for loadFromMemory() is if you loaded the file with another lib, then passed it on, which does arise for some people.

14
Graphics / Re: tile glich.
« on: January 22, 2015, 05:54:54 am »
I've personally had a lot of experience with tile engines, and I'd say one-dimensional array on the heap is certainly the best way to go. For really large tile maps as a warning though you might not be able to just use any STL container such as a vector, because such are limited to one contiguous memory chunk. So I often times found myself hitting a wall with tile sizes with 1000x1000 dimensions using STL containers. I was able to optimize it a bit hand rolling my container but it honestly didn't make much of a difference. I'm pretty sure there are containers out there that aren't limited to one chunk though, I haven't personally tried one however.

15
General / Not sure how to read write correctly with sf::Uints?
« on: June 01, 2014, 05:25:46 am »
I went ahead and used SFML's sf::Uints for file I/O. From what I can see it's just the common typedefing such as

typedef unsigned char uint8

When trying to read and write however, I'm not getting

sf::Uint8[4]

to properly get stored within

sf::Uint32

Files are reading completely wrong, and my ide is giving warnings about me shifting wrong.

sf::Uint32 MapFileHandler::Read32()
{
        if(inFile.is_open())
        {
                sf::Uint8 bytes[4];
                sf::Uint32 value;

                inFile.read(reinterpret_cast<char *>(bytes),4);

                value = bytes[0] | (bytes[1] << 8) | (bytes[2] << 16) | (bytes[3] << 32);

                return value;
        }
}
 

void MapFileHandler::Write32(sf::Uint32 & u32)
{
        if(outFile.is_open())
        {
                sf::Uint8 bytes[4];

                bytes[0] = u32 & 0xFF;
                bytes[1] = (u32 >> 8) & 0xFF;
                bytes[2] = (u32 >> 16) & 0xFF;
                bytes[3] = (u32 >> 32) & 0xFF;

                outFile.write(reinterpret_cast<char *>(bytes),4);
        }
}
 

I'm not very good with handling bits themselves and haven't used these types a whole lot in the past.

Pages: [1] 2