Messages

16

SFML projects / Sassy GUI

« on: August 05, 2015, 11:34:17 pm »

Sassy stands for "straight-forward and su-".... well screw it it doesn't stand for anything it's not an acronym anyways! That's how simple it is. Here is a list of words that could be used to describe Sassy: quick, simple, dirty, straight-forward, robust-ish, ugly, unsafe (currently has scary pointers. That's right you heard me).

Sassy is a GUI made for sfml apps. It contains some generic GUI elements and a simple interface for creating new elements. However it doesn't do much of the work for you, basically just override the processEvent/draw methods and go to town. The purpose of this collection is just to make a GUI in as little time as possible. there is no compiled library just a folder with some headers/source.



Current Features:

• Element interface
• The usual gui elements: Buttons, Sliders, Text-boxes, etc.
• Color theming

Planned features:

• Making creating new GUIs even easier!
• Finding ways to comply with Google's Material Design (That might make it to pretty).
• Adding new default elements: Combo box, color picker, etc.
• Fixing and adding bugs

If you want to get some debug interface up and running quickly I think Sassy might be for you, if you want a sleek UI that players can use, I recommend making something nice and custom. However note that you can still use Sassy for that it'll just require a little more work.

Here's the repo which contains the Sassy source, an example and some other stuff (Debug folder just has a font).
https://bitbucket.org/Verrazano/sassy

Feel free to make suggestions and ask for features. I'll be willing to hear you out.

P.S. Thanks jagoly for the name.

[01:19:00] <Verra> hmm
[01:19:08] <Verra> need to think of a dumb name for a library
[01:19:16] <Verra> or rather just collection of clases
[01:19:37] <jagoly> call it "SQCC"
[01:19:47] <Verra> what's that stand for?
[01:20:06] <jagoly> Sassy Quick Collection of Classes
[01:20:22] <Verra> I like sassy
[01:20:30] <Verra> and so it shall be called sassy

17

General / Re: Advices needed for a HUD/GUI

« on: August 05, 2015, 09:13:20 am »

Here's a quick in dirty setup I threw together a bit ago. It relies heavily on sfml, you might be able to use it as base to get working on your message passing thing you were talking about. https://bitbucket.org/Verrazano/sassy

18

Graphics / Re: Drawing list members

« on: August 05, 2015, 05:10:59 am »

Do you mean std::list or an array, because your syntax list[0] = sf::RectangleShape means array.
Anyways to draw a bunch of objects contained in an array/vector/list is pretty trivial.

for a vector/array:

std::vector<sf::RectangleShape> rects;
sf::RectangleShape box(sf::Vector2f(32, 32));
box.setFillColor(sf::Color::Red);
rects.push_back(box);

window.clear(sf::Color::White);

for(unsigned int i = 0; i < rect.size(); i++)
{
  window.draw(rects[i]);

}

window.display();
 

for a list:

std::list<sf::RectangleShape> rects;
sf::RectangleShape box(sf::Vector2f(32, 32));
box.setFillColor(sf::Color::Red);
list.push_back(box);

window.clear(sf::Color::White);

std::list<sf::RectangleShape>::iterator it;
for(it = rects.begin(); it != rects.end(); it++)
{
   sf::RectangleShape& rect = (*it);
   window.draw(rect);

}

window.display();
 

Hope that helps some.

19

Graphics / Re: My SFML project occasionally BSOD's me

« on: August 05, 2015, 05:04:52 am »

That's a freaky sounding error. Just reading about this error code doesn't look like it could really be your fault. Especially since you say:

Every once in a while when I test the level (in other words, run my Game class and give it the level data, opening a new sf::RenderWindow) I get a blue screen of death with the error "DRIVER_IRQL_NOT_LESS_OR_EQUAL (dxgmms1.sys).  It also happens sometimes when I dereference the Game instance and close the second RenderWindow.

If it's not happening consistently that's not your code. It seems to be an issue with weird drivers. Anyways I think the best thing you could do is to test your game/editor on a few different machines and see if they cause the same error.

Also do you mind posting machine specs, graphics card/driver info?

20

SFML projects / Re: [GUI] SFML backend for ImGui

« on: May 29, 2015, 11:30:58 pm »

The example at the top of the page is outdated as well as the instructions for how to set it up. The repository shows that you've split a lot of stuff into seperate files. I also noticed in imgui-rendering-SFML there is a reference to ImImpl_fontTex which doesn't exist anywhere as far as I can tell. It'd be nice to see you include an example in the repository.

21

SFML projects / Re: Let There Be Light 2

« on: December 02, 2014, 01:20:22 am »

