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

Login with username, password and session length
News:
 
  Home   Forum   Help Calendar Contact Login Register  
Pages: [1] 2 3   Go Down
  Print  
Author Topic: Upgrading the PopCap framework  (Read 25361 times)
0 Members and 1 Guest are viewing this topic.
jpoag
Global Moderator
Hero Member
*****
Posts: 583

Game Designer


« on: August 07, 2009, 05:03:03 PM CEST »

Intro

So I've been toying with the idea of jumping ship for quite a while.  I really like the SexyApp Framework, but there are several issues that will only get worse with time.  I have a huge codebase for Sexy and I'd hate to have to start over in another framework/language.

The first problem is DX7 dependency.  Everyone wants to upgrade to Dx9 (at least) and for good reason: DX7 is emulated on newer cards/chipsets and there are bugs cropping up.  We've all seen Bejeweled Twist with the Dx9 renderer and Pixel shader support: it rocks hard.   Not to mention Dx7 is dropped from newer DirectX SDKs.

Next on the list is platform support.  I know of at least 3 different ports to the Mac: Mark at Red Marble Games has one, W.P. Van Paassen has one (SDL based) and I've even written one (PTK based). My port bites the big one.  It doesn't support RenderToTexture and it hates textures over a certain size.  I've had to write a font fixer tool to reign in fonts that are >512 wide and another to fix animation strips.

The basic necessity is Mac support, but iPhone and Wii would be great.  (Flash or some sort of online version would be nice too).

Latest version of Hungarr for the Mac: >Download<.

What I have
My version of Sexy has all the fixes noted in the forums as well as some other minor fixes/upgrades. 
  • I have fixed the stock BASS implementation to support streaming: an important feature for using FMpeg to decompress movies.  I also have a version with the latest implementation of BASS and a BASS soundmanager (why the SoundManager and Music are two different libs when bass suports both is beyond me).
  • I have a working version of FFMpeg that plays movies inside Sexy: with an excellent framerate on even the crappiest of machines.
  • I have a working in-game editor framework.  Has a properties and list pane as well as a ribbon (tool) bar.
  • XMLWriter
  • Password Protected version of PopPak (PAK files)
  • Profile Manager for multiple users.
  • Widget Generator for fast prototyping of widget screens.
  • Lua scripting support
..and probably a few other things I can't think of right now.

My wish list
  • DX9 and Mac support
  • Animation Editor like Flash only that generates files to be imported into Sexy.  For BWA 1/2 and PvZ, they used Flash to animate the characters and imported them into Sexy using a tool to parse the SWF.  I'd like to not only have that tool, but an editor to create these animations without the Flash middle-man.
  • iPhone support.

CrossPlatform Development
We would need a platform solution that allows the compiling of C++ code. I've looked into several solutions and even went as far as to try the port using PTK.  I've learned a lot from that port attempt.

