will be great if you post some screenshot with a link to the full ones at 1080 to se better the art quality

You're right. I modified the first post to add links to the full size images.

As for seeing it move, we're working on a video.

Will this game be kind of like "Nightmare in the Dark" for the arcade? I'm getting that kind of vibe.

Kind of yes. Just like Nightmare in the Dark our camera doesn't move and shows the whole level on the screen (though it scrolls from one level to the next). But in Citrouille you complete the levels by covering the ground with flowers, not by killing the enemies. Enemies can't be killed unless you have a power up.

Oh, and cute witch!

Thanks

But where are my manners? I forgot to introduce to you our first little witch. She's named Praline and that's how she looks like in the game.

[Here to eat candy and kick ass!]

Here to eat candy and kick ass!

Hello everyone. I am MadWatch from Lumen Section and it is my pleasure to show you our first game. Citrouille is a modern spin on an old arcade classic, can you guess which one?

Arcade game mechanics (full size)

Modern graphics (full size)

Old school difficulty (full size)

In an enchanted world, adorable little witches will stop at nothing in their quest for candy. But danger lies ahead and sweets are hard earned. Use spells, summon magic ladders and cover the world with flowers. What could possibly go wrong? Play alone or cooperate with a friend, settle the score in versus and claim the sweets you deserve!


Game Mechanics:

• Plant flowers by walking on fertile ground, clear levels by covering them with flowers
• Summon ladders to reach higher and lower grounds, no jump
• Attack to temporarily stun your enemies
• And kill them with bonus weapons
• Once you have enough flowers you can use magic spells to temporarily boost your character

Key Features:

• 4 playable characters, each with unique spell
• Story mode up to two players
  
  • 50+ levels
  • 5+ worlds
• Versus mode up to 4 players
  
  • 2 game mode, death match and time attack
  • 10 arenas
• Plenty of candy!

Targeted Platforms:
Windows, Mac and Linux. Maybe consoles if we manage.


Languages:
English, French, German, Polish, Spanish, Japanese, Korean, Simplified Chinese, Russian.


Wanna play?
The game will be released on the 29th of October 2018 on the following platforms:
If you like good old arcade games you might want to give it a shot. Be warned though, it's more difficult than it looks. It's a game with little girls, not a game for little girls

Regards

I think I got it 

Code:

mv = (-4.*d - sqrt(((4.*d)**2.) + 8.*et*((sv**2. + ev**2.)*et - (2.*ev + 2.*sv)*d))) / (-4.*et)
mt = (et*mv - et*sv) / (2.*mv - ev - sv)

Code:

mv = (2*d - t*(ev-sv)) / (2*t)
mt = (2*d - t*(sv+mv)) / (sv+ev)

It doesn't look like those works (assuming the 't' is 'et'). I don't get the expected results when using them. How did you get them ?

I tried solving this on my own but all I get is a second order polynomial equation with no real solution. So I guess I screwed again

I'm not sure where you get the squared terms in the d equation from.

You're right. I screwed up with my first equation. It's obvious when looking at it from a geometric point of view

Thank you very much jgrams

Hello everyone.

I'm working on an algorithm to smooth the animations my artist is making into our home made animation editor. By "smoothing" I mean giving the moving nodes a continuous velocity profile. So my algorithm must transform a broken velocity profile into a continuous one.

So here is the hard part.


I have a function that looks like this. This is the velocity profile I want. The variables I know are:

• sV the start velocity (not necessarily null)
• eV the end velocity (not necessarily null nor equal to sV)
• et the total time
• d the surface below the curve, that also is the distance of the move

I'm trying to use those to compute these outputs:

• mV the maximal velocity
• mt the time of the maximal velocity

The constraint is that the acceleration must equal the deceleration. In other words, both segments of the curve have the same slope (the later is just the negative of the former).

From this I could write the following equations:

• d = (((mV - sV)^2 / 2*mt^2) + sV) * mt + (((eV - mV)^2 / 2*(et - mt)^2) + mV) * (et - mt)
  which can be simplified into
  d = (mV - sV)^2 / 2*mt + sV*mt + (eV - mV)^2 / 2*(et - mt) + mV*et - mV*mt
  This first equation is the primitive of my velocity.
• (mV - sV) / mt = -(eV - mV) / (et - mt)
  which is the constraint that both slope shall be equal.

