[TI-84+CE] - xLIBCE

b/Calculator Development publicado por u/tr1p1ea March 22, 2016, 03:35:50 AM

[TI-84+CE] - xLIBCE

I have been working on porting over xLIBC to the CE and after a slow start have been making some good progress of late.

At this stage I have a number of routines for tilemaps, sprites, images, key input, drawing strings and such already ported, along with support routines for collision detection and map checks etc.

There have been some nice speed improvements with the CE version even in the current unoptimised state (working on functionality first).

Here is a tilemap scrolling test:
TI-84+CSE:

TI-84+CE:

And this morning I ported over the BGPIC & BGPIC32 functions as seen below:

I should have noted that this is the CSE xMEME example program running completely unaltered.

I have implemented 'frames' for both BGPIC's and BGPIC32 images so that you can store multiple images in a single appvar. Here is a speed test between the CSE and the CE:
CSE

I have also ported enough routines so that the xZELDA demo works in fully. Note that this program is unaltered from the CSE version:

Inicia sesión o crea una cuenta para dejar un comentario

u/Dream of Omnimaga March 22, 2016, 04:59:25 AM

What I love about this is that since this uses hooks, this will allow TI-BASIC to almost take full advantage of the TI-84+CE speed boost over the CSE, even more than CE Textlib, plus it has built-in sprite/tiles support. I like the new feature additions such as multi-pic appvars. I hope that 32 color pics will support partial draw too.

Also that scrolling speed is impressive. I'm glad you managed to port xLIBC to this calc, even though there's no community Flash app support.

u/Dudeman313 March 22, 2016, 03:25:43 PM

This is impressive! I love the looks and the speed! I just no longer have a CE.

u/Dream of Omnimaga March 22, 2016, 08:57:45 PM

What would be cool is if xLIBCE supported the following:

-The ability to choose between two resolutions when displaying parts of background pictures, so we could use full-screen 80x60 pics that have fewer colors. There are many scenarios where someone will not need 256 colors for a 80x60 picture, thus, making the higher color depth a waste of space.

-2, 4, 8 and 16 colors background pics with palettes. There are many scenarios where someone might want to use anime-like cutscenes that only requires about 4-6 colors at most.

That would allow people to save a considerable amount of space.

u/Snektron March 22, 2016, 10:31:26 PM

Impressive. How have you made the hook? Does the program which uses xLIB need to enable and disable it or do you store it in some semi-safe place in ram?

u/Dudeman313 March 22, 2016, 10:47:53 PM

Also, @tr1p1ea , is this also compatible with xLIB programs (like Builderboy's SHIFT port)?

u/Dream of Omnimaga March 22, 2016, 11:11:20 PM

It won't run monochrome xLIB games. xLIBC is entirely different. I bet that games could be ported without too much hassle, though. The main difficulty would be that command syntax is a bit different (eg real(12 will be real(7) and making sprites is different.

u/tr1p1ea March 22, 2016, 11:48:45 PM

At this stage I haven't 100% locked down the location of the hook stub itself but the routines will be run from a standard location. There are a number of areas in RAM that can be useful for storing hooks as well.

This may change over the life of XLIBCE however the end user shouldn't notice.

Unfortunately monochrome projects won't work out of the box, however they can be ported with graphics updates and such.

u/Dream of Omnimaga March 23, 2016, 01:36:27 AM

What happens if someone else makes an hook-based library by the way? For example, on the CSE @Cumred_Snektron made DovahCalc CSE, which replaces the TI-OS fonts with something else, and DCS BASIC libs worked fine with it installed. The only difference is that when using Celtic colored text, the font was disabled due to DCS overriding its hook, and when exiting the program it re-enabled the font hook. But could there be conflicts happening on the CE?

u/Lionel Debroux March 23, 2016, 08:15:28 AM

Yup, there could be (and already have been) conflicts between hooks on the TI-eZ80 series. That's why I've been campaigning, perhaps a bit repetitively but for good reason IMO (*), for a common hook framework on the TI-eZ80 series.

*: I think that a common hook framework provided by e.g. libload, or any related place containing core "shell"-independent functionality, is the best way forward for the TI-eZ80 series. Like a powerful library loader, now implemented by Mateo for a little while, that's what was done by the community on the TI-68k/AMS platform as well, with two conventions:
1) Kevin Kofler's "evHk" convention limited to event hooks, which worked without a "kernel";
2) Matthieu "flanker" Gallet's little-known but much more powerful, "kernel"-based, UTSRlib ( http://ti-fr.com/?act=66&art=11 ). Most of this article is written in French but the API description is fortunately mostly in English.

On the TI-eZ80 series, TI-68k old-timers like me can't necessarily bring in much new calculator-side code, but they can at least bring in what they know about existing good and bad practices from 1-2 decades ago in another calculator series from which the TI-eZ80 imported several traits (flat addressing space, flat OS and FlashApps, etc.).

Last Edit: March 23, 2016, 09:28:50 AM by Lionel Debroux

u/Dream of Omnimaga March 23, 2016, 04:46:24 PM

Actually, this is a bit why making all basic tools and ASM routines as libraries would be nice. It would perhaps make shells less useful, but at least we would be able to use Basic libs without being forced to use 1 shell in particular. Mateo's lib already does that and that is how it works on PC I think. But of course it's the author's choice. It would just be more convenient to users I think.

u/123outerme March 23, 2016, 05:28:51 PM

Do you plan to port your changes like the "frames" thing in BGPIC and BGPIC32 back to the CSE, or is it just not fast enough for these things?

u/tr1p1ea March 23, 2016, 09:11:15 PM

DCSE will perform hook chaining so there shouldn't be much of an issue.

The frames functionality was actually written for the CSE first however it hasnt been released. It will depend if there is an update to DCSE8 I suppose.

u/Dream of Omnimaga March 23, 2016, 09:12:58 PM

I'm curious about if Kerm has plans to update DCSE 8 as well. That calc is discontinued but even Kerm himself still releases stuff for it (Graph 3DC comes to mind)

u/tr1p1ea March 23, 2016, 09:20:48 PM

I'm not entirely sure however there is a strong focus for myself on getting CE related stuff released

.

Also I fixed a bug in the DrawString command which can be seen with the extra character in the xMEME example - hopefully it's good now.

I have another bug where some tilemap data gets overwritten that I am investigating now.

I'm very glad that I have 4 days off over easter and am hoping to knock off a few more functions