Page 1 of 2

gsKit with some bugfixes, features, and stuff

Posted: Wed Dec 31, 2008 8:17 am
by ragnarok2040
I've been fixing up gsKit a bit so it can support more display modes. I also added a few features like dithering, setting the dithering matrix, etc. I removed the last of the fileio code and replaced it with equivalent stdio file functions except for the fontm code. I moved all the image-to-gsTexture functions (gsKit_texture_png, etc.) as well as the non-fontm code to a new library called gsKit_toolkit. I couldn't think up a better name, heh. This separates the basic gsKit from the extended features that use external libraries. I also fixed the bmp/png & .dat support so it fully works with LMNOpc's bitmap font builder fonts and associated .dats. I also added scaling support for them as well. The fonts need to be left aligned, 0-255 ascii, and 256x256 when created.

gsKit_init_global_custom doesn't use a mode parameter anymore, instead defining a default one using gsKit_detect_signal. To use a custom mode, you should read the part about gsKit_init_screen. There's also a gsKit_deinit_global now to free up the memory used by the gsGlobal. I ran init/deinit through a loop 100,000 times to make sure it worked.

For, gsKit_init_screen, it now can reset the GS so that modes can be switched. The magnification for modes is now done automatically based on the dimensions of the draw buffer and the mode selected. Now you can define a small buffer like 640x540 which will stretch out to 1920x1080i, if the mode is 1080i, in field interlaced mode, enabling you to use a small enough draw buffer to use double buffering, zbuffering, etc. as well as free up some vram. The draw buffer's width and height dimensions need to be a factor of the mode's width and height least common multiples (DW and DH). E.g. NTSCs least common multiple for width is 2560, so 256,320,384,512,640 can all be supported while for height it's 448, so 224/448 will work. In order to use a custom mode, the gsGlobal's Width/Height/Mode/Field/Interlacing items need to be defined to custom values prior to calling gsKit_init_screen.

For the primitives, I removed the auto handling of height halving and the framed interlacing scanline fix. That's better suited for the app to handle via a macro and vsync interrupt handler or something than for gsKit to do natively.

I also added some functions for adding/removing a vsync interrupt handler. I created some functions to separate context switching and display buffer switching as well. I added a LockBuffer parameter to the gsGlobal structure to be used to lock the display buffer while it's displayed in single buffer mode to prevent the GS from switching buffers before it's ready. I made an example called vsync to show off some of the stuff that's been added.

I didn't post this under the patch submissions forum because some of the modifications break compatibility with things that have been ported with gsKit. I added svn repository information for all the new files and directories so using svn diff will show all the changes. Looking at the Makefile.global, I could tell that it was never intended to be included in an external project's makefile structure, so I added a warning to the Makefile. It's much simpler to just add the paths to gsKit's include and lib directory to EE_INCS and EE_LDFLAGS, respectively.

Here's the changelog:

Code: Select all

-> 12/29/08 - ragnarok2040

   * Fixed a bug in the vsync example. The display buffer doesn't need
     to check if it's locked to display.
   * Moved some FontM code to their respective gsFontM files.
   * Reset the FirstFrame attribute when resetting the GS.
   * Clear the screen as part of initializing to remove
     FirstFrame quirkyness. As a result, the vsync example
     started working with ps2link.
   * Removed gsKit_hsync_nowait since there doesn't seem to be a way
     to catch a hsync interrupt.

-> 12/28/08 - ragnarok2040
   * Added LockBuffer to gsGlobal
   * Added gsKit_lock_buffer to lock the current working buffer
   * Added gsKit_unlock_buffer to unlock the current working buffer
   * Added gsKit_lock_status which returns GS_SETTING_ON if the
     working buffer is locked. All this allows you to lock the buffer
     as it's being displayed and block until there's an active buffer
     to use.
   * Added vsync example based on basic example to show the usage
     of a vsync interrupt handler with display buffer locking

-> 12/27/08 - ragnarok2040
   * Added gsKit_add_vsync_handler to add a vsync handler
   * Added gsKit_remove_vsync_handler to remove a vsync handler
   * Added gsKit_switch_dispfb() to switch buffers for display
   * Added gsKit_switch_context() to switch the working buffers