The question is, what is so great about Sexy? 
  • For starters, I really like the Widget System.  It's been battle tested and is pretty easy to use. 
  • I love the 1.33 Graphics class with Push/Pop render states. 
  • I like the XML (although I'm the only one). 
  • I like being able to manipulate the bits of an image. 
  • I like Update() and UpdateF() being separate.
  • I like keyboard and mouse events being forwarded to the active widget.
  • I also like being able to load an image and not having to worry about whether or not it will load/render (Sexy splits image textures into 64x64 chunks). 
  • Widescreen support.
  • Resource Manager/separate thread loading
  • Bitmap Fonts
I'm no longer worried about Flash Mac support: I can render flash files to AVI and play them with FFMpeg. It's faster than Flash.

There are also a lot of neat utilities inside SexyAppBase that I use.  What I don't use is the Demo Recording.  When I ported the engine, I had to tear out all the Demo recording stuff to make it work, and then there was all this ... clutter where methods had been separated to support the demo recording/playback.

Proposal
Obviously, we need an engine where we can just add our CPP files to it compile and run.  I'd like to be able to support all of version 1.33 features (except Flash).

I've been looking at Irrlicht and it supports all of the features needed to make Sexy work on Windows with a Dx9 renderer and on Mac with OpenGL.  Because it is a 3d engine, we can add support for other things like shaders or viewport tranforms.  We could support Widescreen just by setting the viewport.  We could use BOOST for multithreading (which solves the cross-platform threading issues).  It doesn't look like it loads GIF images, but we have code to load them and writing another image loader looks simple.

Not to mention that by using a 3D engine, you can use 3D effects.

I've also recently stumbled across Cocos2d for iPhone support.  I haven't tried it out, but it compiles C++ (although written in Obj-C).  It uses OpenGL-ES.

After Porting
After the stable port to 1.33 is complete, then we can branch off and start fixing/adding things to the engine.  The Graphics Class is great, but I'd like to fix it so that everything uses transforms and that the transforms can accumulate  (stack) on each other.  I want to be able to Zoom the camera like in Peggle and BWA.

I'd also like to add a pixel/vertex shader program chain.

Full FMOD support (probably just my copy) so I can support FMOD sound triggers/events.

Animations
I got about 1/2 way through an animation editor before I bailed out to code for Haunted Hotel II.  The animation classes made their way into the game and I even added Lua Scripting support for them.  They would still need a lot of work (I plan on upgrading them) but they provide a great starting point for an animation system that supports not only the PvZ animations, but in-game movies.

I have Sexy running in an SDI window (same I used for the particle editor).  If we were serious about going forward with this, I would revamp the editor with tools from codejock and create a real animation editor.  I think the only constraint I would place on the animation system is that it should be easily portable to other render systems (PTK, SDL, Playground).  There are a lot of people out there who need a 2d animation system like PvZ and a replacement for Flash.

Conclusion
It's a lot of work to do and I'm currently busy on another project that won't be done until the beginning of next year.  I'm a full time game developer now and I have to sing for my supper.  I would be more than willing to Host the SVN on Assembla and pay for the occasional tool here & there.

We need to get enough of the right people on board that can all agree on a direction to take the engine.




Logged

-James
jpoag
Global Moderator
Hero Member
*****
Posts: 583

Game Designer


« Reply #1 on: August 09, 2009, 10:21:52 PM CEST »

Ok, so I have a mac version of the framework running and I'm noticing some really strange errors with images not loading.  Then I realize that the images were fonts and really long image strips.

Turns out there's a maximum texture size for images and that Sexy had been cutting up textures larger than 1024 (thanks, Sexy)!  I've been rearranging the image strips and fonts to fix the problem, but we will have to include an algorithm for cutting images into smaller textures when needed...
Logged

-James
jpoag
Global Moderator
Hero Member
*****
Posts: 583

Game Designer


« Reply #2 on: August 10, 2009, 09:14:52 PM CEST »

Ok, I've started an Assembla site to host the SVN Repository and submit future changes to the project.

https://www.assembla.com/spaces/sexy

I've made some minor changes to the documentation for 1.33 (PDF instead of MSWORD), but otherwise it's a clean version of 1.33.  In the next couple days I will upload my changes and merge them with the trunk (tentatively called 1.34).  I've also made a CHM of the Doxygen docs for 1.33 and put it in the /docs folder.

Once 1.34 is locked down, I'll start detailing the necessary changes to make sexy cross-platform compatible (like changing 'Rect' to 'Sexy::Rect' and 'Point' to 'Sexy::Point'), abstracting the D3D stuff into 'Device' and moving to an agnostic image format (Merging Image/MemoryImage/DDImage into a since interface).

After studying up on Pixel shaders I have some ideas for changes in the rendering pipeline to allow for post processing techniques.

Anyways, the SVN:
http://subversion.assembla.com/svn/sexy
http://subversion.assembla.com/svn/sexy/trunk         "basically unstable"
http://subversion.assembla.com/svn/sexy/tags          "release versions"
http://subversion.assembla.com/svn/sexy/branches    "workspace for major changes"

No password to checkout, and you can do an 'export' to use a version in your project.
Logged

-James
jpoag
Global Moderator
Hero Member
*****
Posts: 583

Game Designer


« Reply #3 on: August 11, 2009, 04:38:31 PM CEST »

I've committed my bug fixes to the SVN.  The trunk contains the modifications and there is a release_1.34 node under /tags.

Quote
Changelog for Framework version 1.34:

General
=======
* Added Support for BASS Stream support (Needed for FFMpeg)
* Fixed BassMusicInterface to allow music files loaded from PAK
* Fixed MouseUp() bug in ButtonWidget that would cause an access violation if button was removed in callback
* Added AppData folder support to Windows XP version of Sexy as APP_DATA_FOLDER has been around since NT 5.0
* Fixed bug in VFormat Widestring(size of w_char != 1)
* Fixed Rare race condition where Mouse thread would crash during Mode switch
* Fixed bug in DDImage when trying to access an invalid surface (GetSurface() can return NULL and must be checked)
* Added Check to make sure mOldCursorArea was not NULL in Mouse Thread
* Fixed Dialog buttons to look in String Database for ID_YES, ID_NO instead of being hard coded for English.
* Fixed EditWidget to allow characters > 128 if (gSexyAppBase->mbAllowExtendedChars == true)
* Fixed Bug in DrawLineClipHelper where floating point index would cause access violation int array
* changed expected format of Properties.xml file to ANSI instead of UTF-8 (for porting reasons)
* Commented out Stupid ASSERT when image refcount != 0 on Shutdown
* Added support for 'PAUSED' screen when dragging window instead of Game Window Freezing
* Fixed Window Placement Bug that put window title bar above the top of the screen
* Fixed bug in XMLParser where you couldn't have an '=' in the attribute value.
* Added Password Support to PAK Files


PopPak Password Edition (PopPakPWE)
===================================
The new PopPak now allows for PAK files to be encrypted using a string instead
of '0x7F'.  The encryption is still XOR based (fastest decryption), but instead
of using the same HEX value of '0x7F', the PAK Interface will now cycle through
the password string using each character as the XOR key.

The header on a PAK Lib is standard, with the first 8 bytes being 0xBAC04AC000000000
where 0xBAC04AC0 is the 4 byte 'magic word' and 0x00000000 is the file version. Because
these values are known, the first 8 characters of the password can be broken quite easily.
This means that passwords for PAK files have to be longer than 8 characters to be secure
and that they shouldn't be easily guessable from the first 8 letters.

The new PAK utility also supports unpaking (including the ability to unpak standard
PAK files).

Usage: PopPak [/U] [/P] [/K "The Password in Quotes"] <FileName> <DirPath>
  /U    Unpacks pak file to DirPath
  /P    Creates pak file from files in DirPath
  /K    Changes the Default Encryption Password
  
The '/K' Key can also be a single hexadecimal byte (for instance 0x7F).  This
is very useful for unpaking PopCap games:

PopPakPWE /U /K 0x7F main.pak _unpakdir

PakInterface
---------------------------
To use the new Password feature, you need to change the default password in the
PakInterface and create a batch file with the new password on the command line.

In your GameApp Ctor:
GetPakPtr()->mDecryptPassword = "MyNewPassword"; // "LKJALK;NDFICN,LAJKGLKAJ89084TOIGJM,VN";

In the batch file:
PopPakPWE /P /K "MyNewPassword" main.pak "content"

Note that most if not all of these fixes have been released in Haunted Hotel I & II.  The second Haunted Hotel went through 2 external bug testing/QA departments and both games have been downloaded ~2 million times.
« Last Edit: August 11, 2009, 04:41:12 PM CEST by jpoag » Logged

-James
jeremy
Global Moderator
Full Member
*****
Posts: 244


WWW
« Reply #4 on: August 13, 2009, 12:22:37 AM CEST »

Thanks for this James. I was going to ask you about that pak password stuff you had and now here it is Smiley. I've decided to go ahead and update my project to this version even though I am really too far along to be doing such a reckless thing*. Your note at the end convinced me, though, and I'm sure I don't have all the bug fixes that were posted to the forums after 1.33. (and it can always be reverted if something was to crop up).

Also, after looking at Irrlicht, I'm curious as to how using it could be implemented. Irrlicht looks like it is far more advanced than just drawing code. Would it basically be adding the widget, sound, etc code from Sexy to Irrlicht or just Irrlicht's core graphics stuff to Sexy? (I know, simple question right? Smiley )

*only in the sense that you shouldn't make major changes late in the going. I'm sure it is actually only going to improve things.

Jeremy
Logged

Jeremy Sullivan
Blue Footed Games
jpoag
Global Moderator
Hero Member
*****
Posts: 583

Game Designer


« Reply #5 on: August 13, 2009, 03:31:33 AM CEST »

Thanks for this James. I was going to ask you about that pak password stuff you had and now here it is Smiley. I've decided to go ahead and update my project to this version even though I am really too far along to be doing such a reckless thing*. Your note at the end convinced me, though, and I'm sure I don't have all the bug fixes that were posted to the forums after 1.33. (and it can always be reverted if something was to crop up).

Also, after looking at Irrlicht, I'm curious as to how using it could be implemented. Irrlicht looks like it is far more advanced than just drawing code. Would it basically be adding the widget, sound, etc code from Sexy to Irrlicht or just Irrlicht's core graphics stuff to Sexy? (I know, simple question right? Smiley )

*only in the sense that you shouldn't make major changes late in the going. I'm sure it is actually only going to improve things.

Jeremy

You can use WinMerge to merge your source and 1.34.  If you have any interesting fixes, then you can send them to me and I'll put them in the trunk.

Irrlicht is far more advanced that just drawing code.  It also manages the Window creation and user input in a cross-platform manner. I'll be using 3D code to draw all the 2d stuff, largely because the 2d drawing on Irrlicht is very primitive.

The first step is to get Sexy 1.34 fully functional on Mac (OpenGL) and PC (Dx9) platforms using Irrlicht.  Then an upgrade to the render pipeline followed by an iPhone port (via Cocos2D).
Logged

-James
jeremy
Global Moderator
Full Member
*****
Posts: 244


WWW
« Reply #6 on: August 13, 2009, 04:17:46 AM CEST »

Sorry to report no fixes from me. I did add a #pragma warning(disable:4996) to the top of PakInterface.h  Smiley

Once I get this current game done I will hopefully be able to chip in on some of this. Although I am a bit of a newb with some of this (c++, game programming), currently I consider my self more of a Sexy Framework programmer. But I have programmed other stuff for many years, so I'll get up to speed eventually Smiley....and I do have a Mac.

Jeremy
Logged

Jeremy Sullivan
Blue Footed Games
jpoag
Global Moderator
Hero Member
*****
Posts: 583

Game Designer


« Reply #7 on: August 13, 2009, 06:04:14 PM CEST »

Looks like I forgot to upload the PopPakPWE.exe file.  I added it to the 1.34 release tag and to the trunk.

I've also added my widget generator tool for fast prototyping of widget screen.

The trunk now contains more of my own personal code: XMLWriter and Profile.  There is a document on how to use Profile in the trunk/docs section.
Logged

-James
DmitryShm
Newbie
*
Posts: 9


game developer


WWW
« Reply #8 on: August 14, 2009, 10:49:19 AM CEST »

Obviously, we need an engine where we can just add our CPP files to it compile and run.

It's not so obvious. It's bad style when you are forced to add source files. The good way of exporting code are libraries (dynamic or static).

If I were SexyApp framework developer, I would remove these ugly SexyChars and SexyStrings. We should use standard TCHAR strings (std::basic_string<TCHAR>) and let developers use UNICODE (when wchar_t == TCHAR). Also I'd like to remove all of these "#define M ...", "#define M1 ..." and so on from SexyApp header files. "M" is a bad name for macro. When I use SexyApp with boost libraries which use "M" as a variable name in header files (and it's correct according to C++ programming style) I should #undef all these stupid popcap definitions.
Logged
DmitryShm
Newbie
*
Posts: 9


game developer


WWW
« Reply #9 on: August 14, 2009, 11:00:31 AM CEST »

There're tons of memory leaks in SexyAppFramework.
Logged
jpoag
Global Moderator
Hero Member
*****
Posts: 583

Game Designer


« Reply #10 on: August 14, 2009, 02:44:22 PM CEST »

Obviously, we need an engine where we can just add our CPP files to it compile and run.

It's not so obvious. It's bad style when you are forced to add source files. The good way of exporting code are libraries (dynamic or static).


Really?  You don't want to add your game source code and hit compile? 

When I wrote that line, I was implying that we need a C++ engine (as opposed to java or AS3) that would simply 'run' without a whole lot of fighting with it.  As a guy who's spent a lot of time fighting with XCode, I would have loved the ability to copy my game code over into a project, hit 'compile' and it would 'just run'.  Note that makes no mention of how the SexyAppFramework is linked (dynamically or statically).

So... C++?  Obvious
Hit compile and Run?  Obvious

Bad 'style' to add source code? Libraries?  Static or dynamic? 

Watch your tone. Angry
Logged

-James
jpoag
Global Moderator
Hero Member
*****
Posts: 583

Game Designer


« Reply #11 on: August 14, 2009, 02:48:47 PM CEST »

There're tons of memory leaks in SexyAppFramework.
Send me specific fixes and I will merge them into the trunk.  Saying that there are memory leaks without specific instances and code to fix them makes me think that you see something like:

Memory leak SexyAppBase.cpp line Huh?

and you think it's sexy's fault that you're leaking memory.

IIRC, you're using an external memory profiler.
Logged

-James
DmitryShm
Newbie
*
Posts: 9


game developer


WWW
« Reply #12 on: August 14, 2009, 06:52:49 PM CEST »

I use CRT profiling API. Here's a simple code to play with.

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

#ifdef _DEBUG
   #define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
   #define DEBUG_CLIENTBLOCK
#endif

#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif

int main()
{
   _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
   new int[10];   //   cpp-style allocation
   malloc(1);      //   c-style allocation
   return 0;
}

About memory leaks... There's a good example when we use SafeDeleteWidget instead of delete. Each call to SafeDeleteWidget produces a leak. So if we want to make a good framework, we should remove SafeDeleteWidget.

BTW, I have some custom code. I think it should be placed in separate files from the framework. For example, I have arbitrary shaped button class, and some widgets like dynamic menu. We can talk about standard procedure of testing and packing custom code to place it somewhere in the web to let developers download it and use.
Logged
DmitryShm
Newbie
*
Posts: 9


game developer


WWW
« Reply #13 on: August 14, 2009, 07:23:44 PM CEST »

And about my tone. How can I talk about popcap developers after this code that couldn't be simply compiled without fighting with it.

