Hi,
I think this is my first post to this forum, so Hi guys!.
I've been working on demos or small games for my psp for the last 9 months but I started asking myself (without a clearly answer):
How closely to the official sdk is the pspsdk?
Imagine that you write a really cool (and addictive) game right? and someone who has been licensed want to employ you to make it commercial (or even put you in another project related to the psp), will you be qualified to that job?
I'm asking these things because I don't have an idea and maybe someone could point me to the right direction.
Many thanks in advance.
[I've edited the whole post, It's too late and I'm really tired. Sorry about the mistakes]
pspsdk vs official sdk
pspsdk vs official sdk
---------------------------------------------------------
if you wanna survive you better learn how to lie
if you wanna survive you better learn how to lie
Unless the original SDK used different language than C/C++ I guess there would not be much difference. You have a platform that provides some amount of calls you can use. There may be some additional features in original SDK that would allow you to to do debugging/profiling/etc. stuff different way, there even may be some useful libraries available but apart from that it would be quite similar.
A comparison to that may be: C/C++ development SDK/environment for Windows. There are many of them: Microsoft one, Borland, Watcom, GCC, ... How much do they differ? They all end up calling Windows system, they all implement C/C++ toolchains. The difference is the tools associated with them, maybe few language features they implement and some additional libraries packed with them...
A comparison to that may be: C/C++ development SDK/environment for Windows. There are many of them: Microsoft one, Borland, Watcom, GCC, ... How much do they differ? They all end up calling Windows system, they all implement C/C++ toolchains. The difference is the tools associated with them, maybe few language features they implement and some additional libraries packed with them...
The official SDK (the ones given to game developers) will probably only contain libraries and headers only for user mode functions. So the only thing you will be able to make is game mode stuff.
It would also contain the function names for all the user mode NIDs, some of which we don't know in the PSPSDK.
There may be slight differences in things such as the inclusion of crt0 etc, but for the most part, the actual program code should be compatible between the two.
Sony's SDKs have crappy build environments as well.
Basically the PSPSDK is probably far superior than the game developer's SDK. If a game SDK was leaked, we'd learn the function names and thats about it.
However a kernel SDK leak will probably be useful. For all we know, the random NIDs might be generated by the SDK at compile time itself depending on the firmware version, in which case the names can be figured out.
They should be able to sign an EBOOT generated by either SDK though, so you can actually continue to compile with the PSPSDK and they won't know the difference, unless they reverse it and identify the assembling style of the GCC compiler. GCC appends some crap to the end of binaries but that can be fixed since its open source anyway.
It would also contain the function names for all the user mode NIDs, some of which we don't know in the PSPSDK.
There may be slight differences in things such as the inclusion of crt0 etc, but for the most part, the actual program code should be compatible between the two.
Sony's SDKs have crappy build environments as well.
Basically the PSPSDK is probably far superior than the game developer's SDK. If a game SDK was leaked, we'd learn the function names and thats about it.
However a kernel SDK leak will probably be useful. For all we know, the random NIDs might be generated by the SDK at compile time itself depending on the firmware version, in which case the names can be figured out.
They should be able to sign an EBOOT generated by either SDK though, so you can actually continue to compile with the PSPSDK and they won't know the difference, unless they reverse it and identify the assembling style of the GCC compiler. GCC appends some crap to the end of binaries but that can be fixed since its open source anyway.
If you just compile it to an EBOOT and send it to them, they will know the second the signing process starts due to that fixed, always the same, game ID "our" SDK puts into the EBOOTs: UCJS10041
Again, that can be fixed easiely by adding an option to provide an own (maybe that option even exists and I just didn't stumble over it yet :D)
Again, that can be fixed easiely by adding an option to provide an own (maybe that option even exists and I just didn't stumble over it yet :D)