Lua Player for PSP

[MikeHaggar]

I got it from: http://www.dcemu.co.uk/vbulletin/showthread.php?t=7962

Dunno if alex got an official page...

[indianajonesilm]

Well I added the puck to my air hockey game, if anybody wants to give this test version a try and give me some suggestions I would appreciate it. Feel free to make changes in the code to make it better if you want. Thank you.

Standalone version:
http://webpages.charter.net/aldanafx/st ... hockey.zip

Lowser ready version:
http://webpages.charter.net/aldanafx/st ... hockey.zip

I want to add an options menu, AI for single player game, better puck physics.

[nevyn]

Well I added the puck to my air hockey game, if anybody wants to give this test version a try and give me some suggestions I would appreciate it. Feel free to make changes in the code to make it better if you want. Thank you.

Standalone version:
http://webpages.charter.net/aldanafx/st ... hockey.zip

Lowser ready version:
http://webpages.charter.net/aldanafx/st ... hockey.zip

I want to add an options menu, AI for single player game, better puck physics.

Heh, yup, that puck physics needs serious refurbish :P Some friction ('tho not much), larger friction when hitting something (wall or paddle), and an acceleration multiplication proportional to how "hard" you hit the puck (perhaps you can measure how far into the puck the paddle gets after that frame, and use that as a multiplier for acceleration, and then move the puck outside the paddle.)

[Shine]

I made a list of known luaplayer apps and games over at http://ncoder.nevyn.nu/luaplayer/01%20Known%20Apps%20and%20Games.html

Thanks for your list, I've added some missing programs and published it to a gallery.

Everyone can submit new programs with the form at the bottom of the page or send me an email. Later I plan to write a Wiki, for easier and faster update of the page (this is a server running a Lisp webserver, which I'm using to learn some more Common Lisp, so this might take some time).

[nevyn]

I made a list of known luaplayer apps and games over at http://ncoder.nevyn.nu/luaplayer/01%20Known%20Apps%20and%20Games.html

Thanks for your list, I've added some missing programs and published it to a gallery.

Everyone can submit new programs with the form at the bottom of the page or send me an email. Later I plan to write a Wiki, for easier and faster update of the page (this is a server running a Lisp webserver, which I'm using to learn some more Common Lisp, so this might take some time).

Ooh, Lisp, I've always wanted to learn that... slightly off topic, but do you know where to get a good command line interpreter for it?

On the gallery, nice with the submission form :) It'd be nice though with info on whether the app 0.7-compatible, and if it's Lowser compatible, and some descriptive text... A wiki would work good for that, though :) When's that due? Maybe you could just proxy to an apache with php and use wikimedia's wiki software.

[Arwin]

I just wanted to congratulate you two on doing a very fine job with this! Who knows you can get it up to a level where you can get it published legally even - ever considered that option? Since it is in a managed environment it would be relatively safe. And you could easily make a website to support editing graphics and such.

[nevyn]

I just wanted to congratulate you two on doing a very fine job with this! Who knows you can get it up to a level where you can get it published legally even - ever considered that option? Since it is in a managed environment it would be relatively safe. And you could easily make a website to support editing graphics and such.

I've thought about it, but I'm not sure there's enough market value in it... The official SDK isn't exactly cheap, and add a license to that... You'd have to sell quite a number of luaplayers. And I'm not sure to what extent Sony'll be selling non-umd games. It's an intriguing idea nonetheless, and I'm going to look into it...

[Shine]

Ooh, Lisp, I've always wanted to learn that... slightly off topic, but do you know where to get a good command line interpreter for it?

On PC I'm using LispWorks, which has a nice IDE and on the server cmucl.

When's that due? Maybe you could just proxy to an apache with php and use wikimedia's wiki software.

When I have time for it :-) Apache would be the easy way for fast results, but in the long term I hope that Lisp is easier, so I'll do it with Lisp and perhaps UnCommon Web, a web framework which uses continuations for easier workflow implementation.

