Saturn Lua Player released!

[RockinB]

Finally, writing SEGA Saturn games in Lua has become reality !


Lua is a powerful, fast, light-weight, embeddable scripting language. The Saturn Lua Player is a powerful runtime environment for homebrew Saturn games written in Lua. It provides access to hundreds of functions of popular Saturn programming libraries.


The SLP runtime executable consists of a library and a small application part, it's designed such that new API calls can be easily added and that people can create custom Saturn apps, if they like to. However, it's already complete enough that whole games of any kind can be created entirely in Lua.


It's simple, it's fast, it's powerful and it makes fun ! Creating Saturn games is now as easy as opening up a text editor and writing:

slPrint("Hello World", 5, 5) while true do slSynch() end


The Saturn Lua Player has proved it's usefulness by running Police Officer Smith and various complex 3d demos. It successfully handles multiple 2D scrolls, rotational scrolls, complex 3D scenery, realtime gouraud shading, textures, save files, CD reading, PCM playback and a lot more!

Download the all-in-one Saturn Lua Player package now:


SaturnLuaPlayer_080701_R1.zip (15 MB, Zip)


SaturnLuaPlayer_080701_R1.7z ( 8 MB, 7-Zip)


It includes 12 demos with prebuild ISOs, docs, tools and complete source code of the SLP runtime and all demos. Oh btw: it's intended for a future release to offer an alternative SLP executable that uses only homebrew code (CDC+SGL replacements).

 

[dibz]

This is awesome news, I might have to take a closer look later.

 

[ExCyber]

I don't have time to look at it at the moment, but this seems pretty neat. What do you think of developing a new API rather than exposing SGL? I don't have any experience with Lua, but it seems like it would be preferable to have an API that is matched to the language.

 

[Amon]

A propriatary free api would be nice but takes a lot of work. I am sure when that eventually happens this could be ported over as well. RockinB keep up the good work as always. It rocks!

 

[RockinB]

I knew there is demand of not using SEGA libs. That's why I'm planning to take up the work on my SGL replacement, again, and use it together with CWX' CDC replacement to create a special Saturn Lua Player that's free of propriatery code

 

[djbass]

That is quite awesome, I'm well versed in LUA and as you say its just such a fun language to dev in so its a welcome development.

 

[vbt]

You could test support of Piratero's Yaul and your SDL wrapper.


Well that's a great news, I took the files yesterday but didn't understand everything

 

[ExCyber]

I was talking more about the API per se; while SGL is fine as far as it goes, I'm curious about what a Lua-inspired API would look like.

 

[djbass]

Well LUA is usually used to wrap around existing API & functions internally. A stock LUA implementation has all the foundations of a typical programming language which may or may not include things such as a native print function, how extended capabilities are implemented is really up to the author.


http://lua-users.org/wiki/TutorialDirectory


Has fantastic examples of how to do common tasks in LUA if you want to familierise yourself with it.

 

[RockinB]

Thanks for your feedback! I really hope that the Saturn Lua Player will attract new people for Saturn devving and that we will see more Saturn releases in the future.

Personally, I can't imagine to step back to C, unless I really need to. So it's guaranteed that I'll keep updating the SLP in the future. Dividing a Saturn app in a optimized C/ASM portion and a Lua portion that's easy to manage, has proved to be a good method, for me.

Well that's a great news, I took the files yesterday but didn't understand everything

Please don't hesitate to tell me if anything is unclear, I'll update the README.txt and documentation in this case.

The Saturn Lua Player is just a normal Saturn executable that's put on a usual Saturn ISO, named as "0.BIN" or similar. When it is running, it loads file "0.LUA" from the disc and runs it with the Lua interpreter.

As Lua scripts can grow in size easily, a tool named lstrip can be used to remove all whitespaces from the source code. That's why in the samples, file "0_orig.lua" always is the original Lua script (with comments) and file "0.LUA" is a batch file generated equivalent version of that.

Lua has a built in garbage collector. Using complex data structures is far more easier with Lua now. However, the Lua-coder still has to care a little bit about memory.

It's up to the Lua-coder to give Lua some more memory like low work ram and cartridge ram. If you're coding too careless, you can still force Lua to run out of memory.

So when loading big data from CD, it's good practice to assign the returned buffer with nil, as soon as you don't need it anymore.

When being in a loop, it's no good to create unnamed variables each iteration (example: local table = {X=i, Y=j, Z=k}, then {} creates a new table in each iteration), the garbage collector might not be fast enough to remove it early enough.

In such cases, you can manually call the garbage collector with collectgarbage(collect).

Well LUA is usually used to wrap around existing API & functions internally. A stock LUA implementation has all the foundations of a typical programming language which may or may not include things such as a native print function, how extended capabilities are implemented is really up to the author.

In this case, the author has focused on making the use of SGL in Lua similar to what it's known from in C. The benefit is that all existing documentation on the SGL functions goes for the Lua SGL wrapper, too. Furthermore, existing C code samples can be ported to Lua rather easily.

So a couple of Lua SGL functions use table inputs. Example: the light vector is supplied to slLight() as a table of X,Y,Z entries, rather than 3 seperate integers.

C-code:

FIXED light[XYZ]={toFIXED(1.0), toFIXED(0.0), toFIXED(0.0)}

slLight(light);

Lua-code:

light = {X=1.0, Y=0, Z=0}

slLight(light)

The wrappers for GFS, PCM and STM libraries have been created several months ago and haven't yet been polished like the SGL wrapper. So there is a point for future improvements.

A problem that I have to deal with in SLP is memory consumption. The more API functions I wrap for Lua, the bigger the executable gets. I've also been forced to use double as Lua's native number format, since with float, some numbers like VRAM locations and cycle patterns can't be transfered to the wrapped API 1:1 .