dc v6 graphics

[Torch]

One more thing that is vaguely related:
Is it known how to interact with music_plugin.prx etc?
How does vshmain.prx use those plugins? Is the music_plugin.prx performing onscreen rendering of the song list or is it simply returning data to vshmain.prx for displaying.

If its just returning data then wouldn't it be possible to use it in a custom vshmain.prx if we know the details? Or possible to make a replacement music_plugin.prx providing the same exports that vshmain.prx expects, so we can have a open source music player with lots of format support?

But none of the NIDs are known :(

[Super Sheep]

And I still don't understand what is LIBC T_T

LIBC is pretty much your standard C library functions. stdio.h, stdlib.h, stdarg.h, malloc.h, string.h etc

[moonlight]

Are all these libs required for just the wave background??
-lpsppower -lpsprtc -lvlfgui -lvlfgu -lvlfutils -lvlflibc -lpspreg -lpspsystemctrl_user -lpspkubridge -lpspwlan

And is this still required or is the path set automatically now?

Code: Select all

   char *path = (char *)argp;
   int last_trail = -1;
   int i;

   if (path)
   {
      for (i = 0; path[i]; i++)
      {
         if (path[i] == '/')
            last_trail = i;
      }
   }

   if (last_trail >= 0)
      path[last_trail] = 0;

   sceIoChdir(path);
   path[last_trail] = '/';

In the unload thread can't I just directly load vshmain_real.prx using kuKernelLoadModule or is there some problem with that?

EDIT: OK..Just understood that your freeing all the user memory and loading vshmain_real.prx from a kernel prx so that all memory is available to vshmain on startup.

Code: Select all

static int end_thread(SceSize args, void *argp)
{
	sceKernelStopModule(vlf_mod, 0, NULL, NULL, NULL);
	sceKernelUnloadModule(vlf_mod);
	
	sceKernelStopModule(if_mod, 0, NULL, NULL, NULL);
	sceKernelUnloadModule(if_mod);

	// From here, you cannot use LIBC!

	SceUID mod = sceKernelLoadModule("ms0:/seplugins/vsh_loader.prx", 0, NULL);
	sceKernelStartModule(mod, MODNAME_LENGTH+1, MODNAME, NULL, NULL);
	
	return sceKernelExitDeleteThread(0);
}

I am detecting button presses using the sceCtrl functions in another thread. It works, but should that be avoided and should I use the VLF event handlers instead?

And I still don't understand what is LIBC T_T

You can detect keys yourself. But i recommend using sceCtrlPeekBufferPositive, and not sceCtrlReadBufferPositive.

[Super Sheep]

As to avoid the vshctrl hooks?

vlfGuiGetLanguage (I think thats it) returns an int. Which integers represent which language?

[moonlight]

As to avoid the vshctrl hooks?

vlfGuiGetLanguage (I think thats it) returns an int. Which integers represent which language?

They are in psputility_sysparam.h.

[phobox]

hey! whats

Code: Select all

int  vlfGuiAddNegativeEventHandler(int buttons, int wait, int (* func)(void *), void *param);

?

EDIT: another question, is there a way of removing everything (pictures and texts) on the screen? is that way

Code: Select all

vlfGuiSetRectangleVisibility(0, (sizeOfTheTitleBar), 480, (272-sizeOfTheTitleBar, 0)?
what is the size of the title bar?

[Torch]

There is randomly some nasty flickering when calling the RemovePicture functions. This is truly an awesome lib.

Made my first app using this - Google for Lockdown XMB Style (Once Google has indexed it).

[Torch]

Ahhh help! When making replacement vshmain, the ISOs are not showing in XMB. When making replacement without VLF it works fine.

[Torch]

Ok, the ISOs not showing up are due to iop.prx. Without loading iop.prx the ISOs are visible.

If I do not load iop.prx then VLF cannot access the 01-12.bmp to load the background.
Also without iop.prx my app fails to assign flash0: write mode even though it is in 0x800 mode (where as in the non-VLF version it works even without iop.prx).

Even if I leave iop.prx loaded, the ISOs do not show up.

I looked at the iop source code you provided earlier and it doesn't seem to restore the functions to the original functions when it is unloaded.

[moonlight]

Yeah, this thing is normal now that I think of it, the iso stuff in XMB requires some patches that vshctrl does when vshmain is loaded, and the patches of iop.prx are incompatible with that. I'll create later a version of iop.prx with a module_stop that clears everything to its original state.

[moonlight]

There is randomly some nasty flickering when calling the RemovePicture functions. This is truly an awesome lib.

In which thread are you calling remove picture functions? They should be called from the drawing thread, which also includes all event handlers.

[Torch]

In which thread are you calling remove picture functions? They should be called from the drawing thread, which also includes all event handlers.

I am calling from another thread that is used for sceCtrl reading, not from app_main. It doesn't matter, its too difficult to change my program now as there are so many calls :S

Yeah, this thing is normal now that I think of it, the iso stuff in XMB requires some patches that vshctrl does when vshmain is loaded, and the patches of iop.prx are incompatible with that. I'll create later a version of iop.prx with a module_stop that clears everything to its original state.

I was trying to write module_stop right now.
I just have to save in the beginning
original_address = sctrlHENFindFunction("sceIOFileManager", "IoFileMgrForUser", 0x06A70004);
in module_start and then call
PatchSyscall(sctrlHENFindFunction("sceIOFileManager", "IoFileMgrForUser", 0x06A70004), original_address);
in module_stop right?

[moonlight]

Yeah. That would work.

To delte things in other thread, it is usually better to add an eventhandler with the two first params set to 0 and -1 (0 = no buttons, the -1 indicates no delay will ever be applied), delete objects from the handler which is executed before the painting code of next frame, and returning VLF_EV_RET_REMOVE_HANDLER to avoid being called again.

[Torch]

Yeah. That would work.

To delte things in other thread, it is usually better to add an eventhandler with the two first params set to 0 and -1 (0 = no buttons, the -1 indicates no delay will ever be applied), delete objects from the handler which is executed before the painting code of next frame, and returning VLF_EV_RET_REMOVE_HANDLER to avoid being called again.

Cool thanks for the tip. This way will be easy to change everywhere in my program.

I'll post iop.c in case it works :P

[Torch]

Help I tried to add module_stop but its not working.
http://ifile.it/4l27xaw/iop_unload.zip

Its as if module_stop is not getting called at all, even though I've added it to exports.
Actually I've never succeeded in getting module_stop to work in any of my modules till now.

[moonlight]

Change 0x1007 to 0x1006. The module had the attributes to not be stopped, so module_stop don't get called.

[Torch]

Change 0x1007 to 0x1006. The module had the attributes to not be stopped, so module_stop don't get called.

I changed to 0x1006 and it goes to module_stop, but its crashing. Can you see my code I uploaded above, I dunno whats wrong. Its the same thing with 0x1007 which I changed to 0x1006.

[moonlight]

In module_stop, do not pass the result of sctrlHENFindFunction(...) as the function address is still the original one (only the syscall entry changes). Instead pass directly the address of the patched function:

e.g.

Code: Select all

PatchSyscall(sctrlHENFindFunction("sceIOFileManager", "IoFileMgrForUser", 0x06A70004), (void *)orgaddr[0]);

changes to

Code: Select all

PatchSyscall(sceIoMkdirPatched, (void *)orgaddr[0]);

[Torch]

Oh OK like thaaat. I thought it was like apihook. I assume this will only work on M33 firmware (or other derivative/reversed stuff with similar systemctrl)?

You could have done it in 2 minutes instead of all the time spent teaching me :P but thanks for the learning experience.

Heres working version: http://ifile.it/brjox3v/iop_unloadable.zip

[Torch]

is it just me or does the vlf wave seem to be slower than the xmb one? maybe because of my programs loop. any way to increase the speed of animation? (cant look at vlf.h now typing on psp)

[krosk]

check for the sample included on the newest vlf, it has some tricks to increase speed, size, rotate it...

[moonlight]

Well, I see the speed being the same than in XMB: 1/60.0f. Anyways you can use the vlfGuiSetModelSpeed

[Torch]

Help, I've dummied heaparea1.prx and heaparea2.prx, but when I try to load real ones it crashes.

I have tried to sceKernelStopUnloadSelfModule in the dummy, as well as SleepThread in the dummy and sceKernelStopModule the dummy from vsh_loader.prx. The dummies are 0x0 mode, just like the real ones.

I am trying to load the real ones from the kernel mode vsh_loader.prx

Code: Select all

mod = sceKernelLoadModule("flash0:/vsh/module/heaparea1_real.prx", 0, NULL);
		sceKernelStartModule(mod, 0, NULL, NULL, NULL);
		mod = sceKernelLoadModule("flash0:/vsh/module/heaparea2_real.prx", 0, NULL);
		sceKernelStartModule(mod, 0, NULL, NULL, NULL);
		
		mod = sceKernelLoadModule("flash0:/vsh/module/vshmain_real.prx", 0, NULL);
sceKernelStartModule(mod, args, argp, NULL, NULL);

[moonlight]

I would dummy paf.prx, common_util and common_gui too. When loading original ones they must be loaded in this order: heaparea1.prx, paf.prx, common_gui.prx and common_util.prx.

Don't dummy and load heaparea2.prx, it seems that's actually only loaded for utility dialogs.

[Torch]

Don't dummy and load heaparea1.prx, it seems that's actually only loaded for utility dialogs.

I assume you meant heaparea2.prx.

I'm trying it now. Whats the recommended method for dummying? Should sceKernelSleepThread() in the dummy and then sceKernelUnloadModule(dummy) before loading the real ones? Or should just self unload in the dummy?

[moonlight]

The recommended method to dummy a prx is to have a module with only module_start returning 1 :)

That will make the prx exit inmediatelly.

P.D: If the compiler complains (due to your prx not using any imports), don't worry, type make again, it will work.

[Torch]

Thanks I've dummied them like that now.

Now I have a problem with the parameters passed to VSH I think.

Even though I pass these to vshmain_real.prx, it is still starting from the SCE logo when exiting a game instead of showing any error messages etc.

EDIT:
Its because of paf.prx. If I don't dummy paf.prx then vsh is receiving correct paramaters.

If paf.prx is dummied, and if I load paf_real.prx first, then vshmain_real.prx, vsh is starting from SCE logo.

[Torch]

I'm guessing paf.prx changes the parameters which is supposed to be received by vshmain.prx. With paf.prx dummied, vshmain.prx is receiving incorrect stuff i think.

[Torch]

common_gui.prx/util.prx are also needed for the load/save game list. So the dummy module should be intelligent to load the real one in case bootconf is game mode.

Also how do the parameters get passed to each of the modules in the boot sequence? I dont understand.

[moonlight]

Well, the boot params are only passed to vshmain, and not to the rest of modules.