Who knows you can get it up to a level where you can get it published legally even - ever considered that option? Since it is in a managed environment it would be relatively safe.

I think Nevyn is right, the official SDK is too expensive for it, because I'm not sure, how many copies will be sold. Of course, not only programmers would buy it, but everyone who wants to play Lua Player games, but the best would be, if Sony would include it in a demo disc, like Yabasic for PS2.

[Arwin]

Downloadable software wouldn't be too expensive to manage, so perhaps Sony can offer it that way, or one of the PSP magazines could get a licence to do it from Sony and offer downloadable software through its websites. I'm sure it will be coming eventually - the infrastructure is there, the browser is in FW 2.0 and you can save files to disk, so if they contain the proper licence code, you're all set.

[Shine]

I just want to summarize some discussions from the IRC for this forum. There was the idea to include PhysicsFS into Lua Player. With PhysicsFS you can pack all your game files to one zip-archive, but you can load it from within your Lua script as if it were normal files in normal directories. This could look like this:

System.openArchive("game.zip")

and if in game.zip is the file "image.png", after this you can write simply 'Image.load("image.png")' and the file is loaded from the archive automaticly. This can be used from standalone-scripts, or from Lowser for scanning archives. And it can be used in parallel with normal file access.

Another idea is to provide a function for calling scripts in a new Lua environment, which makes it easier for Lowser: It calls a script in the new environment and the "Home" button could be assigned to close the new Lua instance by default, which returns or starts the caller again.

And finally all files, which are save, are saved in a subdirectory of the PSP/SAVEDATA directory, which is named like the folder or games archive from which the current Lua instance was started. Load is transparent for the script: it searchs first in the archive or startup directory and then in the savedata directory. A special save function can save the standard PSP savedata files, which uses the icon.png from the game directory or archive for the standard PSP savedata GUI.

So the proposed changes to Lua Player:

- EBOOT.PBP first searchs for script.lua and starts it, if found

- if not found, it search for game.zip, opens it as a PhysicsFS archive and starts script.lua from within it

- System.openArchive(name) is added, which adds all files from the archive for all read functions (I omitted the nasty details here, like rewriting Lua io-lib and Mikmod to make this possible :-)

- System.closeArchive(name) is added, for example for Lowser to find the index.lua from the currently opened archive, only

- System.execute(script or archive) is added, which calls "script" in a new Lua environment or "script.lua" from "archive" like the default start concept described above

- System.savedataSave(title, details), which saves the data in the savedata directory, which is determined by the startup directory or archive name. "Title" and "Details" are displayed from within the standard PSP GUI as any other original PSP game (see this thread for the details how to save and load savedata files)

- System.savedataLoad(), which returns the title and details as multiple values as saved

- the "Home" buttons exits the current Lua instance (have you ever hit "Home" without selecting "Yes" after this?) and exits Lua Player, if it was the first instance

- Lowser scans the Applications directory for directories and for zip-archives

- all file access with PhysicsFS and standard Lua file I/O is limited to allow access to the starting directory/archive, subdirectories and savedata of the current application, only (this makes the system kind of virus-safe and you can start games without prior inspection of the script to see if it deletes your memory stick)

The reason for saving all data in the standard savedata location is that Lua Player can be used from within read-only file systems this way, too, so perhaps it can be used for professional game development, without changes to the code.

The whole concept is backward compatible (not that this is important for a < 1.0 version) and you should not see any difference in using it, you just have the possiblity to pack your files to one yourgame.zip, if you like.

I'm sure I've forgot many details, but this is the outline for the new ideas. I don't think that we need to discuss it in all details, because missing things can be designed while programming, if you like the general concepts itself at all.

[gabriel]

InputManager library

I'm working on an InputManager library for lua, and I'm currently in the last steps of bug fixing for the new version of lua player. What are peoples thoughts on the interface. I'm open to suggestions

...

