[Help/Suggestions needed] MultiTasKing v101

[carl0sgs]

Hi guys!
I came here a few months ago under the username "usertestprueba" (xD) and thanks to your help I have managed to get this:

http://www.youtube.com/watch?v=jDLfzjE--qg

I just want to know what do you think about it :-)
Please, suggest things, and checkout the prx sources ;-)

Thank you very much for your help.

Cheers,
Carlosgs

[anmabagima]

Hi,

this really looks amazing. You are starting porting Windows onto PSP ?
Good stuff. I hav't seen the source...the result looks nice ;o)

[carl0sgs]

Hi,

this really looks amazing. You are starting porting Windows onto PSP ?
Good stuff. I hav't seen the source...the result looks nice ;o)

It is not windows, it is my own window manager :-)
Thanks for the support ;-)

[m0skit0]

Nice job :)

[carl0sgs]

Nice job :)

Thanks! :-D

[liberty]

Hi guys!
I came here a few months ago under the username "usertestprueba" (xD) and thanks to your help I have managed to get this:

http://www.youtube.com/watch?v=jDLfzjE--qg

I just want to know what do you think about it :-)
Please, suggest things, and checkout the prx sources ;-)

Thank you very much for your help.

Cheers,
Carlosgs

Really good. A wonder window manager. How about some widget tools?

[carl0sgs]

Really good. A wonder window manager. How about some widget tools?

Thanks! :-)
What do you mean with widget tools?

[Raphael]

A library that provides a list of GUI elements (sometimes called 'widgets'), like buttons, checkboxes, textboxes, menus, etc.

[carl0sgs]

Oh ok then xD

I've thought about that, but still don't have a clear idea of how to make it :-S
By now it is possible to use the common graphics.h printing functions in the windows (enough for simple programs).

If you have any idea on how to make that, it would be really useful :-P
Thanks!

[ne0h]

--- nevermind ---

[Ameen]

Wow, if you would add more to it, I pretty much believe you can end up with some decent project for the PSP community.

You rock!
Cheers,

[carl0sgs]

Hi again!
So I've been thinking about how to implement widgets ;-)

I have the idea, (i've added simple buttons support) and now I just need some speed.

Here is a screenshot:



(The buttons keep count of the times they've been pressed)

I need your help and suggestions:
I want to use OSLib, because it uses the GU (graphics.h is too slow) and it is possible to use intrafont in a fast way, rotate images...

So, my idea is to have in each window a list (doubily linked) with each image, each button... etc, each element of the API.
In the background I'd add just a color.

Then, when refreshing the screen, the program would go through the windows list, and in each window it'd look into the API list, and print all the stuff.

Oh, and the main thing is to use "sceGUscissor" to set the drawing area in each window, limiting everything correctly ;-)

The problem comes when I want to print something into an image, cause OSLib requires the GU (graphics.h uses software only for this, that's why it is slow here).

I have not much experience with OSLib, so some help would be really appreciated.

Thanks a lot :-)

[sauron_le_noir]

Don't mix gu and mod_osl, do all the stuff with mod_osl
a sample menu choice with image + text
if you use c++ you can do a class per object earch object has a render method
all the object you created are put in a linked list for earch event you put the messageto the object that have subscibe to receive the event. Each object is responsible to
render is image. Look at the code of a old homebrew fileassistant it is what you want
to do and it use gu and not osl ;)

Code: Select all

