Jump to content
Posted Sun Dec 6, 2009 2:56 PM
Posted Sun Dec 6, 2009 3:10 PM
...and this necessitates extra work to ensure it always remains visible even when the underlying app is drawing to the screen...
Edited by analmux, Sun Dec 6, 2009 3:11 PM.
Posted Sun Dec 6, 2009 4:14 PM
Posted Sun Dec 6, 2009 4:18 PM
Posted Sun Dec 6, 2009 5:28 PM
Posted Mon Dec 7, 2009 2:57 AM
I've solved this problem by channeling the application's output to a small back-buffer if it hits the mouse. On the visible screen, the mouse pixels are drawn over the new screen data on the fly, and when it moves, the necessary data to restore the background is already in the buffer. The mouse is drawn during the VBI.
Well, a first thought could be executing the mouse-drawing routines at the end of a VBI, and make sure all other drawing commands are finished before that.
Another solution could be to monitor the y-position of the mouse-softwaresprite and do a timed interrupt right before the corresponding rasterline. The interrupt itself will draw the mousepointer. Then do some other stuff (like computing something) when the video chip is displaying the pointer. After the last line of the pointer another GFX task could be started, but it would never affect the already displayed pointer.
Pretty much as you say: I want half-colour clock x resolution, and for the mouse pointer designs to be two-colour (black and white) and quite detailed.
You already know I am a big fan of this project.
One question, just for curiosity.
Why don't you use PMG for pointer? Perhaps because you want an high resolution pointer?
It might end up going that way: it depends if the feature set ends up allowing everything Diamond did (i.e. scroll bars, overlapping windows). A compatible API with a better looking interface is certainly an appealing option.
Are you saying that the your apps for you new OS are going to be compatible with Diamond? If So I like to see this.
Posted Mon Dec 7, 2009 10:37 AM
Posted Mon Dec 7, 2009 10:00 PM
Crap... having problems already. By the time I got the bitmasking working for the pointer (in the VBI), that plus the DLIs to sample the mouse have thoroughly overloaded the system. I can see why a PMG is the preferred mouse pointer, owing to the minimal processing. I'd forgotten just how few cycles can be crammed into the DLI.
Posted Mon Dec 7, 2009 10:11 PM
Posted Tue Dec 8, 2009 4:30 AM
That's an interesting concept that might work well. Default sampling at 50 Hz, then ramp up to 100, 150, 200 or whatever's needed.
I'm sure someone (might have been Heaven) posted some time ago a quick mouse movement algorithm that could quickly be adapted between Amiga/ST mouse types.
Posted Tue Dec 8, 2009 5:15 AM
Posted Tue Dec 8, 2009 5:17 AM
Posted Tue Dec 8, 2009 5:52 AM
Posted Tue Dec 8, 2009 5:56 AM
Amiga/ST mice use the joystick directional lines... it's the Commodore mouse for the 128 that uses Pots.
In some ways, that would be better. Only need to read once per frame, supposedly it gives a delta X/Y value that you only have to scale then adjust your pointer with.
Posted Tue Dec 8, 2009 6:31 AM
Posted Tue Dec 8, 2009 12:46 PM
I'll look into that if I don't have any luck with what I'm working on (see below).
What about only activating the mouse sampling DLIs if the VBI routine notices a change in the joystick port? Won't solve the whole problem, but it'd help when the user is typing.
That's an interesting interface metaphor. I absolutely agree with the last point: The system is growing from the mouse pointer upwards: everything's going to be as tight as Hell. I am giving some thought, however, to utilising extra memory on expanded machines. Diamond used a virtual memory driver which yielded (for example) 64K of text space in Diamond Write. Great!... But it was deadly slow. I'll probably put all the resident code in a 16K extended bank until we get into cartridges, etc (I have no experience of cart programming, BTW). The resident library will ideally contain not only the user interface routines and API entry points, but also a general graphics library with line draw, circle, fill, etc. So applications shouldn't need to be weighed down with proprietary code to do common tasks. The windowing system will also use a 16K bank for heap space (saving the screen RAM behind windows), so clearly an expanded machine will be a must. That said, I can see the appeal of something which would run on the older machines: however, I think that will be a cartridge-based code scenario. I'm already roughing out ideas for the event handler, how to set up dialogues, etc. Optimisations will include a dialogue/window's workspace always being on byte boundaries to speed things up, etc. The text entry control will be fairly sophisticated and may include mouse selection and cut/copy/paste. A clipboard would be nice. Although simplicity is the watchword, a suitably complex text box control could make the creation of a simple text editor as easy as sticking a multi-line control in a window (in much the same way as it's possible in Windows).
I would like a GUI desktop where I can launch a binary (like Atari Tennis or BobTerm for example) via icon double-click. I would like then to be able to terminate it, perhaps by escape key or key-combination, and end up back on the desktop without reboot. The icons would be assigned automatically for all files, with simple images perhaps even 8x8 or 16x16 to start appearing automatically, and different based on file-type. One would be able to rename, move, and delete the files via the icons.
I guess a drawer paradigm is most practical. The user creates drawers on the desktop and can move files in and out of the drawers by moving the icons. Android OS makes use of a labeling paradigm, however. There might be some advantages to going with that, but I don't know if it applies and I don't quite understand it yet.
I encourage you to go as simple as possible each step of the way, and get the memory and other requirements down-down-down, so that the new GUI may even run on a 48k 800 or 400. Good luck!
A possibility, although I'd prefer to do this in VBXE's 640x200 mode in order to maintain the pixel aspect ratio. Just imagine that screen real estate.
I haven't mentioned it yet... go interlaced.
Then there's plenty of room for the cute but still readable smallish fonts.
One barrier to overcome though is keeping it active when SIO is going... but I might have an idea or two there.
Posted Tue Dec 8, 2009 1:02 PM
Posted Tue Dec 8, 2009 2:08 PM
Edited by flashjazzcat, Tue Dec 8, 2009 2:10 PM.
Posted Tue Dec 8, 2009 2:32 PM
Phew... finally got the mouse pointer working. I had to trim the DLIs down to 500 samples per second to offset the larger VBI routine. Unsure how much these interrupts will affect main program speed at the moment, so I may have to rework the interrupt sampling.
Not much to see: just a hi-res pointer you can move, and it's all interrupt driven with pre-rendered mouse images and masks. The main code just goes into an empty loop after doing the setup. Some bounds checking doesn't work yet, x won't go past 255, and so on. Move pointer over the inverse text to see the pointer outline.
Mouse.zip 859bytes 389 downloads
It would be nice to do a 16x16 mouse pointer: then we could do an exact copy of the ST's bumble-bee, for example. That may just be too much for the VBI, however (16 loops instead of 8 for draw and erase, plus 3 bytes of shifted data per line instead of 2). The pointer won't look as tiny in 8x8 when the fonts are proportional, though.
Next update will be the text changing and being printed "under" the pointer when you click on it. The only precaution I'll need to take is to set a flag to prevent the VBI drawing the mouse in a different position for the dozen or so cycles when the main program is writing to a byte under the pointer (and also to the pointer back-buffer).
Only another 1,000 hours work and we'll have a brand new WIMP system for the 8-bit.
Posted Tue Dec 8, 2009 2:38 PM
Well, hadn't thought about the terminal (good idea, though), but further up this topic I mentioned that I intend to release the GUI with:
If you're really going to look to get people to use your GUI - you need to consider coding a good wordprocessor and terminal program to give your environment something useful to run under it.
Edited by flashjazzcat, Tue Dec 8, 2009 2:39 PM.
Posted Tue Dec 8, 2009 8:06 PM
Edited by walter_J64bit, Tue Dec 8, 2009 8:11 PM.
Posted Tue Dec 8, 2009 8:08 PM
Posted Tue Dec 8, 2009 9:51 PM
I would like a GUI desktop where I can launch a binary (like Atari Tennis or BobTerm for example) via icon double-click. I would like then to be able to terminate it, perhaps by escape key or key-combination, and end up back on the desktop without reboot.
Posted Tue Dec 8, 2009 9:58 PM
0 members, 1 guests, 0 anonymous users