I appreciate any feedback, I'd like to get a nice interface that most everyone is happy with. I'm still tossing up if I should allow for multiple handlers registered to a single event, at the moment there can be only one

I think that this would be perfect! Let me know when you're releasing the code so that I can test it. It looks great the way it is so far.

One thing which I wonder is if it will keep track of individual key presses and releases. For example, i've tested some code which would only be executed when the left directional is pressed and released. However, if you hold down left and tap the X button it detects it as though you released the left directional and pressed it again.

Good luck!

[mrbrown]

And finally all files, which are save, are saved in a subdirectory of the PSP/SAVEDATA directory, which is named like the folder or games archive from which the current Lua instance was started. Load is transparent for the script: it searchs first in the archive or startup directory and then in the savedata directory. A special save function can save the standard PSP savedata files, which uses the icon.png from the game directory or archive for the standard PSP savedata GUI.

I would strongly recommend you not futz around with anything in the PSP/SAVEDATA directory. Official games put stuff there. Pick a different directory or you run the risk of breaking something you shouldn't.

[DiabloTerrorGF]

http://haggar.pocketheaven.com/PixelFixer.zip <- I updated your pixelfixer. No need for backgroundX.png files any more. And to slow it down, just increase the delay value I added. Oh... and I hope you don't mind that I updated the code.

Not at all :P

One of the things I love about LUA, it's almost always open source, you can do what you want.

[alex_dsnews]

Dunno if alex got an official page...

I don't. Well, I do have a site, but it's a generic psp/ds news page, and not a programming one. Sorry about that!

[Shine]

I would strongly recommend you not futz around with anything in the PSP/SAVEDATA directory. Official games put stuff there. Pick a different directory or you run the risk of breaking something you shouldn't.

Yes, you are right. It could be misused for exploits and Sony could dislike it, if they don't have the control, which names are registered as savedata game names. But a central place for all data written by Lua Player is nevertheless a good idea, perhaps /PSP/LuaPlayer and within this directory a subdirectory for each game.

[majik]

Hey guys, can i start off by saying how fanatstic the lua player is. I really am addicted to this but have a problem with some code and it's driving me nuts!!!.

I have a function that displays a png background for 4 seconds and then a second background with another pause by using

function splash()
screen:blit(0, 0, background, 0, 0, background:width(), background:height(), false)
screen.flip()
screen.waitVblankStart(240)

screen:blit(0, 0, background2, 0, 0, background:width(), background:height(), false)
screen.flip()
screen.waitVblankStart(240)
end

-- Main code

while true do
splash()
local keyin = Controls.read()
if keyin:start() then
break
end
screen.waitVblankStart()
end

My problem is that the pressing start to break or any other button if i put the code in does not work until the second image has finished loading if i hold it down to catch it. How do i run a loop until a button is pressed and move on in the code?? - i know it's something stupid but it's driving me nuts.... i know it's my code - if anyone could help me that would be great.!! :)

