LOL, szybkie te okienka ;)

Implement blue screen of death :)

Beautiful I can imagine you will put "NewOS" on SIC!Flash.
So you will just boot into "NewOS" from cart...

Well, progress :) Why you're redrawing both windows after resize?

Ostatnio edytowany przez wieczor (2011-04-12 19:13:08)

> memory manager

how it would work?

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.

Very impressive. At first glance it looks much better than Commodore's GEOS.
Have you thought about turning your GUI into a standalone OS?

Thanks! Yes - I have considered that. I figure we need to make the UI work first, and release a version which works with DOS (SDX, MyDOS, etc). Beyond that, we can start to think about loftier goals, such as multi-tasking, and an integral FMS.

At the moment, ST (and compatible) mice only, although Amiga mouse compatibility is simple to add. We'll also support joystick, touch-tablet, etc, etc, in finished version. Keyboard control will also be possible.

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

Video of new window manager:

http://youtu.be/nKenrtfU-lM

After a long break, the project is back on track. :)

Jizz... you're alive! :)