Messages

1

SFML projects / Re:creation - a top down action adventure about undeads

« on: October 06, 2016, 11:42:24 am »

As Ungod already mentioned, you can have benefits from this - free advertisement. But you do need to continue bashing the thief until people realise he stole it.
Not much you can do, but to continue what you are already doing - grab a megaphone and yell that he stole your artwork. Post on all social media you are using, get as many people as possible to know that and share.

The thief can't keep his charade for long. He doesn't have access your game, and will be unable to fulfill his "promise" to 9gagers.
The people who expect the free game must know that they have been lied to. Even after that, if they have the audacity to ask for a free game, they won't have any solid basis for that request, because you haven't made such promise, so all their "complaints" are invalid. 

Besides, people who want your game for free will try to pirate it anyway.

2

SFML projects / GameStateMayhem

« on: September 15, 2016, 05:27:27 pm »

Hi all!

In February this year I have finished my first ‘big’ project  -  the program that has 3 games in it. The goal of the progam at that time is that I wanted to get aquainted with the program and game states, hence the name. But then it evolved into a full project, and I was using it to implement the ideas for every game on the list. I have already put the screenshots of the prototype last year.

The program was an interesting learning experience for me, in it I kinda learned the basics of game (and generaly the program) flow, resources loading and unloading, draw priorities, rudementary user interface etc…

Unfortunetaly, as the program grew larger, so did the code. Since the code was written in veeery amateurish way, it quickly became unwieldy to add new things or to fix things without breaking the code. So in the end, I decided to call it a day and put the final punctuation.

I originaly wanted to share the code and program in order to get feedback on which part of the code I should work on to improve, but I decided not to because I realised that would most probably mean everything. After that, I have decided to hit the books, internet articles and other people’s open-source code to continue educating myself in neat code design, which is the hallmark of my next big project.

After months of completion of my first project, I have decided to share it, because ultimately, the program does work well... mostly well. And I am interested what you guys think. Personaly, for a novice programer with no formal education in progaming, I do believe that finishing this is quite an important milestone.

Here is the dropbox link to the game: https://www.dropbox.com/s/rslmqq2pj9xx574/GameStateMayhem.rar?dl=0
Still I am hesistant to share the code, but I might do so in next few days (just to get familiar with github). 

Also, here are some screenshots:

