libwiisprite on github

[nebiun]

I merged source files and examples, modified the makefile to compile with the latest devkitPPC/libogc and then pushed all files on github.

https://github.com/nebiun/libwiisprite

[WinterMute]

If you're going to make this kind of effort (which, btw is appreciated, don't get me wrong here) it would be good if things were updated for modern standards.

Several files in there just contain the output of raw2c rather than having them generated at build time which makes it awkward to modify and encourages other people to do the same.

Loading png files at runtime & hardcoding references to them is a terrible way to manage assets too. I'd really like to see more in the way of asset management tools around (preferably cross platform). We have tex3ds for generating 3ds texture atlases which could, in theory, be expanded to deal with wii/gamecube textures too.

The habit people have of just dumping all their libraries into the toolchain installation without bothering to talk to anyone needs to stop as well. It causes major headaches with people ending up with incompatible things and various conflicts. We really want things contributed to https://github.com/devkitPro/pacman-packages rather than having a load of random things all over the place setting traps for novices.

Digging through all this I see absolute paths all over the place when data files should just be in the same place as the dol & loaded with relative paths.

It's good to see people around making the effort to update the libraries they're using for latest tools though. It really is appreciated. I'd like to try and pull everything together more so anyone trying to get started with all this has more of a chance of succeeding.

[nebiun]

If you're going to make this kind of effort (which, btw is appreciated, don't get me wrong here) it would be good if things were updated for modern standards.

Several files in there just contain the output of raw2c rather than having them generated at build time which makes it awkward to modify and encourages other people to do the same.

Loading png files at runtime & hardcoding references to them is a terrible way to manage assets too. I'd really like to see more in the way of asset management tools around (preferably cross platform). We have tex3ds for generating 3ds texture atlases which could, in theory, be expanded to deal with wii/gamecube textures too.

The habit people have of just dumping all their libraries into the toolchain installation without bothering to talk to anyone needs to stop as well. It causes major headaches with people ending up with incompatible things and various conflicts. We really want things contributed to https://github.com/devkitPro/pacman-packages rather than having a load of random things all over the place setting traps for novices.

Digging through all this I see absolute paths all over the place when data files should just be in the same place as the dol & loaded with relative paths.

It's good to see people around making the effort to update the libraries they're using for latest tools though. It really is appreciated. I'd like to try and pull everything together more so anyone trying to get started with all this has more of a chance of succeeding.

Well, WinterMute.
Give me a guide line and I do it for this library.

[nebiun]

Several files in there just contain the output of raw2c rather than having them generated at build time which makes it awkward to modify and encourages other people to do the same.

Done! Now binary files are in data directory and Makefile was modified to do the dirty work.

Loading png files at runtime & hardcoding references to them is a terrible way to manage assets too

I leave this for an example because the intention of the programmer was to show the two metods to load images.

The habit people have of just dumping all their libraries into the toolchain installation without bothering to talk to anyone needs to stop as well

Correct. What do you thing about add:
export USERLIBS := $(DEVKITPATH)/userlibs/ppc
to base_tools? If a library is not related with the toolchain and is not a ported library, then it must be installed in USERLIBS ((libgrr, libml, libwiisprite and so on).

[WinterMute]

The habit people have of just dumping all their libraries into the toolchain installation without bothering to talk to anyone needs to stop as well

Correct. What do you thing about add:
export USERLIBS := $(DEVKITPATH)/userlibs/ppc
to base_tools? If a library is not related with the toolchain and is not a ported library, then it must be installed in USERLIBS ((libgrr, libml, libwiisprite and so on).

I'd prefer that nothing that hasn't been officially adopted by devkitPro is placed inside the devkitpro folder at all.

Here's one of the many reasons why.

https://github.com/GRRLIB/GRRLIB/blob/m ... #L165-L188

[nebiun]

The habit people have of just dumping all their libraries into the toolchain installation without bothering to talk to anyone needs to stop as well

Correct. What do you thing about add:
export USERLIBS := $(DEVKITPATH)/userlibs/ppc
to base_tools? If a library is not related with the toolchain and is not a ported library, then it must be installed in USERLIBS ((libgrr, libml, libwiisprite and so on).

I'd prefer that nothing that hasn't been officially adopted by devkitPro is placed inside the devkitpro folder at all.

Here's one of the many reasons why.

https://github.com/GRRLIB/GRRLIB/blob/m ... #L165-L188

My version of grrlib uses only devkitpro (portlibs) libraries, not a local version of them.

[WinterMute]

I'd prefer that nothing that hasn't been officially adopted by devkitPro is placed inside the devkitpro folder at all.

Here's one of the many reasons why.

https://github.com/GRRLIB/GRRLIB/blob/m ... #L165-L188

My version of grrlib uses only devkitpro (portlibs) libraries, not a local version of them.

That's not what I'm pointing out.