So. Two unknown variables. Two equations. The last equation allow me to define one unknown variable from the other. This shall be solvable right ? Right ?

I didn't manage to solve it

When I put the equation on the paper I get something horribly long and complicated and I can't put it into a form that allow me to extract a solution. When I enter it into an equation solving program I get horribly long solutions that are unusable because they always produce division by zero.

Yet, I don't see any reason why this wouldn't be solvable. I guess I'm making a mistake here
Could someone give me a clue on this ? 

Regards

Your links don't work. You should remove the double quotes around the URLs.

There are some sweet tunes in there. Good luck.

sounds like Apple's screwed you out of the possibility of a Mac port.

They did.

Unless somebody knows a magic trick I'm not aware of, the only solutions left are either fixing MyGUI myself (as archangelmorph suggested), kick MyGUI out of my project and replace it by something else, or give up the mac port. I chose the later, I have enough.

Hmm, no? C::B uses GCC. CMake uses whatever you tell it to use.

You can use vanilla gcc on a mac, you just can't use the Mac OS sdk with it. The sdk headers contains non standard attributes only understood by Apple flavored compilers.

I need the sdk, some of the libraries I use require it.

You could also use Code::Blocks on OSX. Or CMake.

That won't help. The problem comes from the compiler, not the project generator.

If you're not in a rush to support mac you could also try reporting the bugs to the Ogre / MyGUI devs, and hope they eventually fix their template code.  I'm not familiar with Ogre but their website seems to claim they support OSX so they probably do care if their code is broken ...

According to what I read on the Ogre board it seems the new 1.9 version addresses the issues I have with clang. I didn't try it yet because I managed to go around these by using llvm-gcc (the fake gcc shipped with Xcode 5) instead of clang. Only the MyGUI issues remain. I didn't see any announcement about a new version of MyGUI. There is a git repo with recent activity and commit messages about supporting clang so I guess they're working on the problem. But it also seems they're doing heavy redesign of their code. I have no way to tell when a new version of MyGUI will come out neither if it will work the same way than the current one.

If you unpack the install package and copy files into place manually, it's pretty likely to work, even if it refuses to install on its own terms.

It didn't. Older versions of Xcode install at a different location than the new ones. There are conflicts between some utilities (such as the fake gcc and g++ commands installed in /usr/bin as well as xcodebuild or xcrun) that expect to find it at the new location and some others that expect to find it at the old one. I didn't managed to hack around it with sym links.

I tried to downgrade to Mountain Lion hoping it would let me install the older Xcode but it doesn't. I can't downgrade further because my mac was bought with Mountain Lion and won't run anything older.

Ironically enough, I think Apple's new system to manage its development tools and sdks is pretty neat. You can install a recent Xcode version simply by dragging it into your Application directory and uninstall it just by putting it in the trash. No need to run a package installer or to do any symlinks. You're not even forced to use Xcode. Any IDE, makefile generator or configure script will find your compiler, tools and sdk transparently.

I only wish they didn't drop the gcc support, or that they would at least let you use a vanilla one, instead of forcing clang down your throat

Well, that wasn't a solution either. I can't install Xcode 4.1 on Mac OSX Mavericks. The installer says the OS is too new. It seems only Xcode 5 works on it.

Screw that, I give up porting my game to mac.

Maybe you could get a hold of an older Xcode where gcc is actually gcc, and an older SDK, and build everything with it? I think it wasn't until Xcode 5 that gcc was completely replaced by clang.

That's the only solution left I guess

But to get a true gcc I must go back to Xcode 4.1. Later version don't ship gcc anymore, they ship llvm-gcc instead and my libraries code doesn't compile with it either.

If any [mature] compiler is complaining about your code I would assume there's something legitimately wrong with it

Well I agree with this part...

that needs addressing.

... but not with that one. This is MyGUI's code, not mine. Even if I manage to understand it and to fix it there is a huge risk of breaking the library somehow. I know this code works well when compiled with gcc, I've been using it for years on Linux and Windows and never had any trouble with it. I would like to keep it that way.

No luck compiling with gcc4.7. Just like last time the compilation fails into MacOS SDK headers because those are full of attributes the vanilla gcc doesn't understand. This one for example

Code:

__attribute__((availability(macosx,introduced=X)))

