(The Unofficial) PopCap Framework Developer Board
September 23, 2017, 12:19:04 AM CEST *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
  Home   Forum   Help Calendar Contact Login Register  
Poll
Question: Useful?
Yes, thanks. - 23 (100%)
No way. - 0 (0%)
Are you blind? SexyApp Framework Already has this! - 0 (0%)
Total Voters: 0

Pages: [1] 2 3 4   Go Down
  Print  
Author Topic: Game Screen Transitions Class (Free)  (Read 30382 times)
0 Members and 1 Guest are viewing this topic.
JPoag
Guest
« on: August 18, 2005, 05:09:42 AM CEST »

Download >Transitions<

Currently features these transitions:

Wipe
Screen Spin
Screen Fade
Fade To Black
Logo Expand
origianlly discussed here (edited to remove broken link, sorry...)

Please Post bugs/Comments in this thread.
Quote from: readme.txt
*************
Introduction:
*************

The Transitions class provides a SexyApp version 1.0+ friendly method for
changing from one screen to another.  It creates a Widget on top of the
all the other widgets and freezes the screen in one manner or another as
to allow the programmer to change all of the contents behind the widget.

The class uses Callbacks in the same style as a ButtonWidget.  The first
Callback lets the user know when it is safe to change the screen.  The
second Callback lets the user know when the Transition is finished.

To implement the callbacks, you must add TransitionsListener to the list
of base classes:

class Board: public Widget, public ButtonListener, public TranstionsListener
{ ... }

..and Override the Callback functions. (Just like ButtonListener)

When the transition is finished, the class automatically removes itself
from the WidgetManager and puts itself in the safe delete widget list.

The Transition class is not responsible for deleting images created
externally of the class.
« Last Edit: June 04, 2009, 04:51:28 PM CEST by Heiko » Logged
vortex
Guest
« Reply #1 on: August 18, 2005, 05:22:52 AM CEST »

looks cool so far  Smiley  as a newbie to the popcap framework, this helps me greatly Smiley.

Good job!
Logged
Kruzoe
Guest
« Reply #2 on: August 18, 2005, 07:28:38 PM CEST »

It's very useful of course.
Thank you so much.
Logged
Mak
Guest
« Reply #3 on: August 21, 2005, 10:15:57 PM CEST »

Sorry for my late reply. Thank you for releasing the code! Smiley

It was easy to implement it. I didn't check out all transitions yet, but it seems to work good.
Logged
JPoag
Guest
« Reply #4 on: August 26, 2005, 01:39:30 PM CEST »

Added a hacked demo file to the .zip (V12Demo).  Also included some comments around some potential compile problems.

Thanks to:

********************
Paul Hamilton
Mooktown Games
mooktown@gmail.com
http://www.mooktown.fun.ms
********************
Logged
vortex
Guest
« Reply #5 on: August 27, 2005, 04:38:28 AM CEST »

Ok so if you got two widgets the menu widget and the "next" widget then this creates a third widget, puts the first menu widget in the front of the "next" widget and does whatever till the first widget isnt visible then it removes the first menu widget leaving only the "next" widget behind?
Logged
JPoag
Guest
« Reply #6 on: August 27, 2005, 04:46:21 AM CEST »

Quote from: vortex
Ok so if you got two widgets the menu widget and the "next" widget then this creates a third widget, puts the first menu widget in the front of the "next" widget and does whatever till the first widget isnt visible then it removes the first menu widget leaving only the "next" widget behind?


Close.  The transition class itself is a widget.  It places itself on top of the screen so you can't see anything behind.  Once it's in place so you can't see anything behind it, it sends a message via a callback (like a buttonWidget listener) to say that it's safe to change the screen.

Then you do what ever you want to change to the next screen or simply rearrange widgets.

Next, the widget transitions to the new screen and deletes itself.  When it's dead, it sends a message (from the graaaveee) to let you know it's finished (again, just like ButtonListener).

It always keeps itself on top, so it doesn't care what you do behind it.
Logged
vortex
Guest
« Reply #7 on: August 27, 2005, 05:25:20 AM CEST »

ok, I will examine the code further. btw why is this needed?:

Code:

