Lua Player OpenGL for Windows, PSP 1.0/1.5 and PS3

[Shine]

I've started to rewrite Lua Player with the SCons build management and based on OpenGL for all graphics output. For the PSP it uses pspgl, which has some limitations (see #ifdefs in common/LuGL.cpp). I have tested it on a firmware 1.0 and 1.5 PSP, but it doesn't use kernel mode, so it should work with other versions, too.

For Windows and PS3 all OpenGL functions should work (but currently textures are not implemented). The Windows version is compiled with Visual Studio .Net and should not need any Cygwin or other library (except the system libraries and opengl). The PS3 version should work on every 64 bit PS3 linux.

You can download all binaries and source code from http://www.luaplayer.org/LuaPlayer-OpenGL-preview4.zip . A sample animation is included in script.lua, which you can change. This is also very good on Windows or PS3 for learning OpenGL: Open script.lua in an editor, open a command line and after saving the script, restart the program. Hit Escape to exit the program.

Crrently o PSP the 3D rendering is very slow and the graphics looks wrong. Maybe someone has an idea how to fix it.

Would be nice to port it to Linux X11, too. Should be not too difficult: See common/luaplayer.h for the list of functions you have to implement and examples in the psp, ps3 and win32 implementations. On startup you have to call luaplayerMain, then the functions you provide will be called.

Screenshot from the PS3:

[holger]

I've started to rewrite Lua Player with the SCons build management and based on OpenGL for all graphics output.

cool!

For the PSP it uses pspgl, which has some limitations (see #ifdefs in common/LuGL.cpp).

You could simplify your implementation if you build a OpenGL function pointer table using eglGetProcAddress()/wglGetProcAddress()/glutGetProcAddress().

If the function pointer table contains the NULL pointer for a particular function, then it's not supported on the current implementation... this will be useful for GL extensions and cross-version compatibility, too (you don't need different LUA versions for OpenGL1.1, 1.2, 1.3, 1.4, 1.5, 2.0 etc but leave some function pointers just empty if they are not supported by the current implementation).

Also this makes it possible to share your wrapper code for multiple functions with the same parameter layout (e.g. same handler for all functions with no arguments, same for functions with float arguments etc).

Crrently o PSP the 3D rendering is very slow and the graphics looks wrong. Maybe someone has an idea how to fix it.

can you please provide some numbers, how many frames per second are actually rendered?

The PSP GU hardware uses a very simple clip algorithm: triangles are clipped when some vertices are outside the clip margin of the screen. We could work around this by doing clipping in software, but this may slow down things and is probably not required in typical game development environments: usually you will have textures, models etc in high-resolution format and scale them down to lower-resolution textures and models for a particular target platform.

For the PSP this means that triangles should get a sane aspect ratio (very long and thin triangles are likely to fall victim of the simple clip algoritm of the PSP GU).

Would be nice to port it to Mac OS X and Linux X11, too. Should be not too difficult: See common/luaplayer.h for the list of functions you have to implement and examples in the psp, ps3 and win32 implementations. On startup you have to call luaplayerMain, then the functions you provide will be called.

For Linux/X11 EGL wrappers are available on the web, for Linux/XGL EGL is a native API, so the PSP port should work as well. Writing an EGL wrapper for OSX should be simple, GLUT is available for all platforms, so a port to GLUT would handle them all.

[bronxbomber92]

I'll take a crack at porting it to Mac OS X :)

Could you give me a quick "low-down" of what each function does? I guess this; create a Window context, get the width of the window, get the height of the window, swap buffers, and releasing the window? So, could this all be easily achieved with Cocoa and a OpenGL (must use OpenGL) context?

Thanks

[Shine]

Could you give me a quick "low-down" of what each function does? I guess this; create a Window context, get the width of the window, get the height of the window, swap buffers, and releasing the window? So, could this all be easily achieved with Cocoa and a OpenGL (must use OpenGL) context?

Thanks for your offer! Some comments for the functions:

Code: Select all

/**
 * This function is platform independant.
 * The main method of the specific platform calls this function
 * on startup and passes the command line arguments. If there are no
 * command line arguments, you can pass 0 for argc und NULL for argv.
 * Then the script "script.lua" is loaded, otherwise the script from
 * the file in argv[1] (argv[0] is the program name itself, for debug output).
 * This function returns on script exit.
 */
extern int luaplayerMain(int argc, char *argv[]);

