abi>>forums

abi>>forums (http://www.anythingbutipod.com/forum/index.php)
-   Zen X-Fi2 Applications & Development (http://www.anythingbutipod.com/forum/forumdisplay.php?f=221)
-   -   Zen X-Fi2 Lua Programming Wiki (http://www.anythingbutipod.com/forum/showthread.php?t=50625)

ThievingSix 12-16-2009 07:15 PM

Zen X-Fi2 Lua Programming Wiki
 
Now that we have a nice pretty section thanks to EnzoTen I'll kick it off.

I've been working on indexing and figuring out all the functions available to use for application creation(and maybe more ;)!).

Here(http://en.wikipedia.org/wiki/User:Thieving6/X-FI_2_Lua) you will find many things. A full function list, examples(soon to come), tutorials(soon to come), and more.

You might notice a 1.1 Whats needed section that lists some things that need more information on. If you have something to add, please do! I only ask you to follow the format already shown so I don't have to follow up. Once the Whats needed section is done I have planned the creation of a virtual test ground for testing lua scripts on your PC. This way you don't have be going back and forth to your player.

I encourage everyone to try and develop applications! Not only will it broaden your view and make your player special, you'll probably make something someone else is interested in!

Jan_DK 12-22-2009 01:56 PM

I was looking at the PSP lua wiki.

http://forums.qj.net/psp-development...-snippets.html

Wauw alot of nice functions in that thing.




Theodore 03-15-2010 02:43 PM

Undocumented Zen (sticky needed?)
 
I think a sticky thread would be useful to hold the things that aren't included in the official API documentation from Creative.

I'll contribute this one for now: Despite the explicit statement in the API doc that color.new just takes R, G, B, you can call color.new(r, g, b, a) where a is the alpha channel.

A dump of the screen, image, text, etc. tables shows some methods not included in the docs too (I'm sure some of these have been mentioned, but it would be good to collect them.):

screen:
.clear

image:
.create
.width
.setbg
.height
.setresource
.fill

os: (all but os.sleep are in the Lua docs)
.exit
.setlocale
.date
.difftime
.remove
.time
.clock
.ostime
.rename
.sleep

ThievingSix 03-15-2010 03:22 PM

Too late: http://en.wikipedia.org/wiki/User:Thieving6/X-FI_2_Lua

In the very beginning when there were only 2 of us here, Zap dumped the tables and we worked on the wiki.

bzdbbb 03-15-2010 03:48 PM

Good idea Theodore - but the wiki already did it. I merged the threads and stickied it :)

Theodore 03-17-2010 11:19 AM

Anybody want to move this to it's own wiki (e.g. on wikia) rather than squatting on Thieving6's Wikipedia user space?

ThievingSix 03-17-2010 01:09 PM

I don't use wiki on anything else. So it really doesn't matter.

ZaPx64 03-17-2010 01:59 PM

Completed os.ostime(). Maybe this helps with an eggtimer app. I remember somebody else having a problem with the timer...

ThievingSix 03-17-2010 02:02 PM

So if what you wrote is correct, we have millisecond timing?!?! Although I'm curious of why one would be second timing and the other millisecond timing.

ZaPx64 03-18-2010 09:33 AM

Ya that's true. Try this app on your Zen and on the simulator:

Code:

screen.clear();

b = color.new(0, 0, 0);

text.size(30);
text.color(color.new(255, 0, 0));

while true do

    screen.fillrect(0, 0, 400, 240, b);

    text.draw(0, 0, tostring(os.ostime()));
    screen.update();
   
    if control.read() == 1 then
        if control.isButton() == 1 and button.home() == 1 and button.click() == 1 then break; end;
    end;
   
end;

I have no Idea why the timings are different, but I think that's another point for the firmware wishes-list ;)

cilmaviel 03-18-2010 10:32 PM

for some reason os.ostime() doesn't show any data on my screen unless i concatenate it with text.
anyway i though this would be as good a place to post this as any. thanks to ZaPx64, this works great for limiting the frame rate in action games for better performance.
just add it to a draw screen function...

Code:

oldtime = os.ostime()
function drawscreen()
    newtime = os.ostime()
    if (newtime - oldtime) > 36 then
        oldtime = os.ostime()
        screen.fillrect(0,370,240,30,bg)
        arrows:draw(0,370)
        text.draw(0,375,page .. " / 10 ","center")
        screen.drawline(0,369,240,369,k)
        screen.update()
    end
end

this was taken from postit. just change 36 to the number of milliseconds before you want the screen to update. (for those that are not good at math, ms = 1000/fps).i suggest trying 25 fps for more action games (for those that don't know, 30 if the max).
this might also help with crashing to a scandisk. i haven't had that kind of crash on any of the apps i tested this with.

Tetrajak 03-24-2010 02:37 PM

Instead of creating a new thread, I figured I'd post my findings here, as it bares some relevance to the wiki.

Quote:

I have been looking into the shell that the X-Fi2 has, and what functions are present in it. I have been doing this because it would be very desirable (for a number of reasons) to have the ability to list directories and files on the player, for such things as easy loading and saving of files. I think I have discovered why we cannot do this.

The firmware of the X-Fi2 runs on an operating system called Nucleus RTOS (Real-Time Operating System). Nucleus runs on a shell called POSIX (or Korn, they're the same thing really). You can think of POSIX like a kind of DOS, but not entirely. POSIX lacks a directory listing command (such as DOS's "dir"), and this hinders higher level code.

To explain a bit further; any higher level coding language relies on the other languages that it is built on. In this case, Lua is based on C, and C relies on the shell of the device that it's running on for it's functions. POSIX lacks a directory listing function, thus C on the X-Fi2 lacks a directory listing function, thus Lua on the X-Fi2 lacks a directory listing function.

For Lua, this means things like io.popen don't work, and can't work at all. Thus, sadly, some file operations can never be used. Nucleus is supposed to run on purpose built devices that are not PC's.
However convenient this theory is, I suppose it doesn't explain why the player can read files from the MicroSD drive (when it doesn't know what's on there) when the shell doesn't have a "dir" function. Perhaps the MicroSD drive is different and has one? I'm unsure.

ThievingSix 03-24-2010 03:38 PM

It has something to do with the "rebuilding" I assume. Does the MicroSD have a "rebuilding" feature like the player?

Habhome 03-24-2010 04:18 PM

No rebuilding as the player does, but it prompts you to "build the library" every time you've restarted your player and try to access files on it.

Tetrajak 03-24-2010 06:28 PM

Quote:

Originally Posted by ThievingSix (Post 454826)
It has something to do with the "rebuilding" I assume. Does the MicroSD have a "rebuilding" feature like the player?

Quote:

Originally Posted by Habhome (Post 454845)
No rebuilding as the player does, but it prompts you to "build the library" every time you've restarted your player and try to access files on it.

Habhome answers ThievingSix's question as I would, as for why this happens and what it does, I presume that if the MicroSD drive doesn't have a "dir" function then it uses a brute force method to test the existance of each possible filename. This seems a little far fetched though as brute force guessing takes a long time on a small processor. However, if it weren't referencing each folder individually, and instead scanned the entire flash memory for files, then it would take considerably less time.

All that's needed is a method in the shell that searches the partition table for files and their locations on the disk. Unless of course I'm completely off and flash media don't have partition tables, instead using something else or not at all?

ZaPx64 03-25-2010 10:05 AM

The file system on my Zen is FAT32 and it does have partition tables because it wouldn't work without them. Finding the files via Bruteforce would not work because FAT32 supports file names with a total lenght of 255 characters. Nucleus comes with several distrubutions which possibly support "dir" functions.

Tetrajak 03-25-2010 12:45 PM

Quote:

Originally Posted by ZaPx64 (Post 455073)
The file system on my Zen is FAT32 and it does have partition tables because it wouldn't work without them. Finding the files via Bruteforce would not work because FAT32 supports file names with a total lenght of 255 characters. Nucleus comes with several distrubutions which possibly support "dir" functions.

Well, if you can find one for us, that'd be awesome. I know under some shells (like BASH) there are small spelling variation in the functions, such as "dirs".

ZaPx64 03-25-2010 03:36 PM

Why do you focus on the shell? I think LUA does not rely on any shell commands nor does C.
I think the shell might not have any dir functions anyway, but that is not important for LUA then. The most convenient thought is that creative disabled these functions for security reasons.
That's just my two cents ;)

Tetrajak 03-25-2010 04:22 PM

Quote:

Originally Posted by ZaPx64 (Post 455169)
Why do you focus on the shell? I think LUA does not rely on any shell commands nor does C.
I think the shell might not have any dir functions anyway, but that is not important for LUA then. The most convenient thought is that creative disabled these functions for security reasons.
That's just my two cents ;)

The Lua documentation at Lua.org states that the return of several os functions rely on the shell that it's running on, such as os.execute. One would presume this rings true for similar C functions as well.

ThievingSix 03-25-2010 05:27 PM

They probably just remove os.execute() from the G_ table after the boot. I still think that the shell we use is coded in lua >.>


All times are GMT -5. The time now is 12:49 PM.