GenesisPlus GX - UI and Ergonomic Modification

In general I am trying to modify the UI from genesis plus gx in order to have the same style as fceu gx, snes9x gx, vba gx.


[s1.directupload.net]

You can see already the problem in the picture.
I dunno how to change the order of the layers.
The selection bar should be under the arrow up and should be under the border of the selection list.

Another topic is the filelist itself.
I would like to add a list item at the top of the filelist which says "previous folder".
So I don't need the "B button" anymore, to return to the parent folder.

Last but not least I would like to know if I can add buttons into this file selection view.
I would like to shift between the buttons and the file list with the B button.

That's the main problems.
My source is the based on eke-eke 706 revision (filesel.c)
(http://code.google.com/p/genplus-gx/source/browse/trunk)
Maybe somebody can help (or has an idea to solve the issues)

static void selector_cb(void)
{
  int i;
  char text[MAXPATHLEN];
  int yoffset = 102; //Starlord: 108

  /* Initialize directory icon */
  gui_image dir_icon;
  dir_icon.texture = gxTextureOpenPNG(Browser_dir_png,0);
  dir_icon.w = dir_icon.texture->width;
  dir_icon.h = dir_icon.texture->height;
  dir_icon.x = 26;
  dir_icon.y = (26 - dir_icon.h)/2;


  /* Initialize selection bar */
  gui_image bar_over;
  bar_over.texture = gxTextureOpenPNG(Overlay_bar_png,0);
  bar_over.w = bar_over.texture->width + 1; //Starlord: extend the bar +1
  bar_over.h = bar_over.texture->height;
  bar_over.x = 10; //Starlord: 16
  bar_over.y = (26 - bar_over.h)/2;

  /* Draw browser array */
  // Starlord: doesn't fit to new UI
 
  /*
  gxDrawRectangle(15, 108, 358, 26, 127, (GXColor)BG_COLOR_1);
  gxDrawRectangle(15, 134, 358, 26, 127, (GXColor)BG_COLOR_2);
  gxDrawRectangle(15, 160, 358, 26, 127, (GXColor)BG_COLOR_1);
  gxDrawRectangle(15, 186, 358, 26, 127, (GXColor)BG_COLOR_2);
  gxDrawRectangle(15, 212, 358, 26, 127, (GXColor)BG_COLOR_1);
  gxDrawRectangle(15, 238, 358, 26, 127, (GXColor)BG_COLOR_2);
  gxDrawRectangle(15, 264, 358, 26, 127, (GXColor)BG_COLOR_1);
  gxDrawRectangle(15, 290, 358, 26, 127, (GXColor)BG_COLOR_2);
  gxDrawRectangle(15, 316, 358, 26, 127, (GXColor)BG_COLOR_1);
  gxDrawRectangle(15, 342, 358, 26, 127, (GXColor)BG_COLOR_2);
  */

  /* Draw Files list */
  
  for (i = offset; (i < (offset + 10)) && (i < maxfiles); i++)
  {
    if (i == selection)
    {
      /* selection bar */
      gxDrawTexture(bar_over.texture,bar_over.x,yoffset+bar_over.y,bar_over.w,bar_over.h,255);
	 
      /* scrolling text */
      if ((string_offset/SCROLL_SPEED) >= strlen(filelist.filename))
      {
        string_offset = 0;
      }

      if (string_offset)
      {
        sprintf(text,"%s ",filelist.filename+string_offset/SCROLL_SPEED);
        strncat(text, filelist.filename, string_offset/SCROLL_SPEED);
      }
      else
      {
        strcpy(text, filelist.filename);
      }

      /* print text */
      if (filelist.flags)
      {
        /* directory icon */
        gxDrawTexture(dir_icon.texture,dir_icon.x,yoffset+dir_icon.y,dir_icon.w,dir_icon.h,255);
        //if (FONT_write(text,18,dir_icon.x+dir_icon.w+6,yoffset+22,bar_over.w-dir_icon.w-26,(GXColor)WHITE))
        if (FONT_write(text,18,dir_icon.x+dir_icon.w+6,yoffset+22,bar_over.w-dir_icon.w-26,(GXColor)BLACK))
        {
          /* text scrolling */
          string_offset ++;
        }
      }
      else
      {
//        if (FONT_write(text,18,dir_icon.x,yoffset+22,bar_over.w-20,(GXColor)WHITE))
        if (FONT_write(text,18,dir_icon.x,yoffset+22,bar_over.w-20,(GXColor)BLACK))
        {
          /* text scrolling */
          string_offset ++;
        }
      }
    }
    else
    {
      if (filelist.flags)
      {
        /* directory icon */
        gxDrawTexture(dir_icon.texture,dir_icon.x,yoffset+dir_icon.y,dir_icon.w,dir_icon.h,255);
		//FONT_write(filelist.filename,18,dir_icon.x+dir_icon.w+6,yoffset+22,bar_over.w-dir_icon.w-26,(GXColor)WHITE);
        FONT_write(filelist.filename,18,dir_icon.x+dir_icon.w+6,yoffset+22,bar_over.w-dir_icon.w-26,(GXColor)BLACK);

      }
      else
      {
        //FONT_write(filelist.filename,18,dir_icon.x,yoffset+22,bar_over.w-20,(GXColor)WHITE); 
	    FONT_write(filelist.filename,18,dir_icon.x,yoffset+22,bar_over.w-20,(GXColor)BLACK);
      }
    }

    yoffset += 26;
  }

  gxTextureClose(&bar_over.texture);
  gxTextureClose(&dir_icon.texture);
}  

Edited 5 time(s). Last edit at 07/29/2012 09:37PM by Paperman.

The rule is actually very simple: what you render first appears at the bottom "layer" so you want to render the overlay bar before the vertical ladder on the right.

Anyway, if you ever get anything out of this mess and decide to release it, the only thing i would ask is that you don't bump the version number like you did in the past and clearly identify this as a "mod" of current version. I don't really understand this need for uniformizing everything or trashing original work already done (and actually think my GUI looks nicer and has much more originality/personality than the other "GX" ones) but I guess there is nothing I can do against users preferences, just that i would like to keep control on the official version for "real emulation" changes.



Edited 1 time(s). Last edit at 07/30/2012 05:51PM by ekeeke.

Quote
ekeeke
The rule is actually very simple: what you render first appears at the bottom "layer" so you want to render the overlay bar before the vertical ladder on the right.

Anyway, if you ever get anything out of this mess and decide to release it, the only thing i would ask is that you don't bump the version number like you did in the past and clearly identify this as a "mod" of current version. I don't really understand this need for uniformizing everything or trashing original work already done (and actually think my GUI looks nicer and has much more originality/personality than the other "GX" ones) but I guess there is nothing I can do against users preferences, just that i would like to keep control on the official version for "real emulation" changes.

That's for sure. ^^
I am going to rename the emulator and to do a separate version.

Really, I love your emulator extremely.
However concerning usability and user flow, the other ones are a little bit better.
I really like simple and quick flows.

Sometimes the ergonomic realization is not really consistent (from my point of view).
For example: In the whole UI it's possible to go to the previous screen with the B button.
But in the file selection you have to use the z trigger or the Home button.
These are small things, but it makes the emulator better (at least for me ^^).


Btw back to the problem:
That's what I already thought (FiFo Renedering). However is it possible to insert the selection bar into the gui_menu declaration? For example as a button?

static gui_menu menu_selector =
{
  "Game Selection",
  -1,-1,
  0,0,15,0,
  NULL,
  NULL,
  bg_filesel,
  {NULL,NULL},
  {&arrow_up,&arrow_down},
  selector_cb
};

Edited 2 time(s). Last edit at 07/30/2012 06:43PM by Paperman.

Quote
Paperman
I am going to rename the emulator and to do a separate version.

It will still be a mod, not a separate version. The core will still be Genesis Plus GX and the name of the emulator should not be changed or advertised as a brand new emulator when it it's just packaging redesign.

Quote

Really, I love your emulator extremely.
However concerning usability and user flow, the other ones are a little bit better.
I really like simple and quick flows.

Sometimes the ergonomic realization is not really consistent (from my point of view).
For example: In the whole UI it's possible to go to the previous screen with the B button.
But in the file selection you have to use the z trigger or the Home button.
These are small things, but it makes the emulator better (at least for me ^^).

How is that "quicker" to browse previous directory by always have to go to the top of the ROM window to select the "previous directory" option ? It's actually faster and more natural to use A/B button to navigate through folders, especially since most of the time when you enter ROM directory, that's what you are going to do and rarely exit the browser without having loaded any ROM (?).The Z/HOME button is just a shortcut for this rarely used case and I think this is actually a better design this way. You can say that you are more used to other "gx" emulator's way of doing but saying they are more ergonomic is not true at all, I actually spent lot of time working on the GUI because of that.

Quote

Btw back to the problem:
That's what I already thought (FiFo Renedering).

That's not "fifo rendering", that's the way GX rendering works. Think about it as a piece of paper your draw on. Obviously, what you drawed "first" will be overwritten by what is last written. Really, this is a very simple framebuffer concept.

Quote

However is it possible to insert the selection bar into the gui_menu declaration? For example as a button?

static gui_menu menu_selector =
{
  "Game Selection",
  -1,-1,
  0,0,15,0,
  NULL,
  NULL,
  bg_filesel,
  {NULL,NULL},
  {&arrow_up,&arrow_down},
  selector_cb
};

You can do anything you want, each "menu" can have a list of background images, a list buttons which are themselves associated with images. You only give pointers to these lists in the menu structures, those pointers pointing to the actual images or buttons with their position, size, effects, etc...
The gui functions (gui.c, gui.h) should be pretty much self-explainable. However, do not expect what you want to achieve to be as simple as changing a few things in the existing code. You might be better rendering everything from scratch using libwiigui, in which case, good luck ^^

Quote
ekeeke
[
It will still be a mod, not a separate version. The core will still be Genesis Plus GX and the name of the emulator should not be changed or advertised as a brand new emulator when it it's just packaging redesign.

You are right. Maybe I was not clear. If I am going to release the new UI then it will be clearly marked as mod.
Credits to you. ^_^

Quote

How is that "quicker" to browse previous directory by always have to go to the top of the ROM window to select the "previous directory" option ? It's actually faster and more natural to use A/B button to navigate through folders, especially since most of the time when you enter ROM directory, that's what you are going to do and rarely exit the browser without having loaded any ROM (?).The Z/HOME button is just a shortcut for this rarely used case and I think this is actually a better design this way. You can say that you are more used to other "gx" emulator's way of doing but saying they are more ergonomic is not true at all, I actually spent lot of time working on the GUI because of that.

Well, the ergonomic design is different at all.
To be honest, you are not that far away from the other "gx" emus concerning the ui flow and behavior.
Your code is great with regard to UI rendering. So I am completely aware you spent a lot of time into the UI. However some aspects are disturbing. (another example would be the home button for the wii. Why isn't it possible to close the UI with the home button if a user started the emulation. He has to return to the root menu in order to close the menu).
It's more a matter of opinion which is the better UI flow.

Quote

That's not "fifo rendering", that's the way GX rendering works. Think about it as a piece of paper your draw on. Obviously, what you drawed "first" will be overwritten by what is last written. Really, this is a very simple framebuffer concept.

Correct me if I am wrong but I thought this is exactly fifo (first in first out). So the first thing you are initiating or requesting is the first thing which is appearing on screen.
You could do the opposite as well. The last image which is initiated/requested is the first thing on screen.
There are different methods of UI realizations. Another one would be to initiate/request all images at once and to assign it afterwards to different fixed layers.

I have to find a way to draw the arrows after the selection bar. But I dunno how to draw the buttons independent of the menu (in this case gui_menu menu_selector). So I always have to assign buttons to a menu in order to draw and use them.

Quote

You can do anything you want, each "menu" can have a list of background images, a list buttons which are themselves associated with images. You only give pointers to these lists in the menu structures, those pointers pointing to the actual images or buttons with their position, size, effects, etc...
The gui functions (gui.c, gui.h) should be pretty much self-explainable. However, do not expect what you want to achieve to be as simple as changing a few things in the existing code. You might be better rendering everything from scratch using libwiigui, in which case, good luck ^^

Yeah, that's true. Much appreciate your work! To repeat myself: you did a great and fantastic job concerning the UI (especially in C).
I want to stay in C. libwiigui has the problem concerning the combination of C and C++.
So it would be more work to find the interfaces in your C code in order to align the code in C++.

As already said. Your design is very close to the general "gx" design.
I will keep some aspects because I like how you realize it.

But anyway I am little bit surprised about some parts in your code.
You already defined some filters and sorter.

static int FileSortCallback(const void *f1, const void *f2)
{
  /* Special case for implicit directories */
  if(((FILEENTRIES *)f1)->filename[0] == '.' || ((FILEENTRIES *)f2)->filename[0] == '.')
  {
    if(strcmp(((FILEENTRIES *)f1)->filename, ".") == 0) { return -1; }
    if(strcmp(((FILEENTRIES *)f2)->filename, ".") == 0) { return 1; }
    if(strcmp(((FILEENTRIES *)f1)->filename, "..") == 0) { return -1; }
    if(strcmp(((FILEENTRIES *)f2)->filename, "..") == 0) { return 1; }
  }
  
  /* If one is a file and one is a directory the directory is first. */
  if(((FILEENTRIES *)f1)->flags && !((FILEENTRIES *)f2)->flags) return -1;
  if(!((FILEENTRIES *)f1)->flags  && ((FILEENTRIES *)f2)->flags) return 1;
  
  return stricmp(((FILEENTRIES *)f1)->filename, ((FILEENTRIES *)f2)->filename);
}

So in general you are already modifying the list but it's not used.
Also the filters (gui_menu menu_load) for the cartridges can be used to filter the games inside the folder.
But I believe you will activate/implement this feature in a later release. :-)

Quote

Correct me if I am wrong but I thought this is exactly fifo (first in first out). So the first thing you are initiating or requesting is the first thing which is appearing on screen.
You could do the opposite as well. The last image which is initiated/requested is the first thing on screen.
There are different methods of UI realizations. Another one would be to initiate/request all images at once and to assign it afterwards to different fixed layers.

You didn't understand, this is not because of the UI design, this is the way the hardware works. What is rendered last in the framebuffer (efb) always appears on top.

Quote

I have to find a way to draw the arrows after the selection bar. But I dunno how to draw the buttons independent of the menu (in this case gui_menu menu_selector). So I always have to assign buttons to a menu in order to draw and use them.

There is a simple function to render single images, externally from common menu rendering. But the arrows are part of the menu rendering. If you want to add a moving ladder like in libwiigui, you must code it yourself.

Quote

But anyway I am little bit surprised about some parts in your code.
You already defined some filters and sorter.

So in general you are already modifying the list but it's not used.

Not seeing what is so surprising. This is actually code sent from someone else that is used to sort files alphabetically. And yes it is used, and it only filters "." and ".." file entries (this might already be done elsewhere, but as i said, this is the code i was sent and i reused it without modifying it)

Quote

Also the filters (gui_menu menu_load) for the cartridges can be used to filter the games inside the folder.
But I believe you will activate/implement this feature in a later release. :-)

No, i won't. You cannot guess the filetype if the rom is zipped (and you don't want to unzip each listed file to know the uncompressed filename extension because this would be slow as hell). I don't want to filter "supported" file extensions because mega drive ROM files already have multiple existing ones and it seems like people are inventing new ones every full moon, so i don't want to have to keep a supported list up-to-date or dealing with complaints of users not seeing their last downloaded romset. It's up to you to arrange your files correctly, with each system to its own folder/subfolders.