i have tried everything :(

[alex_dsnews]

Your code will sit and go through the 8 second pause and then register the start button because that's how you've coded it.

You'd be better off (IMO) having the image displayed within the main loop, and incrementing a timer to rotate between them. I'm not in a position to test just now, but something like this:

Code: Select all

-- initialise count variable (outside main loop)

count=0

-- Main code 

while true do 

if count==1 then screen:blit(0, 0, background, 0, 0, background:width(), background:height(), false) end

if count==240 then screen:blit(0, 0, background2, 0, 0, background:width(), background:height(), false) end

if count==480 then count=0

count=count+1

local keyin = Controls.read() 
if keyin:start() then break end 
screen.waitVblankStart() 

end 
-- end while loop

There's probably a much better way to do it, but that should do the job...

[majik]

thanks for the reply and i understand why my code did not work from your example so i have learnt a bit more - thank you, but,

no image is displayed and the code stays in an infinite loop and won't break out. I have to take the battery out to reset as pressing home and exit freezes.

Also i noticed that an end statement is missing??

i moved the count=count+1 to here :

local keyin = Controls.read()
if keyin:start() then break end
screen.waitVblankStart()
end
count=count+1
end

this stopped the freezing and the breakout works but still no image is displayed. Your code does make sence to me though and i understand how it works. and i know that the count+1 is wrong were i have put it. i cannot understand why it's not working because as i said it makes sense.

thanks again - you guys are awesome!!

[Shine]

this stopped the freezing and the breakout works but still no image is displayed.

Sorry, the documentation is very poor at the moment (if someone wants to improve it, feel free to do it, documentation is not one of my favorite tasks :-)

There are two screen buffers: one offscreen buffer and one visible screen buffer. All drawing functions goes to the offscreen buffer and screen.flip() exchanges the offscreen buffer and the visisble screen buffer. Until you call this function, no don't see what you are drawing. Before switch you should call screen.waitVblankStart(), because otherwise it is possible, that the switch occurs when half of the old buffer is displayed and then half of the new buffer is displayed for 1/60 seconds (search google for vertical retrace etc. for details on this). All this complicated handling is to avoid flickering and is known as "double-buffering" in modern graphics applications.

[majik]

YES!!! Thanks to alec and shine - all working perfectly now. now i can carry on :) - oh by the way the game is commando from the old C64. I have sorted the music and gfx and now need to work out how to do vertical scrolling instead of flipping the images as on pyramid panic.

Thanks again

[MikeHaggar]

I just want to summarize some discussions from the IRC for this forum.

What IRC chan might this be? ;)

- EBOOT.PBP first searchs for script.lua and starts it, if found

- if not found, it search for game.zip, opens it as a PhysicsFS archive and starts script.lua from within it

- System.openArchive(name) is added, which adds all files from the archive for all read functions (I omitted the nasty details here, like rewriting Lua io-lib and Mikmod to make this possible :-)

- System.closeArchive(name) is added, for example for Lowser to find the index.lua from the currently opened archive, only

- System.execute(script or archive) is added, which calls "script" in a new Lua environment or "script.lua" from "archive" like the default start concept described above

- the "Home" buttons exits the current Lua instance (have you ever hit "Home" without selecting "Yes" after this?) and exits Lua Player, if it was the first instance

- Lowser scans the Applications directory for directories and for zip-archives

- all file access with PhysicsFS and standard Lua file I/O is limited to allow access to the starting directory/archive, subdirectories and savedata of the current application, only (this makes the system kind of virus-safe and you can start games without prior inspection of the script to see if it deletes your memory stick)

Sounds good to me.

[nevyn]

I just want to summarize some discussions from the IRC for this forum. There was the idea to include PhysicsFS into Lua Player. With PhysicsFS you can pack all your game files to one zip-archive, but you can load it from within your Lua script as if it were normal files in normal directories. This could look like this:

Isn't sort of the POINT of physicsFS that archives act transparently as folders? Then it should just be System.changeDirectory("game.zip"), and applications using the file system should just continue working, without any additions to the API.

The execute idea is pretty good; sandboxing is a good idea.

As for save data, using the SAVES folder is a pretty good idea, except that I don't like its hierarchy. I wouldn't mind the following hierarchy:

Code: Select all

/PSP/LuaPlayer/{Applications, Documents}/
	Documents/[Application name]/{Saves, playlists, whatever}/
		Saves/[Save file name]/{icon.png, info.xml, [data files]}
	
	Applications/[Application name].luapp (a physfs-compatible zip archive)
	Applications/[Application name]/{index.lua, [data files]}

where System.designatedDocumentsFolder() would create Documents/[Application name]/ if it doesn't already exist, and return the path there, and give write permissions. Then the app can write whatever it wants there.

(have you ever hit "Home" without selecting "Yes" after this?)

Often, to check the volume level, clock, or battery level... I don't think it's unreasonable to expect application developers to themselves write facilities to quit the app ("quit" from the main menu or whatever)

