Feature Requests

[Zaphod Beeblebrox]

Would it be possible to add some extra capability to the real(10 command from xLIB? I was thinking that it currently only has two possibilities for the second arguement, create and delete. Would it be possible to add a third possibility for that argument, that would (un)archive the specified picture?

[vuurrobin]

you can use identity(1 for that.

[darkstone knight]

how about an 15 MHZ command?

that would take... 10 bytes?

[luby]

I'm pretty sure basic runs in 15MHz when it can, so this would be pointless.

[darkstone knight]

really? i thougth thet ran at 8MHZ to save battery life

[Graphmastur]

I had an idea, for Celtic3. Okay, first things first, I think instead of just zero or one in the updateLCD thing, you should also have a two, which is capable of writing directly to the screen, skipping the graph buffer.

The other idea, is to have text support. I hate how text is automatically updated, when using xlib, or celtic3, and it just looks bad.

I just had another idea that is cool.

A sectioned sprite drawer. Say, I have a loading bar, and I want it to look like the mac loading bars, so I create some sprites, for each frame. What I was thinking you could do, is specify the pic to get the pictures from, and have a number, and have a width, and a height attribute, along with a x and a y attribute. This would take the specified 8 by 8 sprite from the picture you wanted, and start in the x and y position. It would then go to the right one. If it can go to the right, but only by a certain amount, e.g., the width is 11, so there is 3 extra pixels, it will cut it off after those 3 pixels. It would then do the same thing going down to the next row. This would also go with my first idea. Say that the input was this: "real(15,PIC_Num,Sprite_Num,X,Y,Width,Height,Update"

[Iambian]

For the LCD update thing, having the app update the LCD directly is completely unreasonable. Most of the functions require the buffer prior to outputting to the LCD, and doing it any other way would completely bloat the application past its bursting point. Okay, maybe not, but I'm not willing to code a second copy of each routine to support direct LCD writing. Especially since applying logic masks if you're not simply overwriting the screen would require actually having to read the LCD *and* then write back out. Result? Slow. There's a reason why there's a graph buffer.

For text support, I was pretty much unaware that this was a problem. Such support would pretty much be easy to code. Might make it to release "R", which ... I haven't worked on since I've got two other projects going on. But I know now what I could do to make that release more substantial. Thanks!

For this "sectioned sprite drawer", I'd like to know why the current sprite routine cannot do what you're asking. I know it's well and good to have something to automate the process, but if it can be done in some way using what is currently available, I don't see a reason to code a specific instance of it. Present a good argument as to why it would be available, and maybe.

So, in short.

1. Never.
2. Yes.
3. Maybe. Need more info.

[Graphmastur]

I am glad that you will do the text one. That is good. Writing another version for number 1 would be a little too much. I only need it for the real 12 for the drawing, and maybe for text. Why not use something besides PlotsScreen? Use AppBackupScreen, and if the user wants it copied to the screen directly copy it directly. If they want it to the graph buffer, just copy it to the buffer, and then update it. You would only have to change a few things.

Now then, the third one, I will try and explain a little better. If I where to have I tile that looked like this:
111[color=#FF000]0[/color]111
11[color=#FF000]0[/color]1111
1[color=#FF000]0[/color]11111
[color=#FF000]0[/color]111111
1111111
1111111
1111111
1111111
and I had another sprite that looked like this:
1111[color=#FF000]0[/color]11
111[color=#FF000]0[/color]111
11[color=#FF000]0[/color]1111
1[color=#FF000]0[/color]11111
1111111
1111111
1111111
1111111


Say that I want to use those top 4 pixels in each sprite, and only these pixels. Sure, I can specify a pixel height, but then, I can't really specify a width that is not a multiple of 8, and that is just for individual tiles. We are still talking about the total width, and total height from a tile map. Basically, as to not mess up functions that already use cletic3's command, you would have to have a new command. Basically, fill up the selected tiles or tile, until it would go past the width. Rotate the tile, until it was in the right spot, and stick it in there. Go to the next row, until you will go over he bottom row, and then just rotate the sprites, until they fit.

It is basically saying that you may have a tile with a height of 8, or whatever, and a width of 1 byte, but you can only fill up an area of a multiple of 8, and your tile height. If I have it 7 bytes tall in the matrix, but only want 27 rows, and 9 columns to be filled up, that is the general idea.

I am really glad you are doing the text thing though. It was a real problem in xlib, when you have a screen that is loading in the buffer, and have to write text, but it automatically updates the screen.

Have you fixed any of the real(12 bugs that I mentioned in the other thread?

If I can think of anything else, I will tell you. Like an idea for link ports so that the receiving calculator doesn't have to be in power saving state...


EDIT: I just had another idea. What about being able to turn on and off the keyhooks. Well, except the function use to turn them off. If I wanted to do the real part of a variable, and it happened to be zero, wold it clear the screen? what If I had the store symbol after it. One Syntax error, coming up!!!

[Eeems]

*B^um_p*
ok, so I wrote down some ideas at school...I don't know if they would be feasible, but who knows...

Interupt---det(#,boolian, program_to_run
------interupts the current program that is being run when the boolian is true and runs the program specified by the second arguement. It will return to where it was after the program finishes
Do_together---det(#,arg_1
------all commands inside the Do_togethers are done at the same time
------arg_1:---if 1 start of do together
---------if 2 end of do together
Task_label---det(#,"task_name",arg_1
------creates a task or macro. kind of like labelling
------"task_name" is used to identify a task
------arg_1:---1 is the start
------arg_2---0 is the end
Task_run---det(#,"task_name"
------runs a task/macro, kind of like a goto
------"task_name" is the name of the task

(sorry about all the --- my nice tabbing didn't work....)

[Builderboy2005]

Ok, so i have a huge feature request that I think would be very possible, and also very very usefull. IsKeyDown. You specify the key you want to check, and it returns 1 is down, and 0 if not. This would make a lot of thinks a lot easier. It would make the code for diagonal movement less weird, and you could do other actions while moving a character, like swing a sword, or jump.

[ztrumpet]

Wow!
Builderboy's request sounds awesome! Is it possible to include this?

[Iambian]

builderboy's request seems rather easy to do, so I guess I can get right to it. That would probably make release [ t ] a little more substantial besides a single bugfix.

[Builderboy2005]

I was inspired by BBC Basics isKeyDown command, that made a lot of things really easy!

[Eeems]

Hmm, I was going to suggest another one...but I forgot as soon as I started typing...so yeah...I'll edit this later with my actual request....if I remember it

[ztrumpet]

How about a free ROM thing? Like real(14 only with ROM.

[Iambian]

[ztrumpet]

Oh...
Sorry.

Wow. det(4...

[ztrumpet]

What about Omnicalc's real(31 Play command. I really like it, and it's the best way I've found to have music in basic programs.

[Builderboy2005]

Possibly full-er support of Omnicalc functions? Such as the useful Linking functions

[Galandros]