Post by Jeff Ledger on Nov 14, 2005 11:36:23 GMT -5
Dave Moorman wrote
Excellent! This would mean some kind of "compiler" between the source [bkgd=3] and chr$(255)chr$(192)chr$(3)chr$(254), which would be the object code sent to the client. Or not. Just thinking outloud.
I would propose that we establish a uniform language and syntax for both CML and CPPP (Commodore Protocol Power Point -- was MediaMeister). Then at the very least, the writer could check out the document before posting on the web.
Good idea! What is the current syntax for CPPP?
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." -Albert Einstein
<t0> This would be printed to a full screen and so forth until some other code, such as...
<w> (wait for keypress) <l0file.shp> (load "file.shp" to buffer 0 ( graphic)) <d0> (display graphic in buffer 0) <t2> This line and the next are displayed on the bottom two lines of the graphic <w> <e> (end)
So I am ready for a complete remake :-)
Last Edit: Nov 14, 2005 12:00:36 GMT -5 by revdave
I need to get to my "real" job. I will look up the docs on MediaMeister and do some fiddling. Do you have docs on CML's syntax? Probably CPPP will change more to match CML.
I do have a gimmick that might be useful -- already implied by the <l0> command. Old MM had 7 load buffers of 16 pages each. Two were usually required for graphics, one for music. With these buffers, one could load up a number of items, then flip between them. Music (MUS files) also were loaded to a buffer, then played by SIDPlayer from there. And the MM document(s) would be loaded into a buffer, then copied to the read area. The MM documents were limited to 12 pages, but could be linked indefinitely.
I was talking about the new presentation software with Kevin -- my PC guru. We hit on what might be a good idea.
What if this program was a sort of Flash for C=? It would be more like a "plug-in" for CML, that offered graphics, text, music, sprite animation, and SAM voice presentations. I am not sure how this would be "connected" to a CML document. But this would offer complex audio/visuals without getting in the way of the simplicity of CML.
Perhaps -- and I am just thinking kind of out loud -- there would be a client program, called CLIPS (Commodore Loadstar Integrated Presentation System) (a good acronym is crucial to creating good software! ;-). When a user called a CLIPS presentation from a website, a collection of files would be downloaded to the C-64, then played with the CLIPS software.
OR -- a direct-from-web connection would access the various text, music, and graphics files as called by the CLIPS script.
As I work on this, I am finding that this CLIP will occupy almost all the memory available -- needing space for graphics, text, music, and programming. So while the markup language could be similar, it won't be compatible at the same time.
However, CML could have a code that would load and run CLIP off a local disk (like flash). The program could be brought in through the internet -- or a whole program is downloaded to disk, then the plug-in kicks in. What it means at this end is to do a RETURN to Browser (much like a RETURN to LOADSTAR that we do all the time around here).
Does your language have built-in downloads? Can a script-list of files be auto-downloaded? This seems to me to be the way to connect the two systems.
The problem is with the graphics files. They add up quick! The CLIPS code is 51 disk blocks, complete. However, if CLIPS was a plug-in -- as I understand the concept -- the program would be on the client's drive. When a page has some display material, the client downloads the show, boots clips, and watches. When finished, the browser is reloaded and run -- returning to the place where it was.