Messages

1

SFML projects / Re: libgfx - Image file format (PNG) with custom data

« on: October 07, 2015, 08:19:20 pm »

There are many sources talking about "metadata", but it seems like "chunks" is the official term [1] [2].

About names... Some ideas:

• "png" + something along "chunk" or "meta"
• "png" + adjective expressing the versatility or self-containedness
• use cases in games... something along "attribute", "property", "trait", or better more specific ones
• names (like I did with Thor). Just don't choose one that will be a movie in the future

Thanks for these ideas, I might think about it later.

It's fully ported to C now and my existing project (after minor updates) still loads my png files successfully

2

SFML projects / Re: libgfx - Image file format (PNG) with custom data

« on: October 07, 2015, 06:35:26 pm »

Thank you for your feedback

It's surprising that existing PNG libraries don't handle metadata or at least not easily. The feature is probably too rarely used.

I'm not sure, if that, what my lib does, can be considered "handling metadata", as it does not handle the author, creation date, comments etc. yet. It only handles the actual image data and private chunks with arbitrary data in it, where you define its format yourself.

Your API uses a strong C style. Don't you want to write it in C directly? It seems like you're hardly using any C++ features anyway. Such low-level libraries are likely to become much more popular when written in C, as they can be used in C code and easily be invoked from other languages.

It would still be fairly trivial to write a C++ wrapper on top. But the current state is not ideal: C++ developers have to use a mix of C and C++ style interfaces, but C developers are not able to work with libgfx because it's written in C++.

I guess, when I started this library, I considered writing it as a pure C library, hence this overall design. Then I wanted to use std::vector for pixels, chunks etc., and you see what happened
After reading your response, I reconsidered it, and yeah, pure C would definitely better. So, I'm going to change the implementation a bit, so that it is really pure C then.

By the way, isn't "libgfx" a rather generic name, especially since it doesn't express anything about PNG and metadata? I'd choose something more precise, also to make it easier to search and distinguish your library from other projects named the same.

When developing games, I liked the idea of using my very own graphics format, that exactly fits the needs of my games, and I would have given it the file name extension ".gfx". But why making another graphics format, possibly with poor or no compression, if PNG is already good at it and even officially support private data (chunks), you can embed in your PNG file?
That's where the name comes from. You may even handle the file signature yourself, so I could replace the usual PNG signature with my very own one, disallowing others to open my graphics in an image program that easy
So, it could be possible that I will really use that feature of using my own signature and use the .gfx extension, so that not everybody immediately sees, that it's actually a PNG file.

Anyways, do you have an idea for another name? Maybe "metapng", but... as mentioned above, my library is not intended to handle "meta" data, but private chunks and the actual image data.

3

SFML projects / Re: libgfx - Image file format (PNG) with custom data

« on: October 06, 2015, 10:15:14 pm »

libgfx 0.0.1 (Beta) released on github!

There have been minor changes and bugfixes in my library and I started using git and publishing it on github. I forgot to increase the version number, but as it is already working quite well in my projects, I consider it now being beta.

You can go to the github page and download the most recent version. It is currently designed to be compiled and installed on a unix or unix-like environment, i.e., it depends (by default) on /usr/local, pkg-config and pre-installed libpng.

4

General discussions / Re: distributing SFML projects on Linux (binaries)

« on: February 15, 2015, 01:41:47 am »

I was reading around the Web and I thought I came across some discussions that static linking on Linux wasn't preferred (although I can't remember the exact reasons - I think it was a StackOverflow discussion).

As far, as I know, dynamic linking is preffered on Linux because it usually has a well managed package manager. For example, don't link your Linux app statically with OpenAL or FreeType, use the dynamic linking and let the package manager care about the dependencies. And, unlike Windows, on Linux having several versions of the same library for dynamic linking is quite good supported. However, what about less known/distributed libraries? I don't know.

5

General discussions / Re: distributing SFML projects on Linux (binaries)

« on: February 14, 2015, 10:52:49 am »

Hm, if you suggest to distribute the SFML lib (.so) with the app anyway, why not linking the app statically with SFML then? That would even eliminate code, that is never called by the app.

6

General discussions / Re: distributing SFML projects on Linux (binaries)

« on: February 13, 2015, 03:57:25 pm »

This link may also be of some use/interest: http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

That's interesting and useful, thanks!

7

General discussions / Re: distributing SFML projects on Linux (binaries)

« on: February 13, 2015, 03:38:27 pm »

At runtime when the app needs to find its own files in "data/" & "etc/" it can just read the  "/proc/self/exe" symlink to find out where it is located, strip the executable name from that path and add "../data/" and it then has a path to its data files. This works regardless of where the user moves the app to.

Wouldn't it work using the path passed with the first argument to main (argv[0]) as well?

There should be tutorials on the wiki about best practices distributing SFML apps for Windows, Linux and Mac (at least, I can't see any such tutorial yet).

8

General discussions / Re: distributing SFML projects on Linux (binaries)

« on: February 13, 2015, 02:47:57 pm »

Some linux distros already provide SFML in the official repositories (such as Linux Mint 17.1, having SFML 2.1), so I would like to distribute my binary with its game data in an archive (e.g. tar.gz) and tell the user he has to install SFML 2.1 via package manager. Unfortunately, some distros don't have SFML or only version 1.6 in the official repository. So, I should rather provide the SFML binaries with the archive? I'm not sure, if that is the best design (of not working with system dependent packages like rpm or deb). Any ideas?

9

General / Re: Having a problem with glGenBuffers(...)

« on: January 05, 2015, 07:38:09 pm »

Tenry, you should be using glGenBuffers(2, &vbo).

Nope. The second parameter expects a pointer to the first GLuint of an array. If I have declared a real array (using GLuint vbo[n], n being a number 1 or greater), vbo equals a pointer to vbo[0]: vbo == &(vbo[0]), that's why I don't need the ampersand.
You're are right if you do like in most tutorials, declared GLuint vbo. Here, you don't have any array and so vbo is a plain integer. By using &vbo you retreive a pointer to your only element.

10

General / Having the same problem

« on: January 04, 2015, 07:14:07 pm »

I have the same problem trying to use OpenGL - for learning. My program:

#include <SFML/Window.hpp>
//#include <SFML/OpenGL.hpp>
#include <GL/glew.h>

#include <stdint.h>

GLuint vbo[2]; // I want to generate two VBOs

void drawProc()
{
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
  glClearColor(0.f, 0.5f, 1.f, 1.f); // light blue
}


int main(int argc, char **argv)
{
  sf::ContextSettings settings;
  settings.depthBits = 24;
  settings.stencilBits = 8;
  settings.antialiasingLevel = 4;
  settings.majorVersion = 3;
  settings.minorVersion = 0;
 
  sf::Window window(sf::VideoMode(800, 600), "OpenGL Test", sf::Style::Default, settings);
  window.setVerticalSyncEnabled(true);
 
 
  float triangle[9] =
  {
    -0.4f, 0.1f, 0.0f,
    0.4f, 0.1f, 0.0f,
    0.0f, 0.7f, 0.0f
  };
 
  float quad[12] =
  {
    -0.2f, -0.1f, 0.0f,
    -0.2f, -0.6f, 0.0f,
    0.2f, -0.1f, 0.0f,
    0.2f, -0.6f, 0.0f
  };
 
  glGenBuffers(2, vbo); // gdb says, that this program crashes on this line
 
  /*glBindBuffer(GL_ARRAY_BUFFER, vbo[0]);
  glBufferData(GL_ARRAY_BUFFER, sizeof(float) * 9, triangle, GL_STATIC_DRAW);
 
  glBindBuffer(GL_ARRAY_BUFFER, vbo[1]);
  glBufferData(GL_ARRAY_BUFFER, sizeof(float) * 12, quad, GL_STATIC_DRAW);*/
 
 
  while(window.isOpen())
  {
    sf::Event event;
    while(window.pollEvent(event))
    {
      if(event.type == sf::Event::Closed) window.close();
    }
   
    drawProc();
    window.display();
  }
 
  return 0;
}

I already got the code working with the drawProc and not generating any VBO, my screen was cleared blue, as wished. But as soon, as I try to generate a buffer (only works, when I include GL/glew.h, it is not available with SFML/OpenGL.hpp...), my program crashes.

I am using linux (64-bit) and compiling the program above with the following command:

Code: [Select]

g++ main.cpp -o opengl-test -g $(pkg-config --cflags --libs sfml-window gl glew)

EDIT: glewInit() right after the window creation solves the problem in my case!

sf::Window window(sf::VideoMode(800, 600), "OpenGL Test", sf::Style::Default, settings);
glewInit();

11

SFML projects / libgfx Alpha released!

« on: April 02, 2014, 05:36:23 pm »

libgfx 0.0.1 (Alpha) released!

Linux (with source code): libgfx-source-unix.tar.gz
Windows (with source code): libgfx-source-win32.zip

12

SFML projects / libgfx - Image file format (PNG) with custom data

« on: March 16, 2014, 10:08:53 pm »

A long time ago, I started a topic about custom information in the PNG file format, which can be useful to store sprite animation data and other stuff, so you don't need extra data files or your own, possibly quite poor graphics file format, just to get these extra data stored.

Finally, I am working on a library for my current project, that is able to read and even write PNG files with custom chunks, named libgfx. It can even be used for loading and writing PNG files without the need of SFML/sfml-graphics (e.g., if you write a low-overhead console application, that shall read/write PNG files), and it will also convert the pixels data to your need (e.g. to 32-bit RGBA, no matter if the file format is 24-bit RGB or palette). And if I remember well, SFML does not support PNG based on palettes (did it change already?).

Download Beta (0.1.0)
https://github.com/tenry92/libgfx

Download Alpha (obsolete)
Source Code + Linux Compiled: libgfx-source-unix.tar.gz
Source Code + Windows Compiled: libgfx-source-win32.zip

Issues

• This is still beta and currently designed for my personal used. This means, only a selected set of color formats and bit depths are supported at the moment. This includes, that it DOES load png files with palettes, but gives you the pixels in pre-converted rgba values at the moment.

Example writing PNG file with custom chunk:

GfxImage gfx;
gfx.colorFormat = GfxFormat_RGBA;
gfx.bitDepth = 8;
gfx.width = ...; gfx.height = ...;
/* allocate the memory based on the specs given above */
libgfx_createImage(&img);
/* now you can set your data in gfx.pixels */

libgfx_createChunk(&gfx, "isPR");
GfxChunk *myChunk = gfx.userChunks[gfx.nUserChunks - 1];

int err = libgfx_writeGfxFile(&gfx, "output.png");

libgfx_destroyImage(&gfx);

Example reading PNG file with custom chunk:

GfxImage gfx;

/* no matter what the input format is, give me 8-bit RGBA */
gfx.colorFormat = GfxFormat_RGBA;
gfx.bitDepth = 8;

int err = libgfx_loadGfxFile(&gfx, "input.png");
if(err != GfxError_None) return 1; // error occurred

if(gfx.nUserChunks > 0)
{
  GfxChunk *myChunk = gfx.userChunks[0];
  /* do something with the user chunk... */
}

libgfx_destroyImage(&gfx);

EDIT: This is, how I currently use libgfx for loading my graphics into OpenGL, might be useful for you:

GfxImage img;

int ret = libgfx_loadGfxFile(&img, filename);
switch(ret)
{
  case GfxError_None: break;
  default: throw std::runtime_error("Unknown error loading " + filename);
  case GfxError_ColorFormat: case GfxError_BitDepth:
    throw std::runtime_error(filename + ": Color format not supported");
  case GfxError_File: throw std::runtime_error(filename + ": Not found");
  case GfxError_FileFormat: throw std::runtime_error(filename + ": Unknown format");
}

if(img.bitDepth != 8)
  throw std::runtime_error(filename + ": Color format not supported (8-bit rgba expected)");


/* OpenGL usually only supports dimensions like 128x64 or 256x256. */
int nearestWidth = exp2(ceil(log2(img.width)));
int nearestHeight = exp2(ceil(log2(img.height)));

tex->actualWidth = img.width;
tex->actualHeight = img.height;
tex->textureWidth = nearestWidth;
tex->textureHeight = nearestHeight;

/* We need to resize the image to fit OpenGL's requirements. */
if(img.width < nearestWidth || img.height < nearestHeight)
{
  /* resize actual texture. note: pixels out of bounds may have random data */
  std::vector<uint8_t> pixels;
  pixels.resize(nearestWidth * nearestHeight * 4);
 
  for(int y = 0; y < img.height; ++y)
  {
    memcpy(&pixels[y * nearestWidth * 4], &img.pixels[y * img.width * 4],
      img.width * 4);
  }
 
  glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, nearestWidth, nearestHeight,
    0, GL_RGBA, GL_UNSIGNED_BYTE, pixels.data());
}
/* The image's dimensions already fit the requirements, pass it already. */
else
{
  glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, nearestWidth, nearestHeight,
    0, GL_RGBA, GL_UNSIGNED_BYTE, img.pixels);
}

