Updated 26th of August: Patch for Jets’n'Guns released

If you have any input, suggestions or questions for me, feel free to ask them here in the comments, on IRC (Zero_Dogg in #lgp on irc.freenode.net), via identi.ca/twitter or via e-mail (to eskild at the domain linuxgamepublishing dot com).

Update: Patches are now available for X² and X³, the workarounds for these games are no longer needed. Ballistics might still need it.

Ballistics, X2 & X3: Problems starting on Ubuntu 10.04

Several users have contacted us concerning problems starting Ballistics, X²: The Threat and X³: Reunion.The problem is due to Ubuntu changing their system for managing ld.so paths and the games not handling it like they are suppose to. A patch will be released soon which addresses this problem, meanwhile you can use the following workarounds to play the games. Instead of just using the “ballistics”, “x2″ or “x3″ commands, use one of these to launch the game instead:

Ballistics:

ballistics --withgl $(\tail -n 1 /etc/ld.so.conf.d/GL.conf)

X²: The Threat:

x2 --withgl $(\tail -n 1 /etc/ld.so.conf.d/GL.conf)

X³: Reunion:

x3 --withgl $(\tail -n 1 /etc/ld.so.conf.d/GL.conf)

]]> http://blog.linuxgamepublishing.com/2010/08/18/customer-services-update-for-august-2010/feed/ 6 http://blog.linuxgamepublishing.com/2010/04/05/which-community-events-do-you-want/ http://blog.linuxgamepublishing.com/2010/04/05/which-community-events-do-you-want/#comments Mon, 05 Apr 2010 14:50:32 +0000 Eskild Hustvedt (Community Manager and Junior Developer) http://blog.linuxgamepublishing.com/?p=412 We have been hard at work on our unannounced ports the last couple of months, and I know some of you get rather impatient waiting for news. So, to help pass the time we’d like to see if there are any particular community events that you’d like to see. If you have other good ideas, feel free to suggest them in a comment. Please vote only for events that you’d be likely to attend, you may select up to three.

