Galcon Games
Phil Hassey - game dev blog
Phil Hassey as Snidely Whiplash
"You can't buy awesomeness.
You're born that way."

Archive for the 'development' Category

How to create and play IVF / VP8 / WebM / libvpx video in OpenGL

Thursday, February 2nd, 2012

Disclaimer: this tutorial covers how to render IVF / VP8 / libvpx video in an OpenGL libSDL / SDL window. IVF video only includes video, not audio. For game developers, it’s trivial to play audio via their own audio system. So you’ll have two files per movie “movie.ivf” and “movie.ogg” or whatever. As an exercise to the reader, you could easily jam both into a single file if you really wanted to.

The Problem We’re Trying To Solve

So you’re an indie game developer and you want to show a clip of video in your commercial cross-platform (PC/Mac/Linux/other?) game! Obviously you want a patent-free open source unrestricted license to do it.

Wait, can’t I go commercial?

Better than that, you could just use the built-in codecs on a platform! I’d suggest this if you are targeting a single platform, iPhone / iOS for example.

Otherwise, you’ll be using Bink, a commercial solution at $8500 / platform. I emailed about their “indie licenses” and never heard back.

The Open Source Options I didn’t like much

Here’s what we have for patent free open source codecs .. and their various problems.

Xiph Theora – Probably the best known codec. To get it working you have to have libogg, libvorbis, and libtheora all built for your target platforms. To me, that seemed like a lot to ask. Also, the libtheora API is a MONSTER. playtheora is a SDL example (similar to this one) that covers some of that ugliness, so I’d recommend checking that out if you want to use theora.

Dirac / Schroedinger – the BBC funded codec. I couldn’t get this one to build. It doesn’t seem to be all that popular.

Motion Jpeg – This isn’t so much of a codec as an idea. Make your own movie file with a ton of .jpg’s in it. I tried this. The files get really huge really fast. I wouldn’t recommend this.

Motion JPEG 2000 – This implementation was also pretty confusing. I couldn’t find where to start. And, yeah, this isn’t all that popular either.

libvpx .. why I chose it

WebM / libvpx – Backed by google this is a new contendor on the block. The thing that sold me was the sample encoder which was pretty simple. It also depends on nothing. Also, building it on OS X and Linux was trivial. Also they offer a pre-built Windows binary. Also, they just had their 1.0.0 release a few days ago.

So, yeah, having a supported, up and coming, easy to build codec was key to me.

How to encode for IVF / libvpx

Since it’s a new codec, not much supports it right now. I used a fresh build of ffmpeg under linux that I built with this configure command:

./configure --enable-encoders --enable-libvpx

Then I was able to use ffmpeg to encode ivf files pretty easily:

ffmpeg -i Untitled.mov -vcodec libvpx -b 1000k -s 1024x512 movie.ivf

Note: we’re not dealing with WebM files. WebM files are container files that also contain audio. Again, you’ll have to store your audio separately, or create your own container file, or figure out what WebM is on your own time.

So .. what’s the bottom line? Do we get any code?

Yes! I created a libSDL player that plays back the video at max speed possible and it converts the YUV data to RGB data and loads it as a texture. Here are the functions I provide:

void playvpx_init(Vpxdata *data, const char *_fname) ;

Just init your Vpxdata with a filename “movie.ivf” .. It’ll try and get libvpx up and running for you.

bool playvpx_loop(Vpxdata *data) ;

Call this once per frame to have it decode a frame of video. It will return false once it has run out of frames. If you want to mess with the libvpx YUV data yourself, it’s data->img. See the playvpx.cpp source or the libvpx example above to see what that structure provides. It’s pretty simple.

int playvpx_get_texture(Vpxdata *data) ;

Call this once per frame to have it convert the YUV data to RGB and upload the texture to OpenGL. It will return 0 on failure or a OpenGL texture ID on success. I convert on your CPU, so it’s not super fast, but it should work fine on modern computers. If anyone cares to provide a Shader version of this function, or provide a SIMD / MMX / SSE version .. well, that would be faster!