-> 12/25/08 - ragnarok2040
   * Merry Christmas
   * Removed gslib tga2fnt font support since the support was broken
     except for certain converted types
   * Fixed png/bmp with .dat variable font widths rendering
   * Fonts need to be left-aligned when created
   * Added ability to scale png/bmp with .dat with variable font widths
   * Converted font example to use bmp/png .dat variable width fonts

-> 12/24/08 - ragnarok2040
   * Changed build structure to use separate Makefile.global files
     depending on what's being built
   * Finished work on the font code
   * Started work on building the examples
   * Discovered bitmap.raw is bad in textures example
   * Discovered testorig.jpg is bad in linuz-texture example
   * Fixed a bug in gsKit_texture_bmp() as fread() returns the
     number of elements read, not the number of bytes

-> 12/23/08 - ragnarok2040
   * Changed gsFont.c and gsFont.h to gsFontM.c and gsFontM.h
   * Finished migration of non-FontM code
   * Started separation of non-FontM code from FontM code in gskit
   * Started separation of FontM code from non-FontM code in gskit_toolkit

-> 12/22/08 - ragnarok2040
   * Continued separation of FontM and non-FontM codes
   * Finished changing fio* file routines to stdio file routines
   * Started work on fixing .fnt support for tga2fnt fonts
     from gslib

-> 12/21/08 - ragnarok2040
   * Modified gsKit_init_font to allocate memory for the ".dat" path
   * Modified gsKit_font_upload to properly load a ".dat" file
   * Changed gsFont->Additional to a s16 type since a ".dat" file is 256 short ints
   * More separation of FontM and non-FontM code

-> 12/20/08 - ragnarok2040
   * Added the ability to clear the vram by resetting the
     vram pointer back to the beginning of useable texture
     buffer space.
   * Continued migration of image lib texture functions
     to gsKit_toolkit.
   * Added a fix to Z Buffering support for mismatched depths.
   * Started modifying non-fontm loading routines to use stdio file functions

-> 12/19/08 - ragnarok2040
   * Fixed draw buffer code to allow for smaller draw buffers
     for the mode selected. This is useful as it allows you to
     use a 640x540 draw buffer that can be used for 1080i or
     640x720 or 640x360 draw buffer for 720p, etc.
   * Added dithering support for 16-bit modes.
   * Added the ability to set the dithering matrix.
   * Started migration of integrated image lib texture
     support into an external library called gsKit_toolkit.
   * Started separation of fontm and non-fontm code for the migration.

-> 12/18/08 - ragnarok2040
   * Added gsKit_deinit_global() which frees all the memory
     gsGlobal allocates
   * Modified gsKit_init_global() to enable DoubleBuffering and
     ZBuffering as default - might not work with large resolutions
   * Fixed a bug with 1920x1080i using GS_FRAME mode

-> 12/17/08 - ragnarok2040
   * Changed gsKit_vsync() to gsKit_vsync_wait()
   * Added gsKit_hsync_wait()
   * Added gsKit_vsync_nowait()
   * Added gsKit_hsync_nowait()
   * Added ability to set which fields to render with gsKit_set_drawfield()
     based on libgraph's code
   * Added gsKit_get_field() which sets gsGlobal->EvenOrOdd from the CSR->Field
     register: 0 is for Even and 1 is for Odd
   * Removed all the half buffer offset (HBOFFSET) fixes which users should do
     using their own vsync interrupt handler
   * Removed all the FRAME height adjustments which users should do depending
     on the interlace mode they choose
   * Added the ability to set low-resolution modes
   * Modified the gsKit_init_global_custom() to remove mode parameter
   * gsGlobal->Width, gsGlobal->Height, gsGlobal->Mode, gsGlobal->Interlace, and
     gsGlobal->Field should all be set prior to calling gsKit_init_screen()
   * Modified gsKit_init_screen() to reset the GS any time it is called
   * Defined a gsKit_reset_screen() symbol for resetting the screen
   * Added aspect ratio detection within gsKit_init_global()
   * Modified gsKit_detect_signal() to use RomGetName() method
     of detecting a PS2's region