You could switch to XCode which still provides support for GCC as an alternative compiler option to LLVM IIRC?

It isn't gcc, it's actually clang disguised as gcc (try gcc --version). Using it instead of raw clang does spare me some errors but not all.

No luck with fixing the template yet. I would prefer to avoid that sort of quick fix if possible.

I use -lobjc -framework Cocoa when linking.

That's what I did though. But since it works for you then it must be a mistake on my end. I will give it another shot. Thank you very much.

I use gcc macports as my compiler on OSX, it works with the Cocoa framework. I followed this tutorial for installing it, I used version 4.9 instead of 4.7 though.

I did install gcc 4.7 already but I've been unable to use the cocoa framework with it. Amongst other things the -mmacosx-version-min option, needed to select the minimum sdk version, is not supported by vanilla gcc, and it flat out refused to compile ObjectiveC code.

But since you managed to do it then I guess I missed something. How did you do ? What options did you pass to your compiler ? Do you have any makefile or the like as example ? That would help me a lot.

You could also use a cross platform library if you want to just avoid dealing with the mac SDK.  I use GLFW+GCC on mac and it works fine.

I already use cross platform libraries. Only these libraries were developed with gcc in mind, back in the days Apple still used it. But now they switched to clang and the libraries didn't all follow yet. By the time they all do (if ever) I guess Apple will have made some other change. Maybe I could try installing a very old apple gcc (not even sure I can) but as I said I would rather use the same compiler on all platforms.

Templates issues. For example this one with MyGUI.

The code :

Code:

slider->eventScrollChangePosition += MyGUI::newDelegate(this, &PhoneKeyboardMenu::scrollChanged);

The error :

Code:

../../Dependencies/MYGUI/include/MyGUI_EventPair.h:54:20: error: no viable overloaded '+='

m_eventObsolete += _delegate;

~~~~~~~~~~~~~~~ ^ ~~~~~~~~~

LevelOpenBox.cpp:46:36: note: in instantiation of function template specialization 'MyGUI::EventPair<MyGUI::delegates::CMultiDelegate2<MyGUI::Widget *, unsigned long>, MyGUI::delegates::CMultiDelegate2<MyGUI::ListBox *, unsigned long> >::operator+=<MyGUI::delegates::IDelegate2<MyGUI::ListBox *, unsigned int> >' requested here

list->eventListMouseItemActivate += MyGUI::newDelegate(this, &LevelOpenBox::listItemSelected);

^

../../Dependencies/MYGUI/include/MyGUI_DelegateImplement.h:285:48: note: candidate function not viable: no known conversion from 'MyGUI::delegates::IDelegate2<MyGUI::ListBox *, unsigned int> *' to 'IDelegate *' (aka 'IDelegate2<MyGUI::Widget *, unsigned long> *') for 1st argument

MYGUI_C_MULTI_DELEGATE MYGUI_TEMPLATE_ARGS& operator+=(IDelegate* _delegate)

It's basically MyGUI template code being rejected by clang. I have yet to find a way around it. I have similar issues with Ogre as well.

I think clang is right, MyGUI's templates must not be fully compliant with C++, but gcc  still accepts them. Is there a way to make clang more permissive ?

Anyway, I would rather being able to use the same compiler on every platforms. I use gcc 4.7 on Linux and Windows, using it on mac as well would be less trouble.

Hi everyone.

Apple is driving me nut. I've been spending weeks trying to port my game to Mac without success 

The problem is simple : AFAIK, if you want to use the MacOS SDK you have to compile your code with the compiler provided by Apple, vanilla compilers don't support the options to choose the SDK version and link with the ObjectiveC++ API. Unfortunately Apple only use the clang compiler. While it is possible to install a vanilla gcc on a mac I have been unable to link to the MacOS SDK with it.

But my project doesn't compile with clang. Some of the libraries I use have weirdness that gcc accepts but clang refuses (clang is more strict with the C++ standard). I can not modify them so I have no other choice than compiling my project with gcc.

So here's my question : is any of you aware of a way to build a mac application with a vanilla gcc ? Or do I really have no other choice than using clang ?

Kind regards.

i'm here ask for some tips, articles and another utilities things.

Use OpenGL. That's really the only useful thing to know about DirectX. Don't limit yourself to only one platform.

Regards