CodeWalrus

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:
(http://tr1p1ea.net/files/downloads/screenshots/xlib_scroll_cse.gif)
TI-84+CE:
(http://tr1p1ea.net/files/downloads/screenshots/xlib_scroll_ce.gif)

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

(http://tr1p1ea.net/files/downloads/screenshots/xmemece.gif)

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
(http://tr1p1ea.net/files/downloads/screenshots/globe_cse.gif)
CE
(http://tr1p1ea.net/files/downloads/screenshots/globe_ce.gif)

I have also ported enough routines so that the xZELDA demo works in fully. Note that this program is unaltered from the CSE version:
(http://tr1p1ea.net/files/downloads/screenshots/xzelda_ce.gif)

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. :)

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

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.

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?

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

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.

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.

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?

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.).

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.

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?

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.

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)

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 :).

Quote from: Lionel Debroux on 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.).

I second this. It would be nice if there was some way of integrating libload into basic, but i think that will be a bit impossible :(.

Quote from: tr1p1ea on 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 :).

YEah the main issue if DCE9 updates are not backported is that some people such as 123outerme don't own a CE and still program for the CSE right now. I can totally understand if the changes aren't backported now, though. Maybe later when you have more time and that DCE9 is out?


Also ouch about those bugs >.<. Glad you got one fixed :)

By the way, I think I recall DrawString returning 0 to Ans or something, erasing the string in the process (requiring the user to store the string in Ans over and over, causing slowdowns). Was that fixed? I think DrawString should not return anything into Ans unless it received wrong input, so that people can re-use the same string with multiple DrawString commands (eg for blinking/moving text animations)



Also @tr1p1ea could you post screenshots of what First Fantasy: Mana Force CSE (not the CE version) and HP Prime Tunnel CSE Demake look like on the 84+CE? I am really curious about the glitchiness in FF:MF and speed differences in both.

Yeah I updated DrawString to restore the string in Ans when it returns .. I think this was in DCSE8.1 ... it's in this version definitely however.

Glad to hear. This will definitively allow text animations to be much faster :)

Btw @tr1p1ea , if you implement custom palettes, that would be a nice addition because then we could potentially do sprite compression by storing multiple sprites into one. I do that with CE Textlib in my tilemapper (which supports color palettes) and I can save a lot of memory and sprite space. For example, if someone had a key sprite inside a wall tile, then he could make the wall colors identical in one color palette so that only the key is visible, or vice versa. Of course that would require you to allow color palettes to have multiple colors that are identical, at the programmer's discretion, though.

yes custom palettes and the ability to modify individual palette entries are already implemented. There is no restriction on whether colours are the same or not; completely up to the programmer.

Awesome. :D Right now I am doing monster sprites using duplicate color trick and from 6 monster tiles I can actually have 11 or so. This could also be handy for some special effects.

You can also structure your palette and then use the xLIBC ColourOffset function to offset to each different set of colours as required instead of manually manipulating the palette all the time :).

Oh nice, I forgot about the color offset. I guess then I could just set colors of a certain hue for even better magic animations than in xLIBC :P

I'd like to see a blue magic explosion exercising xLIBCE's current limits. :)

Good news, I have included a fixed-width small font as per people's request. Here is a screenshot :):

(http://tr1p1ea.net/files/downloads/screenshots/fnt.png)
(http://tr1p1ea.net/files/downloads/screenshots/fnt2.png)

I like the new font tr1p1ea. :D The big one is fine, but being able to cram more text in the screen will definitively be nice for RPGs, especially menus. :)

Awesome job, tr1p1ea! Can we get a full list ofeverything implemented atm?

That's fancy!  :D
Could you do Spiroh's font? I'd want to see that on the CE. :)

Quote from: DJ Omnimaga on April 01, 2016, 04:34:16 AM
I like the new font tr1p1ea. :D The big one is fine, but being able to cram more text in the screen will definitively be nice for RPGs, especially menus. :)

That's true. It was hard for me to cram stuff on screens when I was still working on Mr. Bob's Bad Day.

Quote from: Dudeman313 on April 01, 2016, 03:47:56 PM
That's fancy!  :D
Could you do Spiroh's font? I'd want to see that on the CE. :)

Quote from: DJ Omnimaga on April 01, 2016, 04:34:16 AM
I like the new font tr1p1ea. :D The big one is fine, but being able to cram more text in the screen will definitively be nice for RPGs, especially menus. :)

That's true. It was hard for me to cram stuff on screens when I was still working on Mr. Bob's Bad Day.

Do you have a link to SpiroH's font?

Quote from: Unicorn on April 01, 2016, 05:36:15 AM
Awesome job, tr1p1ea! Can we get a full list ofeverything implemented atm?

Yeah I am curious as well, although I am more curious about what else is new in this version and if there are any bug fixes.

Quote from: DJ Omnimaga on April 03, 2016, 05:06:56 AM

Quote from: Dudeman313 on April 01, 2016, 03:47:56 PM
That's fancy!  :D
Could you do Spiroh's font? I'd want to see that on the CE. :)

Quote from: DJ Omnimaga on April 01, 2016, 04:34:16 AM
I like the new font tr1p1ea. :D The big one is fine, but being able to cram more text in the screen will definitively be nice for RPGs, especially menus. :)

That's true. It was hard for me to cram stuff on screens when I was still working on Mr. Bob's Bad Day.

Do you have a link to SpiroH's font?

No, but I do have 3 similar copies of it, made by people at Omnimaga for zStart: https://www.omnimaga.org/art/zstart-fonts/msg368263/#msg368263

Unfortunately the small font is 4 pixel's wide while the font's linked at 5 pixels.

I think a 4 pixels wide font would be better, since the goal is to allow more text in the screen at once. Else the space gain isn't as great. Also, another thing that is cool about small fonts is that it might make it easier to port certain monochrome games without having to alter the layout too much.

Oh. I didn't know about that.
I agree that 4 pixels wide is more ideal, though.

Question @tr1p1ea : If custom palettes get implemented, if the programmer changes the palette in the middle of the game, will the screen content switch to the new color palette automatically?

Custom palettes are implemented but require a bit of testing, as are functions to change individual colour entries as opposed to needing an entire palette each time.

As soon as you change the palette colour any pixels that index that entry are updated automatically.

Aah I see. Good luck getting them to work. And I'm glad to see the changes will be automatic. This will be very handy for saving archive space by re-using the same sprites over and over (which could be done with xLIBC but only by rotating the color hue and it didn't work with tilemaps), not to mention other special tricks that could be used with this.

Question @tr1p1ea : Will xLIBCE have a feature that detects on which calculator the game is ran? That might be a problem if DCSE8 is not updated, though, unless doing a wrong xLIBC command such as real(8,5 caused xLIBC to ignore it, in which case it would be fine. Basically real(8,5 could return 1, so what the programmer could do is the following:

2
real(8,5

So on the CSE, real(8,5) would do nothing, thus Ans remaining 2, while on the CE it would return 1. That might be handy if someone's game runs too fast on the CE and wants to make it slower without releasing two separate versions for each calc.

The GetVersion command will return the version of xLIB is running, which will be able to tell you what calc you are on.

DCSE8.0 shows xLIBC version 1
DCSE8.1 shows xLIBC version 2
DCSE9.0 shows xLIBC version 16

Ah right, I forgot about that command. That can help a lot, I guess :). Thanks for letting me know.