Hi everyone! Well, the first deadline has been approached! I’ll look over the code in the following two days, changing a couple of function-names and adding a few comments here and there and cleaning up the commit history before compiling a pull request containing everything I’ve mentioned working on on the blog, and some other minor stuff. I’ll see if I’ll include the game-selection widget with cover-art in that pull request, even though it is mostly done, the biggest reason for not including it is that there is no support for it in the theme itself – so either I’ll hack together a makeshift touch-theme, or I’ll keep it in a separate branch for inclusion when the touch-based theme mockups are finalized and started being worked on.
Author: Administrator
Hi all!
Slowly we are approaching the soft deadline for GSoC! The last couple of days I’ve been working on populating a scrollable canvas with game-boxart, as a grid. Right now, what it does is that it loads a bitmap with the gameid as filename, and puts it there. The plan is to get it to work flawlessly by the 16th, a.k.a. the soft deadline. After that, I’ll work on commenting the code and fixing up bugs etc, until the date of the firm pencils down-date. Anyway, that’s all for now, hopefully I’ll have an in-action video showing it running on android in a couple of days 
.
Hi everyone,
Just a super quick and small update: Last week was schools exams-period, so I didn’t get as much work done as usual (as was expected beforehand). I’ve been working a bit on implementing the scrollbars, and creating the horizontal one. Hopefully I’ll have them done and working pretty soon (i.e. by tomorrow)! Then I’ll go about doing the other things mentioned in my previous post.
’till next time!
Hello again!
This post I think I’ll try to explain a bit more into detail what has been done code-wise, regarding the touch-based interface, since I probably won’t do any significant changes at this point:
Firstly, we needed a way for the widgets to handle touch-events: in ScummVM widgets and dialogs have the function handleMouseDown which is called upon the active dialog when we detect a mouse-down event (EVENT_LBUTTONDOWN), for example. Now, all we do is change up the Android, iPhone etc. codes to instead of simulating mouse-clicks and movements, use new events for finger-taps, and create new functions using these (Currently, in my branch, only code for Android is present). “Hold it!” you might say, “this will break the games, since they expect mouse movements!”. Fear not! This is where the “touchmapper” comes into play. It is an EventManager that listens for touch-events and injects their counterpart mouse-events, if we are currently in a game (here, we have two modes, touchpad-mode and direct input-mode – in scummvm-master, this is the responsibility of each port, now it has been moved into this more general place). There are still some things needed to be addressed here though, such as right-clicking – certain ports probably want to implement right-clicking in different ways (i.e. a port maybe wants two finger-tap, while another doesn’t have support for multitouch or has hardware modifiers that can be mapped..).
With our new touch-events, the widgets can respond and set their states accordingly. There is also a new widget, a scrollable canvas, which can be dragged in all four directions, and in which other widgets can be drawn, while still being “interactable”. This is achieved in a similar fashion as the partial text-drawing: The scrollable canvas has a “drawable area”, or a viewport, which is usually its bounds in x and y. It then applies the same viewport to its children, and if they are drawn in a viewport that makes certain parts of them outside it, they are redrawn on a separate buffer and blitted back, but only the contents that are inside of the viewport, and if it is outside we skip drawing it altogether.
Now, when a finger is dragged across the container, loop through it’s children and set their position according to the movement. Currently, we need to redraw all of its children after a movement: In ScummVM-master, what is done is that all widgets are pre-rendered and put into a buffer – and when e.g. a mouse cursor is hovered over a button we redraw it in a hovered state, and when it is withdrawn we restore the contents of the buffer. Since we set the position of widgets we can’t do this, and therefore need to skip committing widgets in movable containers to the buffer for now. I will try to explore other ways of doing this in order to get some performance gains, but this is a relatively clean solution.
Anyway, that is the current state of the code in my branch. A small todo list now would be to:
- Explore solutions to the above mentioned points.
- Allow scrollbars for the scrollable canvas, create a vertical scrollbar.
- Create functions to populate the scrollable canvas with pictures for games.
- Fixing up bugs! (for some reason, dragging on a list sometimes causes it to spazz out, also, sometime ago I seem to have broken tapping on dialogs, such as the About-dialog and Popup-widgets. Whoops :/ ).
- Adding inertial scrolling (this seems to be easy enough for the android port, since we can get the velocity of a flick directly from the API, however, I am unsure how this would be implemented in other ports).
- And some small things such as: adding selection of direct-input and touchpad mode in menus (with possibility of changing sensitivity), adding some #ifdef’s for the touchmapper etc.
Anyway, that’s all for now!
Hello, fellow readers!
What has been done since my last post: Like mentioned, the widgets have been adapted to listen to input from touch: right now they can listen to one finger up, one finger down and swiping with one finger. That means one now can scroll lists, such as the list of saves or folders, by dragging the finger over them, and the selection follows the finger perfectly, altough, there is no inertial scrolling right now. To accomplish smooth scrolling, I’ve added some commits from the previous GUI-Improvements, the partial text-rendering from before.
Also, there has been some work on a ScrollableCanvas-widget. It basically functions the same as the partial text-rendering – altough there had to be a lot of changes to make this work, since widgets in master always draw directly on the screen’s surface. Now it is possible to draw them on a separate surface, to only render parts of them.
Hopefully, by the end of this week, I’ll have the scrollable-canvas working (that is, actually make it scrollable!) flawlessly. Picture-Widgets also need to be adapted to work with this widget (right now, only buttons work).
After that is done, there will be a lot more questions to tackle – in the mockups, the touch-based UI has a scrollable canvas with pictures representing each game. The scollable canvas needs to be populated with these pictures – probably these need to be supplied by the user. But I’ll tackle this problem when I get to it!
Until next time!
Hi everyone!
I’ve been away for a couple of days and haven’t been able to write a blog post, but now I suppose is a good time. The last couple days I’ve been working on refactoring gesture-code, so that the new (and old!) widgets can respond to gestures without resorting to ugly hacks and such.
The way this is implemented (currently, subject to change!) is by a couple of new events, such as EVENT_FINGERMOVE, EVENT_TAPDOWN, EVENT_TAPUP etc. The events are also associated with one or more “fingers”, which contain information about the current position of each finger which is tracked, thereby enabling widgets at certain places to respond to when a finger is tapped on them (right now I’m “reusing” the handleMouseDown-function each widget has, but the plan is of course to add a “handleFingerDown”, “handleFingerMove” and similar functions). Currently, I’ve coded support for these new events in the android port, but other ports should be trivial to add. Also, now, since games still rely on mouse events, I’ve had to create an event listener and injector, a “TouchMapper”, where all code regarding movement of the cursor in game has been refactored into (right now, one can either use direct mode or “touch-pad mode”-where dragging over the screen will move the cursor like a touch pad, tapping the left area will simulate a left click and the right area a right click).
As usual, code can be found in my repository. Anyways, that’s all for now!
Hi everyone!
Whoops, I now realized I never made that post about gestures, I was too busy fixing up the remaining code to work with it . First a small recap of progress since last week: I’ve made a pull request regarding the various GUI-improvements, as can be seen on https://github.com/scummvm/scummvm/pull/361 . Also I’ve worked a bit on the other pull-request, the new version of the code in the backend checks if 32-bit is wanted (by a flag in the config file, as before), and sets the bit-depth accordingly.
As for midterm, the 32-bit code and the GUI-improvements, especially the gradient effect on the bevels, took a bit longer than expected. What’s next is to create widgets for the new touch-based theme, before working on the theme itself. From the current mockups, it seems like a scrollable canvas-type widget needs to be implemented, and also some kind of picture-button class. These need to be able to respond to gesture-events, and the other “old” widgets also need to be able to respond to these events. After that is done, work on the new theme can commence.
Until next time!
Hi everyone!
The last week I’ve been busy working on the 32-bit mode, and submitting it as a pull request. What I did before submitting it was essentially reworking it from the ground up, removing the function setOverlayFormat, which I mentioned in the previous update, and just relying on the function setScreenFormat/( to change format on-the-fly. The request, and also a short description of what the code essentially does, can be found at https://github.com/scummvm/scummvm/pull/359 .
I got some comments on my implementation and will probably rework it quite a bit. Some changes that might be done are:
Since setScreenFormat doesn’t really use the format it is called with (it initializes a new surface and takes its properties from that), the function might be better suited to take in just the BPP which is preferred.
Of course, some cleanup, fixing formatting and such.
In order to avoid ugly if-conditions, I’ll probably split up the GraphicsMode (which currently is specified like kGfxAntialias16bit, kGfxStandard32bit and so on) into two, that specify the rendering used and the bit-depth used. Also, this will probably change setting in the configuration-file.
Furthermore, some other work on the GUI has been done, such as adding gradients to the bevels of the buttons and refactoring the code.
What I’ll get working on more during this week are gestures (swipes and such) on touch-screen based devices. I was originally planning on writing more about the general plan and outline in this blog-post, but I’ll probably do that in a day or two!
Hi everyone!
Now when the switching between the 16-bit and 32-bit mode in the GUI is almost done, I’m going to write a longer blog post detailing the design, decision and implementation of the feature.
Some background: In the scummvm-master branch, the SDL-renderer for the GUI has a hardcoded bit-depth of 16-bits in some places. My intention has been to “un-hardcode” this, replacing the constants into variables that depend on the bit-depth set, so that arbitrary bit-depths can be used (although the code is focusing on 32-bits right now). The difference between 16 and 32 bits in the GUI can, as an example, be seen in the picture below, with the 32-bit rendering giving a nicer gradient, especially on the buttons – without having to resort to dithering:
(Editor’s note: unfortunately, the image that was included here is lost and not available on archive.org)One of the problems one runs into with switching to a 32-bit surface is that it does break games and scalers used, which assume a 16-bit surface is being used. To remedy this problem, my current solution involves switch back to a supported 16-bit format (using a new function setScreenFormat) when running a game from the launcher, and then switching back to the old 32-bit format used (using the new function setOverlayFormat) if the player enters a menu while playing, or re-enters the launcher.
This solution seems to work pretty fine, and only a couple of things need fixing now:
- There is a bug regarding the color of the cursor when running 32-bits,
- The background when entering the in-game menus renders incorrectly due to the switch between the different formats,
- Swapping the theme seems to mess up the rendering for some reason?
As usual, the code can be found on my GitHub-page !
Hi everyone!
The last couple of days I’ve been working on fixing up the 32-bit support in the GUI, which should be mostly done in a couple of days, what’s left is a minor cursor-bug and selection of the 32-bit renderer in the GUI. We’ve also defined a couple of mid-term goals. These are:
- Switching between 32-bit and 16-bit renderer
- Change widgets to look more like the mockups ( https://github.com/scummvm/scummvm-media/tree/master/originals/gui )
- Refactor gesture-code
Also, the mockups for the touch-based GUI should arrive soon!