Want to help out with pspsdk? I mean REALLY help out?
Want to help out with pspsdk? I mean REALLY help out?
We're always looking for new, good coders. If you would like to join the pspdev community, gain write access to the svn repository and add your own code to pspsdk then all you have to do is ask. How do you ask? Simple.
1) Post a patch to this forum.
Posting a patch shows that you have at least a basic idea of the tools involved in pspdev development, it gives an idea of your coding style and most of all it shows that you are genuinely interested in helping out.
We're not an elite group, just a skilled group. In fact, I'm an asshole and even *I* wasn't turned down. So what are you waiting for?
Post today!
1) Post a patch to this forum.
Posting a patch shows that you have at least a basic idea of the tools involved in pspdev development, it gives an idea of your coding style and most of all it shows that you are genuinely interested in helping out.
We're not an elite group, just a skilled group. In fact, I'm an asshole and even *I* wasn't turned down. So what are you waiting for?
Post today!
Last edited by ooPo on Sat Jan 06, 2007 2:30 pm, edited 1 time in total.
I've ported my Savedata Tool to the new PSPSDK:
sdk/kernel/psputility.h
sdk/samples/savedata/
Code: Select all
$ svn diff
Index: sdk/kernel/pspkernel.h
===================================================================
--- sdk/kernel/pspkernel.h (revision 408)
+++ sdk/kernel/pspkernel.h (working copy)
@@ -23,6 +23,7 @@
#include <pspmodulemgr.h>
#include <pspthreadman.h>
#include <psputils.h>
+#include <psputility.h>
#include <pspumd.h>
#include <pspge.h>
#include <pspkerror.h>
Index: sdk/kernel/Makefile.am
===================================================================
--- sdk/kernel/Makefile.am (revision 408)
+++ sdk/kernel/Makefile.am (working copy)
@@ -28,6 +28,7 @@
pspmodulemgr.h \
pspthreadman.h \
pspumd.h \
+ psputility.h \
psputils.h
lib_LIBRARIES = libpspkernel.a
Index: sdk/samples/Makefile.am
===================================================================
--- sdk/samples/Makefile.am (revision 408)
+++ sdk/samples/Makefile.am (working copy)
@@ -3,7 +3,8 @@
SAMPLES = \
sdktest \
- gu/cube
+ gu/cube \
+ savedata
all:
sdk/samples/savedata/
slight error
missing
#include <psputility.h>
in the sample code
#include <psputility.h>
in the sample code
Re: slight error
Looks like anything is included in kernel.h (like utils.h) and the function stubs for the savedata-API are already included in the kernel assembler part, so I've added utility.h to kernel.h, too and it is not necessary to include it from the sample code.jpadams wrote:missing
#include <psputility.h>
in the sample code
pspiofilemgr_stat.h patch (http://forums.ps2dev.org/viewtopic.php?t=2748)
Code: Select all
--- pspiofilemgr_stat.h 2005-07-20 09:37:12.287260600 +0200
+++ pspiofilemgr_stat2.h 2005-07-25 15:35:39.661769400 +0200
@@ -30,9 +30,9 @@
/** Symbolic link */
FIO_S_IFLNK = 0x4000,
/** Directory */
- FIO_S_IFDIR = 0x2000,
+ FIO_S_IFDIR = 0x1000,
/** Regular file */
- FIO_S_IFREG = 0x1000,
+ FIO_S_IFREG = 0x2000,
/** Set UID */
FIO_S_ISUID = 0x0800,
- TiTAN Art Division -
http://www.titandemo.org
http://www.titandemo.org
If we have whole files, where should we post them??
I've got a working pspwifi.h & pspwifi.c that could be a decent start to getting wifi into PSPSDK. Problem is that I dont know how to compile the .s (from PSPPets demo) and pspwifi.c into a .a for linking.. sorry, I'm a complete GCC nub. I'm used to Visual Studio! :)
-Bill
I've got a working pspwifi.h & pspwifi.c that could be a decent start to getting wifi into PSPSDK. Problem is that I dont know how to compile the .s (from PSPPets demo) and pspwifi.c into a .a for linking.. sorry, I'm a complete GCC nub. I'm used to Visual Studio! :)
-Bill
AppliedShazz wrote:pspiofilemgr_stat.h patch (http://forums.ps2dev.org/viewtopic.php?t=2748)
Code: Select all
--- pspiofilemgr_stat.h 2005-07-20 09:37:12.287260600 +0200 +++ pspiofilemgr_stat2.h 2005-07-25 15:35:39.661769400 +0200 @@ -30,9 +30,9 @@ /** Symbolic link */ FIO_S_IFLNK = 0x4000, /** Directory */ - FIO_S_IFDIR = 0x2000, + FIO_S_IFDIR = 0x1000, /** Regular file */ - FIO_S_IFREG = 0x1000, + FIO_S_IFREG = 0x2000, /** Set UID */ FIO_S_ISUID = 0x0800,
Net connectivity for PSPSDK is being worked on. We're currently trying to figure out a clean way to load the PRXs then it should be almost ready to go in.CyberBill wrote:If we have whole files, where should we post them??
I've got a working pspwifi.h & pspwifi.c that could be a decent start to getting wifi into PSPSDK. Problem is that I dont know how to compile the .s (from PSPPets demo) and pspwifi.c into a .a for linking.. sorry, I'm a complete GCC nub. I'm used to Visual Studio! :)
-Bill
See also this topic:
http://forums.ps2dev.org/viewtopic.php?t=3107
I think p-sprint as the default keyboard driver may be a more useful item than what's posted there now (allowing you to press only 8 keys).
Let me know if you agree, then if you give me access I'll upload the files to svn and work on improving it to get a full scancode and modifier emulation up and running (so far looks like I only have to convert the keycodes to the default MW kernel scancodes)
http://forums.ps2dev.org/viewtopic.php?t=3107
I think p-sprint as the default keyboard driver may be a more useful item than what's posted there now (allowing you to press only 8 keys).
Let me know if you agree, then if you give me access I'll upload the files to svn and work on improving it to get a full scancode and modifier emulation up and running (so far looks like I only have to convert the keycodes to the default MW kernel scancodes)
p-sprint belongs in a seperate library but not inside of PSPSDK. PSPSDK encompasses the interfaces provided in the PSP's firmware, as well as supporting code. p-sprint, while useful, doesn't really fit there as it doesn't tie into any native or established PSP interfaces.
Of course I don't have any objections to it going into Subversion, just bug Oobles for an account when he's around.
Of course I don't have any objections to it going into Subversion, just bug Oobles for an account when he's around.
I agree it doesn't belong in the PSPSDK - I just meant that it would be useful for Microwindows, which happens to be in the SVN repository. Sorry for not being clear enough.mrbrown wrote:p-sprint belongs in a seperate library but not inside of PSPSDK. PSPSDK encompasses the interfaces provided in the PSP's firmware, as well as supporting code. p-sprint, while useful, doesn't really fit there as it doesn't tie into any native or established PSP interfaces.
Of course I don't have any objections to it going into Subversion, just bug Oobles for an account when he's around.
I'll ask Oobles for an account. Thanks for the info.
Code: Select all
void sceGumScale(const ScePspFVector3* v)
{
ScePspFMatrix4* curr = gum_current_matrix;
float x,y,z;
x = v->x; y = v->y; z = v->z; // <- *** NEVER USED ***
curr->x.x *= x; curr->x.y *= x; curr->x.z *= x;
curr->y.x *= x; curr->y.y *= x; curr->y.z *= x;
curr->z.x *= x; curr->z.y *= x; curr->z.z *= x;
gum_matrix_update[gum_current_mode] = 1;
}
Could you fix it plz.
Examples in the header comments for sceIoOpen() are wrong:
should be
And this would be the patch. Well I hope it is :)
Code: Select all
* if(!(fd = sceIoOpen("device:/path/to/file", O_RDONLY, 0777)) {
...
* if(!(fd = sceIoOpen("device:/path/to/file", O_WRONLY|O_CREAT, 0777)) {
Code: Select all
* if((fd = sceIoOpen("device:/path/to/file", O_RDONLY, 0777) < 0) {
...
* if((fd = sceIoOpen("device:/path/to/file", O_WRONLY|O_CREAT, 0777) < 0) {
Code: Select all
--- pspiofilemgr.h 2005-10-04 09:02:46.546875000 +0200
+++ mypspiofilemgr.h 2005-10-11 00:40:04.859375000 +0200
@@ -44,13 +44,13 @@
*
* @par Example1: Open a file for reading
* @code
- * if(!(fd = sceIoOpen("device:/path/to/file", O_RDONLY, 0777)) {
+ * if((fd = sceIoOpen("device:/path/to/file", O_RDONLY, 0777)<0) {
* // error
* }
* @endcode
* @par Example2: Open a file for writing, creating it if it doesnt exist
* @code
- * if(!(fd = sceIoOpen("device:/path/to/file", O_WRONLY|O_CREAT, 0777)) {
+ * if((fd = sceIoOpen("device:/path/to/file", O_WRONLY|O_CREAT, 0777)<0) {
* // error
* }
* @endcode
@@ -58,7 +58,7 @@
* @param file - Pointer to a string holding the name of the file to open
* @param flags - Libc styled flags that are or'ed together
* @param mode - File access mode.
- * @return A non-negative integer is a valid fd, anything else an error
+ * @return A non-negative integer is a valid fd, < 0 on error
*/
SceUID sceIoOpen(const char *file, int flags, SceMode mode);
@@ -68,7 +68,7 @@
* @param file - Pointer to a string holding the name of the file to open
* @param flags - Libc styled flags that are or'ed together
* @param mode - File access mode.
- * @return A non-negative integer is a valid fd, anything else an error
+ * @return A non-negative integer is a valid fd, < 0 on error
*/
SceUID sceIoOpenAsync(const char *file, int flags, SceMode mode);
Paco
Monkeying around with the fog in Gu, I couldn't get it to work until I negated the near and far parameters. I don't think my math is off but I'm using Left-handed coordinates, so some right-hander might want to double check if the 3d chip has some weirdo requirement from the projection matrix here (like D3D with w-buffering).
or just
Code: Select all
--- sceGuFog.c 2005-10-04 09:02:44.500000000 +0200
+++ mysceGuFog.c 2005-10-12 00:11:43.828125000 +0200
@@ -10,12 +10,12 @@
void sceGuFog(float near, float far, unsigned int color)
{
- float distance = far-near;
+ float distance = near-far;
if (distance)
distance = 1.0f / distance;
sendCommandi(207,color & 0xffffff);
- sendCommandf(205,far);
+ sendCommandf(205,-far);
sendCommandf(206,distance);
}
Code: Select all
--- sceGuFog.c 2005-10-04 09:02:44.500000000 +0200
+++ mysceGuFog.c 2005-10-12 00:14:24.828125000 +0200
@@ -16,6 +16,6 @@
distance = 1.0f / distance;
sendCommandi(207,color & 0xffffff);
- sendCommandf(205,far);
- sendCommandf(206,distance);
+ sendCommandf(205,-far);
+ sendCommandf(206,-distance);
}
Paco
pspaudiolib doesn't support user-specified data for callbacks, which can be a pain for any serious use. Of course this renders existing code unusable, but better now than never. Oh well you lot choose if it's worth it or apps should use a tweaked version of the lib (which is what I do).
and
Code: Select all
--- pspaudiolib.c 2005-10-04 09:02:18.687500000 +0200
+++ m_pspaudiolib.c 2005-10-12 02:37:33.765625000 +0200
@@ -33,14 +33,17 @@
void pspAudioChannelThreadCallback(int channel, void *buf, unsigned int reqn)
{
- void (*callback)(void *buf, unsigned int reqn);
+ pspAudioCallback_t callback; /* No idea what this is for anyway */
callback=AudioStatus[channel].callback;
}
-void pspAudioSetChannelCallback(int channel, void *callback)
+void pspAudioSetChannelCallback(int channel, pspAudioCallback_t callback, void *pdata)
{
- AudioStatus[channel].callback=callback;
+ volatile psp_audio_channelinfo *pci = &AudioStatus[channel];
+ pci->callback=0;
+ pci->pdata=pdata;
+ pci->callback=callback;
}
int pspAudioOutBlocking(unsigned int channel, unsigned int vol1, unsigned int vol2, void *buf)
@@ -59,10 +62,10 @@
while (audio_terminate==0) {
void *bufptr=&audio_sndbuf[channel][bufidx];
- void (*callback)(void *buf, unsigned int reqn);
+ pspAudioCallback_t callback;
callback=AudioStatus[channel].callback;
if (callback) {
- callback(bufptr, PSP_NUM_AUDIO_SAMPLES);
+ callback(bufptr, PSP_NUM_AUDIO_SAMPLES, AudioStatus[channel].pdata);
} else {
unsigned int *ptr=bufptr;
int i;
@@ -96,6 +99,7 @@
AudioStatus[i].volumeright = PSP_VOLUME_MAX;
AudioStatus[i].volumeleft = PSP_VOLUME_MAX;
AudioStatus[i].callback = 0;
+ AudioStatus[i].pdata = 0;
}
for (i=0; i<PSP_NUM_AUDIO_CHANNELS; i++) {
if ((AudioStatus[i].handle = sceAudioChReserve(-1,PSP_NUM_AUDIO_SAMPLES,0))<0)
Code: Select all
--- pspaudiolib.h 2005-10-04 09:02:18.546875000 +0200
+++ m_pspaudiolib.h 2005-10-12 02:34:34.500000000 +0200
@@ -22,12 +22,15 @@
#define PSP_NUM_AUDIO_SAMPLES 1024
#define PSP_VOLUME_MAX 0x8000
+typedef void (* pspAudioCallback_t)(short *buf, unsigned long reqn, void *pdata);
+
typedef struct {
int threadhandle;
int handle;
int volumeleft;
int volumeright;
- void (*callback)(void *buf, unsigned int reqn);
+ pspAudioCallback_t callback;
+ void *pdata;
} psp_audio_channelinfo;
typedef int (* pspAudioThreadfunc_t)(int args, void *argp);
@@ -38,7 +41,7 @@
void pspAudioSetVolume(int channel, int left, int right);
void pspAudioChannelThreadCallback(int channel, void *buf, unsigned int reqn);
-void pspAudioSetChannelCallback(int channel, void *callback);
+void pspAudioSetChannelCallback(int channel, pspAudioCallback_t callback, void *pdata);
int pspAudioOutBlocking(unsigned int channel, unsigned int vol1, unsigned int vol2, void *buf);
#ifdef __cplusplus
Paco
Cool my first patch! :) I'm curious, why should the callback receive a void* instead of a short*, if the buffer *is* made up of 16-bit signed samples? I ask so I know what the philosophy is and keep it in mind for any further patches. I'm usually quite anal with strong typing and avoiding typecasts whenever I can (10 years of C++ does that to you).
Oh and pspAudioSetChannelCallbackEx() is SO Win32. :)
Oh and pspAudioSetChannelCallbackEx() is SO Win32. :)
Paco
When I changed my engine to send right-handed coordinates to the lighting step, fog went back to work as expected. It would seem the arguments to this function are expected to be the negated fognear and fogfar *in view space* (i.e. after modelview and before projection). So if you're using right-handed coordinate system you pass positive values to the original function; if you're using left-handed coordinate system, you need to pass negative values. Most engines expect you to pass *distances* to the fog functions (i.e. positive znear and zfar regardless of your handedness).Paco wrote:Monkeying around with the fog in Gu, I couldn't get it to work until I negated the near and far parameters.
As a side note, this would imply that fog is calculated per vertex, not per pixel, and therefore would not be 100% accurate when polygons stride across a fog boundary.
So, again, your choice to change this behaviour. My patched version seems more in line with what the hardware expects of this command, but since the PSP hardware behaves better with right-handed coordinate systems (due to the way it calculates specular lighting, see other thread), the current version of this function would be more intuitive to use. Still, some comment about this in the header might be useful.
Paco
Fix for signals in pspgu library. GE signals can be used with pspgu API from now on!
I will update my signals sample with pspgu API support and post it shortly.
EDIT: The sample is here: http://rej.50megs.com/psp/libgu_signals/
Code: Select all
Index: callbackFin.c
===================================================================
--- callbackFin.c (revision 1157)
+++ callbackFin.c (working copy)
@@ -10,7 +10,7 @@
void callbackFin(int id, void* arg)
{
- GuSettings* settings = (GuSettings*)settings;
+ GuSettings* settings = (GuSettings*)arg;
if (settings->fin)
settings->fin(id & 0xffff);
}
Index: sceGuInit.c
===================================================================
--- sceGuInit.c (revision 1157)
+++ sceGuInit.c (working copy)
@@ -52,10 +52,8 @@
callback.signal_arg = &gu_settings;
callback.finish_func = callbackFin;
callback.finish_arg = &gu_settings;
- gu_settings.ge_callback_id = 0;
-/*
- gu_settings.ge_callback_id = sceGeSetCallback(&gu_callback);
-*/
+ gu_settings.ge_callback_id = sceGeSetCallback(&callback);
+
ge_edram_address = sceGeEdramGetAddr();
// initialize graphics hardware
EDIT: The sample is here: http://rej.50megs.com/psp/libgu_signals/
Last edited by ReJ on Thu Oct 20, 2005 5:03 am, edited 1 time in total.
Minor typo fix in build.mak and build_prx.mak
Doesn't actually fix anything, but hey! ;-)
Code: Select all
Index: src/base/build.mak
===================================================================
--- src/base/build.mak (revision 1715)
+++ src/base/build.mak (working copy)
@@ -53,7 +53,7 @@
ifeq ($(USE_KERNEL_LIBC),1)
# Use the PSP's kernel libc
-PSPSDL_LIBC_LIB =
+PSPSDK_LIBC_LIB =
CFLAGS := -I$(PSPSDK)/include/libc $(CFLAGS)
else
ifeq ($(USE_PSPSDK_LIBC),1)
Index: src/base/build_prx.mak
===================================================================
--- src/base/build_prx.mak (revision 1715)
+++ src/base/build_prx.mak (working copy)
@@ -36,7 +36,7 @@
ifeq ($(USE_KERNEL_LIBC),1)
# Use the PSP's kernel libc
-PSPSDL_LIBC_LIB =
+PSPSDK_LIBC_LIB =
CFLAGS := -I$(PSPSDK)/include/libc $(CFLAGS)
else
ifeq ($(USE_PSPSDK_LIBC),1)
-penfold
Re: Minor typo fix in build.mak and build_prx.mak
It was found, as documented in the PRX thread, that the -mno-explicit-relocs CFLAG is required in libraries for PRXs to correctly access global static data (and other?).
For PSPRadio, I patched newlib (absolutely needed to use the flag), pspsdk (not sure if it needs the flag, but it doesn't seem to hurt), zlib, libpng and libmad.
newlib:
pspsdk:
zlib:
libpng:
libmad: (Also removed 2 compiler warnings by using -DHAVE_ASSERT_H)
Hope you can commit these changes, so other developer can start using PRXs. Plus it would relieve me from maintaining patches in PSPRadio.
Other libraries will probably need to be patched as well; I presume.
Thanks!,
Raf.
For PSPRadio, I patched newlib (absolutely needed to use the flag), pspsdk (not sure if it needs the flag, but it doesn't seem to hurt), zlib, libpng and libmad.
newlib:
Code: Select all
Index: newlib/configure.host
===================================================================
--- newlib/configure.host (revision 1808)
+++ newlib/configure.host (working copy)
@@ -574,7 +574,7 @@
mipsallegrex*-psp-*)
sys_dir=psp
syscall_dir=syscalls
- newlib_cflags="${newlib_cflags} -G0 -DCOMPACT_CTYPE -DCLOCK_PROVIDED -DMALLOC_ALIGNMENT=16 -I${prefix}/psp/sdk/include" ;;
+ newlib_cflags="${newlib_cflags} -G0 -mno-explicit-relocs -DCOMPACT_CTYPE -DCLOCK_PROVIDED -DMALLOC_ALIGNMENT=16 -I${prefix}/psp/sdk/include" ;;
*)
newlib_cflags="${newlib_cflags} -DMISSING_SYSCALL_NAMES" ;;
esac
Code: Select all
Index: pspsdk/configure.ac
===================================================================
--- pspsdk/configure.ac (revision 1816)
+++ pspsdk/configure.ac (working copy)
@@ -66,7 +66,7 @@
AC_SUBST(PSPSDK_LIBDIR)
# CFLAGS and CXXFLAGS used to build pspsdk libraries.
-PSPSDK_CFLAGS="$CFLAGS -G0 -Wall"
+PSPSDK_CFLAGS="$CFLAGS -mno-explicit-relocs -G0 -Wall"
PSPSDK_CXXFLAGS="$PSPSDK_CFLAGS -fno-exceptions -fno-rtti"
AC_SUBST(PSPSDK_CFLAGS)
AC_SUBST(PSPSDK_CXXFLAGS)
Code: Select all
Index: zlib/Makefile
===================================================================
--- zlib/Makefile (revision 1816)
+++ zlib/Makefile (working copy)
@@ -4,7 +4,7 @@
OBJS = adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o \
zutil.o inflate.o infback.o inftrees.o inffast.o
-CFLAGS = -O2 -G0
+CFLAGS = -O2 -G0 -mno-explicit-relocs
include $(PSPSDK)/lib/build.mak
Code: Select all
Index: libpng/Makefile
===================================================================
--- libpng/Makefile (revision 1816)
+++ libpng/Makefile (working copy)
@@ -5,7 +5,7 @@
pngread.o pngrio.o pngrtran.o pngrutil.o pngset.o \
pngtrans.o pngwio.o pngwrite.o pngwtran.o pngwutil.o
-CFLAGS = -O2 -G0
+CFLAGS = -O2 -G0 -mno-explicit-relocs
include $(PSPSDK)/lib/build.mak
Code: Select all
Index: libmad/src/Makefile
===================================================================
--- libmad/src/Makefile (revision 1816)
+++ libmad/src/Makefile (working copy)
@@ -5,7 +5,7 @@
OBJS = bit.o decoder.o fixed.o frame.o huffman.o layer12.o layer3.o \
stream.o synth.o timer.o version.o
-CFLAGS += -DHAVE_CONFIG_H -DHAVE_SYS_TYPES_H -DHAVE_ERRNO_H -DHAVE_UNISTD_H \
+CFLAGS += -DHAVE_ASSERT_H -G0 -mno-explicit-relocs -DHAVE_CONFIG_H -DHAVE_SYS_TYPES_H -DHAVE_ERRNO_H -DHAVE_UNISTD_H \
-DHAVE_FCNTL_H -I$(PSPSDK)/include/sys/ -I../include
include $(PSPSDK)/lib/build.mak
Hope you can commit these changes, so other developer can start using PRXs. Plus it would relieve me from maintaining patches in PSPRadio.
Other libraries will probably need to be patched as well; I presume.
Thanks!,
Raf.
Patches for SDL_mixer
I hope this is the correct place to post this. Here are two patches that fix SDL_mixer to compile for me.
First, since I already have libmikmod on my system, SDL_mixer's configure finds libmikmod-config and uses that to set up library paths. This patch to configure.in prevents it from using libmikmod-config when host is set to psp.
The second one is to the README.PSP. Since the README.PSP for the SDL package runs configure with --prefix=$(psp-config --psp-prefix), that puts the libSDL library into /usr/local/pspdev/psp/lib, but the SDL_mixer configure line only put /usr/local/pspdev/psp/sdk/lib into LD_FLAGS. Again, for me now SDL_mixer would find the incorrect libSDL in my /usr/lib instead of in the pspdev area.
First, since I already have libmikmod on my system, SDL_mixer's configure finds libmikmod-config and uses that to set up library paths. This patch to configure.in prevents it from using libmikmod-config when host is set to psp.
The second one is to the README.PSP. Since the README.PSP for the SDL package runs configure with --prefix=$(psp-config --psp-prefix), that puts the libSDL library into /usr/local/pspdev/psp/lib, but the SDL_mixer configure line only put /usr/local/pspdev/psp/sdk/lib into LD_FLAGS. Again, for me now SDL_mixer would find the incorrect libSDL in my /usr/lib instead of in the pspdev area.
Code: Select all
58> svn diff configure.in
Index: configure.in
===================================================================
--- configure.in (revision 2042)
+++ configure.in (working copy)
@@ -112,7 +112,11 @@
[ --enable-music-libmikmod enable MOD music via externl libmikmod [default=yes]],
, enable_music_libmikmod=yes)
if test x$enable_music_libmikmod = xyes; then
- AC_PATH_PROG(LIBMIKMOD_CONFIG, libmikmod-config, no, [$PATH])
+ if test x$host_alias = xpsp; then #Don't use the host's libmikmod when building for the PSP.
+ LIBMIKMOD_CONFIG=no
+ else
+ AC_PATH_PROG(LIBMIKMOD_CONFIG, libmikmod-config, no, [$PATH])
+ fi
if test "$LIBMIKMOD_CONFIG" = "no" ; then
no_libmikmod=yes
else
Code: Select all
61> svn diff README.PSP
Index: README.PSP
===================================================================
--- README.PSP (revision 2042)
+++ README.PSP (working copy)
@@ -12,7 +12,7 @@
To configure:
./autogen.sh
- LDFLAGS="-L$(psp-config --pspsdk-path)/lib -lc -lpspuser" \
+ LDFLAGS="-L$(psp-config --pspsdk-path)/lib -L$(psp-config --psp-prefix)/lib -lc -lpspuser" \
./configure --host psp --with-sdl-prefix=$(psp-config --psp-prefix) \
--disable-music-mp3 --prefix=$(psp-config --psp-prefix)
Re: Patches for SDL_mixer
I think the "--enable-music-libmikmod=no" option should have the same effect, could you test that instead? The fewer changes we have to make to the libraries makes it easier if we ever want to update them to newer versions.Renfield wrote:First, since I already have libmikmod on my system, SDL_mixer's configure finds libmikmod-config and uses that to set up library paths. This patch to configure.in prevents it from using libmikmod-config when host is set to psp.
Are you sure? The --with-sdl-prefix option should already take care of telling it which SDL to use. Look in acinclude.m4: it uses --with-sdl-prefix to find /usr/local/pspdev/psp/bin/sdl-config, which creates the correct library search path. If that's not working right, could you send a copy of the config.log?The second one is to the README.PSP. Since the README.PSP for the SDL package runs configure with --prefix=$(psp-config --psp-prefix), that puts the libSDL library into /usr/local/pspdev/psp/lib, but the SDL_mixer configure line only put /usr/local/pspdev/psp/sdk/lib into LD_FLAGS. Again, for me now SDL_mixer would find the incorrect libSDL in my /usr/lib instead of in the pspdev area.
I have found that if I use the --enable-music-libmikmod=no, then nothing is compiled in the mikmod directory. If I use --disable-music-mod, then configure still looks for libmikmod-config, and finds it on my computer. Ultimately I want the MOD functionality for the application I am programming.
I have found also that I need to run --enable-music-wave=no or else when I compile my own application I get this error:
And finally even after all that when I try to load a mod format audio file from my program I get an error that says "Module format not recognized".
Actually this is probably getting rather off topic. Maybe I should start another topic to address these problems.
I have found also that I need to run --enable-music-wave=no or else when I compile my own application I get this error:
Code: Select all
/usr/local/pspdev/psp/lib/libSDL_mixer.a(wavestream.o): In function `WAVStream_PlaySome':
/usr/src/SDL_mixer/wavestream.c:196: undefined reference to `SDL_MixAudio'
/usr/src/SDL_mixer/wavestream.c:196: undefined reference to `SDL_MixAudio'
Actually this is probably getting rather off topic. Maybe I should start another topic to address these problems.
I just tested it: "--disable-music-libmikmod --enable-music-mod" is the correct way to force use of the included mikmod. I'll add that to the README.PSP.
SDL_MixAudio is defined by libSDL.a. If it's undefined, it's because you have the incorrect link order; verify that -lSDL_mixer comes before the SDL libs on the linker command line.
Yeah, this topic is for submitting new samples, so starting new topics would be more appropriate in the future.
SDL_MixAudio is defined by libSDL.a. If it's undefined, it's because you have the incorrect link order; verify that -lSDL_mixer comes before the SDL libs on the linker command line.
Yeah, this topic is for submitting new samples, so starting new topics would be more appropriate in the future.
Some time ago InsertWittyName noticed some artifacts on fullscreen textures in ortho view. I had some similar problems with some textures in 2D mode too, so we started to wonder what caused that.
After some fiddling with the vertice coordinates and ortho view parameters, that didn't lead to a sufficing solution.
Now IWN found that PSPGL produced correct results with the same ortho setup, so the problem was found pretty soon after: sceGuViewport is wrongly submitting the height parameter.
Here's the patch:
Not sure why chp (?) added that sign bit, maybe a leftover from ps1 coding(?), but it lead to some rare artifacts with textures. Hope the patch is applied soon :)
@chp next time better listen to IWN/Insomniac when he says there's something buggy ;)
After some fiddling with the vertice coordinates and ortho view parameters, that didn't lead to a sufficing solution.
Now IWN found that PSPGL produced correct results with the same ortho setup, so the problem was found pretty soon after: sceGuViewport is wrongly submitting the height parameter.
Here's the patch:
Code: Select all
--- sceGuViewport_old.c 2005-09-28 00:02:16.000000000 +0200
+++ sceGuViewport.c 2006-11-22 21:01:32.281250000 +0100
@@ -11,7 +11,7 @@
void sceGuViewport(int cx, int cy, int width, int height)
{
sendCommandf(66,(float)(width>>1));
- sendCommandf(67,(float)(((-height) + ((-height) >> 31))>>1));
+ sendCommandf(67,(float)((-height)>>1));
sendCommandf(69,(float)cx);
sendCommandf(70,(float)cy);
}
@chp next time better listen to IWN/Insomniac when he says there's something buggy ;)
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl
sceGumScale
Hi,
I wanted to check the status of the sceGumScale fix suggested above. I'm using a precompiled SDK for Win32 from http://xorloser.com/ .
AFAIK it uses the SDK from SVN dated 2nd December 2006, but because I don't have the source I can't verify that the above fix is in my version.
The bug I'm seeing is that if I perform the following:
sceGumTranslate
sceGumRotateZ
sceGumRotateY
sceGumRotateX
sceGumScale
The object gets warped and sheared. However if I make up the scaling matrix manually and call sceGumMultMatrix, it's all fine.
I suspect that this is down to sceGumScale either:
1. still having the above bug in it, or
2. being optimised in a way that it doesn't anticipate a rotation being done first.
I hope this post helps anyone who is experiencing the same issue.
I wanted to check the status of the sceGumScale fix suggested above. I'm using a precompiled SDK for Win32 from http://xorloser.com/ .
AFAIK it uses the SDK from SVN dated 2nd December 2006, but because I don't have the source I can't verify that the above fix is in my version.
The bug I'm seeing is that if I perform the following:
sceGumTranslate
sceGumRotateZ
sceGumRotateY
sceGumRotateX
sceGumScale
The object gets warped and sheared. However if I make up the scaling matrix manually and call sceGumMultMatrix, it's all fine.
I suspect that this is down to sceGumScale either:
1. still having the above bug in it, or
2. being optimised in a way that it doesn't anticipate a rotation being done first.
I hope this post helps anyone who is experiencing the same issue.
http://aaiiee.wordpress.com/
I can no longer do any homebrew PSP development nor discuss PSP specific topics.
I can no longer do any homebrew PSP development nor discuss PSP specific topics.