Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[HonestFlames]

I have today completed the most basic, usable version of WireANSI.

Features and limitations of this preview: -
- Fixed 80x25 editing area.
- Very good optimised saving of ANSI files.
- 'Overwrite' mode editing only.
- Loads ANSI files but only understands colour-change escape sequences.
- No support for underline, bold or italic styles.
- Saving is slow.
- Loading is very slow. Like watching a 300-baud BBS connection on an Amiga 500.

Bugs: -
- Does not ask permission to overwrite files. Be careful!
- Clicks on toolbar buttons are acted upon immediately, rather than at button-up time.
- Probably does not fit on regular displays (slightly overscanned resolution used).
- Booting from the ADF gives a slow keyboard repeat rate. Launch from your HD instead (assume you've adjusted your input prefs for faster repeat?!).

There is a help screen (hit HELP), but it does not give much assistance

Pressing F1 - F8 will change foreground colour. Shift + F1 - F8 to change background. Cursor will show current colour (top half = foreground, bottom half = background).

Two attachments here are a zip of the bootable ADF (not really recommended to do so, just launch your Workbench instead) and the source for this version (V0.22).

I will welcome your criticism, good and bad. 

[SamuraiCrow]

I looked at the source.  Part of the reason it's so slow is that you're storing the foreground color, background color and character each in a separate array of integer.  You could speed it up quite a bit by packing all of those data items into a single array entry.  I = FG * 65536 + bg * 256 + char will store all three values in one array (assuming they're each a byte long).  Also, Amos does range-checking on every array access.  If you have already done your own range checking on the indexes, just do an I=Leek(Varptr(arrayname)+4*(x+80*y)) to get the value I=arrayname[y,x], for an array with the second dimension being 80.

I hope these tips help you.

[HonestFlames]

Many thanks for the tips. I'm implementing the Varptr() optimisation in the redraw procedure right now.

I'll run some timing test once I've done it.

[HonestFlames]

Measured using Timer=0 at start of the loop.

Unexpanded A1200:
Interpreted, unoptimised = 193
Interpreted, unrolled loop (factor 8) = 190
Interpreted, Varptr() + unrolled loop (factor 5) = 169

Compiled, unoptimised = 105
Compiled, unrolled loop (factor 8) = 105 !
Compiled, Varptr() + unrolled loop (factor 5) = 97

With Blizzard 030/50 + 64MB @ 60ns, the compiled + Varptr() = 31


It's certainly an improvement, but there are some major slowdowns caused probably by the Ink and Text commands.

The actual processing of the loaded ANSI takes quite a while, too. There's room for improvement there with Varptr() too, but I'll work on editing features and usability before I go doing any great amount of optimising.

Thanks again for the tip!

[SamuraiCrow]

Be careful on the loop unrolling.  The instruction cache on your '020 and '030 is only 256 bytes long!  The '030 only adds a 256-byte data cache.  Keeping the loop small can actually make it faster than unrolling on the compiled version because the looping overhead is small anyway.

BTW, did you eliminate the parallel arrays using the packing technique?  To unpack them you Peek(Varptr(I)+3) to get the first byte, Peek(Varptr(I)+2) for the second, and Peek(Varptr(I)+1) for the third.

Storing the Varptr in a separate integer variable might be faster too assuming you do the Varptr lookup outside the loop.

If you're using Varptr on the array, you can use the same formula to access the data from banks substituting the bank start address for the Varptr of the array.  If you want to make an array equivalent for byte or word-size data remove the multiply by 4 for bytes.  For words precalculate the byte offset and Deek(offset+offset) to eliminate the need for a multiply at all (adding is faster).

[HonestFlames]

Noted on the loop unrolling. Some final testing might be in order, before V1.0. I have a hunch that even a tight loop will stray outside the cache area. Possibly the Ink and Text commands result in some lengthy code crawling. I know there are extensions which have some fast text rendering commands though. I'll investigate those later into the project. Being performant on an A600 is my aim for V1.0.

I kept Varptr() outside of the loop. Just incrementing an offset variable by 4 between every Leek(). As a result, the screen now redraws from left to right instead of top to bottom, due to the way the array is stored.

I didn't merge the arrays together, as I knew already that I should use a bank instead. I'll make this move fairly soon, before I implement too many features relying on the arrays. Rather annoyingly, I need 17 bits to store everything...

8 for the character
3 for the foreground colour
3 for background
1 for underline on/off
1 for bold on/off
1 for italic on/off

I could pack everything into 32 bit longs, or I could separate the bank into 3 areas of byte data. One for chars, one for colours and one for styles.

The move to a bank from arrays opens up the possibility of an 'undo' facility. Copying banks (or between areas of 1 bank) is a quick operation, enabling multiple buffers for storing before/after undo points. If each character can be described in 3 bytes, that's 6000 bytes for an 80x25 screen. Shame there's no Bank Grow command

[SamuraiCrow]

Bank Stretch is in the AMCAF extension.    (Although I'd avoid using it too often as it does quite a bit of memory copying and dynamic allocating.)

Also, I'd avoid using a bank with an odd number of bytes.  Sometimes they get buggy when you try to compile them.  You'd be better off packing them in longs for speed purposes.  Btst and ROR.L may also come in handy for those single-bit flags and 3-4 bitfields you'll be using for styles and colors.

[Lonewolf10]

Also, I'd avoid using a bank with an odd number of bytes.  Sometimes they get buggy when you try to compile them. 

I believe the same is also true for Icon/Sprite banks with an odd number off Icons/Sprites. I haven't tested this extensively though.


Regards,
Lonewolf10

[HonestFlames]

Development has lagged a bit because I've been playing Minecraft solidly for ... a little while

Still, just to get something done I replaced the character and colour arrays with a memory bank and a whole bunch of peeks and pokes. Runs like treacle on a stock A1200 still but it's not optimised.