Here's some simple code presented down there. "M" macro defined in ModVal.h prevents from using boost library. We even have no compilation here.

#include <SexyAppFramework/ResourceManager.h>

//#ifdef M
//   #define FUN_M_UNDEF M
//   #undef M
//#endif

#include <boost/thread.hpp>

//#ifdef FUN_M_UNDEF
//   #define M FUN_M_UNDEF
//#endif

int main()
{
   return 0;
}

But if we uncomment protection macro definitions the code compiles.
Logged
DmitryShm
Newbie
*
Posts: 9


game developer


WWW
« Reply #14 on: August 14, 2009, 07:53:23 PM CEST »

And something about so called "pak interface". It's something that draws effects. Who could write this code in PakInterface.h?

PakInterface * gPakInterface = new PakInterface();

And it's not a function code. PakInterface * gPakInterface declared as static and global. And there's no delete operator for gPakInterface.

I think it should be rewritten like this.

PakInterface * gPakInterface = NULL;

and new/delete in SexyAppBase derived class ("gPakInterface = new PakInterface;" in constructor and "delete gPakInterface; gPakInterface = NULL;" in destructor).

So if we clean up and fix the framework from the buggy code SexyAppFramework could become the best framework at all. And we can upgrade it safely then.
Logged
Pages: [1] 2 3   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