I uploaded it to http://homebrew.thewaffleiron.net/ragna ... 908.tar.gz.
You might need to go to http://homebrew.thewaffleiron.net/ragnarok2040 and click on it, if the anti-hotlinking script is still running.

Posted: Wed Dec 31, 2008 8:38 am
by cosmito
Great work! Just downloaded and going to try ASAP (the hotlinking is ok). And it would be a very nice extra if it already supports true low resolution modes, unlike the original option of a 320x256 texture scaled to a 640x512 PAL display.

Re: gsKit with some bugfixes, features, and stuff

Posted: Wed Dec 31, 2008 8:45 am
by cosmito
ragnarok2040 wrote:I removed the last of the fileio code and replaced it with equivalent stdio file functions except for the fontm code
What's the issue with fileio?

Posted: Wed Dec 31, 2008 9:51 am
by ragnarok2040
There's nothing wrong with it, really, except for hard disk support. I'm not sure if that's entirely true, though, since on my ps2, using fileio to open a file on a mounted partition worked fine. Other people were having issues, though. The texture/font functions needed to be converted to stdio file functions because they use _ps2sdk_open, _ps2sdk_read, etc... symbols which are defined to use fileio functions by default, and redefined to use fileXio equivalent functions when fileXioInit is called. This allows the stdio file access functions to be independent of the underlying access method.

Posted: Wed Dec 31, 2008 10:04 am
by radad
I was the one who initially put the _ps2sdk_open, _ps2sdk_read,.. symbols in so they could be swapped with the fileXio functions because fileio wasnt able to read a mounted hdd partition. Since then I fixed it up so the fileio is now able to open a file on a mounted hdd partition. Since they werent necessary anymore I removed the _ps2sdk_open, _ps2sdk_read,.. symbols but they seem to have returned lately.

Posted: Wed Dec 31, 2008 12:49 pm
by ragnarok2040
Hey, radad, :D. I found your old post with the patch that added them so I knew you did it initially. The authors of uLE discovered some sort of bug, related to opening jpeg files on pfs with fileio so that it went into an infinite loop, and reapplied part of the patch you made to swap symbols to fix it. It seemed to happen with any revision newer than 1403, at the time. 1404 was the revision where the trick was removed. At the same time, for FCEUltra, I was getting reports of a similar issue with fopen, that caused either a crash or infinite loop, which weren't happening to me, so I couldn't debug them. I kept trying to fix the bugs in my own code and FCEUltra's code before I was pretty sure it wasn't causing it. Hence, I submitted a patch not too long ago that added them back, heh. I prefer the trick, anyway, since it allows a transparent method of using either fileXio or fileio for fopen and etc.

Posted: Thu Jan 01, 2009 10:31 am
by radad
Do you know if putting them back now fixes it?

Posted: Fri Jan 02, 2009 4:07 am
by ragnarok2040
For myself, not yet. I know that it fixed the problem libjpg was having with uLE. If I remember right, it was returning -19, or -ENODEV when using fopen, which used fioOpen, on a pfs# path for them.

I decided to do a re-port of FCEUltra, with more planning used in the design than the quick hacks to the original port I did, in order to make it easier to test for what was happening as FCEUltra's code is kind of a mess in relation to I/O errors. From the reports I received for the last release I made with the older code, the crash or infinite loop seemed to consistently happen any time FCEUltra tried to fopen and fwrite to a new file using a pfs# path even though it tested fine on my end. I played quite a few games using savegames and save states, sometimes for hours, without any trouble, using the same build.

Posted: Sat Jan 03, 2009 7:05 am
by Neovanglist
Wow!!

Please commit this to svn.

Posted: Sun Jan 04, 2009 2:39 pm
by ragnarok2040
Hey Neovanglist, :D. I just wanted to say thanks for creating gsKit, :D.

Posted: Mon Jan 05, 2009 9:49 am
by ooPo
NeoV says yay and it seems to be well-liked, so shall we commit this to the ps2dev repository?

