Some might have noticed – my blog got hacked and some malicious javascript injected.
I have now removed the malicious javascript and updated wordpress, in hope to avoid another such injection, though I’m not sure the security hole that was used really got fixed. I have no time to investigate it, so I just have to push thumbs.
Sorry for any inconvenience this may have caused and thanks to psp-programming user “Salvy”, who notified me of the hack.
Yes I’m still alive, but I’m no more active in the PSP scene I have to admit. However, after stomping over a couple very nice Youtube tutorials on “How to install Joysens”, but not finding a single one on how to actually set it up, I decided to put together a quick Tutorial that wasn’t all about the mathematics and background-functionality. It explains some of the most common problems that can be solved with joysens as simple as possible.
I know this is late, really really late, but better late than sorry 
After quite a long time of absence I’m here to notify you all that I’m still around and have returned to some PSP coding. I was really amazed at how many people have visited and written on my blog since the last time I checked and it seems that especially my JoySens CFW plugin is still famous.
Since the last release a whole bunch of new custom firmwares have been released (namely 3.90-3.93 as well as 4.01) and I had a lot of questions to add support for those firmwares to JoySens and release version 1.4 which was in development before. Today I upgraded my 3.71 M33 PSP to 4.01 M33 and first my plugins wouldn’t work and just make the PSP freeze on startup. However I knew that they had to work, because it was already reported and since the CFWs since 3.80 all have a NID resolver the old plugins (ie the non-3.71 joysens.prx) should just work. After a format of my memstick not helping I just decided to try and format my flash1 and reset the PSP and voilá – all plugins started working perfectly again.
So if you have problems getting the plugins to run on your > 3.71 PSP, just try formating flash1 from the recovery menu and be sure you use the non-3.71 version of JoySens.
I also started putting a little work back into JoySens and finished the new config file system that was planned for 1.4. The next steps will include working this system into the plugin and enable different configurations for all execution modes (VSH/GAME/POPS) as well as for different EBOOTs/UMDs. After that I’ll add a few small updates that got onto my todo list, like fixing HOLD button actually preventing any input (don’t try having remapping enabled and putting the PSP for mp3 playback into your pocket) or improving the auto-center function a bit. I’ve also got a request for analog -> round buttons remapping which would be an option for a new feature.
Unfortunatley there’s also one unlucky happening: I’ve lost a part of my motion kit driver source – namely the config file loader. But that’s only half bad, because the config file system for JoySens 1.4 will make it easy to rewrite that part. I also already added a few small changes to the motion kit driver and will release a non-beta version soon, probably together with JoySens 1.4 or shortly before.
Apart from all that I’ve also thought about releasing some of my code to the public. Into my mind came Mudkip Adventures – the first and till now only game written with triEngine, which was released already half a year ago, so there’s nothing stopping me from releasing the game source (apart from the sloppy design, but it was a 72hour project anyway so there’s not much to expect ). Next thing could be JoySens, seeing how the community seems so interested in it, so maybe there might be some people that can advance it even further.
My biggest and highest-priority project at the moment though is finishing up my supposed-to-be Rubik’s Cube Compo entry, which died due to a graphical glitch that frustrated me so much that I just had to take a timeout from PSP coding. Well I’m back to finish this one up and release a fabulous game to the community, but there’s still a lot to do before (mostly interface design and implementation).
So far – enjoy the summer and I’m waiting for your comments 
Finally, the first public beta of my motion kit driver for the Neoflash motion kit.
You can find the Neoflash motion kit here:
http://www.neoflash.com/forum/index.php?topic=4644.0 http://www.neoflash.com/go/index.php?option=com_content&task=view&id=189&Itemid=37
It currently only works for custom firmwares < 3.71, though a simple NID fix should make it work on 3.71 too. I didn’t release that version yet because I couldn’t test it, but it will be available with the final 1.0 release.
The motion kit driver allows you to make use of the motion kit in the VSH or games even though they weren’t written for the motion kit. A configuration file allows you to setup the driver per homebrew/UMD game, so you don’t have to use the same configuration everywhere.
Also, the driver fixes the missing sound issue with the motion kit plugged in and allows you to switch between motion kit and headphones any time without problem.
The SDK provides the source for compiling libmotion_driver that allows you to interact with the driver and poll motion kit data, as well as source for a small sample application that shows usage.
If you wonder where the last announced releases are, well, the effort with the motion kit driver was unexpectedly higher and kept me busy the last week. However, I am now in the state to do the final testing and polish on the motion kit driver before I roll it out to everyone. After that I will finish up JoySens 1.4 and release that as well.
Together with the motion kit driver, I will release a small SDK that allows developers to make use of the driver for their own homebrew creations. This guarantees that an already installed driver by the user will not interfere with the homebrews own implementation of the motion kit communication and allows the developer to influence the drivers behaviour. For the developers, that already want to start developing a game for the motion kit and want to be compatible with the driver on it’s release, you can find the header for the motion kit driver library here.
For the end-users, the first release of the motion kit driver will allow you to make some basic input through the motion kit to any of your homebrew or UMD games, without them having to be specially programmed for that. This will be achieved by forwarding the motion kit input to user specified buttons of the PSP, so the homebrew/UMD game is just handling the normal inputs. Also, those buttons can be adjusted in a configuration file per homebrew/UMD.
Also, the driver will be able to track plugging the motion kit in and out at any time and is even compatible with inserting the headphone remote, so you can at any time change the motion kit support for headphones, even in game. However, the first release will probably not yet contain a fix for the sound output problem, since I still haven’t found a viable solution to this. I’m still working on reverse engineering Sonys remote driver code to find a possible software solution that will be compatible with normal headphones/remote being plugged in.
After some thoughts on the project and some consulting with the others involved, I decided to release the triEngine that was being developed by Tomaz, InsertWittyName and me for public. Unfortunately the old assembla space somehow denied to let me make it public, so I had to create a new space and reimport the SVN tree.
So what does this “triEngine” do? Well, it provides you with pretty much everything necessary to start writing a game on PSP. It comes with a set of 2D graphics functions with support for animated sprites, a basic 3D interface with rendertargets and some blur functions, a full OpenGL style texture manager that keeps your textures in VRAM, a font system based on TTF fonts, audio playback for AT3 and WAV files, video playback for PMP files (yay, intro videos!), a full-featured particle system with lots of functions, WiFi code for multiplayer support, a fancy ingame console over PSPLINK to be able to control and adjust your variables at runtime (Quake style CVARs) plus some other helpul things.
However, it’s not a finished product – it was still a WIP until this release, so there’s no guarantee that everything works without problems (even though it was tested with various test samples – all available in src/tests). That it is functional nonetheless can be seen through my “Mudkip Adventures” game – it is entirely written around triEngine.
So here you go, released under GPL for the time being (License might change to a more liberal one later on):
trac (SVN browser, ticketing): http://trac2.assembla.com/openTRI
SVN repository: http://svn2.assembla.com/svn/openTRI
For anyone that wants to commit code, please read the coding style specification first:
http://www.fx-world.org/tri/coding_style_specification.txt
UPDATE: A bug and request tracking system has been opened for public: http://trac2.assembla.com/openTRI/newticket
Well, the Rubik’s challenge is over and as the interested people may have noticed, I missed getting my cube done in time. I could have submitted a working cube without any interface, but I hate such unfinished things. Well, I’m still working on my Rubik’s cube but am currently stalled by an ugly graphical glitch that I can’t seem to get rid of – oh the joys of PSP graphics programming 
Apart from that I got a (gratefully sponsored) PSP Motion kit from neoflash.com today, so I’m up to writing a CFW plugin that allows users to enjoy the motion kit with all homebrew and UMD games. I’m still thinking about a good way to map the motion input to the PSP’s default control input. Currently I’m aiming at a per-homebrew/UMD game config file, that allows you to forward the motion input to any combination of the PSP’s controls – with or without disabling them. The only problem left is the disabled sound. The joy of the motion control gets hit a lot by the silence and the only solution I found till now is a hardware solution, but I’m still aiming at a possible software solution.
PS: JoySens 1.4 is in the works as well and should be released in a hand full of days (possibly a few more). It’s going to contain a fix for the broken primary button mapping, keep backlight on when the analog is pressed, disable the input when HOLD button is set as well as contain the possibility to set different configurations for VSH and game/UMD.
I just wanted to inform you that I am taking part in the devsgen.com Rubik’s challenge and I’m trying to win the price of $500. I don’t want to give out too much information at that point, since the deadline is still too far and the competition is tough , but I can say that this is gonna be my most complete and cleaned-up homebrew for PSP.
I’m very interested in that challenge, since I find it more appealing than most other coding competitions where people can enter things they are working on for ages already and then outrule anyone that started a project specifically for that competition. Also it gives much more possibility to show the coding skills and compare them to the other entrants, so the judging will be much more objective (or at least so I hope). I also like the fact that the source code also gets judged, since that really forces people to think about their code design, rather than club everything together so that it just plain works somehow (and I’m one of the many that suffer from the lazyness of proper code layout and commenting unless forced to ).
I really hope there are more such challenges in the future and I’m looking forward to the other entrants’ versions of a Rubik’s cube for the PSP
So look forward to September 30th when the result is revealed.
I spent today to work out a very elaborate (with lots of mathematical background to satisfy my needs ) tutorial on how JoySens functions and how to configure it correctly. It seemed necessary as lots of questions turned up about how to set it up correctly and people did not catch the real depth of the plugin. Comments are wanted!
I released a cardgame library today that I wrote on a day back in december. I wanted to try out a card counting mechanism for black jack and ended up with this cardgame library. It makes use of OSTL – my Open Standard Types Library for ANSI C and is therefore a good sample for it’s usage.
The goal was to make the code as clean as possible and provide all basic functions for a type of french tarock cardgame.
As it stands, you can create decks with variable number of card sets in it (each set containing 52 cards), shuffle decks, draw cards from decks, put cards onto discard piles, create player hands and put and discard cards into/from the hand.
The sample application is a mere card-drawing and printing application to test the functionality of the library. Maybe someone can make this into a game eventually
Everything is released under GPL as always, the download link is in the download section. Enjoy!
PS: There has also been an update to the DEV plans/WIP site – yes, coding on the PMP Mod GUI goes on!
Bad Behavior has blocked 125 access attempts in the last 7 days.