popmilo Posted June 13, 2012 Share Posted June 13, 2012 Silly little thing but I love how you can see pointer moving while windows are being redrawn ps. When is api getting out in a public ? We need to start writing games for this one Quote Link to comment Share on other sites More sharing options...
+DarkLord Posted June 13, 2012 Share Posted June 13, 2012 Very nice. Love watching the progress. Keep'em coming! Quote Link to comment Share on other sites More sharing options...
fibrewire Posted June 13, 2012 Share Posted June 13, 2012 logo for the GUI?? 1 Quote Link to comment Share on other sites More sharing options...
NuY Posted June 13, 2012 Share Posted June 13, 2012 Just looking at the vids, and it all looks great, well done! One thing that looks a little weird to my eyes however, is the order in which the redraws are done. Not being a programmer, I'll try and explain this, because it doesn't really make sense in my head... When moving the window, there are momentarily two copies of the window you've moved; it's destination and it's new position. I have no idea why, but this just looks...well, odd. And I can't explain why. I don't use STs and I've not seen old Mac behaviour, so maybe it's the same there. So thinking about it (bearing in mind this is purely cosmetic, and I'm probably the only one who thought about it...), could this be altered maybe by masking out the old window position in background colour until it's ready for redraw, or possibly by changing the orders of redraw, making window's old position the priority for redraw, before making the new one? Obviously it would need some kind of algorithm to ensure you're only getting rid of old window position where there's no overlap with the new one, otherwise you're just wasting redraw when none is needed. Did any of that make sense? Am I the only one sad enough to think about it? Don't take it as a criticism by the way, and also feel free to ignore the point if it's unfeasible Quote Link to comment Share on other sites More sharing options...
Bryan Posted June 13, 2012 Share Posted June 13, 2012 That would slow things down a bit since it would result in two redraw events, one when you grab and one when you release. The way to think of it is that you aren't really dragging the window as you are on modern systems. Instead, you're telling it where to go and it moves once you pick the spot. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 13, 2012 Author Share Posted June 13, 2012 (edited) Silly little thing but I love how you can see pointer moving while windows are being redrawn And I love how the the pointer doesn't flicker at all while windows are being redrawn... definitely +1 for us over the Mac and ST there. When is api getting out in a public ? We need to start writing games for this one Hopefully before the end of the year... I know it's taking a long time, but it's slowly taking shape. One thing that looks a little weird to my eyes however, is the order in which the redraws are done. Not being a programmer, I'll try and explain this, because it doesn't really make sense in my head... When moving the window, there are momentarily two copies of the window you've moved; it's destination and it's new position. I have no idea why, but this just looks...well, odd. And I can't explain why. I don't use STs and I've not seen old Mac behaviour, so maybe it's the same there. So thinking about it (bearing in mind this is purely cosmetic, and I'm probably the only one who thought about it...), could this be altered maybe by masking out the old window position in background colour until it's ready for redraw, or possibly by changing the orders of redraw, making window's old position the priority for redraw, before making the new one? Obviously it would need some kind of algorithm to ensure you're only getting rid of old window position where there's no overlap with the new one, otherwise you're just wasting redraw when none is needed. Did any of that make sense? Am I the only one sad enough to think about it? Don't take it as a criticism by the way, and also feel free to ignore the point if it's unfeasible That would slow things down a bit since it would result in two redraw events, one when you grab and one when you release. The way to think of it is that you aren't really dragging the window as you are on modern systems. Instead, you're telling it where to go and it moves once you pick the spot. Bryan's right, but I might as well go into some detail about how this system works, and what's similar to the ST and what's different. You'll hopefully see why the system's a good compromise on a slow, small memory system, and why the Mac and ST do indeed use a similar technique. Here's what happens when you move a window on the A8 GUI: 1. If the window was originally entirely on-screen, the window is bit-copied to the new position. If it was off the edge of the desktop, the non-client area (scrollbars, drag bar, etc) is drawn in the new position. 2. The application receives a WM_MOVED event, and can take any necessary action. 3. If the window arrived from an off-screen position, the application then gets a WM_REDRAW message. It must then set the clipping region to the new position and size of the client area, and draw the contents. 4. The GUI creates an RLE encoded opaque mask (nothing draws through it) occupying the entire screen. 5. The GUI draws a transparent silhouette of the moved window in its old position on the mask. 6. The GUI draws an opaque silhouette of the moved window in its new position on the mask (what we now have is a foreground mask which is the exact shape of area "vacated" by the moved window) 7. The GUI figures out if the first window behind the focused window intrudes on the moved window's old position, and if it does, it draws the window's non-client area through the mask, and sends the application a client area redraw message. 8. The GUI adds an opaque silhouette of that second window to the previously created mask. 9. Loop back to (7) for the next window, finishing up with any parts of the desktop which intersect with the exposed area. As far as the application is concerned, it's always drawing the client area as if it were in the foremost window. The graphics library itself takes care of clipping and masking, and decides whether to return to the application without drawing anything at all if said graphic element is hidden. This is why you see fragments of characters and lines being drawn when a window moves. The application doesn't have to worry about this at all. Now, GEM on the ST maintains a rectangle list for each window, and the application has to walk this list when it gets redraw messages, checking if the rectangles intersect with "dirty" areas and redrawing their content if they do. The method is different (we use masking because our drop-shadow windows don't fit well with byte-level rendering), but the visual effect is the same (run STeem at a reduced speed and you will see this). The "Classic" Mac OS also uses the front-to-back redraw method, but employs "regions" so that applications (as in our system) believe they are drawing to an unobscured foreground window. Now what's really cool about the RLE compressed window mask is that not only can you store a very complex mask for several windows in less than 1KB, but new window silhouettes are added VERY quickly (we'd otherwise be manipulating an 8KB bitmap). Moreover, by saving copies of the mask as we walk through the window list, we can assign each window its own unique compressed mask, making dynamic, ad-hoc redraws to the client areas of partially obscured desktop windows a trivial undertaking, with zero performance overhead. GEOS 2.0 and Diamond GOS (among others) do a complete bottom-up redraw of all the windows every time one of them moves. This makes it impossible - for example - to blit the relocated window to the new position when moving it. The MS Windows "Desktop Window Manager" - since Vista - uses completely buffered client area redraws, which means Windows has a complete bitmapped copy of every window on hand at all times. This is how the taskbar thumbnails are produced, and how 3D "Flip" works. Naturally window moves are lightning fast using this method, but the storage overheads would be high on an 8-bit machine (we'd need to allocate 8KB per window in case it was maximized). Also, it's quicker for us - even with all the masking and clipping - to draw directly to the screen than to draw to a back buffer and then blit to the frame buffer. We would, however, reap the benefits when redrawing static back windows, and this is why I aim to make window caching an extra component which transparently kicks in when a lot of extended memory is detected. But the purist in me likes something which works on a 128KB machine... Note there's nothing at all stopping the application managing its client areas any way it likes: it could cache them itself and blit the information whenever it received a redraw message. Edited June 13, 2012 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
+DarkLord Posted June 14, 2012 Share Posted June 14, 2012 And I love how the the pointer doesn't flicker at all while windows are being redrawn... definitely +1 for us over the Mac and ST there. Hmm, flashjazzcat, can you tell me where you are seeing this on an ST? On my STacy, I can see some flicker when I'm moving a window, but not when it's redrawn. What I do get sometimes, if its an especially fast response/small update, is a flicker where the busy bee icon starts to come up, replacing the mouse pointer, but never actually gets there because the operation ends first.That's a system feature though (the busy bee icon for the mouse pointer during operations), not a flaw. Thanks! PS Its very cool that yours doesn't even flicker during window movement though. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 14, 2012 Author Share Posted June 14, 2012 (edited) Hmm, flashjazzcat, can you tell me where you are seeing this on an ST? Quite simply every time I open a menu or something is redrawing: the mouse pointer momentarily vanishes. It's because the OS removes the mouse pointer from the screen (necessarily) when things are being redrawn. It's a simple factual observation (verifiable by looking at the TOS source code). The routine that highlights menu items, on the other hand, is either masked or the operation is so fast that the flickering isn't noticeable. As soon as I started writing the mouse demo I ran into this issue myself (I had a "slow" masked screen render which drew "around" the mouse pointer after first freezing its position, and a fast pointer off - draw - pointer on routine). Thanks to andym00's idea and Popmilo's coding help, however, I was able to dispense with those old, flickery routines. PS Its very cool that yours doesn't even flicker during window movement though. It is, although - as I say - the idea of using a blocking DLI to simulate a hardware sprite was not mine. Edited June 14, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted June 14, 2012 Share Posted June 14, 2012 Fantastic work flashjazzcat, keep it up, its a real pleasure to see an ~1.8 MHz 6502 be able to perform this kind of work! Quote Link to comment Share on other sites More sharing options...
atari8warez Posted June 15, 2012 Share Posted June 15, 2012 When moving the window, there are momentarily two copies of the window you've moved ........... Hi fjc, just out of curiosity......when I watched your video carefully, I noticed that while you re-size a window, the old copy of that particular window momentarily drops behind other windows on the screen before it's actually erased all together. In other words, the screen is re-drawn giving other windows priority over erasing the old copy of the moved window. Is that intentional?. My brain tells me that the old copy of the moved window should have priority over other objects on screen when the screen is redrawn. Not a critisizim, just curiosity.... great work and a big achievement for the ol' 8 bit. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 15, 2012 Author Share Posted June 15, 2012 (edited) Hi fjc, just out of curiosity......when I watched your video carefully, I noticed that while you re-size a window, the old copy of that particular window momentarily drops behind other windows on the screen before it's actually erased all together. In other words, the screen is re-drawn giving other windows priority over erasing the old copy of the moved window. Is that intentional?. My brain tells me that the old copy of the moved window should have priority over other objects on screen when the screen is redrawn. Not a critisizim, just curiosity.... great work and a big achievement for the ol' 8 bit. When you understand what's happening during the redraw process, it shouldn't be too surprising that old bits of the resized window not obscured by any other windows are the last to disappear. Starting with the first window immediately behind the front window, we're redrawing only those objects which partly or wholly intersect with the old size and position of the resized window. So, if there were no other windows behind the bit of the front window which has been "trimmed off", that trimmed off section won't disappear until the relevant section of the desktop pattern is redrawn. You can't really ensure the defunct part of the window will disappear first by juggling the priority. Even if it were possible (using the chosen redraw system) to draw the desktop pattern first (thus getting rid of the old window bits immediately in the scenario you describe), you'd then find that if the resized window had another three windows directly behind it (as opposed to vacant desktop behind it), the old areas of the resized window would once again be the last things to disappear. It's like filling in bits of a jigsaw puzzle when a window moves or is resized. We're travelling back through the layers of windows, filling in the vacated space, which steadily shrinks as we head towards the rearmost layer (the desktop). Anyway - I hope that explanation makes some kind of sense. I don't mind being asked about this stuff at all. It's nice to know folks are interested! PS: As an afterthought, I'll mention that when we reach the stage at which each window has its own unique window mask (right now, there's a global window mask which each window has to redraw through before then next window's outline is added to the mask), we'll be able to draw all the non-cient areas and the desktop before looping around again and issuing client area redraw events. This will have the effect of making left-over window parts in front of the desktop vanish before the window contents update themselves. Edited June 15, 2012 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
atari8warez Posted June 18, 2012 Share Posted June 18, 2012 PS: As an afterthought, I'll mention that when we reach the stage at which each window has its own unique window mask (right now, there's a global window mask which each window has to redraw through before then next window's outline is added to the mask), we'll be able to draw all the non-cient areas and the desktop before looping around again and issuing client area redraw events. This will have the effect of making left-over window parts in front of the desktop vanish before the window contents update themselves. Sounds great, thank you for the detailed explanation Quote Link to comment Share on other sites More sharing options...
edward1469 Posted June 26, 2012 Share Posted June 26, 2012 I know the name thing is done but what about GEM/8 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 26, 2012 Author Share Posted June 26, 2012 I know the name thing is done but what about GEM/8 Where's the name thing done? I missed that meeting... seriously, people seem to think this thing's called Fuji-X... it ain't. Thanks for the suggestion, anyway. I've had a few more ideas myself (they seem to come to me when I'm pulled away from working on the GUI, as I am at the moment). Quote Link to comment Share on other sites More sharing options...
kogden Posted June 27, 2012 Share Posted June 27, 2012 You could as obnoxious as Apple and simply call it "System" and "Desktop" (Finder might get you sued) AGE - Atari Graphical Environment CartHAGE - Cartridge Hosted Atari Graphical Environment ROME/UI - ROM Environment / User Interface There's my contributions lol Quote Link to comment Share on other sites More sharing options...
WizWor Posted June 27, 2012 Share Posted June 27, 2012 I like ROME Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 27, 2012 Author Share Posted June 27, 2012 Yep: ROME/UI's good. AGE is already on the (long) list me and MrFish worked out last year, IIRC. Quote Link to comment Share on other sites More sharing options...
Carl_R Posted June 27, 2012 Share Posted June 27, 2012 Since I'm a bit new to Atari 8-bitters I have to ask, will this OS require some sort of extra hardware to be able to run? I have a 130XE. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 27, 2012 Author Share Posted June 27, 2012 Since I'm a bit new to Atari 8-bitters I have to ask, will this OS require some sort of extra hardware to be able to run? I have a 130XE. You'll need some sort of flash cartridge, and that's it. You already have the required RAM, although you'll want a memory upgrade if you intend to have lots of applications open at the same time. AtariMax 1Mbit or 8Mbit carts will do fine, as will Sic! carts or SIDEs. I have a RAM cart here which Steve Tucker made for me which I'm keen to use, and this would allow the GUI to run on a stock 48K machine. 1 Quote Link to comment Share on other sites More sharing options...
JamesD Posted June 27, 2012 Share Posted June 27, 2012 Since I'm a bit new to Atari 8-bitters I have to ask, will this OS require some sort of extra hardware to be able to run? I have a 130XE. You'll need some sort of flash cartridge, and that's it. You already have the required RAM, although you'll want a memory upgrade if you intend to have lots of applications open at the same time. AtariMax 1Mbit or 8Mbit carts will do fine, as will Sic! carts or SIDEs. I have a RAM cart here which Steve Tucker made for me which I'm keen to use, and this would allow the GUI to run on a stock 48K machine. Incognito boards should also support it then? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 27, 2012 Author Share Posted June 27, 2012 Incognito boards should also support it then? Sure - the RAM expansion is suitable for the GUI. Dunno if I'll get any ROM space on there (so we can have the GUI installed internally on the machine); I'd hoped for 64KB of Ultimate 1MB's flash ROM, but Candle found another use for it. Quote Link to comment Share on other sites More sharing options...
JamesD Posted June 27, 2012 Share Posted June 27, 2012 Incognito boards should also support it then? Sure - the RAM expansion is suitable for the GUI. Dunno if I'll get any ROM space on there (so we can have the GUI installed internally on the machine); I'd hoped for 64KB of Ultimate 1MB's flash ROM, but Candle found another use for it. Shame on him! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 27, 2012 Author Share Posted June 27, 2012 Shame on him! I can only assume that faced with the option of leaving that 64KB unused for another year or so or putting it to use today (for... ahem... "game" slots), he opted for the latter. 1 Quote Link to comment Share on other sites More sharing options...
Stormbringer Posted June 27, 2012 Share Posted June 27, 2012 Can you comment on what that use is and can we un-use it for the gui? lol Quote Link to comment Share on other sites More sharing options...
BillC Posted June 27, 2012 Share Posted June 27, 2012 Shame on him! I can only assume that faced with the option of leaving that 64KB unused for another year or so or putting it to use today (for... ahem... "game" slots), he opted for the latter. Hopefully he provides a flashing tool that will allow re-tasking that 64KB for use with the GUI once you release it. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.