Exp For Gp2X And Wiz. We Have Achievements!


saboteur2

Still Fresh
Joined
Jan 14, 2009
Messages
16
Age
53
Website
www.saboteur.arrakis.es
EXP is a program wich add Experiencies (achievements, trophys, etc) to your games for GP2X and WIZ.
There is a SDK and a application to manage profiles.

[cut]For gamers (all goes in games directory, in Wiz):

- EXP Application. Manage you EXP (or your friends one). Select one and exit. Last EXP selected will be the active one.
- Escape from Minos (Versión EXP). 32 EXPERIENCIES, 1000 POINTS.
- Rock Rain 2 (versión EXP). 18 EXPERIENCIES, 500 POINTS.


For coders:

- EXP_SDK. You know. exp.h in include directory, libexp.a in lib directory.

Include next line in your headers:

#include <exp.h>

and -lexp in link options.

Examples.


exp_init(“Author”,”Escape from Minos”,screen); // screen is a SDL surface (optional)

exp_add(1,10); // experience 1, 10 points
exp_add(2,20); // experience 2, 20 points
exp_add(3,30,1); // experience 3, 30 and is secret

exp_add_desc(1,silly”,”you falled”); // description of experience 1


Do you want more languages? The system load the language selected in profile.

exp_add_desc(1,”tonto”,”te has caído”,”Spanish”); // description spanish
exp_add_desc(1,”silly”,”you falled”,”English”); // description english

exp_win(1); // active experience 1
exp_win(2); // active experience 2
exp_win(3); // active experience 3

Remember:

exp_update(); // just before SDL_Flip(), to show the system messages
exp_end(); // when close the game

There are another functions (look at exp.h):

exp_user(); // get the name of the profile
exp_data_path(); // get the path where you can save data files, etc...
exp_add_img() // add an image to experience
exp_add_icon() // add an image of the game

If you don't use SDL but want EXP, use exp_init("author","game",NULL); You don't see the messages, but data will be saved.

Data is stored in directory EXP, in root of SD.

It's a beta, but very stable. Please, I need feedback. Thanks to all.

APPLICATION AND GAMES ARE IN ENGLISH!!!

exp_01.png
exp_02.png
exp_03.png
rockrain2.png


[/cut]
 
Gotta say, this is seriously cool.
 
Any chance OpenSourceBox Live[sup]TM[/sup] will be coming to the caanoo/pandora?
 
In the words of Nova Ophensauce... This is seriously cool.

Is there any way to select profile from within the game? And to manage your experience from within your game? It sounded like it was a separate application?

/Uni
 
well yes, i also like the idea - great stuff :)

one suggestion though - how about adding a callback function if not using SDL? so that the app itself can display the messages?
 
b1ueskycomp1ex said:
Any chance OpenSourceBox Live[sup]TM[/sup] will be coming to the caanoo/pandora?

:D Good name. I don't have that consoles, but would be possible. It's coded in C++ with SDL, so I think there is no problem.

u9i said:
Is there any way to select profile from within the game? And to manage your experience from within your game? It sounded like it was a separate application?

/Uni

Good point. I think it is easy to add an option to select another profile, I'll take a look. And... to manage profiles, is better a separate application and the SDK as little as possible to avoid memory problems.


crow_riot said:
one suggestion though - how about adding a callback function if not using SDL? so that the app itself can display the messages?

:lol: It's the same I thought when finished the library. I was to split de code in Core_Exp, SDL_Exp, etc... The Core_Exp manage all experience, and SDL_Exp will show the messages of the core with SDL (for example).

Thanks to all... All your sugestions are welcome to get a better sdk. ;)
 
Last edited by a moderator:
Nice idea!

A couple of suggestions, most of these I would consider "must-have":

  • Documentation on the data format
    This would allow for alternative implementations
  • Callbacks or data query functions in the API
    Implementations not using SDL can still use the data functionality of the lib.
  • Source code
    Allows usage of the lib in projects that cannot use the library binary, maybe because they
    already link against a different version of SDL... it could also be possible to turn SDL support off
    at compile time, if it is not needed/wanted in a project.
  • Proper open source license (GNU compatible)
    Otherwise it will not be legal to use the lib with a lot of stuff out there.
 
"Experience Unlocked: Crashed PCSX4ALL emulator."

Jokes aside, this is something I am looking forward to seeing in new homebrews. Like the people above me said: this is cool.
 
Echoing the others here, I think this is cool. My Xbox 360 is the one "main stream" system I play and I love collecting achievements on it. I would have never dreamed I would be doing something similar on my WiZ. I hope other home brew developers will include them in their games ;).
 