if (id == mDemoButton->mId)
{
delete mDemoWidget;
mDemoWidget = new DemoWidget();
mApp->mWidgetManager->AddWidget(mDemoWidget);

// What, more flags? Yup. Since our little DemoWidget isn't a dialog, when we add it,
// it won't change anything about the widgets drawn below it. Which means, unmodified,
// mouse clicks could still be passed down to the board (if the click wasn't in the DemoWidget),
// the board still updates, still draws, etc. Let's turn off mouse clicks for all widgets below the
// DemoWidget. But, let's still allow all widgets below it to update. Note that if we used the form
// of the method that only takes one parameter, then it would use mDefaultBelowModalFlagsMod
// which we modified in our app. By passing in our own flags though, they're used instead.
// Which means the only flag we need to remove from the widgets below it is the allow mouse flag.
// We do that by making a temp FlagsMod object, and setting
// its mRemoveFlags variable to be ORed with WIDGETFLAGS_ALLOW_MOUSE. Upon calling
// the WidgetManager's AddBaseModal method, we then pass in the DemoWidget, and the above flags.
// AddBaseModal will then treat this new widget as a modal object, applying any flags we passed in.
FlagsMod flags;
flags.mRemoveFlags |= WIDGETFLAGS_ALLOW_MOUSE;
mApp->mWidgetManager->AddBaseModal(mDemoWidget, flags);
}


It looks like it is totally redundant as it just deletes the widget and recreates it :S.
Logged
JPoag
Guest
« Reply #8 on: August 27, 2005, 03:11:54 PM CEST »

No clue. Wink

I didn't write that portion of code.  I hacked the V12Demo board and that stuff was already there. (Well, somestuff is left over from figuring out other people's problems, but that's not one of them).

The parts you should be looking at are in that same section, but have to do with "Transitions trans" and what-not. Maybe I'll clean the demo up some, I wanted to illustrate some of the effects better and that demo doesn't really do it justice.
Logged
vortex
Guest
« Reply #9 on: August 27, 2005, 04:47:34 PM CEST »

thanks Smiley.
Logged
JPoag
Guest
« Reply #10 on: August 28, 2005, 02:35:18 PM CEST »

Updates:

- Added more documentation.
- Paul Updated LOGO_EXPAND to have a nicer effect
- Paul made some sample images for the new and improved effect

Quote from: Readme.txt

Code:
________________________________________________________________________________
////////////////////////////////////////////////////////////////////////////////
Name:    Logo Expand
Description: Takes a snapshot of the screen and dissolves the middle in the
        shape of the provided logo outwardly. Like the effect in
        Chuzzle or Banjo-Kazooie. Also has an option for an overlay
        image that is drawn on top of the hole.

Credits:    'Paul Hamilton of Mooktown Games'
////////////////////////////////////////////////////////////////////////////////
Construction:

Create the Transition as you normally would with Transitions::LOGO_EXPAND as the
TransitionId.

There is a required ScreenLogoExpandInit() function that needs to be called for
the transition to behave properly. The first parameter is required and is the
shape of the 'hole' that will expand in the image.  The shape image needs to be
roughly square, or within 20% of being square.  The second parameter is an image
that will be drawn over the hole as it expands.

The second image is used to smooth the hard, pixelated edge created by the hole.
It is recommended that this image has an alpha center (the image is essentially
an outline of the hole) so that you can see the next screen through it.

Paul provided some images that can be used to illustrate the effect so you can
get the idea of how the images are supposed to look/work.
--------------------------------------------------------------------------------
Example Use:

Transitions* trans = new Transitions(mApp, this, Transitions::LOGO_EXPAND);
trans->ScreenLogoExpandInit( mApp->GetImage("images/logoexpand"),
                   mApp->GetImage("images/logoexpandtopper"));
mApp->mWidgetManager->AddWidget(trans);

////////////////////////////////////////////////////////////////////////////////
Logged
monkeymook
Guest
« Reply #11 on: August 30, 2005, 02:39:51 AM CEST »

oh i missed the voting!

this has been very helpful to me, it adds a lot to the presentation value of my current projects.

thanks for releasing your code J  Smiley
Logged
Extremest
Guest
« Reply #12 on: March 19, 2006, 01:18:20 AM CET »

I am trying to use this but for some reason if I put my init for the next level in the halfway callback instead of the finished one the program locks.
Logged
JPoag
Guest
« Reply #13 on: March 20, 2006, 02:11:05 AM CET »

Quote from: Extremest
I am trying to use this but for some reason if I put my init for the next level in the halfway callback instead of the finished one the program locks.


Try debugging it in windowed mode.  You might have a problem with a widget being deleted before it should (access violation) or possibly an infinite loop.

Place a debug break on the halfway Callback entry point and stop it the first time it runs into that function.  Then hit the 'Go' button.  If it hits that breakpoint again then look at the call stack to see where the loop is occuring.

It it locks up without ever coming back to that break point then you're going to have to debug it (possibly infinite loop).
Logged
Extremest
Guest
« Reply #14 on: March 20, 2006, 02:58:57 AM CET »

Ok it don't have a problem with screen_swipe or with the fade one I believe the rest all lock right whent he board comes up and the transition has not even been used yet.
Logged
Pages: [1] 2 3 4   Go Up
  Print  
 
Jump to:  


Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!
SimplePortal 2.3.3 © 2008-2010, SimplePortal