My two cents.

[Shine]

Chris O'Shea has sent me an image for a new design of the Lua Player wegpage. I don't have time for this, but if someone wants to do it, you are welcome. But it should be easy to maintain, so no complicated nested table structures and to support the widest range of browsers, it should be valid HTML 4.01 Transitional (you can check this with http://validator.w3.org).

Would be nice, if someone could write a better documentation and a small tutorial. You could use the standalone Lua version from http://www.lua.org to generate the functions.html output from a formal definition, written with tables in Lua source :-)

[Shine]

Isn't sort of the POINT of physicsFS that archives act transparently as folders? Then it should just be System.changeDirectory("game.zip"), and applications using the file system should just continue working, without any additions to the API.

You can add multiple archives and directories to a search path, see http://icculus.org/physfs/docs/html/ for details. Changing directories and loading files should be transparent (if a directory was changed, all further file access should prepend this directory to the filename before passing it to PhysicsFS), but the initial setup of the user specified archives (if the script was started from normal file system) should be specified within the script with special functions, I think.

As for save data, using the SAVES folder is a pretty good idea, except that I don't like its hierarchy. I wouldn't mind the following hierarchy:
/PSP/LuaPlayer/{Applications, Documents}/

Yes, this is a good idea. With this paths we have anything below one directory and the Lua Player is more seperated from the scripts.

(have you ever hit "Home" without selecting "Yes" after this?)

Often, to check the volume level, clock, or battery level...

Ok, then perhaps we should provide a callback function for the home-button (if Lua is reentrant, otherwise this is not possible) and a function to exit the current Lua calling level and one function to exit the whole Lua Player. The default behaviour, if no callback is specified, would be the default PSP behaviour, but saying "Yes" means that the current Lua instance level is exited, only. If the first level was exited, Lua Player is exited.

[majik]

has anyone done any vertical scrolling?? as in 1 png file thats 480 x how ever long the level is?? is it possible yet??

TIA

[nevyn]

has anyone done any vertical scrolling?? as in 1 png file thats 480 x how ever long the level is?? is it possible yet??

TIA

Just blit a rect, this should be very simple.

[alex_dsnews]

I thought about this before - the coding is simple, but is there any limit (dimensions and/or filesize) in LuaPlayer as to the size of png you can blit from?

[nevyn]

I thought about this before - the coding is simple, but is there any limit (dimensions and/or filesize) in LuaPlayer as to the size of png you can blit from?

Why not just try it? :P

http://ncoder.nevyn.nu/luaplayer/Crater ... roller.zip -- Works fine. But try removing crateria.png and renaming acrateria.png to crateria.png. This picture is *large*. Using that one will crash hard. Which is not entirely good :/

[Shine]

I thought about this before - the coding is simple, but is there any limit (dimensions and/or filesize) in LuaPlayer as to the size of png you can blit from?

Yes, there is a limit of 512 pixels for width and height. I think the GU has problems with larger textures, which are used for blitting, but I don't know exactly, it is on the safe side now.

But you can load multiple images and draw it like. I assume you meant horizontal scrolling, not vertical scrolling, this is an example with 2 images (untested, but should work) :

Code: Select all

x = horizontal start position of your level
xc = math.mod(x, 960)
if xc >= 0 and xc < 480 then
  screen&#58;blit&#40;-xc, 0, image0, 0, 0, 480, 272, false&#41;
  screen&#58;blit&#40;480-xc, 0, image1, 0, 0, 480, 272, false&#41;
elseif xc >= 480 then
  screen&#58;blit&#40;960-xc, 0, image0, 0, 0, 480, 272, false&#41;
  screen&#58;blit&#40;480-xc, 0, image1, 0, 0, 480, 272, false&#41;
end

With this code image0 is followed by image1, which is followed againg by image0.

[majik]

i did mean vertical scrolling but you code looks good shine, would the same code apply vertically by changing the settings?