flashjazzcat Posted December 14, 2014 Author Share Posted December 14, 2014 If only it wrote and debugged itself as fast as it runs, but I'm glad to hear it still looks reasonably quick. 1 Quote Link to comment Share on other sites More sharing options...
Mr.Amiga500 Posted December 14, 2014 Share Posted December 14, 2014 Gee, I noticed that this thread is 5 year old today! I didn't know if you were into traditional or modern gifting so here's both. Repeating that made me think of this: 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 14, 2014 Author Share Posted December 14, 2014 Is it a national preoccupation? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 17, 2014 Author Share Posted December 17, 2014 (edited) Scroll bar finally actually does what it's supposed to: I've turned off the auto-refresh of the process list here since unwanted periodic redraws don't look too good right after you've let go of the scroll bar and the thing has just redrawn anyway. I'll implement some kind of flag so that the application knows the list has just updated itself so it can reset its sleep timer. I'm toying with the idea of trying live scrolling content once I start using the blitter for scrolling lists (which I'm not doing yet), although I have no idea whether it would look good or not. Not much left to add. Edited December 17, 2014 by flashjazzcat 7 Quote Link to comment Share on other sites More sharing options...
+Ripdubski Posted December 17, 2014 Share Posted December 17, 2014 Awesome work! Not sure if you noticed this or not, but the Fuji menu has "Task Manager" which launches "Profiler". I know there was debate at some point and I thought you ended up at Profiler. Anyway, this is not to spark the debate, but rather to point out the discrepancy so you can fix one or the other. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 17, 2014 Author Share Posted December 17, 2014 Not sure if you noticed this or not, but the Fuji menu has "Task Manager" which launches "Profiler". I know there was debate at some point and I thought you ended up at Profiler. Anyway, this is not to spark the debate, but rather to point out the discrepancy so you can fix one or the other. Quite right - the naming strategy is without rhyme or reason. Quote Link to comment Share on other sites More sharing options...
Prodatron Posted December 17, 2014 Share Posted December 17, 2014 Very cool What does "Live scrolling" mean? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 17, 2014 Author Share Posted December 17, 2014 Very cool What does "Live scrolling" mean? It's my term for the list content scrolling while the thumb is being dragged. Quote Link to comment Share on other sites More sharing options...
fibrewire Posted December 18, 2014 Share Posted December 18, 2014 It's my term for the list content scrolling while the thumb is being dragged. Is smooth scrolling possible on byte boundaries? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 18, 2014 Author Share Posted December 18, 2014 Is smooth scrolling possible on byte boundaries? It doesn't matter on the vertical plane, but we can now blit by pixel on the horizontal plane too. Nothing's bound to bytes now. 3 Quote Link to comment Share on other sites More sharing options...
Prodatron Posted December 18, 2014 Share Posted December 18, 2014 It's my term for the list content scrolling while the thumb is being dragged. Oh I see! Phew, that would be cool! But then I want live window dragging, too! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 18, 2014 Author Share Posted December 18, 2014 (edited) Oh I see! Phew, that would be cool! But then I want live window dragging, too! I can't see it working well for anything but lists, and even that might not look good, but it's worth a try for a laugh. Edit: for live window drags, check out a very late version of TOS for the Atari ST. Remarkably, it blitted the front window while dragging, and issued redraw events to the back windows on the fly. The result was... interesting, even with a hardware blitter. It's called SuperTOS: http://www.atari-forum.com/viewtopic.php?f=14&t=16398 Edited December 18, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 18, 2014 Author Share Posted December 18, 2014 (edited) Got the blitted scrolls working: I'm pleased with the speed and smoothness, although this is not reflected in YouTube's rendition. Those pauses while the top/bottom of the list is filled in do not happen in actuality. Note the list snaps to list entries (rather than allowing arbitrary positioning with - say - the top of the first line chopped off). This is the way SymbOS works too, and is why the scroll thumb sometimes "snaps" back when it's released: that's the list homing in on the nearest full text line offset. Either way would be good, I guess. I think "live" scrolling would work pretty well - as an option, at least (although I need to isolate the list body and scroll bar rendering code for this to be attempted) - but it would be pretty inconsistent with the rest of the UI (harking back to what Prodatron light-heartedly said about full window drag, which will NOT happen ). Anyway: plenty of time to play around later on. Gotta make sure these blits clip to the screen properly, then think about what else can be done in the limited time available. Just looked back through some of the YT videos and noticed that the first cartridge build didn't get a first test until the beginning of August, and we've covered a hell of a lot of ground since then. Edited December 18, 2014 by flashjazzcat 5 Quote Link to comment Share on other sites More sharing options...
Prodatron Posted December 18, 2014 Share Posted December 18, 2014 Note the list snaps to list entries (rather than allowing arbitrary positioning with - say - the top of the first line chopped off). This is the way SymbOS works too, and is why the scroll thumb sometimes "snaps" back when it's released: that's the list homing in on the nearest full text line offset. Either way would be good, I guess. I choosed this way as somehow it looks strange, if the first line is chopped of. Maybe it's because Windows did it/is still doing it like this in most cases as well. I think "live" scrolling would work pretty well - as an option, at least (although I need to isolate the list body and scroll bar rendering code for this to be attempted) - but it would be pretty inconsistent with the rest of the UI (harking back to what Prodatron light-heartedly said about full window drag, which will NOT happen ). Anyway: plenty of time to play around later on. Haha, ok! I couldn't find a video about this SuperTOS, but I can imagine that it's just too much Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 18, 2014 Author Share Posted December 18, 2014 (edited) I choosed this way as somehow it looks strange, if the first line is chopped of. Maybe it's because Windows did it/is still doing it like this in most cases as well. I forgot how Windows handled it, but I'm in OS X (10.6.8 ) ATM and that DOES allow chopped off lines. I just followed SymbOS. Doing it the OS X way will require a slightly different way of recording the list position in the list header record (pixel offset instead of item offset). I'll try it, though; see how it looks. Edited December 18, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Prodatron Posted December 18, 2014 Share Posted December 18, 2014 These little details are always interesting, usually you never take care of them I just had a look: Most lists in Windows don't allow chopped off lines at the top. Some even don't show chopped off lines at the bottom! Some show them. And some lists even allow chopped lines at the top In SymbOS the multiline textinput control allows chopped off lines at the top, too, but the list control won't. As you mentioned it would require changes in the control data record, too... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 19, 2014 Author Share Posted December 19, 2014 Yes: trying out different UI subtleties is a lot of fun, but I try not to get too sidetracked at the moment since there is so much to do. But that "polishing" stage, when software is basically working and debugged is really great. Can't wait for that. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 24, 2014 Author Share Posted December 24, 2014 (edited) List box control finished now, with all the bugs worked out: http://youtu.be/ZUOsaT8-zjA I swear I keep trying to scroll that list with the scroll wheel on the mouse... Unfortunately the downloadable demo was set back a few days at the weekend after I came down with food poisoning or the winter vomiting bug (hard to tell which, since - for what will be the last time in my life - I'd eaten Scampi for dinner) and I'm still somewhat becalmed by the after-effects... to the extent I sat at home coding this evening instead of drinking in the pub. In any case, I want to add (read: debug) a few more things before I upload some ROMs here, and I'll need to send it to MrFish first, although he - like most people - will probably have better things to do than test GUIs for the next few days at least. Source code line count has now exceeded 27,000... meanwhile, I hope I can develop some kind of appetite for Christmas dinner. Edited December 24, 2014 by flashjazzcat 9 Quote Link to comment Share on other sites More sharing options...
jacobus Posted December 24, 2014 Share Posted December 24, 2014 Looks awesome Jon! I hope you're feeling better soon! 3 Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted December 25, 2014 Share Posted December 25, 2014 We call that the Stomach Flu here in the states. I went through that a month or so back. It's no fun at all. Try to enjoy Xmas as best you can! Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted December 25, 2014 Share Posted December 25, 2014 Get well soon. And make sure to be "becalmed" on "the throne". Not around it, right on top of it, so the ill effects (codename "turds" ) can all be neatly collected and flushed away. Merry and smelly Xmas to all. Quote Link to comment Share on other sites More sharing options...
Prodatron Posted December 27, 2014 Share Posted December 27, 2014 harking back to what Prodatron light-heartedly said about full window drag, which will NOT happen Are you 100% sure? I was really curious and just made a little test: There is no blitter function for window moving in SymbOS, so they are always completely repainted. I think it looks quite ok and in reality it's even better. With a blitter routine it could be even better, at least for all more complex windows. I can't see it working well for anything but lists, and even that might not look good, but it's worth a try for a laugh. Edit: for live window drags, check out a very late version of TOS for the Atari ST. Remarkably, it blitted the front window while dragging, and issued redraw events to the back windows on the fly. The result was... interesting, even with a hardware blitter. It's called SuperTOS: http://www.atari-forum.com/viewtopic.php?f=14&t=16398 Is there a video about this available? I couldn't find something... 3 Quote Link to comment Share on other sites More sharing options...
+Ripdubski Posted December 27, 2014 Share Posted December 27, 2014 Interesting that the full window redraw while moving works as well as it does above. Although slightly jumpy, it works. That said, I would rather see just the frame being moved to favor precision in movement. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 27, 2014 Author Share Posted December 27, 2014 (edited) Are you 100% sure? I was really curious and just made a little test: https://www.youtube.com/watch?v=n5D13-CXL2s Wow! I first watched this on my smartphone and couldn't wait to get home to see how it would look on the Atari. Having lacked energy all week, well - you just reminded me why this project is FUN. There is no blitter function for window moving in SymbOS, so they are always completely repainted. I think it looks quite ok and in reality it's even better. With a blitter routine it could be even better, at least for all more complex windows. The redraw speeds in SymbOS are remarkable, especially given the bit depth used. Certainly blitting the windows is worth looking into. The Atari is using the new blitter in the video, although I'm careful not to move the window off the desktop since that will trigger a full window redraw (which doesn't look too bad anyway, as you point out). What should really happen anyway is that fragments of partially off-screen windows are blitted to the desktop and only the newly revealed parts redrawn. I guess some extra code to generate the right update regions will do the job fairly simply. EDIT: actually I was mistaken. I do trigger full redraws in places, and they're fast enough that at first I didn't notice. Rest assured the old ghost-drag method is preserved; it'll be user-selectable. Now... dare we attempt live window resizing too? Is there a video about this available? I couldn't find something... I couldn't find anything either for the moment, but I spent most of this evening reinstalling my OS so aside from thirty minutes coding, I didn't have much time. Edited December 27, 2014 by flashjazzcat 6 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 27, 2014 Share Posted December 27, 2014 I am not worthy... Quote Link to comment Share on other sites More sharing options...
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.