Compiling on Linux - how to.

[davemoore22]

This is a wonderful library. It doesn't compile on Linux out of the box however, but with a modicum of work I got it compiling and working wonderfully on Ubuntu 20 (SFML 2.5.1) using Codeblocks 20 with the following steps, so I thought I'd drop you a line to tell you what I did.

1. Convert cpp and h files to ASCII Format (they're currently in Unicode 16 UTF)
2. Create a new Codeblocks project in the toplevel Example Demo folder.
3. Add Demo.cpp and pch.cpp to the Project.
4. Add the header files in Demo Activities.
5. Rename these header files to be exactly the same case as they are referred to in the code (due to Linux case sensitivity)
6. change references to rsize_t to size_t (IIRC they're the same) in the header files
7. change references to strtok_s to strtok (again, these ones are cross-platform IIRC)
8. add the top level src, the Swoosh, and DemoActivities to the search paths.
9. link to the usual SFML libraries (sfml-graphics, and so on)

Compile, and run from the terminal (see screenshot below)

There's no music on the main menu the first time around, but music plays fine after that.

Thank you for an excellent library.

[TheMaverickProgrammer]

Im glad you're enjoying the utilities swoosh has to offer, Dave. I admit the demo is not convenient to build at the moment. I do have plans in the next month to make it posible to generate IDE and build scripts using cmake. This should make things easier.

…

On Tue, Jun 2, 2020, 1:21 PM Dave M ***@***.***> wrote: This is a wonderful library. It doesn't compile on Linux out of the box however, but with a modicum of work I got it compiling and working wonderfully on Ubuntu 20 (SFML 2.5.1) using Codeblocks 20 with the following steps, so I thought I'd drop you a line to tell you what I did. 1. Convert cpp and h files to ASCII Format (they're currently in Unicode 16 UTF) 2. Create a new Codeblocks project in the toplevel Example Demo folder. 3. Add Demo.cpp and pch.cpp to the Project. 4. Add the header files in Demo Activities. 5. Rename these header files to be exactly the same case as they are referred to in the code (due to Linux case sensitivity) 6. change references to rsize_t to size_t (IIRC they're the same) in the header files 7. change references to strtok_s to strtok (again, these ones are cross-platform IIRC) 8. add the top level src, the Swoosh, and DemoActivities to the search paths. 9. link to the usual SFML libraries (sfml-graphics, and so on) Compile, and run from the terminal (see screenshot below) There's no music on the main menu the first time around, but music plays fine after that. [image: image] <https://user-images.githubusercontent.com/48893555/83555303-fdd16700-a505-11ea-984d-547794197545.png> Thank you for an excellent library. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#8>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAWMPMFBLNWYG4W55IZX5LRUU7LRANCNFSM4NQ633HA> .

[davemoore22]

This is probably more of a use-case question, but I've had a look at demo.cpp etc and can't quite figure out how to use this when plugged into my own code and when using shared_ptrs etc.

My scenario is this. Top level app has an activity controller member as thus:

_activity_controller = std::make_unique<swoosh::ActivityController>(*window);

I then have a splash screen class, so if I read your code right, it needs to inherit from Activity, and I pass in the aforementioned _activity_controller. Therefore the constructor is as follows (don't worry about the additional parameters - these are additional controller classes I'm using)

class Splash: public swoosh::Activity
	{
		public:

			// Standard Constructor
			Splash(swoosh::ActivityController& activity_controller, System& system, Display& display, Graphics& graphics);

		private:

All fine so far. So I then create a splash object:

_splash = std::make_shared<Splash>(_activity_controller.get(), *system, *display, *graphics);

How do I trigger the seque into it, and then "execute" it?

_activity_controller->push<swoosh::intent::segue<BlendFadeIn>::to<Splash>>();

gives the following error:

no matching function for call to ‘Sorcery::Splash::Splash(swoosh::ActivityController&)

Which is correct, as that's not the constructor. How can I pass additional parameters into the sequed class? Maybe I'm missing something as its been years since I've done templated C++ gubbins! Thank you for your help.

[TheMaverickProgrammer]

You're close. Per the readme, swoosh's API discourages allocating scenes on the heap directly. Instead you pass the type as the template type value for push: ``` getController()->push<Splash>(...); ``` Now your splash constructor has additional arguments. You can pass this into the `...` variadic parameters ``` getController()->push<Splash>(*system, *display, *graphics); ``` It is the same for segues. This and more is covered on the readme if you get stuck! :)

[davemoore22]

Amazing! Good news is the splash works! My first instinct was to wonder how to grab a pointer to the Splash once its been pushed for use by its parent, but then I think I'm right in thinking that with the activity paradigm, the answer is instead to have a common resource accessible by Splash AND parent and deal with access to the common resource properly via appropriate threading/mutexs etc that way instead?

The bad news is that the segue doesn't quite work yet. Though not sure if I'm using it right?

I am replacing

_activity_controller->push<Splash>(*system, *display, *graphics);

with

_activity_controller->push<swoosh::intent::segue<BlendFadeIn, swoosh::intent::seconds<5>>::to<Splash>>(*system, *display, *graphics);

The intent was to blur in the Splash over five seconds or so.

But this blows up with a Segfault:

Program received signal SIGSEGV, Segmentation fault.
swoosh::Segue::onStart (this=0x555555a7c4f0) at inc/swoosh/Swoosh/Segue.h:44
44	    void onStart() override final { next->onEnter();  last->onLeave(); timer.reset(); }

Does a segue need a previous activity to segue "from"?

[TheMaverickProgrammer]

It looks like you may have caught an edge case I didn't think about. Did you try using a segue without any activities on the stack? The very first activity on top of the stack should be a non-segue activity (aka a scene).

I'm guessing based on your error, but you're trying to segue from the previous activity (none which is nullptr) and so it crashes. Let me know if that fixes it for you.

TL;DR

Do not segue at the very start of your app. You must have at LEAST ONE activity on the stack to segue from.

EDIT:
If you want to blur in your Splash screen, create a BlankScene activity that is just empty.

[davemoore22]

Yes. That is almost certainly it. That's what I was doing. I'll try the blankscene tomorrow and let you know what happens. Thank you for the quick reply.

[TheMaverickProgrammer]

Do you think it would be beneficial for the AC to auto-generate a blank scene to segue from in the event the user forgets or doesn't want an "initial scene" to segue from?

[davemoore22]

Yes and no.

Yes as in it would stop the error, but no as in it could be simply noted in the documentation that you need to create a blank one first.

If there was a way to maybe create a hidden blank scene corresponding to the initial state of the Sfml window and to use that only if needed perhaps?

[TheMaverickProgrammer]

The latter is what I meant. I could grab the window context in the event of a segue without a previous scene and use it.

…

On Sat, Jun 6, 2020, 2:54 AM Dave M ***@***.***> wrote: Yes and no. Yes as in it would stop the error, but no as in it could be simply noted in the documentation that you need to create a blank one first. If there was a way to maybe create a hidden blank scene corresponding to the initial state of the Sfml window and to use that only if needed perhaps? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAWMPLUAJQ2BINRE46KTYDRVHY5BANCNFSM4NQ633HA> .

[davemoore22]

The Segue works perfectly when you define and push a blank scene first, thank you.

One thing though, I notice that with the Blend Fade In, even though I specify say a duration of say 5 seconds, when used against a dark background, it tends to do the majority of the blending very quickly, in the first couple of seconds.

_activity_controller->push<swoosh::intent::segue<BlendFadeIn, swoosh::intent::seconds<5>>::to<Splash>>(*system, *display, *graphics);

Toward's the end of the Blend, it also tends to slightly brighten the blended in graphic over and above the actual brightness, resulting in a noticable "jump" in image brightness down a bit at the end.

I'll see if I can grab a video of it to show you what I mean.

[TheMaverickProgrammer]

Both code and video would help me identify what is happening

[davemoore22]

Ah, nvm, I think it was an issue with my graphic image. But, if I may, one final question before I get on with the rest of the code.

I have two activity objects, a splash screen that should blend in immediately on program start, which should remain on screen for a couple of seconds, followed by a banner image that should fade in over a few seconds. That should stay up for a few seconds, then that should fade out to a main menu. How do I do this? Do I need to start a sleep in the onupdate, and call the second segue in that? Am I missing the mobile/multithreadedness of this all?

Here's my current code. What happens with it is that there is a delay of 5 seconds, then the first segue happens, then the rest of the code executes (which eventually will be that segue into a main menu). The second segue doesn't happen at all with this code.

Individually each segue works fine, but I can't quite get them to go in sequence.

	_activity_controller = std::make_unique<swoosh::ActivityController>(*window);
	_activity_controller->push<BlankScreen>();
	_activity_controller->draw();
	window->display();
	_activity_controller->push<swoosh::intent::segue<BlendFadeIn, swoosh::intent::seconds<3>>::to<Splash>>(*system, *display, *graphics);
	_activity_controller->draw();
	window->display();
	std::this_thread::sleep_for(std::chrono::seconds(5));
	_activity_controller->push<swoosh::intent::segue<BlendFadeIn, swoosh::intent::seconds<3>>::to<Banner>>(*system, *display, *graphics);
	_activity_controller->draw();
	window->display();

I'm almost there, I think I'm maybe missing a conceptual leap here or something. Though I suspect the last five years of professionally coding PHP/JS has addled my brain.

[TheMaverickProgrammer]

multithreadedness

You'll never need to worry about threads and swoosh ever so no worries! 👍 😎

I can't quite get them to go in sequence

The last activity in the stack is top of the stack and therefore the current one. What you're doing is pushing 3 activities onto the stack and it uses the main menu one. That's why it skips the 2nd segue.

Use the Demo.cpp code as a basis for your main loop. The segues automatically remove themselves when their timer is up, but the timer only updates when you update everything through the AC: _activity_controller->update(elapsed);

In your main loop, you want to do 4 things:

update the activity

_activity_controller->update(elapsed); // calculate elapsed as the time in-between frames

clear the window

window.clear();

draw the activity content onto the window

_activity_controller->draw();

display the final window to your screen

window.display()

---

If you want to chain screens you'll want to push inside of an activity

using namespace swoosh;
using namespace swoosh::intent;

class Splash : public Activity {
double fadeOut; // initialize to 0 time elapsed
public:

void onUpdate(double elapsed) {
    fadeOut += elapsed;
    const double duration = 2.0; // 2 seconds

    // fadeOut is the current time in seconds.
    // wideParabola creates a curve starting a 0, meeting at 1.0 in the halfway point, and back to 0
    const double alpha = ease::wideParabola(fadeOut, duration, 1.0);

    // make your logo fade in and out using calculated alpha value from swoosh::ease util
    logo.setColor(sf::Color(255,255,255,static_cast<sf::Uint8>(255*alpha)));

    if(alpha<= 0) {
        using effect = segue<BlendFadeIn, sec<3>>;
        getController().push<effect::to<Banner>>(*system, *display, *graphics);
    }
}

// ...
};

and then in your main.cpp

_activity_controller = std::make_unique<swoosh::ActivityController>(*window);
_activity_controller->push<BlankScreen>();

using effect = swoosh::intent::segue<BlendFadeIn, swoosh::intent::seconds<3>>;
_activity_controller->push<effect::to<Splash>>(*system, *display, *graphics);

---

I can see why you'd want to push activities onto the stack and expect them to chain like you originally did. The issue is that any activity could push or pop more during their update() routine. You can never predict what another programmer is going to do. For instance, how does your BlankScreen know when to move onto the Splash screen?

I'll think on this for a bit maybe I can come up with a reasonable outcome to allow for chaining things in a simpler fashion.

[davemoore22]

Alright, with that, I think I have it. Thank you!

[TheMaverickProgrammer]

master branch now has cmake scripts to generate visual studio project on windows.
TODO: test on linux

[TheMaverickProgrammer]

Master branch now has a new feature: AC will generate a blank activity from the window contents if the first activity on the stack is a segue.

[TheMaverickProgrammer]

Master branch now has cmake scripts that work on linux with codeblocks and other IDEs. All features are added. closing this issue.