Posted: Mon Jan 05, 2009 12:00 pm
by ragnarok2040
I'm fine with it being committed, :D. I double checked to make sure that all the files I modified/added in the last archive were all under subversion control and discovered that the vsync example somehow escaped. I uploaded a new archive that just adds the vsync example under subversion control.

Edit:
Didn't check the files I'd renamed.

http://homebrew.thewaffleiron.net/ragna ... 08.tar.bz2

Posted: Tue Jan 06, 2009 1:20 pm
by LBGSHI
Despite the small possibility of this breaking a few ported apps, after noting the benefits, I've tentatively added it to the pre-built, Win32 PS2SDK I threw together. I hope you don't mind (I've added credit, of course), and thanks for the awesome work.

(oh, and...you've named your '09 sources incorrectly, giving them '08 years)

Posted: Wed Jan 07, 2009 9:01 am
by ragnarok2040
I don't mind, :D, but you don't need my permission to do that, heh. The AFL 2.0 license grants permission for creating derivative works.
(oh, and...you've named your '09 sources incorrectly, giving them '08 years)
Oops, :?, that's always a problem for me. I finally get used to putting the correct year on everything then the next year comes around.

Posted: Wed Jan 07, 2009 11:53 am
by LBGSHI
Yeah, I think everyone does that from time to time.

Thanks again.

Posted: Thu Jan 08, 2009 3:19 am
by ooPo
Its annoying to merge two separate svn checkouts, can you do up a quick diff? :)

We really should get you svn access...

Posted: Thu Jan 08, 2009 11:23 am
by ragnarok2040
Ahh, ok, :D. I thought it'd be easier to commit an update from the original source because I'd added binary files. I made a diff and added the binary files in the archive with the patch. The dejavu files go into the font example and testorig.jpg goes into the linuz-texture example to replace the corrupt one that's there.

http://homebrew.thewaffleiron.net/ragna ... ch.tar.bz2

Posted: Fri Jan 09, 2009 12:29 am
by ooPo

Code: Select all

Sending        ChangeLog                                                                                                                                                                                                           
Sending        Makefile
Sending        Makefile.global
Sending        Makefile.pref
Sending        ee/Makefile
Sending        ee/gs/include/gsCore.h
Sending        ee/gs/include/gsFont.h
Adding         ee/gs/include/gsFontM.h
Sending        ee/gs/include/gsInit.h
Sending        ee/gs/include/gsKit.h
Sending        ee/gs/include/gsTexture.h
Sending        ee/gs/src/Makefile
Sending        ee/gs/src/gsCore.c
Sending        ee/gs/src/gsFont.c
Adding         ee/gs/src/gsFontM.c
Sending        ee/gs/src/gsInit.c
Sending        ee/gs/src/gsMisc.c
Sending        ee/gs/src/gsPrimitive.c
Sending        ee/gs/src/gsTexture.c
Adding         ee/toolkit
Adding         ee/toolkit/Makefile
Adding         ee/toolkit/Makefile.global
Adding         ee/toolkit/include
Adding         ee/toolkit/include/Makefile
Adding         ee/toolkit/include/gsToolkit.h
Adding         ee/toolkit/src
Adding         ee/toolkit/src/Makefile
Adding         ee/toolkit/src/gsToolkit.c
Sending        examples/Makefile
Adding         examples/Makefile.global
Sending        examples/alpha/Makefile
Sending        examples/alpha/alpha.c
Sending        examples/basic/Makefile
Sending        examples/basic/basic.c
Sending        examples/bigtex/Makefile
Sending        examples/bigtex/bigtex.c
Sending        examples/fb/Makefile
Sending        examples/fb/fb.c
Sending        examples/font/Makefile
Adding  (bin)  examples/font/dejavu.bmp
Adding  (bin)  examples/font/dejavu.dat
Adding  (bin)  examples/font/dejavu.png
Sending        examples/font/font.c
Sending        examples/fontm/Makefile
Sending        examples/fontm/fontm.c
Sending        examples/linuz-texture/Makefile
Sending        examples/linuz-texture/texture.c
Sending        examples/png-texture/Makefile
Sending        examples/png-texture/textures.c
Sending        examples/texstream/Makefile
Sending        examples/texstream/texstream.c
Sending        examples/textures/Makefile
Sending        examples/textures/textures.c
Adding         examples/vsync
Adding         examples/vsync/Makefile
Adding         examples/vsync/vsync.c
Sending        lib/Makefile
Transmitting file data .....................................................
Committed revision 1500.
Committed! May the weeping and gnashing of teeth begin!

Posted: Fri Jan 09, 2009 12:32 am
by ooPo

Code: Select all

Adding  (bin)  testorig.jpg
Transmitting file data .
Committed revision 1502.
Binary files act strange in svn. Beware!

Posted: Fri Jan 09, 2009 11:59 am
by ragnarok2040
I just checked out the latest revision and it compiles fine. The dejavu font files and the testorig.jpg file are all good. I'm not sure how, but an empty gsFont.h was left in ee/gs/include and an empty gsFont.c was left in ee/gs/src/. They were replaced with gsFontM.h and gsFontM.c. The 'svn diff' command probably just created a patch that just deleted all the lines because the files were absent... That probably means my latest patches for libpng and libjpeg will probably do the same thing, leaving the empty shells of files behind :?.

If you want to set me up with svn access, I'm fine with that now, since I learned a bit about using a svn repository on sourceforge. I'll be at #ps2dev.

Posted: Sun Jan 25, 2009 6:03 am
by LBGSHI
I seem to be having a problem compiling gsKit, all of a sudden.

I check it out, and have it copy directly into the ps2dev directory. Upon using "make all install", it finally gives me the error:

Code: Select all

cp *.h ~/ps2dev/gsKit/include
cp: copying multiple files, but last argument `/home/ps2dev/gsKit/include' is no
t a directory
Try `cp --help' for more information.
make[3]: *** [install] Error 1
make[3]: Leaving directory `/local/ps2dev/gskit/ee/gs/include'
make[2]: *** [install-include] Error 2
make[2]: Leaving directory `/local/ps2dev/gskit/ee/gs'
make[1]: *** [install-gs] Error 2
make[1]: Leaving directory `/local/ps2dev/gskit/ee'
make: *** [install-ee] Error 2
It's true that /home/ps2dev doesn't exist. In looking for the reason for it referencing this path, I found the following line in the gsKit Makefile.pref:

Code: Select all

PS2DEV = ~/ps2dev
I believe ~ is home. Removing this line seems to resolve this issue, but brings about another one:

Code: Select all

cp libgskit.a libdmakit.a libgskit_toolkit.a /usr/local/ps2dev/gsKit/lib
cp: `libgskit.a' and `/usr/local/ps2dev/gsKit/lib/libgskit.a' are the same file
cp: `libdmakit.a' and `/usr/local/ps2dev/gsKit/lib/libdmakit.a' are the same fil
e
cp: `libgskit_toolkit.a' and `/usr/local/ps2dev/gsKit/lib/libgskit_toolkit.a' ar
e the same file
make[1]: *** [install] Error 1
make[1]: Leaving directory `/local/ps2dev/gskit/lib'
make: *** [install-lib] Error 2
Has anyone had similar problems? I didn't have these with previous versions of gsKit.

Posted: Mon Jan 26, 2009 1:54 am
by ragnarok2040
I had Makefile.pref edited to reflect my ps2dev directory location when I made the patch. Back when I was using MinGW/MSYS, I kept running into trouble with /usr/local. The cp command needs to be forced to copy over existing files, as well.

Code: Select all

Index: lib/Makefile
===================================================================
--- lib/Makefile	(revision 1525)
+++ lib/Makefile	(working copy)
@@ -18,7 +18,9 @@
 
 install:
 	mkdir -p $(GSKIT)/lib
-	cp libgskit.a libdmakit.a libgskit_toolkit.a $(GSKIT)/lib
+	cp -f libgskit.a $(GSKIT)/lib
+	cp -f libdmakit.a $(GSKIT)/lib
+	cp -f libgskit_toolkit.a $(GSKIT)/lib
 
 include ../Makefile.global
 include ../Makefile.pref
Index: Makefile.pref
===================================================================
--- Makefile.pref	(revision 1525)
+++ Makefile.pref	(working copy)
@@ -15,7 +15,7 @@
 
 include $(PS2SDK)/Defs.make
 
-PS2DEV = ~/ps2dev
+# PS2DEV = ~/ps2dev
 
 ifeq (x$(GSKIT), x)
 GSKIT = $(PS2DEV)/gsKit
These changes will fix those problems.

Posted: Mon Jan 26, 2009 11:54 am
by LBGSHI
Done, but it now gives this error:

Code: Select all

mkdir -p /usr/local/ps2dev/gsKit/lib
cp -f libgskit.a /usr/local/ps2dev/gsKit/lib
cp: `libgskit.a' and `/usr/local/ps2dev/gsKit/lib/libgskit.a' are the same file
make[1]: *** [install] Error 1
make[1]: Leaving directory `/local/ps2dev/gskit/lib'
make: *** [install-lib] Error 2
Which I believe stems from the fact that gsKit/lib is already where it should be (I'm compiling gsKit from within the ps2dev directory).

Posted: Tue Jan 27, 2009 9:58 am
by ragnarok2040
Compiling the source in the installation directory makes a mess of things. Mixes headers up, harder to find binary files, and it's possible to add issues like not being able to run the 'make install' command because it expects to be migrating binary files to a remote path. You should really have a separate directory tree that holds all of your ps2dev/ps2sdk/ps2sdk-ports/etc. related sources, e.g. ps2dev/src so that the installation directories holding the binaries can be removed and reinstalled to keep it tidy.

Posted: Wed Jan 28, 2009 12:58 am
by dlanor
ragnarok2040 wrote:Compiling the source in the installation directory makes a mess of things. Mixes headers up, harder to find binary files, and it's possible to add issues like not being able to run the 'make install' command because it expects to be migrating binary files to a remote path. You should really have a separate directory tree that holds all of your ps2dev/ps2sdk/ps2sdk-ports/etc. related sources, e.g. ps2dev/src so that the installation directories holding the binaries can be removed and reinstalled to keep it tidy.
I agree that it is often a good idea to separate source releases from binary releases, but your description of how to do it conflicts with established usage for PS2SDK, as well as various other packages (though in differing ways).

For PS2SDK the separation of binary release from source release is already completely implemented and requires only that the user defines two different paths as values of the environment variables "PS2SDK" (binary release) and "PS2SDKSRC" (source release as downloaded from SVN).

Then the proper way of producing the binary release content is a series of commands like these:
cd $PS2SDKSRC && make clean && make && make install

Judging from the makefile scripts of the old gsKit, someone started implementing something similar for it, but botched the job completely, making this somewhat messy. I assume this is what prompted you to try doing something about it, but I have not yet had time to familiarize myself with your updates to gsKit.

In any case, in my opinion it is not possible to impose a single consistent method for handling these things, as any one method is bound to conflict with existing usage of various projects.

So while I agree in principle that a common system of ordering these things would be good to have, I don't see any way of imposing it without messing up the functionality of existing projects.

Best regards: dlanor

Posted: Wed Jan 28, 2009 4:39 am
by ragnarok2040
I'm not sure what you mean when you say my method conflicts with established usage of PS2SDK. I follow the FHS as best I can when managing my ps2dev tree. All the projects' source releases go into ps2dev/src with them mirrored in ps2dev/src/clean in case I taint any source in some non recoverable way, where 'svn revert -R *' doesn't work. As far as I know, it's impossible to mess up the functionality of any project by doing that unless it has no 'install' or 'release' rule.

gsKit depends on this standard, where the Makefile.pref defines GSKIT as $PS2DEV/gsKit and the Makefile defines GSKITSRC as the current working directory, which is always a separate directory from $PS2DEV when following the standard.

Posted: Wed Jan 28, 2009 7:44 pm
by cosmito
I think it would a good idea to mention these recommendations preferentially at the README of the toolchain or at any existent FAQ/Wiki.

Posted: Thu Jan 29, 2009 4:45 am
by LBGSHI
Ah. Renaming my gsKit directory (still within ps2dev) to 0gsKit (arbitrary name, of course), then performing a make clean all, make, make install created the gskit directory and the proper libraries without incident (after making the modifications you suggested above, which should probably be committed). But, I still had to copy all the remaining files directly under the original gsKit (0gsKit; the src directory), as well as the entire ee directory, and the examples dir (well, I didn't HAVE to copy that directory). I also had to add this environment variable to my etc/profile file:

export GSKITSRC=$PS2DEV/gsKit

I could have just made a separate gsKitsrc directory, and pointed the environment variable there, but that would require modifying quite a few pieces of gsKit (and the examples), which are built around "../.."-style non-explicit directives.

I agree that a standardized system should be put in place, or at least there should be some basic instructions in the ReadMe for several common problems (I do have SVN privileges, so I suppose I could muster enough unlaziness, and pry myself from my other projects long enough to write something up myself, heh).

Posted: Thu Jan 29, 2009 9:08 am
by radad
gsKit builds fine for me but I did just fix something in the makefile. PS2DEV was been set to '~/ps2dev' and the '~' wasnt working properly so I changed it to '$HOME/ps2dev'. Also I changed so it didnt reset PS2DEV if it was already set.

This looks wrong:

Code: Select all

export GSKITSRC=$PS2DEV/gsKit
GSKITSRC should be set to where you checked out gsKit to, usually under your home directory. The makefile uses a `pwd` if this isnt set which should work fine.

GSKIT should be set to where you want it to install to, usually under /local. The makefile defaults this to $PS2DEV/gsKit.

PS2DEV should be set to something under /local.

Posted: Thu Jan 29, 2009 12:00 pm
by ragnarok2040
That PS2DEV variable was set to /usr/local/ps2dev, I believe, prior to my patch. I don't think it's really needed at all in Makefile.pref and can probably be removed from it. I have my ps2dev directory in ~/ps2dev from a bad habit gained from trying to fix a bug with MSYS showing Windows style paths when configuring gcc. It was easier to setup repeatedly than /usr/local/ps2dev, heh. I'm planning on reinstalling soon, though, which will remedy that.

I agree that there should probably be some information somewhere which suggest some recommended reading materials. The FHS and GNU CS are very useful in keeping things organized. I found out about the FHS about a year ago, now, when I was curious about the Linux filesystem and stumbled upon the standard. Perhaps links to the various standards could be placed under a Recommended Reading section under the FAQ thread. FHS, GNU CS, standard libc docs, etc.

FHS:
http://en.wikipedia.org/wiki/Filesystem ... y_Standard
http://www.pathname.com/fhs/pub/fhs-2.3.html
The command 'man hier' if you have the manpages installed for it.

GNU CS:
http://www.gnu.org/prep/standards/html_node/index.html

Here's my detailed plan, in case it helps:
  • Binaries will install to PS2DEV at:
    • /usr/local/ps2dev
    The working directory where source is compiled should be in a user specific directory such as:
    • ~/ps2dev
    Mirrors of the sources for the binaries, for reference purposes, should be copied to the prefix location of:
    • /usr/local/ps2dev/src
    PS2SDKSRC should reference:
    • /usr/local/ps2dev/src/ps2sdk
My ps2dev hierarchy:
  • Binaries:
    • /usr/local/ps2dev/ee
      /usr/local/ps2dev/iop
      /usr/local/ps2dev/dvp
      /usr/local/ps2dev/ps2sdk
      /usr/local/ps2dev/gsKit
      ...
    Sources used for reference:
    • /usr/local/ps2dev/src/ps2sdk
      /usr/local/ps2dev/src/gsKit
      /usr/local/ps2dev/src/ps2sdk-ports/libjpeg
      /usr/local/ps2dev/src/ps2sdk-ports/libpng
      ...
    Working directory for compiling:
    • ~/ps2dev/ps2sdk
      ~/ps2dev/ps2sdk-ports/libjpeg
      ~/ps2dev/ps2sdk-ports/libpng
      ~/ps2dev/gsKit
      ~/ps2dev/project_name
      ...