Agenaworld: A “Homeworld” type of game. Agenaworld is an original multiplayer PSP to PSP game that allow you to command a spacecraft to other galaxies and visit all nine planets (plus the sun). In addition, the game backgrounds are real 24bit/pixel large space images that scroll in the background (courtesy of Hubble telescope). Try to reach Earth! Click on link above to download. Press the “Triangle Button” to use the “spacegate hypercube” gravity assist.
Release notes:
In Agenaworld 1.6, the major fixes are double buffered FULL 720×480 24bit color output to the TV (when run on your slim). Note that this release requires that your set up the game folder to be running the firmware 3.x homebrew code (as opposed to firmware 1.5). It should run fine on both the fat and slim versions of the PSP.
Another update is the ability to output proportional fonts! What this means is that character sizes are not fixed width (like in Agenaworld 1.5). If you press the left trigger or right trigger button, you should get a screenful of text that shows off how nice it looks in proportional font. You will notice this for words that contain wide and narrow characters (characters “i” and “w” are at the extreme points of narrow and wide characters).
Also, this version fixes the problem people may have reaching earth if you are running on Slim output to the TV (the spacegate cube was off screen).
This version moves many gates on the maps. The algorithm for calculating the location of the gates so they are fixed at the same place whatever the screen size will be fixed in the next version, but basically, in this version you should be able to reach every place in every galaxy. Also the starting point is now at Earth, this way you can see familiar planets before venturing out into the different galaxies.I tidied up the code, and the game resembles more and more like a game engine rather than a game. Soon, it will be able to load in a file with all the map and gate info. Gates are like teleporters to different places on the same map or to different maps when you press the Triangle button when touching them. You enter one gate and exit another gate (looks like cubes on the map). In the future it should be easy for people to place gates on their own custom maps.
I will explain some technical details of what I changed in this release to make 1.6 work.
In the previous release, I mentioned that the PSP had only 2MB of vram memory. Well, apparently, the PSP Slim actually has 4MB of vram. What this means is that you can use the whole 4MB for your display buffer (the buffer that connects directly to your TV or PSP LCD screen). Apparently, this extra 2MB is only available on the Slim for homebrew if you call a kernel function:
sceGeEdramSetSize(4*1024*1024);
That call will open up the whole 4MB for homebrew. This function call was put into a newer version of dvemgr.prx (which the original was released by the maker of the M33 custom firmware).
As you can see, there is no need to move the display buffer to display from the system memory anymore, and since the old fat psp didn’t have the ability to output to the TV, the original double buffered 480x272x32x2 LCD display code fit in the 2MB vram limitation.
Concerning the proportional fonts, I was able to design four different types of fonts. If you open up splash.bmp in an image editor, you will see what looks like four lines of fonts (with some lines interleaved with a line of blank blocks or numerical blocks right below it). If you wish to follow along below, please do open up splash.bmp now, so you can get a better understanding of what is being described.
The first font line is 6 pixel wide by 8 pixel tall of fixed width font. I allow 106 different characters per font, and start it at ASCII code 32 (the “space” character).
The second font line is 4 pixels wide by 8 pixels tall of semi-fixed width font. “Semi” in that the majority are 4 pixels, but I allow an extra 4 pixels for characters that need more than 4 pixels. I put this extra 4 pixel wide info in the font line right below the second font line. This line allows more than 106 characters of font data, but I only implement the first 106.
The third font line is a proportional font that I did not implement in the game, after finding out that it was easier to code using the last font type (the fourth font type). In this type, I basically used 4 pixels wide to hold the data, and if extra are needed it gets expanded to the next character. The problem with this method was that you had to put in extra code to know where the start of a character was in the bitmap, and without a fixed starting location, it gets very tedious since each font character data can start anywhere based on previous fonts that used the extra 4 pixels.
The fourth font is also a proportional font, and this got implemented in the game. The font data were shifted left so that it is at the leftmost position on the font grid. This allows narrow font characters to use up the least amount of space when output. All fonts character blocks take up 6 pixels, but during actual copying, the number of pixels to copy (width) are listed below the font (you can see all those numbers which indicate the actual bit width).
The game can actually display all three font types concurrently, but in the game you see the fourth type (proportional) throughout. The fonts look nice, and I am thinking of porting it so that it is used as a text reader application if the need arises.
Webboard: http://www.edepot.com/forums/viewtopic.php?f=8&t=12