void playvpx_deinit(Vpxdata *data) ;

Call this function when you’re done to cleanup.

Conclusion and Source Code

Okay, here’s playvpx for you to check out. It’s a C-style API, but I’m sure I use some minor C++ in there. Probably wouldn’t be hard to make it C-only if you require C for your project.

Oh, and I include the libvpx binary for Windows, OS X, and Linux. So you may not have to build it for any platforms!

The code is licensed under the libvpx BSD-style license. My code here is a gutted version of their sample_decoder.c, so .. that seems to make most sense to me.

Tough decisions, interesting beginnings

Wednesday, September 28th, 2011

So, if you’ve been following this blog for a while (like a year) you might recall last year’s “October Challenge” game called “Stealth Target” that I attempted to release as a paid beta game, which I then issued refunds for and then made a few vague efforts to revive and .. well ..

I mean, it looks, sort of okay. Those dynamic lights are neat stuff, man I learned a ton about OpenGL and tricks doing this game. The trouble is, since it is a 3D rendered game, when you stick it next to shots of (links to any recent Unity game on touchArcade left as an exercise to the reader) it looks awful. “Why is this dev even bothering?” Coupled with the fact that the interface was a bit kludgy using a mouse and at least twice as bad using touch, it just wasn’t a great fit for, well, anything sadly. To finish the project it would take me at least 3-4 more months of serious work and I don’t expect that I would be happy with the final result, so I had to kill it.

.. But I had written some keen code. And I still liked the game concept. So I thought about it a bit more. I had made another game a ton of years ago called Escape from Anathema Mines. It was a similar “dodge the guards” type of game with an overhead visual aesthetic that actually worked pretty well.

I thought it over and decided that with some of the GL experience I had acquired while working on Stealth Target, and by going in the direction of the overhead view that worked so well in that game, I could re-mix the two games together and create something new and exciting and simple enough that I could get it done. After just a few days of work I’ve already got a OpenGL / HD playable of Escape from Anathema Mines.

I’m going to extend the game with some of the bomb concepts from Stealth Target and maybe top it off with some other wacky features. This game is much easier to work on for the primary reason: it isn’t in 3D. Not being in 3D just makes rendering and working on it so much easier. One thing that also helped getting this up and running quickly was being able to reuse a ton of the code / algorithms that I had already written for Stealth Target.

I also been learning about the Object Component model over the past year and I’m using this game as my first attempt at it. I went to a talk at 360iDev (check it out) and got a very nice overview of the model. But the BIGGEST point he made that worked for me was when he said, “It doesn’t really matter how you do this, as long as it works for you. You won’t make a perfect model, so just make one that gets the job done and don’t feel bad about it.” Which was really liberating for me, I’ve always felt it was supposed to be some perfectly coded model, and being allowed by someone to just “get the job done” really helped. I was able to use the things I learned in his talk to help my code without having to do weird stuff that wouldn’t work with my style of coding. I have everything in a single structure named Entity. Really simple, but the thing I also do is have a bunch of bools like “has_light” “has_position” and then more members like “position_x, position_y, light_a” and so on. That way everything is always there (very C) but it’s component oriented (I can test if a component is there and take action on it if it is.)

Here’s the level editor, which is actually is very similar to the one for Stealth Target, only .. since the game is actually an overhead game, it was a ton easier to get working.

So, yeah. I’m enjoying doing this project. It’s actually my “hobby project” which means I’m only allowing myself to work on it during off-hours. I will probably attempt to monetize it somehow, but my main goal with this project is to satisfy my need to get these game ideas out the door and see how they come out. I’ve got my main work hours dedicated to some of the other commercial projects I’m working on this year.

Which I should talk about more soon. A lot more.

-Phil

From 0 to iCade in 3 hours 16 minutes

Tuesday, August 30th, 2011

Hey,

1. The Arrival and Assembly (30 min)

So my iCade arrived at 2:58pm today. It took me 30 minutes to unbox the parts and put the whole thing together with a hex-screwdriver. The completed item looks 110% win!!! There are tons of detailed unboxing guides on the internet, so I’ll just give you a shot of mine:

2. Testing it out with GAMES (30 min)

I had to check it out with a real game, so I went to the definitive touchArcade post on the subject. I realized I already had several of those titles on my iPad, so I dove right in with Velocispider which was totally awesome on the iCade!! I can only hope more devs add support! 30 minutes elapsed “fun time”.

3. Downloading the iCade SDK (1 min)

The “official” SDK is sort of useless, it’s just a manual telling us what we already knew. The great bit is there is an Open Source SDK (MIT) that is ready to go! I downloaded and unzipped that and began adding it into my project. 1 minute.

4. Being stupid (2 hours)

I then proceeded to brilliantly comment out the two lines of code that make the iCade code work. And then spend 2 hours realizing it. /facepalm

5. The iCade Integration (15 min)

Once I fixed my error, the integration took approximately 15 minutes. The bulk of the code was just a switch statement that converted the iCade SDK events to my own internal framework events. I already had keyboard support, so it was no trouble at all.

- (void)setState:(BOOL)state forButton:(iCadeState)button {
    int v = 0; unsigned char c;
    switch(button) {
        case iCadeButtonA: v=KEY_a; c='a'; break;
        case iCadeButtonB: v=KEY_b; c='b'; break;
        case iCadeButtonC: v=KEY_c; c='c'; break;
        case iCadeButtonD: v=KEY_d; c='d'; break;
        case iCadeButtonE: v=KEY_e; c='e'; break;
        case iCadeButtonF: v=KEY_f; c='f'; break;
        case iCadeButtonG: v=KEY_g; c='g'; break;
        case iCadeButtonH: v=KEY_h; c='h'; break;
        case iCadeJoystickUp: v=KEY_UP; c=0; break;
        case iCadeJoystickRight: v=KEY_RIGHT; c=0; break;
        case iCadeJoystickDown: v=KEY_DOWN; c=0; break;
        case iCadeJoystickLeft: v=KEY_LEFT; c=0; break;
    }
    Event e;
    e.v = v;
    e.c = c;
    e.type = state?EVT_KEYDOWN:EVT_KEYUP;
    game_event(e);
}

I also had to go ahead and add Universal (iPad) support to the game, this didn’t take too long as my framework has smarts for doing that pretty easily.

6. In conclusion …

I’ve submitted my update to the App Store, so hopefully it’ll be in your hands within a week.

In conclusion, integrating iCade into your iOS game only takes 15 minutes, unless you’re as stupid as I am. I encourage all devs who have appropriate games to do this so that I can play more games on my iCade!!! Go GO GO GO!

-Phil

tinypy2 musings

Thursday, June 2nd, 2011

So, my mind has been poking away at the idea of making a “tinypy2″ that would be a bit less like python, so probably even more confusing for end users. Being only one sentence into my proposal here, and it already sounds bad. Well, here goes:

-1 All objects would be assigned and passed by value instead of by reference
=0 There would be a dictionary of global variables
+1 The VM state could be saved to readable JSON
+1 The VM state could be loaded from JSON
=0 The VM would be written in C++
+1 The VM would have super-easy interoperability with C++ code
-1 The VM would be on the slow side

Tallying up the pros and cons, we get to a +1 for this idea. I don’t suppose there’s much way for anyone to comment on if this sounds like a good idea or not, but thos are some of the thoughts going around in my head right now. It seems like it would be an interesting rudimentary scripting language. The load / save of VM state and C++ interoperability are the key points.

#badideas ??

-Phil

The Galcon Office 2011 Edition

