raphael’s devblog

Lately, triEngine has been updated again by me. A lot of fixes and new features have been added.

Here’s some of the log messages:

• Added default sprite mode width/height (if set to 0) resolving to image width/height.
• Changed triDraw*Rotate to not depend on ortho mode anymore (Thanks Xfacter).
• Added double displaylist optimization.
• Added triple Sysram buffer mode that saves up VRAM (API change for triInit() required).
• Added TRI_DLIST_SIZE_KB macro to override the display list size.
• Added new triDraw primitives and fixed triDrawCircle functions (also don’t require a numSteps parameter anymore).
• Added inbuilt font.
• Added support for saving/loading own file format (trf) and compile without Freetype (TRI_SUPPORT_FT).
• Added function to make a font mono spaced.
• Fixed font drawing bug.
• Added triArchive (by tommydanger).
• Added custom particle render function.
• Added more documentation to triGraphics.
• Created branch/modelanimation for preliminary implementation of model animation support.

Also, the documentation has been regenerated, to match revision 30: http://tri.fx-world.org/doc/html/

Apart from that, tommydanger has started working on some tools to support triEngine. The first will allow you to create triArchive files easily to use in your game. The next is a small image converter for saving triImage files.

Lately a lot of (great) projects that make use of triEngine have emerged. It’s nice to see this engine finally get recognized in the scene, so I decided to give contribution by listing some of those projects.

First today is Geometry Wars PSP written by Sturatt:
http://forums.qj.net/showthread.php?t=143852

Next is a PDF reader application by sauron le noir:
http://forums.ps2dev.org/viewtopic.php?t=10845

Also LuaPlayer HomeMister v2 (LPHMv2) is based on triEngine to speed up Lua and compete with PGE Lua:
http://forums.qj.net/showpost.php?p=2102549&postcount=100

If you too have a project in the works that makes use of triEngine, please feel free to post a feedback and tell me about it. I’m eager to hear of more

On a sidenote: I have found the supposedly lost MotionKit driver source of the 1.0b release. Seeing how the 1.0 release was a major miss for anyone not just interested in getting the driver working under 3.xx+ kernel, this gives me the chance to fix this issue once and for all. Sound enable will work again, compatibility will be same as 1.0b again, just that it will work under 3.xx+ kernels too and add the new function added to unload the driver module. Hopefully a 1.0 final will be done soon.

After a long time, here’s an update for the motionkit driver too. It finally brings the driver and SDK out of beta status and merely contains a new motionUnload function that allows to unload the currently running motion driver so you can load a different version as well as addresses a problem when trying to load the driver in a 3.xx+ kernel application.

So what does it do?

If you are a dev: You get easy acces to the neoflash motion kit input data without any SIO coding on your side, provided as raw gravital acceleration vector as well as a rotation vector that represents the tilting of the PSP. Those values are also filtered and smoothed over time in a configurable way to enhance signal quality without any coding on your side. You also don’t have to care whether the user has the motion kit plugged in or not, you just poll the motion data as an additional input method - as long as no motion kit is plugged in, the driver will just return zero values for all vectors. If your application requires a motion kit to be plugged in, you can easily check for that too (the SDK sample application shows a method to do so). Apart from that the driver bypasses the nosound problem that the motionkit suffers from because it’s being connected to the headphone port. It’s even possible to switch the motion kit and headphones at any time without a problem.

If you are a user: You get a custom firmware plugin for adding a simple support for the motion kit to any UMD game or homebrew by enabling the button forwarding mechanism, which interprets motion gestures as configurable button presses. Ever wanted to navigate through XMB by tilting your PSP? Do it!

DOWNLOAD

Here’s another update on JoySens, this time fixing some of the issues that were introduced with 1.4/1.41:

- fixed compatibility issues with Sony UMD driver (and possibly some other applications that require more kernel memory)
The config file system now uses a mere 1Kb of RAM where it used 24+Kb in 1.4/1.41
- Reduced module size a bit (to further help memory problems)
- added a workaround info output for POPS (flickers a lot, but at least you see something)
- fixed the adjust calculation to avoid crashes for high values (shouldn’t happen anymore even with adjust 32.0)
- fixed a little Button remapping bug

It took quite some time to completely rewrite the config system (once again) to not use any dynamic memory allocations and still work reasonably well. I could have got it down to not using any memory (besides stack) at all, but that would have reduced the speed a lot, as there wouldn’t be any buffering on the file reads and for every setting the whole file would have to be read through. I’ll probably release the config system as a library for plugin writers at some point. For now, enjoy JoySens 1.42!

If you still find any compatibility issues with specific UMD drivers, homebrews or games, please let me know about it with detailed information on your firmware version, other plugins running and any other circumstances that might influence the behaviour of JoySens.

[UPDATE]
1.42 has been replaced with 1.42b fixing a bug that messed up the settings file after saving settings from in game or vsh.

DOWNLOAD

Long awaited and finally here to stay. JoySens in version 1.4 adds a couple of features and fixes:

- Added support for configs for different modes (VSH/POPS) and game/eboot paths
- Added analog<->Buttons mapping modes
- Fixed primary button mapping
- Fixed HOLD button preventing analog input
- Fixed to keep PSP from suspending/shutting down LCD if analog was pressed
- Fixed font output shadow making it better readable on light background
- Improved auto-center function a bit
- checked compatibility with CFW up to 4.01-M33-2
- Made installation easier

Yes, it’s now easier to install for all those that couldn’t get around those .txt files  and allows you to specify settings for each of your games/UMDs individually. Play your favourite racing games with high smoothing, while the shooters have low smooth and higher sensitivity.

If you have problems making JoySens run on your latest firmware, try formating your flash1 from recovery menu and resetting the PSP.

If you haven’t heard about JoySens before:
- “JoySens is a custom firmware plugin for Sony PSP that allows you to control the sensitivity of the analog stick in a very efficient way as well as “repair” faulty analog sticks. In very bad cases where the analog stick is not repairable, you can also just disable it so it doesn’t interfere with your games anymore. Apart from that it includes functionality to swap and remap DPad input to analog stick and vice versa, hence allows you to control the XMB with the analog stick for example.”

DOWNLOAD

[UPDATE]
Version 1.4 has been replaced with bugfix version 1.41 dealing with the following problems:
- fixed crash when saving settings from game
- fixed JoySens not starting in homebrew
- made JoySens not boot in recovery

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 :P). 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.

DOWNLOAD

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.