From WiiBrew
Jump to navigation Jump to search

Thank you for finally writing a nice graphics library in C! I greatly appreciate your work. --SquidMan 16:51, 1 June 2009 (UTC)

Looks really quite nice. A few networking functions and the lib would be complete! --Pinecone 17:18, 1 June 2009 (UTC)

Thank you guys ! :) --Minishlink 19:29, 2 June 2009 (UTC)


I use your library in my application FMyLife and I was hoping you could add clipping as well as different surface blitting/drawing if possible. It would make my life a whole lot easier, LOL. Thanks very much for the library BTW. Rosch 06:38, 21 July 2009 (UTC)

It's now written in my brain, thanks for the idea. ;) --Minishlink 10:44, 7 August 2009 (UTC)

Hum... if what you want to say is to change the value of a pixel of an image; it's already in the library ! The function "ML_SetPixelColor(ML_Image *image, int x, int y, u32 color)". --Minishlink 17:15, 30 August 2009 (UTC)

Clipping is now added in the SVN, but I still don't know what you want to say with "different surface blitting/drawing". --Minishlink 14:05, 31 August 2009 (UTC)

Well right now I can draw images, objects, etc to one surface - the only visible surface. What I would like is the abilitu to create more drawable surfaces of any size and draw objects to those. Those surfaces are not on screen until I draw that entire surface (or parts of it using clipping) to the main drawing surface.

For example, I'd like object Foo to have its own surface for it to draw too that won't be visible on the main screen. I could draw and draw pretending its surface is its own and use absolute positioning on its own surface. Then when I want the contents of Foo on screen I just blit the entire Foo surface to the main drawing surface.

I could always write this myself now that you've included clipping, however it would be a layer manager on top of your library which is not as elegant.

Rosch 23:58, 1 September 2009 (UTC)

Ok, it's on the to-do list. --Minishlink 15:55, 5 September 2009 (UTC)


Is there any tutorial for this? Or would someone like to write one? --RiiSen 18:18, 31 July 2009 (UTC)

There is a wiki at but it's not complete now. ;) --Minishlink 10:44, 7 August 2009 (UTC)


* Do the user requests
* Font handling ML_Font -> I have to port FreeTypeGX from C++ to C, it works now, but there's a very strange bug. (When I move the Wiimote, I dunno why but the text transforms itself into a background of a lot of colors; and colors changes when you move the Wiimote : sooo weird !)
* Release 1.2

--Minishlink 15:55, 5 September 2009 (UTC)

[Old] "GPL" Problem

I just checked the code, it near an entire code ripping from GRRLIB ( !! Ripping is so lame... without any credits.... --NoNameNo 21:21, 21 June 2009 (UTC) —Preceding undated comment added 00:48, 21 June 2009 (UTC).

Are you just kidding me ? When the code is "ripped" like you say, I say it ! And credits are there. Just read before say. --Minishlink 09:05, 21 June 2009 (UTC)

GPL Violation

Portions of your code were taken/modified from other libraries. For example, a large amount of ML_video.c clearly originates from GRRLIB. This is fine (this is the point of open source), but you must credit the code sources properly - "Special Thanks" is not sufficient. Each source file and/or function should have the original authors credited, and you should be more specific in your readme that code credit is due to others (and to whom for what). If you fail to comply, MLlib will be removed from WiiBrew. --Tantric 20:55, 28 June 2009 (UTC)

Roger that. I will credit it properly when I'll be at home - 12th of July - I didn't know it wasn't sufficient and I apologize for that. --Minishlink 06:20, 30 June 2009 (UTC)

It will take some more time, I'm not at home until the end of August, sorry guys ! --Minishlink 10:44, 7 August 2009 (UTC)

Here's the usage agreement from the readme.txt in GRRlib 4.0. How hard is it for you to simply mention GRRLib in your THANKS text file?--Michael 15:59, 7 August 2009 (UTC)
  GRRLIB is NOT provided under any shitty license.

  If you use it, we only ask to :
  - dont forget us in the credits !!
  - to display the grrlib logo in you product as it's possible
How is it a GPL-violation, when GRRlib is not GPL licensed...? --Mechaelvis 13:22, 25 August 2009 (UTC)

Anyway, I finally clarified that point in my library, yipiiie ! (well, can I have my page back please ? :/ ) --Minishlink 19:53, 27 August 2009 (UTC)

Thank you Tantric :) --Minishlink 21:00, 27 August 2009 (UTC)

Thanx from the GRRLib Team

big thanks to you tantric for this clarification, there is a lot of more than the ML_video.c concerning GRRLib, but i bet that lot of other lines are direct copy/past from other libs. Minishlink should at least code a real wrapper, i mean let original library and code in mllib project, and only code a wrapper without "renaming" original lib functions names. There is even not the word GRRLib on the wiibrew page of mllib. Let me "re add" the "Homebrew using GRRLib" category. --NoNameNo 07:17, 30 June 2009 (UTC)

That's fine to add the category if you want. But you don't seem to understand that my lib is a framework first of all, the name of the functions have to be comprehensible and so on : I think it'd be very confusing to suddenly have a GRRLIB_Something which you don't know where it comes from... and anyway I modified the functions, so I can't leave it as it was in your lib... Sorry. One more thing please, all the things that I "copied/pasted" like you love to say are open-source : it means I can take some of your functions and include them into my lib, and then modify them... I just didn't pay enough attention for that credits thing, it's seriously boring to do these things but I swear it will be done for the next release. --Minishlink 05:06, 1 July 2009 (UTC)

i don't want to start a drama like, but it should be so easy to add GRRLIB to your framework project, then only code a wrapper ( MLlib_yourfunction calling GRRLIB_our ) and all could be respected without any problem ;) and to finnish, remember that open source is a philosophy based upon respect and sharing !!! --NoNameNo 16:31, 1 July 2009 (UTC)

Please do not use this program or Makefile

the Makefile has a very bugged make clean. it is using /include instead of include which can cause major issues. fix this before others suffer the same fate I did. Megazig 02:45, 15 October 2009 (UTC)

It's not very clear... Are you talking about the template Makefile or the MLlib Makefile ? The template Makefile do that when "make clean" : "rm -fr $(BUILD) $(OUTPUT).elf $(OUTPUT).dol" -> It's not deleting /include... And for the MLlib Makefile, it DOES delete include but it's my will : the MLlib folder is the release, and the MLlib_ folder is the source, compile from de MLlib_ and you will get your new MLlib.

on a *nix system, / is the root of the filesystem, so /include is the include directory on the root NOT the include directory in the MLlib directory or wherever. afaict this is what megazig is complaining about. --Yossi 07:18, 15 October 2009 (UTC)
thank you Yossi. that is exactly what I'm talking about. you use /include which is the include folder on the root of a *nix system. delete that and mess up a system. Very poor Makefile.
Here's what your absolutely terrible Makefile does.

megazig@megazig-desktop mllib % make clean 5:09:55
make: /home/megazig/devkitpro/devkitPPC/bin/powerpc-eabi-gcc: Command not found
rm -fr /include
rm -fr /lib
rm: cannot remove `/lib/': Permission denied
rm: cannot remove `/lib/': Permission denied
rm: cannot remove `/lib/udev/scsi_id': Permission denied
rm: cannot remove `/lib/udev/fstab_import': Permission denied
rm: cannot remove `/lib/udev/usb_id': Permission denied
rm: cannot remove `/lib/udev/': Permission denied
rm: cannot remove `/lib/udev/pcmcia-check-broken-cis': Permission denied Megazig 10:15, 15 October 2009 (UTC)