Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.

Do you prefer a fast rendering algorithm without symbols, or a slow one with symbols?
Fast without symbols
 52%  [ 10 ]
Slow with symbols
 47%  [ 9 ]
Total Votes : 19

Personally I liked it being white and showing the current open filename better. Also, you asked in IRC about ditching different align modes, and I think that you should probably ditch them.
I don't implement neither aligning nor word wrap, which are too hard to implement. Instead I'm going on with bullets, and got it ready. In the string, they are represented as "[xhat]", with a <G> before it.


[UPDATE]
Thanks to Kerm and Ivoah, I've implemented a loading screen where you can select 1 of the maximum of 15 documents. The first time you start the program it automatically creates an appvar. Why 15? That is because 1) I will focus me on the editor, and not spent time implementing unlimited amount of documents, and 2) that will eat RAM.
Ok, I just changed the storing of documents what I said earlier. This is much easier for cursor movement and it is smaller - I saved around the 200 bytes.
An example of an appvar with a document is

Code:
Document1
\
\ TEST
<B>
TEST
<U></B><I>
TEST

(That backslash is only for a space at the beginning of the line)
Btw, I could probably remove the < and >, just like

Code:
Document1
\
\ TEST
B
TEST
UI/B
TEST
This saves more spaces. Is that a good idea?
It also saves you the hassle with all those "sub("'s so it definitely is.
I just changed it all and removed the < and >
Now the 'style-line' looks like "BUI<COLOR=25>GS". Instead of using the "/", I just saying that if inString("B"), then not(B -> B
The next thing is that I made a list with the amount of characters per line, inclusive the symbols.
So

would return L1={28,8}. THis would be easier for the editor.
The last thing is, that I've added a Doors Icon, do you like it?


EDIT: I'm very happy to say that the first and main part of the editor is ready: the cursor movement.

This was extra hard, because real(7 expects the calc in half-res mode, but my program don't, so it must switch the LCDBuffer.

I'm now going on with adding and deleting characters.
What is your cursor movement based on? Do you actually have custom movement between each character since they are different widths? Or is it a locked grid movement like in BasicNote? Looking at your screenshots I would assume you have custom but I'm not completely sure.
Michael2_3B wrote:
What is your cursor movement based on? Do you actually have custom movement between each character since they are different widths? Or is it a locked grid movement like in BasicNote? Looking at your screenshots I would assume you have custom but I'm not completely sure.

As I already said, I keep noting the amount of characters each line. The X- and Y-co÷rdinates of my cursor are S and T. The maximum of X is then the amount of characters. And the maximum of Y the amount of lines. So the code for me looks like

Code:
min(dim(L1)-1,max(0,T+sum(DeltaList(K={25,34->T
min(L1(T+1),max(0,S+sum(DeltaList(K={24,26->S

Each characters have a width of 8 pxl, so that is just the same as BasicNote. And no, I'm displaying them with real(6. Only the symbols are custom, but I made them so, that they have also a width of 8 pxl. You can say that you move within a locked grid with some limits.
Instead of implementing adding and deleting characters, I'm busy with tracking the style of each character. If it is bold, then the bold-character is inverted. It works for me with pressing left and right (see gif below), I will now going on with up and down which is much harder.


EDIT: now it works also with pressing [DOWN]
That looks surprisingly fast; nice job. I'd imagine that scrolling up and down is rather slower, though. While we're on the topic, have you thought about how documents longer than one screen of text will be handled yet? Do you plan to scroll by lines or by screenfuls?
KermMartian wrote:
That looks surprisingly fast; nice job. I'd imagine that scrolling up and down is rather slower, though. While we're on the topic, have you thought about how documents longer than one screen of text will be handled yet? Do you plan to scroll by lines or by screenfuls?

Nah, going up or down is not much slower. I am happy [DOWN] finally works good without bugs and I'm busy with debugging [UP].

And for the scrolling: it would be awesome if there was a way to shift the screen up but I don't know of such one. For rendering time makes that no difference, but I hope I will being able to implement a scroll bar.
Yay! I'm finally ready with cursor movements. Now it checks for the style at that point (but important: it takes the style of the character BEFORE the cursor, not after). The time to traces it, it actually faster as I first thought.
Time for some updates. At first I removed the underlined and the strikethrough at a bullet.
Next, I fixed the style checking at a point - if you stands at the beginning of a line, it takes the LAST character of the PREVIOUS line as to check against the style. I fixed it, now it works properly (I hope so Razz)
I will finally work on adding and deleting characters.


Bucket list for the editor:
- (Done) Cursor movement
- (Done) Style-checking at a point
- Adding characters
- Deleting characters
- Changing style
- Replacing characters
- Selecting characters
- Deleting selected text
- Replacing selected text
- Multiple pages/scrolling

BTW, I can remove the 'save-icon', it will be automatically saved.
I will continue this project now, because my school life was very busy. I'm thinking of a better rendering algorithm, without extra symbols. Instead of displaying characters one by one, I can display them style by style. This means that I can't include symbols, because real(6 displays trash instead of ┴ etc. Now I wanna ask everyone: what do you prefer? A slow algorithm with symbols, or a fast algorithm without symbols?
I have asked you in a poll about that (my previous post), but it is now 2 vs 2 votes Razz
Therefore I created both algorithm, here are the results:
vs
As you can see, the second one is much faster, but as I said, it don't include symbols. Please could people vote in my poll to see what I can use. Thanks!
A third possible option: would you consider including an archived spritesheet of all the italicized characters? A spritesheet can be 8x16 sprites, each 8x8 pixels, so you could fit 128 characters (enough for the ASCII portion of the character set).
I think a refinement of style-by-style could get you the best of both worlds.
Time for a new post!

I am really busy with school and personal stuff, so I don't have much free time for programming such projects like this. That doesn't take away I didn't thought about it. I'm really demotivated to continue this, because
1) it is hard, since I'm not in half-res mode
2) I don't have some time to finish it, because I'm in my exam year

The hardest thing is programming not in half-res mode. That means I must check continue which GRAM I should use, etc.

What do you think? Can I chop off this project or should I continue it?
Looking amazing! Might there be customizable skins added in? I take it this will not be for the CE as well because of the use of both sides of the screen?

So can we get an up to date todo list? Unless the one in the OP is.
Unicorn wrote:
Looking amazing! Might there be customizable skins added in? I take it this will not be for the CE as well because of the use of both sides of the screen?

So can we get an up to date todo list? Unless the one in the OP is.

Thanks!

What do you mean my customizable skins? Images, the images for B, I or whatever? Nope, this is not for the CE, because it uses indeed both sides of the screen

Today, I've created the most important part: adding characters. It will look like this:


My new todo list:
- Finishing adding characters (Done) - it automatically deletes the first character of the new style if you're at the end of a style
- Deleting characters (Done) - this was extremely hard to implement
- Highlighting
- Copying-pasting
- Select B, I, U or S
- Multiple pages

I will keep it up!
Looking good! I guess by skins I mean the ability to change the colors of the program. Wink
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 3
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement