So, another routine done, sum(3). This lists all of the picture variables on the calculator that are instantiated. If no pictures exist, the output contains the one-element list {0}. The list {1,10,42} indicates that Pic 1, Pic 0 (note that 10=Pic0), and Pic 42 are on the calculator. A negative number means that the Pic number with the negative of that value exists, and is archived. Positive=in RAM, negative=archived, 0=no pics on calculator. This demo uses two programs. prgmA uses the sum(3) function. prgmB uses the XLib function real(9) (as emulated by Doors CS, of course) to create picture variables for the demo.

sum(4) completed, the routine that archives or unarchives pictures. If the picture is already in the desired state, nothing happens. If the picture does not exist, nothing happens. This works with Pic 1 through Pic 255. Check out the demo below, complete with sum(3) wrapper to demonstrate that the desired action is occurring.

I'm not sure, I just got back from a week in Maine, but I'm contemplating.

sum(1) completed and tested! I tried making a floodfill program in BASIC to demo this, but it was slow, so here's a different example. You use the mouse (sum(6)) to choose a point, then press one of the four direction keys to choose a direction. Sum(1) is used to find the first pixel of a different color in that direction, and draw a line to that point. Notice how much insanely faster it is than a loop of pxl-tests, and how this could help with collision detection and such.



This actually only leaves sum(2), sum(7), and sum(12) to do! sum(2) is the homescreen-to-gbuf copy, which will be trivial, but sum(7) and sum(12) will be a massive undertaking. Good luck to me.

idk if this is possible, or even helpful at all. But what if you allowed data (in bytes) at the bottom of the program? That way if we wanted, we could use the much faster bytes than floating points. I don't think it would mess up too much when editing, but idk. Another way it could be done, is by having a command tack data at the end of the program, and then when DCS calls it add the data at the bottom and when the program is over (either error, or EOF) remove that data. Just a thought.

The features look awesome as of now good job

For token(5), what will it return something different if running in DCS, but Celtic III support is disabled? And will returning a different number than Celtic on its own break some programs?

For Menu(, I had recommended adding an extra parameter at the end to differentiate from the regular Menu( command.

I hadn't planned that, as the current system turns off all BASIC libs simultaneously when that Options checkbox is unchecked, including the DCS ones.
Good question, and no, it won't, because no existing Celtic III program checks with det([[42]]) instead of the standard det([[1]]) test.

Indeed, but due to the way Menu( triggers the parser hook, I unfortunately will be using a sum() routine for the custom Menu, so it won't be an issue.

another idea! adding sound support (through interrupts) so, you use sum(#,{list of pitches},{list of note lengths}
The pitches would (hopefully) be pretty easy to use, maybe like 1-16 for low C to high C. and note lengths...could maybe be in percents of a whole note, so 25 would be 1/4 of a whole note, or a quarter note.

Also, what about my earlier idea about data at the end of a program?

An excellent idea! Wasn't there an Omnicalc lib for this? Maybe I could just support that...

Yeah, it's possible, but it's sometihng I'm only going to add if I really have to. At this point separate data files are a much more elegant way to do things, from my end.

Thanks!

At any rate, after a TON of annoying problems with this routine, finished sum(2,{update}). I must warn that this does the somewhat incomprehensible of setting bit 4,(iy+24h) in order to print the 16th character of each line, which I only figured out by reading the 2.41 disassembly of VPutMap. Here's a demo of it working with fullscreen and splitscreen text display! The mouse proves that the homescreen is getting plopped onto the gbuf.

Somehow I think that mouse is faster than the DoorsCS7 mouse.

The new features look really awesome. Will this be included in the next beta?

Actually, it's all using the exact same mouse routines. There's only a single set now in the entire Doors CS codebase, so anytime you see a mouse, whether on the DCS desktop, inside Document DE, or in BASIC programs, it's all the same mouse.

That's the plan! My target release date is July 4th for Doors CS 6.7 beta, so that gives me just over a week to implement sum(7), sum(12), and sum(13), besides all the other commitments I have in my life. If it comes to this, would you guys rather I delayed to release to finish the planned libs, or omit the unfinished libs to release the beta on time?

I'd suggest you delay the beta. No point in putting it out if you aren't getting all of the features tested.

idea: An extended parser hook, it would search through all your programs looking for an associated filetype, which would be an SE with the extension to the parser hook inside. That way people could develop their own sum(# routines.

btw, you can adjust the acceleration settings to make the mouse zippier system-wide.

Interesting, but I'm not sure if it needs to be implemented.

1) If you come up with some idea, what advantage is there if programmers use the sum( token instead of directly calling the program (ala Codex, Celtic2, etc...)?

2) Part of the appeal of libs like xLib/CIII/DCS is that they are standardized: as long as the user has one app and my code, everything works fine: no other programs are needed, which makes sharing easier.

On a side note, coming up with standardized "filetypes" would be epic; it would be awesome if you could open the same document in multiple programs.

Indeed, thanks for that.

Point (2) is the bigger one for me. I'd prefer that with Doors CS' (relatively) massive 48KB, everything you need is in the tin, and you don't need to start tacking on more stuff for a particular program to work.

Well, that's kind of the idea I've been going for. Notice that, for example, Anakclusmos' ProgPad can open DocDE6 files.

So! After a bit of messing around, and finding some errors in Celtic III's internal documentation, sum(7,0, sum(7,1, and sum(7,2 are functional. Check out this screenie demonstrating sum(7,1 and sum(7,2:

That's _SStringLength, I guess?

That wouldn't work because that works on ASCII (well, not ASCII, but TI font code), not on tokenized stings. Here, I'll show you my code for it, Mapar:


Code:

I posted this idea in IRC, but I didn't stick around long enough to get a response about it.

Would it be possible for the coder to define their cursor in hex so they have a custom mouse throughout the program?

I'm assuming the mouse sprite is saved in the appvar? I'm not sure how Flash apps or appvars work, as I'm not that experienced in ASM just yet.

The idea would be to have two different sprite 'variables'...
DCSMouse and PrgmMouse

DCSMouse would be used 100% of the time while in DCS.

On program startup: DCS checks for a hex-sprite defined in the program's header. If hex-sprite exists and is valid, set as PrgmMouse. Else, set PrgmMouse as DCSMouse if it isn't already.

My original idea had the PrgmMouse being set to DCSMouse every time you return to DCS, but I feel like the idea I just posted would save a lot of resetting of variables.


Unless...

DCSMouse was set, the old contents of DCSMouse was temporarily stored, and restored at the end of the program if DCSMouse was changed at program start. Anyway. Just ideas. I would LOVE to a custom mouse feature

It's a very cool idea, and one that I see having wide applicability, but not something I want to touch until 6.7 is out and I have the existing planned library features down in code. I hope you'll keep reminding me, though, because I think a lot of coders would want this.

Understood. I know I'll definitely be using this if/when it's implemented

Keep up the good work, Kerm! I'm quite excited to start using these