while (!osl_quit)
  {
 //Doit on faire le rendu?

    if (!skip)	
      {
         oslStartDrawing();
         oslDrawImageXY(img, 0 ,0);
         oslSetTransparentColor( couleurMasque );
         if (num_tableau == 0)
              oslDrawImageXY(imgchoix[num_tableau], 90 ,25);
         else oslDrawImageXY(imgchoix[num_tableau], 90 ,40);
         oslSetBkColor(RGBA(0,0,0,0));

	 oslSetTextColor(RGB(0, 128, 0));

	 oslPrintf_xy(180, 13, titre[num_tableau]); 
         if (tempo == 15)
            {
               tempo=0;
               sav = textinfo[0];
              for&#40;i=0;i<strlen&#40;textinfo&#41;-1;i++&#41;
                textinfo&#91;i&#93; = textinfo&#91;i+1&#93;;
              textinfo&#91;i&#93; = sav;
            &#125;
         else tempo++;
         strcpy&#40;text,textinfo&#41;;
         text&#91;60&#93; = '\0';
         

         oslSetTextColor&#40;RGB&#40;255,0,0&#41;&#41;;
         oslPrintf_xy&#40;20, 250, text&#41;;
         
         oslEndFrame&#40;&#41;;

	 oslEndDrawing&#40;&#41;;
      &#125;
    //Pour pouvoir gérer les touches

    oslReadKeys&#40;&#41;;

    if &#40;osl_pad.pressed.cross&#41;
      return num_tableau;

   if &#40;osl_pad.pressed.circle&#41;
     &#123;
       num_tableau++;
       if &#40;num_tableau == 3&#41;
           num_tableau = 0;
     &#125;

   //Synchro à 60 fps

    skip = oslSyncFrameEx&#40;0, 6, 0&#41;;
  &#125;
  return -1;
&#125;

[carl0sgs]

thanks for the source!

but i think i haven't explained myself correctly
the problem is that the sceGU is needed in different threads, and when it is started in one thread you cannot use it from other threads.
This is solved by making objects lists wich are printed all at a time in the screen.

But! what if I need to manipulate images from other threads? shall I add something like a semaphore to avoid starting the GU from different threads?

Any idea?

Thank you for your help!

[carl0sgs]

I think i'm going to make a semaphore, so you can "lock" the GU if it is been used.
Something like "MTimageGuStart" and "MTimageGuEnd" before and after using image functions.

[Jim]

You probably want to split your code up better. Sounds right now like the drawing and updating and input are all mixed together. It would be better if you had a data structure for your windows - for simplicity's sake let's say it was just a linked list of id,x,y,width,height of each window.
Then you have a semaphore which locks access to the list. Any thread wanting to modify a window locks the list, makes the change, and unlocks it again.
You also have a single thread which knows how to draw windows. It also locks the list, draws all the windows in one go, then unlocks the list.
That way you have divided responsibility for update and drawing into separate places and solved the problem of multithreaded gu access.

If the 'big lock' on the list is too 'lumpy' you can work on having a semaphore for each window and a drawing semaphore. Updating a window locks both its own semaphore and the drawing one.

Jim

[carl0sgs]

Thanks! Great idea :-P

Right now the windows are structures, so thats not a problem xD

For drawing in the windows I have thought about making "drawing" and "reading" buffers,
two lists with the window's content. (One of them would be printed out in the main "printing" thread, the other one used for drawing things into the window and then, swapping the buffers).

I'm going to learn and practise with semaphores, cause I have no idea right now.
(I've been using variables like "printingWindows = 1" and while(printingWindows == 1) delay(1000); as a kind of semaphore lol)

Thanks again,
Carlos

[Jim]

For drawing in the windows I have thought about making "drawing" and "reading" buffers,

Right, double buffering is another excellent way of reducing the amount of locking.
There are proper sce calls for semaphores in the pspsdk, or else there's a port of pthreads for PSP in svn.

Jim

[carl0sgs]

Ok I'll take a look when I have time.

Thanks again!

[n0w]

Simply amazing! Are you planning to release sources?

[carl0sgs]

Yes, actually I would like to make an opensource project about this, but for that I need first to have something stable, the "main structure".

It would be really awesome to have even 3D drawing capabilities in the windows, maybe I'm pointing too high with this ><

I'm thinking a lot about how to make this (well. Right now it is just "usable", i want more ;-)).

I will have time for this in Summer, anyway.

Cheers,
Carlosgs