If you have any input, suggestions or questions for me, feel free to ask them here in the comments, on IRC (Zero_Dogg in #lgp on irc.freenode.net), via identi.ca/twitter or via e-mail (to eskild at the domain linuxgamepublishing dot com).

An example of this would be something like this short debug function

int ptf(const char *fmt,...)
{
  va_list varlist;
  FILE *fp=fopen("/tmp/debug","a");
  va_start(varlist,fmt);
  vfprintf(fp,fmt,varlist);
  va_end(varlist);
  fclose(fp);
}

This function isn’t rocket science, it just simply appends your string into a file. It is a simple time saver utility.

However, using it can be a problem. You can do something like this

int x=1;
ptf("Error %s\n",x);

And gcc will say ’sure, no problem’.

But running the code will always crash. It tries to interpret the integer as a string.

This is the kind of thing that should be picked up on by the compiler. And in fact it can be, quite easily.

In your prototype for the function, you would have something like

extern int ptf(const char *,...);

This is pretty standard, and no surprises there. However, gcc has the capability to be given a hint as to how this function should be handled. You can instead prototype the function using

extern int ptf(const char *,...) __attribute__ ((format (printf, 1, 2)));

This tells gcc to treat the parameters 1 and 2 as the parameters to printf (which it knows how to check for errors). It will then check parameter 1 (the format string) against what is passed in starting at parameter 2 (the …). If an incorrect data type is used, this will now be detected and flagged up as a warning, in exactly the same way as an incorrect type used in a printf.

We have tried to make it as easy as possible to become a reseller, and we encourage any company or individual who is interested to apply. You do not need to be rich to start a store, we have resellers that started with no advance money needed.

The different types of reseller

When you decide to become an LGP reseller, you have a number of different options open to you.

1. Traditional reseller
   This kind of reseller operates in the time honoured tradition of buying stock from us at a discount, and reselling it to their customers. The same kind of reselling that has been going on for centuries in all industries. We offer these resellers a discount of around 40%, and we ask that they buy at least 10 games at a time. Not a huge amount, we like to set the barriers  to entry low.
   Of course, for the bigger buyer, there is incentive to buy more and get bigger discounts. The more games that you buy at once, the bigger your discount.
2. Dropship reseller
   This kind of reseller is the type with the lowest barriers to entry. If you have a website and would like to sell LGP games, you can simply list all our games, right now if you like, and if you get any orders, simply have us ship them to your customers. You simply login to your reseller account, and buy the game with your credit card, and leave the rest to us.
   This system was set up specifically for those who want to ‘give it a try’, and who don’t want to spend money buying games they aren’t sure they will sell. Of course, with less risk is less profit. The discount for this kind of reselling method is around 30% instead of the 40% we offer for standard resellers.
3. Download resellers
   This is, as many of you will know, our newest method of game distribution. We offer the ability, with some of our games, to buy a downloadable version of the game. The system for this works a little differently.
   When you sell a downloadable copy of a game, it is the responsibility of the reseller to supply the download to the customer. Whether that be as a disc image (which is how we supply the data to the resellers), an RPM, or any other method, that is up to the reseller. The reseller also needs to supply a key to unlock the game.
   The keys are the bit that you as the reseller would pay for. The discounts on keys are similar to the discounts for standard resellers, but they work a little differently. Instead of asking resellers to buy keys in advance (which they may of course do if they wish), we offer them the ability to buy ‘key credit’ and then buy they keys in real time when a customer orders a game.
   The simple web-based system involves sending a request to our webserver, and if you have purchased enough key credit, then a new key is returned, and you can then provide that key to the customer.
4. Private groups
   While not quite a reseller, private groups are also welcome to apply for discounts. Examples of such groups would be Linux User Groups, or companies that run Linux desktops who want to buy lots of copies of games for internal use.
   Private groups receive the same benefits as traditional resellers. The same discounts, but just aren’t listed on the website as places to buy our games (for obvious reasons). If you are part of a group that would like to buy games for your group at a discount, you should set up the standard reseller account with us.

So, now you know what the options are, lets get into the mechanics of how.

The task of creating an account is actually very simple. You simply go to our website and follow the ‘Account’ link that you will see on every page of the site. From here, you can follow the correct path, and apply for an account.

Once accounts are created, we check them out, and authorise genuine resellers or groups. We are happy for anyone to apply, but if you are an online reseller, we ask that you have some kind of web infrastructure available for us to examine before you create your account. We generally do not open accounts for people who ‘will make a website soon’. Accounts that are authorised are generally authorised within 24 hours, or we will send you an email to let you know why they have been rejected (which happens rarely).

Each account is capable of any of the resale options described above, you do not have to open a type of account for downloads or for dropship. Just a reseller account.

So, now you know what is available, and how to do it. The last thing to know is why would you.

For three reasons:

1. For You
   If you own an online or physical store already, our products make a good addition to the lineup, and with the dropship system, you can add them at no risk.
   Even if you don’t, then starting reselling LGP games as a part time website owner, or even to your local Linux using friends, is a nice second income, and probably better than all these ‘get rich quick through Google’ ads that you see all over the place.
2. For Us
   Simply, because LGP needs as many resellers as we can get. We need as many people talking about our products as possible. The more games we sell, the more games we can make, and the more games we can make, the better it is for you, us, and everyone.
3. For the Community
   Because games are, without doubt, the big block to Linux adoption on the desktop. Do you want everyone running Linux? So do we, and games help to make that happen.

I will say right now that I am an application developer, I don’t know the fine details of how the inner workings of the compilers work, so some of this is merely an educated guess as to WHY the problem happens, but the effect and solution is correct.

The first issue for today is a fairly rare situation where g++, upon hitting a certain piece of code that builds fine under Visual C++, gives the helpful error message:

some/source/file.cpp:172: sorry, unimplemented: called from here

Now, I don’t know about you, but I find that error message singularly unhelpful. It took some time to run this one down the first time. It seems  that g++ and VC++ perform some symbol resolution in different passes to each other. Because what this message is saying is that ‘at line 172, you have tried to use __forceinline, or something you reference has a member function that has __forceinline in it, but I do not know what the thing is, so I cannot inline it’.

EDIT: g++ does not have the __forceinline keyword. There is an equivalent which does the same job however

#define __forceinline inline __attribute__((always_inline))

As VC++ has no problem with the same calls, the only real answer must be a compiler difference that allows VC++ to get away with something that g++ doesn’t. The simple solution is to just change __forceinline to inline and let the compiler inline as it sees fit. Otherwise, you will need to hunt down the exact problem and resolve the order of events for g++

The second issue I thought I would raise today is one that actually happens quite commonly on porting from Windows to Linux. This is the case of bad memory management.

On Windows, the way memory is allocated allows for a certain sloppiness in code. While HIGHLY unrecommended, this is the sort of thing that happens in Windows code all the time. The following is a highly simplified example of the problem.

char *str;
str=(char *)malloc(6)
strcpy(str,"hello");
free(str)
switch (str[0])
{
  ...
}

Now, as you can see here, the application uses the variable str right after it has been free()’d. On Windows it seems that this kind of thing can be gotten away with. The memory manager on Windows is highly unlikely to either assign this memory address somewhere else, or to mark it as unavailable. On Linux however, you will often find that this kind of code leads immediately to a segmentation fault.

The example above is highly simplified, but illustrates what some of the more complex segmentation faults we have seen boil down to.  If you see an error like this, which works on Windows and not on Linux, check your order of accessing. I know it sounds obvious, but it happens so often in commercial code that I feel it is worth stressing – free memory only when you have REALLY finished with it.

Current Linux distros primarily use either RPM or DEB (and a load of other less common ones that are only used by a distro or two). Most deb distros are somewhat compatible, as most of those are in one way or another based upon Debian. However, on the RPM side we’ve even got two completely different development trees of rpm itself, and a load of distros that are not compatible with each other. Last I checked (feel free to correct me here), most RPM distros let you install a 32bit package on a 64bit system, but last I tried I couldn’t do the same on a deb system. So now we’re up to three packages. One 32bit RPM, one 32bit DEB and one 64bit DEB. But now we’re assuming that all people have one of those two, but the fact is that they don’t (yes I know RPM is part of LSB, that doesn’t really guarantee that it is always present, nor properly set up). So we’re going to need another one anyway. We could go with a tarball, which at least gentoo and slackware will be used to, and possibly others, but for the others, well, we’ll either have to provide a lengthy technical README, or an installer. So, that’s five.

Now, consider that many of our games are several gigabytes, it is completely impossible for us to package all of them on the DVD. As far as I know, neither RPM nor DEB can have their payload as a separate and compatible file. Things could be copied in post-install hooks, but then we’re just about back to square one, as we’re pretty much bypassing the package manager anyway. As the installer could be made to use the tarball, we’ll need four full-size packages, and all of this is assuming that the package formats will stay compatible.

So to sum it up, not only would it be a lot of work to test and document it all, we’d still have to provide the packages we’re providing now to keep it accessible to everyone, but it would also take roughly four times the space, and I for one would not pay extra for a game to have four install DVDs containing the same game, just in several different installation formats, when one would suffice (yes yes, I know it would provide you with backups, but with the new copy protection system we have added you get free downloads of your game anyway, so that’s not a valid argument:).

If you have any input, suggestions or questions for me, feel free to ask them here in the comments, on IRC (Zero_Dogg in #lgp on irc.freenode.net), via identi.ca/twitter or via e-mail (to eskild at the domain linuxgamepublishing dot com).

Now most C/C++ programmers are probably thinking ‘what is so hard, you get them when you start main, right’…

int main(int argc,char **argv,char **envp)

That’s true, and in virtually all cases, you can store these values, either in a class, a global variable, a function, whatever your programming style uses. And from then on, you can simply access them from anywhere in the program. Its really simple, and something that most programmers know how to do in their sleep.

But what do you do before main happens? Or what about if you don’t have a main()

I know, you always have a main and nothing runs before it.

But that is very not true. Lets take two examples

Firstly, in C++

class gamedata
{
public:
  gamedata()
  {
    commandline=get_argv();
  }
  char **commandline;
}

static gamedata datastore;

int main(int argc,char **argv)
{
   set_argv(argv);
   ...
}

To start, this looks OK. Sure, Ive missed out a whole bunch of things, assumed what the user functions set_argv and get_argv do. But it looks fine. Until you look again. That static class instantiation will run its constructor before main runs. How on earth can you POSSIBLY get argv at this stage??

Lets look at an example in C now

If you are creating a shared object, you will very often need to initialise it to ensure that its state is known for the first call into the objects functions.

static char **commandline;

void __attribute__ ((constructor)) localinit()
{
  commandline=get_argv();
}

Again, you try this, and you get a big nothing. This function is called before main runs, before you ever have access to the values.

So, what is the answer?

The answer is, unfortunately, ugly. There is, in Linux, no good way of doing this. There are two perfectly good symbols inside libc which do the job perfectly, __libc_argv and __libc_argc, which are defined way before the program gets to any user-created code. Unfortunately they are declared private and you as a user are not permitted to see them. So, another way is needed.

We came up with two ways to make it work. Neither are portable, and one of them, while it works just fine, does make me go ewww. I’ll leave it to your imagination which one makes me go ewww the most.

char **get_argv()
{
  static char **preset_argv=NULL;

  if (!preset_argv)
  {
    FILE *fp;
    fp=fopen("/proc/self/cmdline","r");
    if (fp)
    {
      //Your implimentation to take the commandline as typed from this
      //file and turn it into argv. Its fairly basic
    }
  }
  return preset_argv;
}

char **get_argv()
{
  static char **preset_argv=NULL;

  if (!preset_argv)
  {
    extern char **environ;
    char ***argvp;
    void *p;
    asm ("mov %%esp, %0" : "=r" (p));
    argvp = p;
    while (*argvp != environ)
      argvp++;
    argvp--;
    preset_argv = *argvp;
  }
  return preset_argv;
}

So, a little explaination

The first example relies on /proc, the part of the filesystem that you can get all sorts of interesting information from. /proc/self/cmdline is always an exact duplicate of the command typed to execute the application, or the exact value passed in from the menu option you clicked to get it working. I haven’t bothered to create the bit of code to separate out the commandline parts onto their components. Partly because that code is fairly straightforwards, and partly because it is quite long and dull (remember it isn’t just a case of separating by spaces, you have to take into account things grouped in quotes, and other fun stuff). This is not portable beyond Linux, and people keep telling me that not all Linux distros have /proc either.

The second example requires a tiny bit of assembler knowledge. It is portable across most unix flavours, but I expect trying it outside of unix will cause you much pain. It relies on the fact that a unix standard is to push the argc and argv values right onto the top of the stack when a program starts. The example reads from the top of the stack until it finds the environ value (which is globally available at all times), and then reads back one value to get the pointer to argv. This way has the advantage that the values are correctly parsed for quotes and the like already. It makes the assumption that environ is the next thing on the stack after argv. I have seen many reports claiming this is always true, but I cannot find the location of an authoritative piece of documentation saying that it is specified true and will not change in future.

It isn’t often that you will need to do this. Most of the time, argv and argc are perfectly usable in the way you will probably have been using them for years. Even the examples above can be ‘worked around’ using initialisers called immediately after main() starts. But if one day, you come up against a problem where you need your argv where you usually don’t have access, I hope you find this post useful.

It seems that she has adopted us, as she spends pretty much all of her time in the office, and is a constant disruption to work. At every opportunity she loves to sit on keyboards – especially when typing is going on, and she is very insistent when she wants some attention, as you can see from the picture above when she decided to sit on my keyboard and demand my time.

I decided we weren’t going to name her until she had stuck around for a couple of weeks, afterall, she could have just wandered off again. But it does seem she is here to stay.

So, we have a few ideas for names, but we can’t quite decide which, if any, of them are right. So, I thought, lets get a bit of community involvement, and set up a name poll.

So, add your votes below, and if you have suggestions for a better name that isn’t on the list, add a comment, an if we like it, we’ll add it to the poll! You can choose multiple answers if you like.

EDIT Oct 8th: Well, the poll has been going for just under 4 days now, and you can’t leave a cat without a name for too long! We will now be taking the top three, Qwerty, Switch, and CatMonster, and over the next week we’ll see which one seems to fit her best. The one that works best, we’ll name her, and update this post with the final result! Thanks everyone for your contribution, and I’m sorry I never got around to adding some of the new suggestions to the poll!

EDIT Oct 16th: After a weeks trialling, one name is clearly a winner based on her personality and attitude and what comes naturally when talking to her. CatMonster! It is great as an all-purpose name that can have its start changed, so when she meows a lot she is a NoiseMonster, when she’s asleep she can sometimes be the SnoozeMonster. And when she sneezed a while ago she was the SnotMonster. All in all, CatMonster wins!

A bit of explanation as to some of these names…

• CatMonster: A bit like KateMonster from Avenue Q
• Ceefer: Ceefer Cat. Say it aloud, you’ll get it.
• Natasha: The whole Boris and Natasha thing, and she likes eating spiders (Boris the spider). Its a bit convoluted, but made the list
• Piper: She’s a mouser. So from the Pied Piper. Also has a nice link in to the ‘Charmed’ TV show
• Quark: She loves having her ears scratched, so a Ferengi name was needed!
• Qwerty: She is a keyboard cat. Obvious really
• Splodge: I mentioned the new addition to my mother on the phone a week or so ago, and she insisted this be the new name.
• Spot: Another Star Trek reference. Data’s cat.
• Switch: Her favourite place to sit is on the office gigabit switch. Its warm and by the window. Also a Matrix tie-in
• UsrBin: /usr/bin/cat. OK so cat is usually in /bin but you can’t call a cat just Bin