Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
jimbauwens wrote:
Just to keep the this topic a bit updated.
I've done some work on the TI-Nspire part and I think cubefield (an Nspire Lua game) should work partially. That is of course as soon the math lib get's integrated. KermM is working on that, so I'm not worried Smile
Thanks. Smile I'm currently trying to get libm to behave nicely with our PrizmSDK toolchain, and it is being very stubborn. Based on your questions in IRC, it looks like I should probably mention which vanilla Lua libraries (like the bit32 library, for example) LuaZM supports directly.

Edit: I got the math library functioning. Currently LuaZM is 191KB, up from about 150KB before the math library was included. Jimbauwen, the test program you sent me currently chokes on "setColorRGB", from drawHorizon from render from callEvent from startNspire. For reference, the included libraries so far are marked with a '1':


Code:
#define LUA_LIB_CORO 0
#define LUA_LIB_TABLE 1
#define LUA_LIB_IO 0
#define LUA_LIB_OS 0
#define LUA_LIB_STRING 1
#define LUA_LIB_BIT32 1
#define LUA_LIB_MATH 1
#define LUA_LIB_DEBUG 1
#define LUA_LIB_PACKAGE 1
#define LUA_LIB_ZMG 1


Edit #2: A beta looms ever-closer. I implemented the popup box for about(), the necessary PrizmIO changes to support the F-keys, and the lua_readline() changes that make F5 turn into about() and F6 turn into run(). I'll just need the file browser from AHelper, and a beta should be just about ready.
*bump* So what sort of text-displaying facilities should I give LuaZM? I was thinking of trying to closely approximate the Prizm text routines, including a bunch of sizes of bitmapped serif and sans-serifs fonts, but I'm not sure that's the way I want to go. I don't think it's necessarily a good idea to expose the PrintXY routine. Thoughts?
It would be nice to support multiple font sizes, but that might not be so easy to do. Or maybe you could have both the Prizm routines and a simple text renderer made by you, for example only supporting the base64 characters.
Just go with what you think is best for the Prizm, speedwise and implementation wise Smile

Also good job on the Math lib! The code I gave you before on IRC should work fine now. (at least I think it should Razz)
So, with a few tweaks, it gets as far as drawing a black horizon and some black squares on a white background, but then stops. If I try pressing a key, it crashes with an error about handleKey. Great progress, though. Smile
*bump* Thanks to the illustrious AHelper plus a day spent converting C++ to C and re-implementing some features (and sleeping a lot), I integrated AHelper's file browser GUI into LuaZM, so you can now browse to a Lua program instead of typing in the name manually. LuaZM is therefore just about ready for a beta, save that I wanted to have a text routine of some sort in the ZMG library for the LuaZM beta. That'll be my next coding challenge, as it's looking like Graph3DP is just about complete.
Great ! Smile

I assume that once you release the beta, I could test stuff inside the 'emulators' that are available ? That would be a great help for me Smile
So are all the compatibility done too? (being able to run LuaFX and nspire lua).

Or is it just vanilla lua?
I'm busy on the TI-Nspire compatibility layer, not yet done though (not that simple).
Also, it's not vanilla as it included several custom functions: http://prizm.cemetech.net/index.php?title=LuaZM_Reference .
Ahh, got it. Cool. Smile

Can't wait for the first release!
And now it has a text function, rudimentary as it is. I was going to implement a custom bitmap font, but then I got lazy.
zmg.drawText()

I guess this is just about ready for a beta release too.
Can you allow the mode argument for that? Having a transparent background or inverted text will be desired.
AHelper wrote:
Can you allow the mode argument for that? Having a transparent background or inverted text will be desired.
Oh, is that what PMF_DO_NOT_USE_BACKCOLOR is for? Also, I'm baffled by the MF_UPPER_X_LIMIT_IGNORED = 0xFFFFFFFF claim on WikiPrizm, as that would seem to set every single bit.
oh, I can explain that. That will set the max right x value for printing text. with 0xffffffff, the OS code will ignore clipping.

PMF_*, no idea what that is. I just set the bits required for it. Simon's chm doesn't have the transparency, but it has others. I don't know what the bits are for transparency off-hand.
AHelper wrote:
oh, I can explain that. That will set the max right x value for printing text. with 0xffffffff, the OS code will ignore clipping.

PMF_*, no idea what that is. I just set the bits required for it. Simon's chm doesn't have the transparency, but it has others. I don't know what the bits are for transparency off-hand.
But with 0xFFFFFFFF, then you can't specify ignoring the status bar or using a transparent background, because allll the bits are set. I don't think that that mask is correct. PMF is PrintMiniFix; those have been standardized by Merth:

http://prizm.cemetech.net/index.php?title=PrintMiniFix

Don't be a Simon and use cryptic random numbers. Wink
Don't use PrintMiniFix. Use PrintMini. You read PrintMini. PrintMini != PrintMiniFixed.
AHelper wrote:
Don't use PrintMiniFix. Use PrintMini. You read PrintMini. PrintMini != PrintMiniFixed.
Fine, but the flags are the same. It passes the flags unchanged to PrintMiniGlyph, and my problem with the 0xFFFFFFFF issue remains. Smile I like the idea of exposing the flags argument to LuaZM users, but I think I'll force the 0x40 flag to be on.
That will remove the background color completely. I can see problems with that, especially when overlaying text, simple text changing, etc..

A value for something other than 0xffffffff would be useful for something like this:

You have a text box on the left and an info pane on the right. Maybe an image or something. You can use that argument to have the text wrap at a certain pixel (in this case, the middle of the screen). This would let you have proper text wrapping for this splitscreen case.
Idea: Either give the file manager the ability to rename files or allow luazm to run txt files so that lua progs can be written on-calc.
flyingfisch wrote:
Idea: Either give the file manager the ability to rename files or allow luazm to run txt files so that lua progs can be written on-calc.
AHelper's original file manager did indeed have the (very beta) ability to rename files, but I chose to remove that. Can you indeed edit .txt files on-calc?
KermMartian wrote:
flyingfisch wrote:
Idea: Either give the file manager the ability to rename files or allow luazm to run txt files so that lua progs can be written on-calc.
AHelper's original file manager did indeed have the (very beta) ability to rename files, but I chose to remove that. Can you indeed edit .txt files on-calc?

Yup Smile

in the program menu, press [f6]. "Save-as" saves as txt, "load" loads a txt.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 5 of 6
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement