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.

Topics - Austin J

Pages: [1]
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
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.

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. 

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


to properly get stored within


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

sf::Uint32 MapFileHandler::Read32()
                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)
                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.

General / A way to cobble sprites?
« on: April 08, 2014, 07:00:11 pm »
  I have a map editor, which uses a sprite for each tile. Obviously since it's a map editor it needs to be ready to change the tiles etc. and I just keep all the tiles to themselves.

  However, in the game itself, I don't want to have to do this. The tiles aren't going to need changes or do anything but be displayed really, and so I'd prefer not to have to make that many draw calls (which leads to lower performance). My maps can have a lot of tiles, so it would certainly be beneficial in my opinion to simply have some big (or maybe even just one?) cobbled together textures to reduce the amount of draw calls.

  Is this correct, and if so, is there a means to do so? I haven't been able to find anything on the subject.

Feature requests / File/Directory Detection
« on: March 19, 2014, 01:59:01 am »
  Forgive me if this has been requested before, but I couldn't find anything related to this so I'm going ahead making this request.

  I don't think SFML needs to handle much file I/O for you. It already loads major file formats like bitmaps and .png's, .wav etc... Other things are up to the user of SFML to do.

  One thing that I think would be really handy though...

  If you wanted to do something like go in a folder and detect what files are there (say the players different saves) you have to use OS specific code to do so. This adds some complexity to keeping your game cross platform.

  Personally just think it would be neat if SFML had a solution to detecting files and directories.

SFML projects / Space - Level Editor
« on: March 04, 2014, 06:40:37 am »
  Space - Level Editor is the level editor I've been working on for a game called *drumroll* Space. (Well the name isn't set in stone, that's just what it is right now). The game itself has minimal functionality currently (I said I wasn't going to work on it without levels to test on)

  The level editor has various neat features (in my opinion anyways):

- Full screen compatibility on practically any monitor
- Fast level saving/loading. You can save and load hundreds of thousands of tiles in 0.5-2 seconds currently.
- A lightweight GUI with mostly clean functionality (I'd be lying if I said it was all clean  ::) ) Includes buttons, 3 windows sizes (small,medium,large), and text entry fields will be coming in a little bit
- Good performance in general ( I.e no lag when painting on tiles)
- Simple tile rotation

Intend to add in the future:
-A scripting system (after making myself go bald and crying a river or two most likely)
-Easy entity and tile creation (I want the game to be highly moddable. The user will be able to create their own kind of entities(space ships, tanks etc.) and import textures for tiles.
- Brush sizes (I just haven't done it yet for some reason)
-Hopefully some more advanced file I/O to prevent accidentally overwriting files etc + one slight issue (currently I don't write the rotation state of the tiles down  :( )

General rule: If somethings looks nice my artist designed it. If something looks horrible I designed it then pray every day afterwards that my artist will actually work this week. I.e that window in the bottom left corner, that would be mine.

General / Help applying line algorithm
« on: February 13, 2014, 01:44:02 am »
  I really wish I could just solve this myself but working with non-Cartesian coordinate system plus a few other things can confuse the hell out of me :(

  I'm working on a map editor that I want to be able to handle quite a few tiles. I've already set it up so that it won't render anything that is outside the view of the window. I can also get the tile the mouse is on by some simple math. (Use the mouses position to know what the index should be). However holding the mouse and moving it more than medium speed will still leave many gaps. I've been wanting to use a line algorithm to solve this, however I'm confusing the hell out of myself I feel like.

  Current implementation I have going it seems like it sort of does what its supposed to, but horribly. If I move the mouse just somewhat fast it's not that big a deal but if I move the mouse very fast it does odd things like this.

The most top right tile and the very bottom left tile, I went in a mostly straight diagonal line between the two, never releasing the mouse. So yeah what I'm doing now definitely doesn't work.

Here's the code I've got trying to deal with this. Note that I'm not worried about views yet, it's not on my to do list currently.

void Map::handleClick(sf::RenderWindow & WINDOW,std::string tile)
        sf::Vector2i mp = sf::Mouse::getPosition(WINDOW);
        sf::Vector2f mousePosition = static_cast<sf::Vector2f>(mp);
        if(lastTile != NULL) // When the mouse is released lastTile gets reset to NULL
                int x= lastTile->getPosition().x;
                int y = lastTile->getPosition().y;
                int x2 = Map::getTileByCoords(mousePosition).getPosition().x;
                int y2 = Map::getTileByCoords(mousePosition).getPosition().y;
                int dx = x - x2; int dy = y - y2;
                for(int i = x/16; i != x2/16;)
                        int cy = (i*(dy/dx))*16;
                        if(i > x2/16)
                                i --;
                        else{ i++; }
        Map::lastTile = &Map::getTileByCoords(mousePosition);

General / sf::String::erase() troubles.
« on: November 18, 2013, 04:45:13 am »
SFML 2.1 - Static
Windows 7 - 64 bit

No matter how I go about it, sf::String::erase() doesn't work properly for me. Whenever I use it rather than erase the character it just replaces it with a box.

(I am filtering out backspace)

sf_string.erase(sf_string.getSize()-1,1); // Results in box first press then nothing afterwards(No size change)

std_string1 = sf_string;
sf_string = std_string1; // Same results

I've tried other ways and it doesn't matter how I go about it I get this damned box.

Any help appreciated, thanks.

Graphics / Help needed with drawing sprite?
« on: September 26, 2013, 07:04:26 am »
It involves a white box, and no, believe it or not it's not because the sprite loses a reference to a texture  ;)

In SDL, when you're drawing tanks, spaceships, monsters, whatever, you had to write some code to get rid of that annoying background.

When I draw a sprite, it has that annoying background, a good example would be my custom mouse cursor.

I haven't been able to find anything regarding SFML on how to keep this from happening. This is the second game I'm working on. Last game was very simple, just an altered version of Battleship, so I could just make the background color for a sprite texture match the board. I can't do that now though.

Can someone be a pal and tell me how to handle this?

Pages: [1]