13

General discussions / Re: AW: I am developing a game using 2 engines - comparison

« on: January 23, 2014, 03:45:26 pm »

Better key handling is on its way, not sure if Laurent has made a decision yet.

Yeah, I read a recent topic about it here (by Laurent I think), where it was discussed and compared with other libraries.

Also assuminv that "codes" are equal between libraries is a flawed assumption from the beginning. Instead you'd havd to abstract the codes again and use your own ones for thd config file.
With SFML you could use Thor's action map.

There are generally 2 ways how the config file might identify the keys:

• library-independent: I store scancodes or key names, and convert them to the lib-specific IDs.
• library-depentent: I store the codes given by the lib (with SFML it's the enum values, with SDL I can choose whether I want the scancodes or the physical position related codes).

At the moment I am the second version (having 2 different config files, one for each library) to avoid the need of a long switch-case or other kind of long mapping data.
The key (and gamepad button) mapping is almost fully implemented, I am not using Thor's libraries, but thx

SFML was never meant to have different backends and especially no software renderer, since that was exactly the one of the reasons why SFML was built.

That's okay, that's why it is called a simple library.

As for you VM you'll need to activate GPU rendering.

Possible. But strangely, the SFML version worked without any problems, although it uses OpenGL in any case. With SDL, I couldn't initialize OpenGL. Maybe there's a version issue or something...

14

General discussions / I am developing a game using 2 engines - comparison

« on: January 22, 2014, 05:08:20 pm »

Hello everybody,

I am currently working on a 2D platformer game using various libraries for certain tasks. But for the most general functions - window, graphics - I am using two libraries: SFML and SDL. Nope, I am not using them both the same time. Instead I am developing two versions of the game: one based on SFML, the other one on SDL.
Reasons why I am doing this is because I like SFML and I believe that the new SDL 2 isn't bad, either. Both have their pros and cons (there are tons of discussions, speed tests etc. on the web), but I will do the direct comparison in a real case example. There are issues I am encountering and I want to share them with you while developing on that game. When the game is (almost) finished, I will propably decide for only one of the two versions, but as of now, I am developing both.
Note, that I an not using any of these two libraries for loading graphics from the files or playing music/sfx.

Feel free to discuss about my points.



Key Mapping
The first "issue" I encountered is the key mapping. I am using a configuration file where the key mapping is set. Each action (jump, move, confirm, ...) is assigned a "key" to. That might be a key of the keyboard, a button of the joystick etc. I wanted to use a common config file for both game versions, but I found out that the both the keyboard "key codes" and the gamepad "button indices" differs in SFML and SDL. I'd prefer SDL's way of identifying the keys either by standardized scancodes or physical location. SFML instead gives the keys completely different IDs, making the configuration incompatible to each other. There was already a discussion about it in the SFML forums, and I think, it's even an issue in the SFML tracker.
I am confused about the different button IDs of the same gamepad in the libraries (using Windows), more details to come...


Graphics Engine
SFML is completely OpenGL based, whereas with SDL the programmer has the choice (Direct3D, OpenGL or even Software-rendered). I tested the SDL version on WinXP in a virtual machine, but I couldn't initialize Direct3D nor OpenGL, only the software-version worked (which is propably the slowest of these). I feared that SFML wouldn't work at all (OpenGL), although it might only be a VM issue. But luckily, the SFML version runned in the VM without any issues!


Threaded Loading (Textures)
Loading textures in a separate thread is quite easy in SFML. You need to care about activiating the OpenGL context in the thread, you are currently working in, but that's all. There's even a tutorail about this in SFML's wiki.
SDL, however, does not support this feature, as far, as I know. There is even a ticket about that issue.

15

Feature requests / Re: Joystick information

« on: January 05, 2014, 05:15:34 pm »

I am having the same issues and I found a nice website, that might help at least a little bit: http://pineight.com/mw/index.php?title=USB_game_controller