Messages

1

SFML projects / Re: Ignition Engine

« on: January 13, 2014, 10:08:26 am »

Nowadays the C++ standard removes need for unnecessary checks.

Not nowadays, but since more than one and a half decade. C++ was standardized in 1998.

I only keep these template functions around for DX programming because from what I can tell, it is not safe to use C++11 smart pointers due to reference counting issues

Written in such a general way, that's wrong. I don't see a problem with reference counting, and not all smart pointers use it anyway. std::unique_ptr is a simple pointer wrapper that is just as fast as performing manual new/delete, and it's faster and much safer than your SafeDelete() function.

"Safe delete" is an abomination which inspired a lot of C++ developers to write questionable code, and unfortunately it has survived a long time, even though the original problems have disappeared long ago. One could even call it an anti-idiom; there's absolutely no sane reason to use it. This has nothing to do with C++11, smart pointers and RAII have been around for much longer (boost::scoped_ptr, std::auto_ptr). Even if those are not ideal nowadays and std::unique_ptr should be preferred, they're still much better than any way of managing memory or other resources manually.

If you're interested, read the RAII thread, we all tried to explain why RAII is such a powerful idiom that should be applied wherever possible.

Again I would highly advise against using std::unique_ptr with DirectX COM objects.
http://msdn.microsoft.com/en-us/library/hh279683.aspx
illustrates the idea.

But to each his own I guess. I've already read up on RAII, and yes it can be a great idiom, but it really does depend on your target platform.

For example, I know some developers tend to stay away from RAII designs for embedded systems due to exception overhead.

Also, please stop re-iterating what I clearly already know, and have stated my reasons for keeping it around. Its not going to change the templates, really. Thanks! 

2

Feature requests / Re: sfml for ps4

« on: January 11, 2014, 08:07:21 pm »

Playstation 3 used libgcm as its rendering api, (PSGL sorta became deprecated). Im assuming developers still continue to use libgcm on PS4.

LibGCM and PSGL was an effort by Khronos (from my knowledge) to develop for Sony a version of opengl that could be used on embedded system with a shader pipeline.

There is *probably* a way to get SFML to run on PS4, but Laurent would A) need a license B) anyone wanting to use SFML for Ps4 would aslo need a license.

This is a similar problem to what MonoGame is going to face as they are currently planning a Ps4 release, but it requires you to be a licensed playstation developer.

3

SFML projects / Re: Ignition Engine

« on: January 11, 2014, 07:10:01 pm »

Also, just so you know. It is completely safe to delete a nullptr object from what I can tell. Multiple deletions of a nullptr will do nothing. It is not an error in modern c++.

We know but the question is why do you post code that checks for null before deleting?

Just a habit I picked up when I started learning C++ a while back. My background is in DX programming and you'll find rather quickly why that matters. Most of the resources for learning DirectX from the past decade used either the template functions I posted, or a SAFE_DELETE macro such as this

#define SAFE_DELETE(x) { if(x) delete x; x=NULL; }

These books are written by professionals who coded long before smart pointers, and it was a time where deleting a null value WAS actually dangerous and ill advised hence the check. Nowadays the C++ standard removes need for unnecessary checks.

I only keep these template functions around for DX programming because from what I can tell, it is not safe to use C++11 smart pointers due to reference counting issues, and I don't want to clutter my code with both C++11 smart pointers and COM smart pointers.


That is all. Sorry I wasn't clear before.

4

SFML projects / Re: Ignition Engine

« on: January 11, 2014, 05:55:11 pm »

I don't recommend the SafeDelete() function template, because it's a weak solution to a non-existing problem and because it hides logic errors. If you attempt to delete a pointer multiple times, that's a bug which should be noticed, not ignored. Plus, the if (t) has absolutely no effect.

Anyway, I don't see a reason why you don't use std::unique_ptr -- it's almost always superior to new and delete. Even in the case of Release() you can construct a custom deleter and thereby apply the RAII idiom.

Exactly, that why i specifically said "in replace of delete", it would be much preferred he use smart pointers seeing as its 2014 now...not 1995.

Also, just so you know. It is completely safe to delete a nullptr object from what I can tell. Multiple deletions of a nullptr will do nothing. It is not an error in modern c++.

5

SFML projects / Re: Ignition Engine

« on: January 11, 2014, 06:14:29 am »

Just some input. You should really be using const qualified getters. something like

const sf::Vector2i& Ignition::Camera::Get_cam_size() const
{  
     return *Cam_size;
}
 

Thats just my two cents. That way the return value cannot be modified by the user and your intentions are clear as to what this getter is for. *im assuming just to return the size for info not for modification*

Using pointers is dangerous, so I would recommend return by const correct reference wherever you can and think it would make since.

Write set methods for actually setting the values.

Also, i noticed this line

Manager.~Texture_Manager();

Just call delete...or use

std::uniqure_ptr<Texture_Manager> Manager

and it will
auto delete when out of scope.

Here put this namespace somewhere in your engine for use. Its what I use for memory management of
pointers in replace of delete

namespace Memory
{
        //Due to comments below, I've removed the check for value before delete
        template <class T> void SafeDelete(T& t)
        {
                delete t;
                t = nullptr;
        }

       
        template <class T> void SafeRelease(T& t)
        {
                if(t)
                {
                        t->Release();
                        t = nullptr;
                }
        }
}

There is more, but i think that will give you a start. Cheers!

6

Window / Re: Fullscreen Window OpenGL Distortion

« on: January 02, 2014, 06:20:39 am »

Its not the windowing system. Its my failure at correctly mapping texture coords........ 

7

Window / Fullscreen Window OpenGL Distortion

« on: January 02, 2014, 05:36:36 am »

Okay guys, so I'm getting this weird issue with my SFML window where when I recreate it in fullscreen using
a fullscreen mode retrieved from

sf::VideoMode::getFullscreenModes()

If it helps, here is how i set my window to fullscreen:

void GameWindow::setFullScreen( bool fs )
{

        if(isFullscreen)
        {
                std::vector<sf::VideoMode> modes = sf::VideoMode::getFullscreenModes();
                for(auto mode : modes)
                {
                        if(mode.isValid())
                        {
                                fullscreenMode = mode;
                                break;
                        }
                }

                create(fullscreenMode, windowTitle, sf::Style::Fullscreen);
                setVerticalSyncEnabled(true);
        }
        else
        {
                //revert back to windowed mode
                create(windowMode, windowTitle);
                setVerticalSyncEnabled(true);
        }
       
}

my textured cube primitive looks strangely distorted on the top and bottom. Not sure whether this has something to do with the inner working of DevIL the image library im using to load my texture images or what.

But changing the video mode to fullscreen from windowed makes the top and bottom of the texture look distorted. Here is an image to show what it looks like: