Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
KermMartian wrote:
I am very interested. Those actually look surprisingly easy to implement, with the exception of performing clipping in an arbitrary rectangle, the pen settings, and the text functions. I'll probably get started on those after I release my first LuaZM alpha or beta.

Great Smile
Also note that the fillPolygon function on the Nspire supports concave polygons. In order to fill a concave polygon you need to start doing some tricks like triangulation (or similar stuff), so it's a bit more complex. Anyway, it's not that important to support them, but it would be cool Smile

KermMartian wrote:

Hmm, that's a good question. Looking at the Prizm RTC Unit documentation, I probably can't use anything from that, but I wouldn't be surprised if I could derive a (rough) 100Hz clock from one of the CPU clocks.

I see AHelper0 found some stuff already, so great !
Indeed, he suggested setting the TMU to 100Hz and just grab a 100Hz signal that way. I think I need to (1) figure out what functions I'm missing in the ZMG library and implement those, as well as debug existing functions, then (2) decide whether to focus on Nspire or LuaFX support first.
Regarding (2), I can easily create the compatibilty layer for the Nspire once you added a few more functions to the ZMG lib. Actually I can start already, just need some more free time Razz
jimbauwens wrote:
Regarding (2), I can easily create the compatibilty layer for the Nspire once you added a few more functions to the ZMG lib. Actually I can start already, just need some more free time Razz
Fair enough. Smile I'll do my best to keep the ZMG library updated, and perhaps share some C code with you so you can work on the libraries in C (unless you were planning on writing them in Lua). AHelper was awesome enough to post information on the BFile-listing syscalls, so he or I can get started on the file browser. I also made a few small changes to PrizmIO, so EXIT, MENU, and ON no longer have the terminal effects on LuaZM that they previously (incorrectly) had.
Most of the things I need to programs can be done in Lua and should not give a speed penalty Smile

Also, there is one other thing I forgot .. the graphical functions in the Nspire allow drawing offscreen, something that is used a lot. Currently this will be a problem for ZMG, and I guess implementing it will not be too easy.
Of course, if you decide to implement the cliprect stuff then this problem will be solved too.

Anyway, just do whatever you can and don't focus too much on my requests Razz They are by no means important.
Well, copySprite currently clips sprites, and as soon as I implement copySpriteMask (which I am going to do in a moment) it will also clip sprites. The Line routine and Circle routine should also be easy to make clip to the screen, or indeed an arbitrary rectangle, since they all call the plot() routine. In fact, I'm making that change now...

Edit: Clipping to a clipping rectangle added to all graphics routines. Implemented a zmg.clipRect(x,y,width,height) function as well; currently also creating the clipSpriteMask routine.
jimbauwens wrote:
Most of the things I need to programs can be done in Lua and should not give a speed penalty Smile

Also, there is one other thing I forgot .. the graphical functions in the Nspire allow drawing offscreen, something that is used a lot. Currently this will be a problem for ZMG, and I guess implementing it will not be too easy.
Of course, if you decide to implement the cliprect stuff then this problem will be solved too.

Anyway, just do whatever you can and don't focus too much on my requests Razz They are by no means important.


unsigned int GetVRAMBackgroundAddress( void );

Smile
I'm not following why that function is relevant, is that a replacement for my now-implemented clipRect() functionality? Sad
That returns the background VRAM buffer address. You can draw offscreen to that. Note that it is *not* word aligned and it *will* get trashed when you go to the menu.
AHelper wrote:
That returns the background VRAM buffer address. You can draw offscreen to that. Note that it is *not* word aligned and it *will* get trashed when you go to the menu.
We're talking about off the physical edges of the screen (or clipping rectangle) rather than off of the current VRAM buffer, if I understand you properly. Smile
Wow, the api looks good, its comming along fast!
Sorry, my posts were rushed as welcome week at MSOE is underway.

jimbauwens said that the graphical functions on the nspire let you draw offscreen. That, or you can use clipping rectangles. I mentioned the background buffer so you can just do offscreen rendering instead of clipped drawing. it sounds that that would be better in case you want to draw a lot of sprites and tile them. Then again, I don't know exactly what the nspire did, so I just wanted to get that info out there Smile
jwalker wrote:
Wow, the api looks good, its comming along fast!
That it is. Smile I love how much faster it is to work with C than z80 ASM. Do you have any comments about any functions being missing or having confusing arguments?
The only function I noticed is missing that realy matters that I can think of this late at night is drawText.

Also @AHelper, I think the Nspire just clips the screen.
How should that me done? an enum for the different fonts? a function for every font? What should we do about the cursor- vs. pixel-based Print* functions?
jwalker wrote:
The only function I noticed is missing that realy matters that I can think of this late at night is drawText.

Also @AHelper, I think the Nspire just clips the screen.
I originally implemented LCD-edge clipping, but after reading the Nspire Lua documentation and listening to jimbauwens, I expanded it to have a variable clipping rectangle. AHelper, I continue to agree with jwalker in thinking that jimbauwens was talking about partially-offscreen as opposed to double-buffered. Smile With my current drawing method, double-buffering is far from impossible, but I don't see any immediate applications.l
@Ahelper as far as I know there are only two fonts, sansserif and serif. The other part Im not quite sure how to do it. I do know that the Nspire fonts are bitmap based, as jimbauwens has said it earlier.
Yes, I was talking about drawing objects partially-offscreen (something that is used quite in the Nspire API).
Great job on your work KermM, it's progressing very nicely !
I'll see to do some more work on the Nspire layer today.

Also, do floating points work correctly in LuaZM ?
jimbauwens wrote:
Yes, I was talking about drawing objects partially-offscreen (something that is used quite in the Nspire API).
Great job on your work KermM, it's progressing very nicely !
I'll see to do some more work on the Nspire layer today.
Thanks! I look forward to seeing your work.

Quote:
Also, do floating points work correctly in LuaZM ?
I wasn't sure until I tested just now, but yes, they appear to work perfectly. Just as an aside, for space reasons I modified Lua to use floats under the hood instead of doubles.
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
  
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 4 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