Messages

1

Graphics / Re: Trying to load glitched JPG file causes access violation

« on: April 09, 2015, 10:48:34 am »

The fact that other tools are able to display your possibly corrupted image, doesn't mean that it is valid. We're using a small library, stb_image, to load images in SFML, and it may be able to handle some cases of incorrect data, but certainly not all.

Unlless you can prove that your modified image is still a valid JPEG file, or that your modification is likely to happen to real-life JPEGs, nobody will take the time to find a "fix" for you.

That's basically what I wanted to know. ^_^

Seems I'll have to get in depth with the JPG format then.

2

Graphics / Trying to load glitched JPG file causes access violation

« on: April 09, 2015, 01:00:03 am »

Yo,

So basically I was messing around with some JPEG-glitching. I changed some bytes between the end of the JPEG header and EOF and tried to display the new image, but encountered access violations. Sometimes the image loading would work, sometimes it would not, and I can't figure out when and why.

This is a glitched image that makes the application throw an exception:


Here is a minimal example:

#include <SFML\Graphics.hpp>

int main() {

        sf::RenderWindow window(sf::VideoMode(800, 600), "G-Glitch", sf::Style::Close);
        sf::Texture tex; tex.loadFromFile("newpic.jpg");

        sf::Sprite spr(tex);

        sf::Event event;
        while(window.isOpen()) {
                while(window.pollEvent(event)) {
                        switch(event.type) {
                        case sf::Event::Closed:
                                window.close();
                                break;
                        }
                }

                window.clear();
                window.draw(spr);
                window.display();
        }

        return 0;
}
 

The weird thing is that the image displays just fine in my browser and native image viewer.. Can someone please explain this phenomenon?

I'm not linking debug code with release libraries or vice versa. I've been using SFML for a couple of years now. ;^)

~BZep

EDIT!:
Here is the original picture to actually prove that the other particular picture is causing misfits:

3

SFML projects / Re: Image Atlas Generator

« on: December 20, 2014, 05:01:40 pm »

By the way: The included header for the image_atlas can be found here: https://github.com/cgloeckner/SfmlExt

Errr...

4

SFML projects / Re: Image Atlas Generator

« on: December 20, 2014, 04:31:58 pm »

Great project!

Is it on GitHub?

Would like to follow this, so I can quickly find it if I found a need for it.

5

SFML projects / [LD48 #31] Owl'd Hurricrash

« on: December 19, 2014, 10:25:16 pm »

Late forum submission but what the hell.

Found the time to compete in the Ludum Dare 31, so I conjured up a game with SFML:





I highly recommend playing the PostJam version
The goal of the game is to stay alive for as long as possible. Your energy is displayed on the orange bar and can be replenished by eating fish (in the water). Score is accumulated when you return to your nest.


The game is written in C++ with Visual Studio 2013 (C++11) and SFML 2.1. Lots of elements from the SFML Game Development Book are included, like the State Machine, Resource Loading and Sound Player. I've also built the game on top of my SFML extension: bzsf.


Links:
- Owl'd Hurricrash on LD
- bzsf on GitHub
- PostJam source

6

Graphics / Re: Why is sf::Drawable::draw() private?

« on: December 19, 2014, 03:48:01 pm »

As another alternative, imo "animation updates" belong in an update() method, separate from the draw() method, so you could simply inherit from sprite, add an update() method, and leave it at that.

I completely agree with this. I'll consider the public sf::Sprite or this solution. Both will have to make me change the source code in my projects that use this, so I think I'll implement it correctly and add the update() method.

7

Graphics / Re: Why is sf::Drawable::draw() private?

« on: December 19, 2014, 02:48:50 pm »

It would be cleaner to have a class that's Drawable and has a Sprite (composition):

I know and I have tried that.
But I wan't my class to behave exactly like an sf::Sprite with a little added functionality, and forwarding all calls to the member is really tedious. I guess I could do some sort of sf::Sprite& getSprite(), but I find the other solution a lot cleaner. :/

sf::Sprite::draw is private exactly because we want to prevent users from inheriting from it, as it's generally a bad idea. Can you explain why you want to do that?

I guess what I want to do is a bit hacky, but it's so much easier than having to call another method do the work before drawing. Basically I just want to do some animation updating in the draw call and then draw the sprite afterwards.

8

Graphics / Re: Why is sf::Drawable::draw() private?

« on: December 19, 2014, 06:06:31 am »

Exactly how do I call the sf::Sprite::draw()?

I have:

class MyClass : public sf::Sprite {
    private:
    void draw(sf::RenderTarget& target, sf::RenderStates states) const {
        // My functionality
        sf::Sprite::draw(target, states); // Yields compiler error due to member being inaccessible
        sf::Drawable::draw(target, states); // Yields linker error
    }
}
 

So how do I do it the correct way? o:

9

Graphics / Why is sf::Drawable::draw() private?

« on: December 18, 2014, 02:32:11 pm »

Okay holy ****, I spent 2-3 hours struggling with this issue last night without noticing that the original access modifier on Drawable's draw() is indeed protected. I'll toy some more with it when I get home and report back later.

10

Graphics / Why is sf::Drawable::draw() private?

« on: December 18, 2014, 01:56:54 pm »

I'm trying to extend the sf::Sprite class with some magic functionality before the derived sf:: Sprite::draw() call, while still allowing the window.draw(drawable) type of call, but it seems almost impossible due to the access modifier on draw() being private and not protected. Of course I could  contain an instance of sf::Sprite within my custom class, but I don't want to forward all calls to this instance.

Generally I've been told that making virtual functions protected and not private is a good code style, as having to call the original function within the derived is often a desired functionality. What is the reasoning behind not doing it here?

~BZep