Jump to content
IGNORED

New GUI for the Atari 8-bit


flashjazzcat

Recommended Posts

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 by flashjazzcat
  • Like 7
Link to comment
Share on other sites

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. ;)

  • Like 1
Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

Oh I see! Phew, that would be cool! But then I want live window dragging, too! :P

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 by flashjazzcat
Link to comment
Share on other sites

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 by flashjazzcat
  • Like 5
Link to comment
Share on other sites

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 :P

Link to comment
Share on other sites

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 by flashjazzcat
Link to comment
Share on other sites

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 :D

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...

Link to comment
Share on other sites

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 by flashjazzcat
  • Like 9
Link to comment
Share on other sites

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...

  • Like 3
Link to comment
Share on other sites

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. :D

 

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? :D

 

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 by flashjazzcat
  • Like 6
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...