/**
 * Is implemented for specific platforms.
 * Initializes the GUI, e.g. creates a window or switches to graphics
 * mode. And initializes the OpenGL subsystem. Subsequent OpenGL calls
 * will be made after this function was called, from the same thread.
 * The OpenGL system must be initialized in a way that provides 2
 * buffers: One back buffer and one front buffer. The front buffer
 * is visible to the screen and the back buffer is the one on which
 * OpenGL functions are drawing. With flipFrame the front buffer
 * and back buffer are switched.
 */
extern void initGui();

/**
 * Is implemented for specific platforms.
 * Returns the width in pixel of the drawable area for the OpenGL functions.
 */
extern int getFrameWidth();

/**
 * Is implemented for specific platforms.
 * Returns the width in pixel of the drawable area for the OpenGL functions.
 */
extern int getFrameHeight();

/**
 * Is implemented for specific platforms.
 * Waits for VSync and flips the front and back buffer with VSync.
 */
extern void flipFrame();

/**
 * Is implemented for specific platforms.
 * Restores the graphics mode before calling initGui, e.g. deleting
 * a window or restoring the old text or graphics mode. This function
 * is called before luaplayerMain exits.
 */
extern void releaseGui();

But do you think Cocoa is the way to go? AFAIK Cocoa is mainly implemented with Carbon, so Cocoa is slower, because it is higher level (at least when loading a Carbon application). And I'm not sure, if it is easy to integrate Objective C with the rest of C++. So maybe Carbon is better, because the needed functions are very simple. With Carbon it would be even possible to port it to Mac OS 9, but I don't think this is necessary.

[bronxbomber92]

Ok, I think I may have a working build. it uses GLUT for window management, so it's not the best way to go. I was going to use cocoa (which is NOT carbon. Cocoa is the best, and probably fastest way to go for Mac OS X.) but Cocoa uses the Objective-C language. So, unless a major rewrite was made, I don't think it would be possible. Carbon would be the next option. Carbon is slowly fading away and dieing, and I don't know Carbon, so that wouldn't be such a good idea either :p. That leaves GLUT, or SDL. I choose GLUT for ease and familiarity. I may choose to write a complete cocoa rewrite some day...

I will attach what I have so far, but there are errors, but it's all in the actual LuaGL.... >.< Mainly, it says all the .c lua files are missing, and that there are invalid conversion from GLint* to *int and invalid conversions from int* to *GLint... Those are all the errors except "no such file "malloc.h"

Errors and project file: http://www.bronx-development.ardo.org.u ... luaplayer/

[OneSadCookie]

Mac OS X port done!

full source download (based on the version linked earlier, with Mac OS X support added):

http://onesadcookie.com/~keith/LuaPlayer.zip

patch (bigger than it needs to be, because I changed some line endings to unix):

http://onesadcookie.com/~keith/LuaPlayer.patch.gz

It's written using Cocoa, and threaded properly so we can handle events, quit nicely, etc. Seems to work OK for me on my Core Duo iMac, might be interesting to check it works on a single-processor machine.

[OneSadCookie]

It's been drawn to my attention that you need scons 0.96.91 or later for Objective C and Objective C++ support; this won't build with an earlier version of scons.

[Shine]

Mac OS X port done!

It's written using Cocoa, and threaded properly so we can handle events, quit nicely, etc. Seems to work OK for me on my Core Duo iMac, might be interesting to check it works on a single-processor machine.

Thanks, but I don't like Cocoa and Objective C, so I've implemented it with Carbon. Thanks to bronxbomber92 for fixing the casting errors in the source.

Currently there are still problems with the Application Bundle, but starting "luaplayer" in release/macosx works (maybe you have to change executing flags with "chmod a+x luaplayer" from a terminal). Event handling would be nice, too. I'll include it, if it is not written for Cocoa :-)

The new version (source and binaries for all systems) : http://www.luaplayer.org/LuaPlayer-OpenGL-preview4.zip In this version some of the graphics bugs of the PSP version are fixed, too, but it still doesn't look right.

[bronxbomber92]

I have my own port also, completely different frm the other two, but I won't release it.

Shine, OneSadCookies port has event handling and multi-threading, and it works perfect, why not use it?

[OneSadCookie]

Bronxbomber92 showed me your Carbon port, but it beachballs horribly and uses a bunch of functions that are deprecated or will be soon.

Cocoa is the right way to do this, and my port behaves nicely.

[PiLX]

just when you think this couldnt get any better it does..

just curious ....how much longer (estimated) .. till we get a full stable release? ..

[carlosdc]

I did this linux port and it runs gl stuff alright but not regualr scripts, they all have errors is this ok(I mean I know it is not hehe but I don't know if this version of lua player just handles gl and I don't have windows or mac to test it) here it is, so let me know what happens, It uses SDL for window managment

http://fismat.umich.mx/~carlosadc/files ... yer.tar.gz