Kerm, the topic "Help with Associated Programs" may be deleted now. I no longer need it.

TI-Point Version 1.0 will be official release of a PowerPoint simulation program for the TI-calc. It will be made with Axe Parser.

TIPOINT.8xp, the creator program will have the ability to create slides and edit them. These slides may contain lines, circles, and text, and perhaps more. TIPOINT will export them to appvars structured as follows:

first three bytes

TPF (identifier byte. Means TIPOINT FILE). Can someone help me out with an asm routine to return a list of all appvars starting with these three bytes (is it 3?)

Next byte

A number between 1 and 10, indicating a Pause length between slides, or 0 which means only keypress. (Pause will wait the time, or for a keypress).

Then will be the data storage, by pixel. Every pixel will have a value in the appvar, 1 for on and 0 for off. That's 94x62 bytes. Then a Pause byte, that will simply be "P". That's one byte, ain't it.

This will repeat for however many slides.

If my calculations are correct, that will be 5828 bytes per slide? Can anyone help me figure out how to compress that? Or am I wrong about this? It should be only 767 bytes?

Oh, and yes, I will be releasing a separate viewer program.

All images are bit-packed to 8 pixels per byte. If you're only storing one pixel per byte, then you'll be wasting seven out of the eight bits in every single byte. Your slides will therefore be (96*64 not 62)/8 = 768 bytes, plus the identifier and pause time, for a total of 772 bytes each. You also call this TIPoint, but your splash screen says PowerPoint. I strongly recommend you fix that to avoid infringement on a copyright/trademark.

Yeah. I meant to do that. Forgot to change the String for that.

Also, how do I bit-pack an image.

And, I won't reupload the image, but i just changed the splash to "TI-Point"


Let me also add that each slide *File* will be one appvar. And each File can have multiple slides. The size for each file will be

3+1+(769n)

Where n is the number of slides in the file.

OK, that's good to hear. You don't really do anything explicit to bit-pack the image, other than that if you want to change individual pixels you need to use a bitmask like %10000000 or %00010000 to set and reset pixels.

Gotcha. So it'll actually be 3+1+(768+1)n, to make it more explicit, where the first +1 is the number of slides in the AppVar, right?

No.

3 is the identifier
+
1 is the Pause time
+
(768 is the bitmap of slide
+
1 is the Pause byte)
*n is the number of slides.

I won't needing to indicate how many slides in the appvar, because I will code the viewer program to keep cycling until it hits the end of the appvar. Thats when it knows its done.

Then what do you have two pause bytes for? That doesn't make sense to me.

To be honest, it isn't needed.

The first was going to tell the calc how LONG to pause.
The second was to tell the viewer program WHERE to pause.

but, if it is uniformly 768 bytes per slide, then i can just make it pause every 768 bytes, not needing the second.

I don't understand the difference. You're going to need a separate pause byte for each slide, in case the user wants one slide to display for 99 seconds and the next for only 1 second, no? So I don't understand what the global pause byte is for.

Ah, that's true. I never thought of that.

If I understand you correctly, you were assuming that each slide would be paused for the same amount of time?

Yes. But, I should make variable pause lengths.

Good, I'm glad we agree. Now, what tools will you be offering users to edit and create slides?

Text writing, obviously.

Line placement.
Circle drawing.
Possible sprite importing, but not sure yet.

"Auto-Center Text" is a future goal.

Oh and to avoid the issues caused by having to download and send multiple files to your calculator, I will not package the actual TIPOINT.8xp and TIPVIEW.8xp files for download. Instead, there will be one program, PTINSTAL.8xp. This program will be an installer script that will contain 3 segments:

1. The installer
2. The data that makes up TIPOINT.8xp
3. The data that makes up TIPVIEW.8xp

You run PTINSTAL.8xp and the installer creates the actual programs, then runs TIPOINT. TIPOINT's first routine is to Archive the installer, in case of a RAM clear.

All files (appvars) are held in Archive. Thus, its essentially crash-proof. (My main weakness as a programmer is that I put alot of effort into crash-proofing my stuff).

Errr, why not just make it a group file? Groups are exactly what you're describing, and will save people (and you!) the trouble of using or making an installer.

I generally dislike groups. It involves the user knowing how to ungroup, which most non-programming users don't. With an installer program, all the user has to do is press ENTER and let the calc work its magic.

Although we agree on the fact that a group would be easier on ME.


Version Plans

0.1 alpha:

Get Splash Screen and Options Select Done
Get Options Menu and Changing Done

0.2 alpha

Get text input routines done
Get line drawing routine done
Get circle drawing routine done

0.3 alpha

Get by-Pixel drawing done
Get file save done

0.4 beta (will release every version hence)

Get file open done
Get editing capabilities done (Pxl-Off, clear line)

0.5 beta

Write Viewer program.

0.6 beta

Reserved for fixes on beta testing

1.0 (official release)

Write installer.[/u]

I notice you have no option for users to import an existing Pic0 through Pic255; is that something you might consider adding at some point? I understand your point about the installer vs. a group, although I still think a group would be a better option; I think you underestimate the caliber of person who would be using a program like this.

Well, you're probably right on that Kerm, but when I make a program I try to do it so that anyone, even a person whose IQ will yield an imaginary number when you square root it, can use it.

As for the importing actual pic vars, I though of it, but as of now do not know how to implement it using Axe Parser. I will try though, but not in likely it will be either not there or very buggy in Version 1.0.

Sounds good. If you were writing this in ASM I could easily guide you through how to do that, but since you're using Axe, I'm significantly foggier on it. You really need to learn ASM one of these days.

Well, Axe uses name strings, so by saying

"Pic0"->Str0AA
GetCalc(Str0AA)->P

It returns a pointer to the TI-OS variable Pic0 into P. So that's probably what I would need to do.

You may even be able to do better than 768 bytes per image if you use a more complicated structure than a bitmap. Maybe a quadtree or something like that.