hmn said:
[*]Source code
Allows usage of the lib in projects that cannot use the library binary, maybe because they
already link against a different version of SDL... it could also be possible to turn SDL support off
at compile time, if it is not needed/wanted in a project.
[*]Proper open source license (GNU compatible)
Otherwise it will not be legal to use the lib with a lot of stuff out there.
[/list]

Licensing problems are a lot of pain, and opening everything does not necessarily solve the problem.

Linking to an external (i.e. dynamic) library does not necessarily violate the GPL / LGPL. With GPL it's still an unanswered question with open-source lawyers arguing both sides. With LGPL, that was the entire purpose of the licence. Most LGPL software (like SDL) and other open-source code recognises this. It's fine for me to supply a binary that is linked against SDL, SDL_mixer, SDL_gfx, etc. so long as the parts of the LIBRARIES that I link to have source-code available - i.e. if I link to a dynamic SDL library (e.g. DLL or .so) and distribute that, then the code to THAT library is still subject to the license and any source-code-visibility-restrictions, but the code that loads the SDL library and executes commands from it - i.e. my game - is not (in general).

The bad thing is static linking, which some GP2X apps see as necessary - as soon as you statically link SDL (i.e. build SDL into your binary such that it becomes a whole piece that cannot be separated from your code) then your code needs to be under the same license. I did this myself with STPPC2x because, well, it made licensing simpler when it was starting to get out of hand (STPPC2x has MIT, BSD, GPL and LGPL code in it, I believe, and I was as careful as I could be to make sure everything was compatible and legal - it was developed in Cygwin but all distributed binaries are from non-Cygwin dependent code). But a new project of mine, which probably won't be open-source, was developed in MinGW and dynamically loads SDL and some other libraries from separate, external library files and that's fine. If someone wants the source to those particular library files, no problem. You can even have the source to my whole development environment (in theory). But they don't need the source to my program that uses those libraries (in general). It means that everything became a lot easier to manage from a distribution point of view. GPL'ing STPPC2x meant that it was ported to everything from the PSP and NDS to the Wiz/Caanoo because someone took my source and could do something with it. But I had to spend a lot of time checking licenses properly in order to make sure that it was legit. I'm not sure that a lot of programmers do that kind of due-diligence work - I've seen GPL/LGPL code inside GP2X programs that don't have an offer of source, and even some people who wrote ports of STPPC2x never fed their source code changes back.

