Heh... six months for the first beta, I'd say. There's still a lot to do. :)

First demo:

http://www.atari8.co.uk/downloads/gui_10_06_11.zip

Guidelines and notes:

•Run this with BASIC off and no carts present (SDX users use "X GUI.XEX"). You can boot the file with an XEX loader (for example, in an emulator), since it doesn't yet require DOS.
•You need a mouse on port 2.
•Use File->New to open more windows on the desktop. They're all called "C:>*.*" at the moment.
•Use Tools->Hide Mouse to toggle mouse pointer hiding when doing redraws. When the option is ticked, the mouse pointer will disappear and flicker, etc. Personally I can hardly tell the difference performance wise.
•Single-click registering is very slow: this is just a tweaking issue I was too tired to rectify this evening. To bring a back window to the front or use the maximize button (which doesn't toggle yet), you'll need to hold the left button down for a good second.
•You shoudn't need to single-click a back window before dragging its scroll handle or size box, etc, but you do at the moment. This is because I haven't finished the buffered event pipe yet.
•You can't close windows down yet.
•The desktop icons aren't "live" yet (i.e. they don't do anything).
•Don't be surprised if you manage to make a window wrap around and create screen garbage. The boundary checks are rough at the moment.
•The border flash is part of some debug code.
•Please no complaints about full desktop redraws. I'm well aware of what needs to be done. There are no back buffers or any "smart" redraws at the moment. That comes later.
•There are several really terrific bugs just waiting to be discovered.

There's a very odd bug which I need to track down which creates all kinds of problems when new code gets inserted or old code removed. I figure there's some rogue write going on in RAM which does or doesn't upset something important depending on the size of the code. Gonna be fun tracking that one down.

I've probably forgotten to mention some other salient points. Hopefully I'll get some feedback over the weekend.

I optimized the VBL and slashed a load of cycles out of it this evening: it now uses the font renderer bit-shift lookup table to divide MOUSE_X by 8. I also created a lookup table for the dynamic DLI to save doing computations on MOUSE_Y in relation to the display list. This has probably saved several thousand cycles per second.

Lots of changes in the pipeline, so hopefully this will be the first of many regular updates.

Slight update to the Polish font pack:

http://www.atari8.co.uk/lastword/

Full desktop redraw with icons and labels:

http://youtu.be/EvtD0ye15Yg

I have done, but the error message is confusing. It merely says "READY". :)

Demo by the weekend, with overlapping windows: just need to code up the scrollbar scaling:

http://www.youtube.com/watch?v=Enh5MQaK4sc

Progress is slow, but the scrollbars are working:

http://www.youtube.com/watch?v=2H1xJUF3jes

A downloadable demo with a movable, sizeable window (or two) will be available in the next few days. After that, I'll take a short break to do other things, then come back and optimize what I've written, do some more planning, and then start the dialogue handler and the virtual window coordinate system.

Have a look over at the Atari Age forum to see how the project is progressing. I considered it more important to make significant progress on the core code than release frequent demos. I am currently working on a resource manager (having done a complete re-write of the menu manager) and when this is closer to completion I will release another demo for people to play with. It will demonstrate a movable/sizeable window with a complete set of controls, as well as the menu system and some static icons on the desktop.

What - rewriting the whole GUI from scratch? I have around 2,500 lines of code, and only 500 lines of code (those in the GFX.S module) are concerned with drawing to the screen. And of those 500 lines of code, there are about 20-30 direct writes to the screen RAM. Moreover, GFX.S hasn't grown in size for weeks (while GUILIB.S grows exponentially). There is much more to a GUI than drawing lines and blitting. The bulk of the system is all about object manipulation.

Exactly so. Most of the GUI operations are reducible to:

- Clear an area of the screen
- Move an area of the screen to a back-buffer
- Move buffered background data back to the screen
- XOR an area of the screen
- Draw a horizontal/vertical line
- Blit a bitmap to the screen (an icon or alpha character)

This is all pretty straightforward and re-usable code (e.g. the code to draw boxes and drop-shadow boxes simply calls the draw horizontal/vertical line routine a few times). To implement VBXE support, one would change the clipping limits, re-write PARTS of GFX.S, replace certain code with blitter operations, etc. Not a trivial task, but probably only a month's work.

As for drivers, why on earth would I concern myself with a device independent screen driver when I'm writing a GUI for an Atari 8-bit? 99.9% of these machines have a fixed 1bpp 320x192 display. Why overload screen draw operations with multiple levels of indirection, varying screen dimensions, etc, just to have a system which runs sluggishly but which is easier to convert for VBXE use?

The fact is, it would be better to regard GFX.S as the "driver", and to think in terms of "draw line", "render bitmap", and "clear screen area" as the lowest-level operations. There are half a dozen such operations at the moment, and this code is all we need to re-write to implement support for VBXE modes.

Well said. Of course the "proper" way would be to render everything at the pixel level and simply implement a driver which provides the low-level interaction with the screen. But this is an Atari 8-bit with a 6502 processor. I said at the start that the GUI would have to employ "techniques normally seen in games and demos". How many demos draw to the screen using the CIO? :D

VBXE modes would obviously solve a lot of problems (such as representing a 72dpi document on the screen), but the objective is to get something working on standard hardware first. Of course it's fairly easy to add VBXE support later: amend masking and screen RAM write routines, and adjust the size of the root (SCREEN) object in memory. But naturally when you introduce device independence, you introduce an overhead. "JSR write_byte" is many cycles slower than "STA (SCR),Y". Let's get the basics out of the way first. In any case, with VBXE's blitter, it would be difficult NOT to write a fast and responsive GUI. Or one could just use an ST. :)

Pin's meaning is especially hard to translate, ;) but SDX plus GUI is a match made in heaven. The system will use the full features of the Sparta FS, and will have a clock-widget in the top-right corner of the screen. You'll double-click on it to set the system time. Drag and drop files(s) from one folder to another. The usual basic GUI stuff.

Cartridge or files? Who knows. I'll make the best practical decision after taking everything into account. All my software has always been free. If it's on a cart, you'll have to buy yourself a flashable cart and flash the GUI onto it. It's it's on disk, there is zero financial outlay. :)

Cascading menus are now finished, and I've started the window/dialogue render routines, and the rest of the event handler. It will take several weeks to code up all the controls (scroll bars, text boxes, list boxes, buttons, etc, etc).

The new GUI will be able to launch "legacy" applications and return to the desktop. It's a pretty essential feature. I should have listed that in the specifications. :)