Thursday, June 2nd, 2011

So, hey, we recently (3 months ago) moved to “the goat ranch” and I finally got around to decorating my office. Since moving in, I’ve released one game and I’ve got three (or so) in the works. So a lot of stuff is going to be happening here this year!

Everything in that picture has got some sort of anecdote behind it, so if you’re curious about anything, just ask :)

-Phil

Invasion of the Blobs & dev toolkit in the works

Friday, May 20th, 2011

Hey,

A few weeks ago I entered the Ludum Dare game development contest and whipped together a fun game about defending off invading blobs using a spray can.

I spent another week getting it polished up so it works on a ton of platforms. The game is “The Invasion of the Blobs” (iBLOBS for short). You can get it here. It’s available on iPhone/iPad, Android, PC, Linux, Mac, and pretty soon the Mac App Store.

The reason for the porting frenzy with this game is I’m working towards releasing an open source C++ toolkit for supporting all these platforms (and maybe a few more). This is my first game release with this kit. It uses code from all my recent games, but it finally puts that code into a clean and organized re-usable structure. This is going to be super helpful for reducing bugs and improving game code across each platform.

Anyway, I hope you enjoy iBLOBS. It’s totally free, so you might as well give it a whirl. If you want to help out, please post a message here if there are any crashes or support issues on any platform, I want to get those ironed out best I can :)

Have fun!
-Phil

UPDATE: The Android port has been giving quite a few people trouble. If you are a dev with the Android dev kit, please do an “adb logcat” and post the results here, that would be a huge help!

UPDATE2: The Android build is so broken I took it down.

Paid game betas aren’t for everyone

Friday, January 7th, 2011

So, I just sent out my “hey everyone, come get a refund” email to all the people who purchased the Stealth Target beta. There are a number of pretty high-profile indie games that have built an entire business upon being a paid beta. Minecraft, Wolfire’s Overgrowth, Data Realm’s Cortex Command are a few that come to mind.

Here’s some analysis on the subject, and why it didn’t work for Stealth Target .. and at the same time, the factors I think that would be important to having a successful paid-beta project.

  • Commitment to a larger vision. In the case of Stealth Target, I had a larger vision, but I eventually realized it was too grand for me to realize.  I’m more of a small-scale game kind of guy at this point.  Perhaps later in my game development career I’ll be doing larger projects, but right now, a “Galcon-sized” game is about as large as I can manage.  I think paid-beta games need to be larger to justify the whole “user-buy in to help fund an epic game” concept.
  • Commitment to regular updates. I’m only one dev, and when I take a month to work on Galcon updates, and then take another month to take a break, suddenly the beta users haven’t heard a peep from me about the game in 3 months.  Pretty weak “paid beta”.  If I had a team and I had someone always working on the beta so it kept living despite my other obligations / plans, it might have gone better.
  • Building a development team. Yeah, I just touched on that, but it really does make sense.  I could have a team, but my lifestyle doesn’t allow for it at the moment.  My hours are too random and my work schedule too unpredictable.  To have a team you have to have some consistency in your life, otherwise (I’m pretty sure) your team-members will get pretty tired of you.  I think having a team would help deliver the quantity and quality of content and updates to make a paid beta make sense.
  • You can’t change your mind and be crazy. I still plan on finishing Stealth Target, however, I’m no longer planning on doing a desktop release of the game.  The paid beta was for a desktop version of the game.  So changing to a iOS-only plan really isn’t possible.  The only way to cleanly resolve this was to terminate the entire beta and issue refunds.  Really, for a paid-beta to make sense, the users have to have something they can depend on, and changing platforms mid-stream is just asking too much.

Anyway, to wrap it all up, here’s the email I sent out to folks who already bought the game today:

Hi,

Turns out the business model of doing a pre-beta-sale really doesn’t make sense for me.  I’m more of a “do what I feel like” kind of guy, and committing to making some sort of super-great-game in some kind of pre-beta-sale promise just isn’t something I can really do.  I think in the case of “Stealth Target” I bit off way more than I can chew.

I’m hoping to finish Stealth Target this year, but I’m probably only going to release it to mobile platforms, so I don’t even think I’m going to be launching a desktop version.

Either way .. I’m offering refunds to anyone who wants one!  Just reply to this email and say so.

Thanks for coping with a crazy indie-dev :)  Your support is greatly appreciated and I hope I can churn out some cool games that you’ll enjoy in 2011!

Cheers!
-Phil

P.S. Also, thanks for all the feedback you have given me so far on Stealth Target.  I’ve been taking notes on just about everything! You’ve been a huge help!

And, who knows what the future will hold for Stealth Target.  If the mobile version comes out feeling really good, I might try and release it for the desktop.  But the important thing for me is to know that I’m not obligated to produce a “desktop-sized” title when I’m really making a “mobile-sized” game.  I’ve got a lot of things I want to do this year, and I want to do them in the order that I want them to.  A paid-beta project would have “cramped my style” so to speak, and I don’t want to subject my users to a shoddy paid-beta experience.

Thanks!
-Phil

Part-time iOS game maintenance job for Galcon

Wednesday, November 17th, 2010

jobadI’m looking for someone who wants to do maintenance on my Galcon games for the iPhone. There are a ton of great features that really need to be added to the game, but I just don’t have time to do them all myself!

Galcon has large fanatical on-line multiplayer base who would absolutely love you if you were the one to help bring the features to the game that they are begging for!

While working together we would meet at least once a week to make plans and we would work towards being on a rather frequent app update schedule. The skills I’m looking for are:

- Proficient in C / C++ code and OpenGL.
- Strong experience with ObjectiveC / iOS.
- Knowing how to work with In App Purchases, Game Center, and iOS 4.x features a plus.
- You must own a Mac.
- You must own an iPhone / iPod touch. An iPad is a plus.
- Roughly 10-20 hours/week to start, this is flexible.
- Python or PHP experience is also a plus.
- Location: Anywhere! We’ll stay in contact virtually.

Contact me if you are interested, and tell me why you’re the best for the job! Payment would be hourly based on experience. This job has the potential to grow into a full-time position.

Thanks!
-Phil

Galcon for Sixense

Thursday, August 12th, 2010

I spent the first few days this week integrating Galcon with the Sixense motion controllers! It was a nice break from the work on the Android as I waited for a G1 to get shipped to me (I’m not sure if Galcon will work on the low-end phones yet, but I’m going to find out soon!)

galconsixense

Working with the Sixense was very different, the controllers are great, and it really provides a completely unique Galcon experience. I modified the game to allow all modes to be played Co-Op with multiple users (mouse + up to 4 Sixense controllers). And I also added a special Sixense Multi-player mode where you are divided into two teams and can play against each-other.

Like with any interface design I always try and fit Galcon to the device. In this case, I had to modify a few subtle things in the user interface to make it work just right with the Sixense. I also set one of the controller’s buttons to be a “Select-all” and a “Deselect-all” button, which makes it easy to do those common actions. So I think I’ve done a pretty good job matching the Sixense controller interface with the Galcon interface. You can also see in the screenshot that each controller gets a different color for their planet selection / action choices, and the crosshairs contains the Ships % information. The mouse player still goes off the standard Ships % that’s show in the bottom right corner.

All-in-all, I think this variant of Galcon is going to be a ton of fun! I have no idea when it will be available for people to play, but I’m sure it’ll be good times when it is!

-Phil

Porting to Palm / WebOS

Wednesday, July 14th, 2010

I’ve just completed and submitted my port of Galcon to the Palm. The entire process took 2.5 days. Here’s my play-by-play of the porting process. A huge thanks goes out to Mike Kasprzak for hand-holding me through the process and co-writing this post.  If you’re doing a Palm port, be sure to read the whole blog post over before you begin so you get the big picture.  Also, not everything is exactly in the right order, so that’ll give you the birds-eye view.

Day 1: Preparing the device for Development

11:00

- Unbox the Palm Pre Plus.

- Figure out how to plug in the USB.  This is a bit tricky, you gotta really yank on that plastic tab on the side to get it off.

11:30

- Use WebOS Doctor to flash the device with latest OS

http://ws.palm.com/webosdoctor/sorry.htm

12:00

- Activate phone.  If your phone isn’t activated, you use a program that can bypass activation

http://developer.palm.com/index.php?option=com_content&view=article&id=2051&Itemid=30

12:15

- Connected to local WiFi on activated device

12:30

- Final preparation of the device for development.

http://developer.palm.com/index.php?option=com_content&view=article&id=1973&Itemid=336

“Card view” is the view where you can see a view of all the open apps minimized. Apps are called Cards.

12:45

- ssh onto the device, password is blank

$ ssh -oPort=10022 root@localhost
root@localhost’s password:
root@palm-webos-device:/var/home/root#

1:00

- Install the Palm SDK and PDK, read whole document so you know where the cross-compiling binaries are located. It varies depending on windows / mac.

http://developer.palm.com/index.php?option=com_content&view=article&id=1970&Itemid=335

1:30

- Install a SSH key.  This way I don’t have to keep pressing return on the password entry during SSH sessions.

$ pdk-ssh-init localhost:10022

1:45

- Verify installation by using a Palm demo app.  This is an important step!  This step shows you where the example code and scripts are and you’ll be referring to those when you build your own build/deploy/packaging scripts for your own app.  And if it works, you know your Palm is ready to go!

http://developer.palm.com/index.php?option=com_content&view=article&id=1974&Itemid=336

- Errors about not finding various .so files can be ignored

- [This should be irrelevant as Palm gets their SDK's and firmware all synced across the networks] The PDL_Init error is actually the device talking back to you.  I had to go into the src folder and comment out PDL_Init to get it to run. This error is due to the 1.4.1.1 firmware on my Palm Pre Plus .. 1.4.5 is required for apps.  Had to do some hacks to get around this, won’t bother explaining, as this shouldn’t matter in a few days.]

3:00

- Rebuild simple sample app with PDL_Init included, works fine

3:30

- Got a copy of Mike’s app and tried it out.  Works nicely.

Day 2: Porting the App

- 10:30

Hacking up the /opt/PalmPDK/share/samplecode/simple/mac example building, packaging and deployment scripts.  Mostly just getting them to work with my code.  Was pretty straightforward if you know shell stuff.  I’m doing my work on the Mac, so I have a bash shell at hand all the time.

- 11:30

Got it compiling with a few tweaks. using rsync over ssh to deploy my game :)  I’m a big fan of rsync.  Here’s my “deploy” script:

rsync -v -urt –exclude ‘*~’ –exclude tmp –exclude .svn -e “ssh -oPort=10022″ ./out/ root@localhost:/media/internal/galcon

- 12:00

I had trouble loading images to textures.  But this was mostly due to my own dumbness.  Ended up being really straightforward.  Used SDL_image to load, converted it to 32 bit, then loaded it in.

- 1:30

.mp3′s won’t play with SDL_Mixer, so you must use oggs instead, check out this hack that I use to covert my “.mp3″ extensions to “.ogg”:

sprintf(f,”%s/%s”,DRIVER_DATADIR,fname);
int l = strlen(f);f[l-3]=’o';f[l-2]=’g';f[l-1]=’g';

- 1:45

SDL keyboard events not passing numbers when I use the Palm number presser key.

This is a palm bug, I should file a bug report. If the user holds down the NUMBER key, and then pressed a letter, they get the proper number.

-5:30

Handled SDL_ACTIVEEVENT to switch game into pause mode when being minimized.
if ((e.active.state&SDL_APPACTIVE)!=0 && e.active.gain == 0) { /* pause game */ }

- 6:00

Added a few PDL_ calls.  I’m really liking the set of lightweight functions they give you.  They cover most all the stuff you need for game integration in just a few calls.

http://developer.palm.com/index.php?option=com_content&view=article&id=1990&Itemid=340

#include “PDL.h”

PDL_Init(0); // in init function
PDL_GetCallingPath(char *buffer, int bufferLen); // to find out where our app is being launched from so i can find my data files
PDL_GetDataFilePath(char *dataFileName, char *buffer, int bufferLen); // find out where my app can write save games and settings.. the buffer is a fullpath to where we can save a file to
PDL_LaunchBrowser(const char* Url); // go to interwebs
PDL_Quit(); // wrap it up

Here are a few tips from Mike that I found really helpful:

About the Palm itself:

  • There’s a touch strip beneath the LCD screen. Gesture up or down from the middle of the strip to bring up the menu.
  • To “Card” (minimize) a running application, gesture upward or tap on the gesture strip
  • To close an application, throw the card away (up)
  • To delete an application, hold down the keyboard button with a square on it, then tap the icon of the app you want to remove.
  • When you plug a device in, Just Charge is the ideal mode. USB mode is useful for copying files via drag+drop, but you can’t run things while in USB mode

Linkable Libraries

  • -lSDL
  • -lGLES_CM (for OpenGL ES 1.1)
  • -lGLESv2 (for OpenGL ES 2.0)
  • -lSDL_mixer
  • -lpdl (Palm specific calls)

SDL Tips

The following call is required BEFORE setting your graphics mode, yet after initializing SDL

SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 1);

The number represents the OpenGL ES version. 1 for 1.1, 2 for 2.0.

webOS actually supports blending what you do against hardware decoded video. Unfortunately, this feature is on by default. The alpha value in the frame buffer decides weather video will bleed through or not (even if no video is displayed). To disable writing Alpha to the framebuffer, use this call.

    glClearColor(0,0,0,1);
    glClear(GL_COLOR_BUFFER_BIT);
    glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_FALSE);

Day 2.5: Packaging the App

Time to figure out how to package this into a sellable .. package!  I used Mike’s app and found that we really don’t need all the skeleton stuff palm-generate can generate for you.

http://developer.palm.com/index.php?option=com_content&view=article&id=1976&Itemid=375

You need an appinfo.json file in your distribution folder. It should contain something like this:
{
“id”: “com.galcon.app.igalcon”,
“version”: “1.9.8″,
“vendor”: “GALCON.COM”,
“type”: “pdk”,
“main”: “galcon”,
“title”: “Galcon”,
“icon”: “icon.png”,
“requiredMemory”: 48
}

I ssh’d in and used top to figure out my required memory.

And also a framework_config.json containing:
{
“logLevel”: 99,
“debuggingEnabled”: true,
“timingEnabled”: false,
“logEvents”: false,
“escapeHTMLInTemplates” : true
}

And lastly, I gotta include icon.png . Palm specifies this:

“Application icons should be 1 in. square, 64 x 64 pixels, encoded as a PNG with 24 bit/pixel RGB and 8 bits alpha. The icon’s image should be about 56 x 56 pixels within the PNG bounds.”

And lastly create this file:
package.properties containing:
filemode.755=your_app_binary

Then just copy all those files, and the app files into a folder named the same as your app id (com.galcon.app.igalcon for example) then run palm-package against that folder and you’re done!  Here’s a checklist from Palm that helped me through a few things:

http://developer.palm.com/blog/2010/07/a-quick-pdk-submission-checklist/

Then you just send that app package off to Palm! Have fun!

-Phil


Galcon   Watermelons   Dynamite   The Hairy Chestival
All content of imitation pickles (c) 1999-2008 - Phil Hassey  "we care"