And God said, “Let there be light,” and there was light. God saw that the light was good, and he separated the light from the darkness. And our lord lolz123 spoke and he said, "Have a soley SFML dependent version of LTBL. I will cast out the evil dependencies and your programs will be blessed."

But seriously I've been waiting for this for a long time. Awesome work dude.

22

SFML projects / Re: Thor 2.0

« on: May 09, 2013, 05:54:23 am »

Hello, I've recently built and setup thor and I've finally gotten around to trying to test it out. I started out with particles which seemed interesting . . . and that's where my fun ended. :<

Anyways I feel like I'm missing something blatantly obvious or I just have a setup that's incompatible with thor.
With this code:

#include <Thor/Particles.hpp>
#include <Thor/Animation.hpp>
#include <Thor/Vectors/PolarVector.hpp>
#include <Thor/Math/Distributions.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>

int main()
{
        sf::RenderWindow win(sf::VideoMode(400, 300), "Thor test", sf::Style::Close);
        sf::Event event;

        sf::Texture smoke;
        smoke.loadFromFile("smokeparticle.png");

        thor::ParticleSystem smokeSystem(smoke);
        sf::Clock smokeSystemClock;

        thor::UniversalEmitter::Ptr smokeEmitter = thor::UniversalEmitter::create();
        smokeEmitter->setEmissionRate(15.0f);
        smokeEmitter->setParticleLifetime(thor::Distribution<sf::Time>(sf::seconds(5)));
        smokeSystem.addEmitter(smokeEmitter);

        smokeSystemClock.restart();
        while(win.isOpen())
        {
                while(win.pollEvent(event))
                {
                        if(event.type == sf::Event::Closed)
                        {
                                win.close();
                                return 0;

                        }

                }

                smokeSystem.update(smokeSystemClock.restart());

                win.clear(sf::Color(255, 255, 255));
                win.draw(smokeSystem);
                win.display();

        }

}
 

Errors:
Line 20: Method 'setEmissionRate' could not be resolved
Line 21: Method 'setParticleLifetime' could not be resolved
Line 22: Invalid arguments ' Candidates are: void addEmitter(?) void addEmitter(?, sf::Time) '

I've also tried the example code for particles found on github, with the same errors, everywhere that 'emitter->' and '.addEmitter' are used. I am able to compile the above project with thor if I exclude the emitter code and keep the ParticleSystem it builds and runs properly.

I've setup the compiler flag for c++11 I've tested using shared_ptr separate from the above code with success. I'm using MinGW, gcc 4.7.2 with Eclipse CDT

I hope you have some idea of what's wrong and where I was a derp. Thanks for the help in advanced.

EDIT:

I fixed the issues with functions of UniversalEmitter being unresolved by casting the shared_ptr before using it. like this:

        ((thor::UniversalEmitter)*smokeEmitter).setEmissionRate(15.0f);
        ((thor::UniversalEmitter)*smokeEmitter).setParticleLifetime(thor::Distribution<sf::Time>(sf::seconds(5)));
 

The issues with adding the emitter to the particle system still remain however.

EDIT: EDIT:
I believe I found where I was being a derp all a long. I should have checked the time stamps on the .exe. It was building just the eclipse indexer was saying that there were issues that would stop it from compiling. That still remains a problem so if you know how to fix that, that would be much appreciated.

23

SFML projects / Re: SFML Light System - Let There Be Light

« on: August 19, 2012, 11:32:32 pm »

so first off pretty great library dude, i'm going to be doing a lot of stuff with it and modifying it.  second I did have a lot of trouble with your 1.5.1 release in EclipseCDT - MinGW - gcc 4.7 a lot of errors were being thrown. So my friend and I took about 7 hours to fix it all so now it works pretty well with everything I've got. I'm going to be building an archive file of it soon so you don't have to stick the source in to your project.

Now for the fun part this is the test project I was using. It combines box2d and the ltbl library similar to how you used it in your gore factor remake. I had a few questions about optimization. I've noticed that it has some issues with objects on the same plane, it likes to render shadows on top of things it shouldn't I don't know if it's just because it doesn't take into account other blocks when it renders each one, but is there a way to stop shadows from going through other blocks. Second how would I turn down the intensity of the shadow I noticed in your gore factor game that the shadows were very soft and not quite as hard as the ones in 1.5.1 how would I replicate that. And lastly what's the easiest way to optimize ltbl with box2d so that when you render the shadow it actually keeps up with the physics shape. I've noticed that when I throw a box instead of just being slow to render things the box2d will render faster than the shadow does even though they happen sequentially before I display them on the screen. i.e the shadow will be in a previous position of the box.

Just to show what is happening in my test project here are some screen shots.