Lots of programs on Windows work using open-source DLL's (*dynamically* linked *libraries* - the thing we're talking about here) and yet don't subject their main program to the GPL. "Super" (the video convertor) was one last time I looked. The FSF says that dynamic linking isn't allowed, other lawyers disagree (and the FSF are NOT the official source of information here - it's all very much a legal grey area dependent on a court's interpretation, not the FSF. It would be a costly fight to decide which is right and would be one of the defining moments of open-source... nobody has yet done that or knows for sure if it'll be successful. It centers around whether an external DLL is "derivative" of a program that uses it, or a work-alike DLL, and work just the same. LGPL makes things clearer - lots of commercial games use SDL libs and things like that and don't pay for a commercial license.

In this case, it would not be difficult for someone to link against this library with a GPL program, but not include it in the final executable, and supply an external, dynamically-linked file along with the program whose source code was closed. If that file was missing, it would be very simple to run the game but without the "achievements" library loaded at all. Or vice-versa, linking a GPL library from a closed-source application. So long as you don't generate a single binary that has bunched together code with lots of different licenses, you're almost certainly fine.

That's why the library binary is supplied, I guess, because it avoids 99% of the licensing problems - without needing to give away the source code. However, I believe there may be a licensing problem here - if the library can take and act upon an SDL_Surface, it suggests that it was compiled using SDL headers or code. That means it's almost certainly required to be LGPL anyway. Thus, the very act of publishing it here means that the author might have to divulge source code if someone asks. This is why a lot of the open-source licensing stuff is avoided by some programmers.

Licensing is a nightmare. Even if someone opens up their code, the arguments and pitfalls of combining licenses is a pain. Hell, compiling MinGW apps with profiling enabled makes them subject to the GPL - but without, they can even be entirely proprietary or public domain. And it matters what version of the GPL you interpret the licence as being. An external library that programs choose to load if it's present solves 99.9% of the problem for everyone. Whether it's GPL or not, doesn't really make anything any easier.

Whenever I program, I keep a file in the project folder - it says, in my own plain English, what source I've used, what the license means and where I got it from. I even save things in there like "permission" emails from graphics artists, musicians etc. if I ever use their work. It's not unusual for that file to be larger than most of the source code files, even if I state stuff briefly. To me, the GPL is/was a wonderful idea but it's been so corrupted by technical problems, unclear generic wording, and other things that it's become a BIGGER pain to use GPL stuff than to just use other licenses or public domain stuff. If you GPL this library, for instance, then games-authors might be obligated to GPL their games. If you LGPL it, then other programmers will be able to use it dynamically but you have to release the source. If those authors link statically and your library is GPL or LGPL, they are in violation. If their game is GPL but they link with your proprietary library, they are STILL in violation. If you just leave it as proprietary, it's up to the individual programmers whether they want to load/bundle it and under what terms, and the onus is on them, not you.

OS licenses are never clear-cut, and rarely solve any licensing problems. Linux uses GPLv2 ONLY (no "or above"), Cygwin has weird GPL dependencies that (although clarified) seem contrary to the licence, MinGW can introduce GPL'd code when you debug if you're not careful, cdrecord tried to mix GPL and an incompatible licence and still nobody's sure what to do about it, GPLv3 doesn't solve anything but a few patent problems - at any point the wording on the licenses could have been written to take account of that stuff much more sensibly (at least for the "or above" users) but hasn't. Open-source licensing is hideously complicated for such a simple thing - "use my code, but don't run off with it or claim it as your own".

The author of this library would probably be massively discouraged now if they wanted to keep source secret - the only real sensible way to avoid legal hassle at all is to LGPL it or remove the "Supply an SDL_Surface" parts, which could cripple its usability. And encouraging static linking would be quite a bad thing either way, but at least the violation would not be the fault of the author of the library, but the person who statically links and distributes.

A lot of games, libraries, etc. on the GP archives are violating some clause of some licensing somewhere, it's just that nobody has bothered to report it. That's not to condone it (I don't, and if I found out my proprietary code had GPL code in it, I'd rip it out immediately and/or publish source and would be INCREDIBLY embarrassed and much more careful in future), but open-sourcing this particular library doesn't actually solve any more legal problems that it creates. I'd encourage the author to remove the SDL Surface functionality, or LGPL the code if possible, but claiming that merely throwing it under some GNU licence would fix things is short-sighted.

Code licences are a minefield. Hell, I have a line for every third-party PNG image, OGG file and piece of code that my latest game uses describing it's origin and licence. When I modify them to suit my game, I have to keep track of where the original came from and what I did to them and what images use what artist's copyrighted works. It's a pain and yet still most programmers do NOT keep track of this stuff. This library is the least of any FSF-fanatic's worries.
 
Last edited by a moderator:
What I wanted was to use a LGPL license, because of SDL. But checking the code I think is better remove SDL references and split library in two parts: core and messages. If anybody don't use SDL, I don't want to force him to do it, but I can include a library that show the messages in SDL, OpenGL, etc...
If this library is really interesting and people use it I'll give the code anyway (LGPL probably), but for now I only want a stable system for games. I'll use it more until I show the code.
 
If the game works with SDL, you only need to link the library and include some instructions. I did it in minutes with Escape from Minos. If not use SDL, it works but you will not see the messages.
 
saboteur2 said:
What I wanted was to use a LGPL license, because of SDL.

I would go with something more permissive than the LGPL (but still something GPL compatible), to allow use in closed source, non-dynamically linked applications as well. MIT/X11 license or zlib license come to mind.
 
Last edited by a moderator:
ledow said:
The bad thing is static linking, which some GP2X apps see as necessary - as soon as you statically link SDL (i.e. build SDL into your binary such that it becomes a whole piece that cannot be separated from your code) then your code needs to be under the same license.
I don't think so. The only point is to allow users to link against different versions of the LGPL library in question (in this case, SDL), so providing the compiled object files will suffice. Debatable of course, but nobody seems to give anyone a hard time about these things in this community, which is nice and as it should be.
 
Last edited by a moderator:
if there were an easy way to get this to work with bennu, i'd add this to my games in a heart beat
 
saboteur2 said:
I'm on it... ;)

great, let me/us know when this is possible. adding experience to games is a great idea.
 
Last edited by a moderator:
is there any more news on this ?

I'm interested in this trophy system as well and would like to use it in one of the games i'm going to make for the caanoo. Did you release a final yet what about the sources and license did you found one that served your needs ? Is the lib (like it is now for the wiz) compatible with the caanoo ? i'm not certain if the libs from wiz are binary compatible with the caanoo, i could try it out tonight or tommorow if i find some free time... But i'm highly interested in this as wel

The more games that use it, the better it becomes, maybe someday it's a standard for gph (and other) related consoles :)
 
I tried to do it compatible with Caanoo, but I couldn't. Finally, I left for a while. For any reason, I can't make the programs work for Caanoo, so either finished the library.
Perhaps I'll try one more time soon.

Anyway, I will release another game with EXP in next days, for a contest in gp32spain.com. ;)
 
Back
Top