Edit: Here is link to the source code, in case you want to take a look on it. (It's awful, you have been warned   )
PS: It uses SFML 2.3.2 version.
https://github.com/Braximus/GameStateMayhem

3

General / Re: Resolution

« on: August 26, 2016, 02:52:42 pm »

I am not 100% sure I understood what you ask, but if you want to know how many fullscreen resolutions can a monitor support, try this:

//  inside a class:
std::vector<sf::VideoMode>      mVideo_Modes

// In a function:
mVideo_Modes = sf::VideoMode::getFullscreenModes();

 

This will give you the list of all resolutions and all bits per pixel (8-bit, 16-bit, 32-bit) a monitor can support.
( you might do a bit to kick out all 8-bit and 16-bit resolutions  )

If you have a windowed screen mode, then just make sure that the width and height of the window are not greater than the desktop resolution.

4

General / Re: My petty dillema: Separation of graphical drawing of UI objects

« on: June 05, 2016, 08:05:15 pm »

Alright, thanks everyone for writing, and thanks recoil for the link, I will read it whole.
I will go with the route of less ressistance and combine the UI objects with drawing components. I do not intent to make them complex, so they can live with it. 

but  i found myself i have to find a way for those classes class Graphic and class Object to be interacting. although, i ended up with some thing like Graphic::update and object::update which is, IMO, pointless.

You do need to compensate for decoupleing objects from drawing. It may look pointless to write two functions that do almost identical thing, but as I said, the perk of decoupleing is to make smaller objects, making them easier to manipulate.

As for their mutual interaction, that is why my objects have an ID variable (simple unsigned int) within them, so the graphic class could know which sprite (or sf::RectangleShape) belongs to which object. It is indeed obvious to me that this aproach can have preformanse impact - graphic class first needs to find a coresponding ID within the std::map before it can update the spirte, and that thing alone can be bad.

But I will not bother with optimisation just yet. I will do so when my FPS drops bellow 30 with 50 drawn objects. In release mode.

5

General / Re: My petty dillema: Separation of graphical drawing of UI objects

« on: June 04, 2016, 08:14:54 pm »

Hi.  I personally dont see whats wrong with having game objects draw themselves.  In fact all of mine do.  It sounds like you may be trying to optimize too early but example code could help in understanding your concern.

When I was starting out with SFML, I too was writing objects in a way that they could draw themselves. It is indeed more convinient for a beginner to write code like that, but it becomes more limitating as the code becomes more complex. Maybe it can affect preformanse significantly, but my projects were never that much demanding, so I can not tell.

In this project I wanted to change my code desing to be more modular, so the classes should not contain the more variables and function than they need.

Oh, and this is how I consider separation of drawing from objects:

(click to show/hide)

Pseudocode and simplified

class Object
{
   int            mID;   // I find this variable most imprortant!!!
   sf::Vector2f   mPosition;
   sf::Vector2f   mSize;
   sf::Vector2f   mVelocity;
// and rest of variables you may want.
public:
   void           update();
   int             getID();
   sf::Vector2f   getPosition();
   sf::Vector2f   getSize();
   sf::Vector2f   getVelocity();

}
 

class Graphics
{
   std::map<int, sf::Sprite>   mGraphicObjects;  // the int is the ID of the object!!!
public:

   void   draw(sf::RenderWindow&);
   void   removeObject(int)   // removes the object of particular "int" ID
   void   addObject(Object); // it takes everything it needs from the object during creation of sprite and puts it in the map container.
   void   refresh(std::vector<Objects>& mObjectContainter); // assume we have more objects
}

 

Of course, the real code that I wrote is more complex, but this is in a nutshell. Don't know is it any good, I will probably find out the hard way. 

And the priciple is the same for UI objects, if I want to draw them like this.

There may be very little benefit in separating a user interface element from its visual representation. In fact, you may consider that the element itself should be a drawable one; that's what it is - a display element, a graphic.

Exactly what I tought.

Maybe I should rephrase my question: Should my code design be the same for all elements, or should I make exeptions where applicable, in case the code design would make things more complex that necessary?

6

General / My petty dillema: Separation of graphical drawing of UI objects

« on: June 03, 2016, 09:12:29 pm »

In my new project, I have started to seperate the graphic drawing from the ingame objects ( i.e. an object contains the position, size, velocity ect... and a Graphic class contains sf::sprite)

My dillema is, does the same code design should also apply to the UI objects, like mostly stationary buttons and labels?

I can understand such logic for game objects, where they would get constantly updated and changed and should not be burdened by all the drawing components, but for UI objects, I do not view them as complex enteties, and I wonder should they contain the drawing components and draw themselves?

Sorry if the question is kinda noobish to you guys.

7

SFML projects / Re: Cendric: An RPG Platformer

« on: May 09, 2016, 03:41:23 pm »

It looks gorgeous.

8

General / Re: Help with basic collisions

« on: May 06, 2016, 05:28:02 pm »

Or better, check if boundry of a sprite intersects wtih a boundry od another sprite:

if (aSprite.getGlobalBounds().intersects(aSprite2.getGlobalBounds()))
{
  // apply rest of magic here.
}

9

SFML projects / Re: Screenshot Thread

« on: April 28, 2016, 03:55:47 pm »

Awesome

10

General / Re: game crashing on draw. Possibly because of pointers.

« on: February 13, 2016, 01:46:16 pm »

This:

if (event.mouseButton.button == sf::Mouse::Left) {
    // Blah, Blah...
    Laser l(rot, spd, pos);     // Object is created;
    Laser * ptr;                // Pointer is created;
    ptr = &l;                   // Pointer points to the memory address of the object;
    p.shots.push_back(ptr);     // Pointer is stored inside the vector in the player class (std::vector<Laser*>)

} // Here things go wrong: The object that pointer points to is destroyed here because it left scope. Pointer is now nullptr.

 

One of the solutions to your problem is to make pointers own their own memory using std::unique_ptr<...>. Access them by including "memory.h".
Most likely you will have to change your own std::vector<Laser*> into std::vector<std::unique_ptr<Laser>>.

Another solution would be simply to not use pointers at all: You already use std::vector, it can store objects instead of pointers. Each time you release mouse button, you should make a object and that object store (copy) into the vector.

That should take care of your problem.

For everything else (or if your problem persists), next time post complete and minimal example and description of the error.


Also, couple of remarks:

1. There is no point to use "this->" inside classes;
2. Call pointer member objects by using "->" operator, instead of "(*Typename)." It makes the code more readable.
3. If default constructors and destructors do not have code in their own declaration, there is no point to explicitly initialize them. This can also be problematic, because you can by accident call the empty constructor and all the members then will be uninitialized;

There a couple of more things too, but these fell under my eye.

11

General / Re: Implementing Collision Detection ?

« on: January 23, 2016, 04:52:28 pm »

The basic collision detection and response is done by using sf::FloatRect:

sf::RectangleShape player;
sf::RectangleShape object;

sf::FloatRect  player_bounds = player.getGlobalBounds();
sf::FloatRect  object_bounds = object.getGlobalBounds();

//  check if two entities collides and make an adequate response:

if (object_bounds.intersects(player_bounds)
{
    // Response
}

// for single pixels, use ".contains" - usually used for checking if mouse is inside object.

sf::Vector2f   mouse_pos;
if (object_bounds.contains(mouse_pos)
{
    // Response;
}

 

Also, keep in mind that bounds of entities always needs to be updated, so after you have moved your entities elsewhere, you need also to call .getGlobalBounds() to it's respective sf::FloatRect again.

12

SFML projects / Re: Screenshot Thread

« on: January 11, 2016, 01:18:56 am »

Here's a video of it in action:

This is awesome on soo many levels 

13

Graphics / Re: Shadermanager [Problem with Noncopyable]

« on: January 07, 2016, 09:11:41 pm »

The error says it all - The shader can't be copied. Therefore, the following won't work.

void add_Shader(sf::Shader shader, std::string name)
{
    // do whatever you do
}

sf::Shader a_shader;

add_Shader(a_shader, "a name");  // This will not work, because the function is using arguments by value (i.e. copying it)
 

A common solution to these problems is to pass arguments by reference:

void add_Shader(sf::Shader& shader, std::string name)   // Note the '&' sign right after the sf::Shader
{
    // do whatever you do - but a map needs to hold a shader reference too.
    a_map.insert(std::pair<std::string, sf::Shader&>(name, shader));
}

sf::Shader a_shader;

add_Shader(a_shader, "a name");  // Now it should work
 

Now, since you probably want that your std::map holds a shader, the upper solution will also not work, because the shader that is already created needs to live long enough for reference to work, and you want your maps to have actual shaders, not references.

Maybe the best course of action is the use of smart pointers:

void add_Shader(std::string name)   // Note that there is no shader here
{
    // Create a shader here using smart pointers
    std::unique_ptr<sf::Shader>  a_Shader(new sf::Shader);
    // Set everything you need for that shader here.

    //  You will also need to make a std::map hold "std::unique_ptr<sf::Shader>" instead of "sf::Shader",
    // then insert it using the "std::move()" function:
    a_map.insert(std::pair<std::string, std::unique_ptr<sf::Shader>>(name, std::move(a_Shader)));
}
add_Shader("a name");  // It should work too.
 

Of course there are other solutions as well, but this should be enough.
You could also pass a smart pointer as a function argument, that should work too.

Edit: minor code correction

14

SFML projects / Re: Zombie Shooter 2000

« on: December 29, 2015, 08:52:52 pm »

Couple of things:

The game stops to respond and it needs to be forcefully closed if the window focus is lost and when roughly 5 seconds have passed (the console is working btw). My wild guess is that you have a malfunctioning timestep with window ".hasFocus()" function. Check your "while" loops and all sf::Clocks and sf::Time.

Also it would be good if you could limit the framerate, because it eats up the CPU if application does not have a frame limit.

Other than that, everything works fine. Managed to kill 89 vertex eating triangles.

15

General / Re: scale and resolution question

« on: December 15, 2015, 12:28:21 pm »

I don't quite understand what you want to do.
As far as I can guess, you want to make the buttons be the same dimensions regardless of the resolution (i.e. to occupy the same space on the screen when resolution is 800x600 or 1280x1024) and you fear that by changing resolution, it will going to mess up the sprites dimensions (or texture rect) inside buttons.
I will assume that this is what you wanted to say. 
If it wasn't, then try again with explaining your problem, preferably with some minimal code.

but each button has its own sprite and when I change the resolution I think it will break because I need all the sprites to stay the same size relative to the resolution of the window

When you set a texture rect to your sprite, it should remain the same until you explicitly demand to be changed. The texture rect of sprite also represents it's dimensions. The only other way to change dimensions without changing the texture rect is to call "scale" or "setScale" functions.

Therefore, changing resolutions shouldn't change the texture rect of a sprite.
But when you change resolutions without changing the dimensions of objects, then they will appear bigger or smaller, in regard of resolution's size.

In order to make object scale with the resolution, you need to use sf::View and keep the old view when you change resolutions.
This is the simplest aproach, do this only when you are recreating windows (usually when they are in fullscreen).

// First create a window:
sf::RenderWindow win(sf::VideoMode(1024,768)), "Bacon", sf::Style::Fullscreen);
// then make a view using the current size of the window:
sf::View view;
view.setSize(win.getSize());
win.setView(view);

// Sometime later, you recreate the window in new resolution...

win.create(sf::VideoMode(800,600)), "Bacon", sf::Style::Fullscreen);
// But now you don't reset the view size, but merely applying the old size onto the new window.
win.setView(view);
// And now the contents of the program will be resized to fit the screen.
 

Bear in mind that this is default behavior when you resize the window with your mouse. But you can't resize when in fullscreen: you need to recreate the window.

Hope it helps.