forums.ps2dev.org

Hum, and an other little question, what's missing/the we should implement/... on the m.e side to have threads support ???? (as it's done on the core side, without reimplementing the wheel)

Short question, what do we have in 0xbc100080 ?????? (And the value 7 for ?)
Shouldn't it be 0xbc100050 to enable the ME clock ?

Thx

That's weird... what makes you think that the voume controlled by those two ghost buttons and the volume controlled by soft are the same (and not as I was wondering speaker vs chip volumes) ? That's so strange how they seem both decoupled... Do we have some hardware audio registers ? Time to look at...

Even in kernel mode ?

Ok I did not catch the goal was to get the volume set by the +/- buttons... It seems (or I'm wrong) that there is physical volume (speakers) and logical volume (audio).... I did not try to catch +/- pad events to modifiy the "soft" volume instead...should be feasible, not ? Else.... dunno :D

I agree :D That was why I mentioned "At least if your app is using pspaudiolib" as at init, the volume is init'd to the max. So that's a little virtual :D but enough ? Else.. you can use int sceAudioChangeChannelVolume(int channel, int leftvol, int rightvol); Set it then yo...

Look in pspaudiolib static psp_audio_channelinfo AudioStatus[PSP_NUM_AUDIO_CHANNELS]; typedef struct { int threadhandle; int handle; int volumeleft; int volumeright; pspAudioCallback_t callback; void *pdata; } psp_audio_channelinfo; At least if your app is using psp...

MSN said me that I should not give any code anywhere.... but I've got one too....

Bahhhh where's Mr Closer ??? :D

Hello, That's not exactly an issue, more a lack of understanding.... Let's say I've got a sphere, which is envmapped (as done i nthe PSPSDK sample) using a classic environment mapping texture (kind of spherical glow). So that works. But then using the world matrix (sceGumMatrixMode(GU_MODEL);) I set...

Again, interesting tests chp ! I looked at the test code, hard to find what to optimize to achieve the "Graphics sub-system running at 166 MHz on a 512-bit bus with 2 MB of DRAM, rendering [...] 35 million polygons per second" (sic) (what's a polygon ? 3 vertices ?) Or maybe, as the PS2, t...

480x272 could be a bad size since it clips the last 64-width block in half, which makes 32-texel slices better when going fullscreen directly. Have you seen the presentation about the PSP from Breakpoint 2005? Yes really makes sense... I'll try to test the stuff in 448x256, just to see... if it's l...

I took a few minutes to pass all the tests...results are interesting :D Forgive me, I just took the integer value :D Results are in frames per second, red is the best value, texture is 512x512 http://tmpstore.free.fr/blog/BenchsSpeed.png So 64 pixels slices seems still to be the best value except fo...

Good job chp ! And it answers top my past question ( http://forums.ps2dev.org/viewtopic.php?t=4368 ) ! I did some tests too (not so precise unfortunately) and yes I found too that sometimes slices of 64 pixels is not a good choice (5551). But not always... Interesting thing maybe to test (as I found...

I know many posts were already posted on the topic but... still very unclear for me as I never solved the following issue. If a texture is directly set in VRAM (not using sceGuCopyImage but directly writing the texture in the VRAM address), is it : - possible to swizzle it (I was not able..) ? - if ...

oh that's interesting... I did not try using a "column" approach... I'll try too !

Obviously, rather than only asking questions, I write some tests... And despite many some wrong conclusions, here are some stuff I found and many some talks would confirm or not... 1. It seems better to call sceGuGetMemory() one time with a bigger vertex list than in a loop (for smaller vertex list ...

Thanks both for the answers... it really helps. Maybe can I add some new questions ? 1. Swizzling textures : So whatever the format, that's better, but, according to the time needed to swizzle a texture, should we swizzle only static textures (images...) or realtime generated textures too (render ta...

Humm that's an idea... I was thinking more of measuring the time of my different routines than the time that the GE/GU takes to handle the display lists... but that's a very fair statement... thx ! So while speaking of this kind of stuff, maybe you'll have some answers to a list of dumb questions : ...

Hello, I'd like to know what is the easiest way to measure graphical routines CPU(/GPU ?) usage (not using PSPGL, only PSPSDK/GU/GUM libs). If it's still possible to measure, like in the old days, more or less tme used by each routine by changing the bgcolor, stuff like that... Thanks ! (And if you'...

what a good question :D

I wonder if the timers are configurable as they were on the PS2 (bus clock, HBL, VBL,...), the resolution (16b ? 32b ?) and so on...

Ah ah works perfect !

You're a master Marcus ;-)

Many thanks !

Hello,

I'm porting a piece of code using ntohl, ntohs Byte Order Conversion functions. Shouldn't we have then in the toolchain ? Else does somebody have a simple stub or implementation for them ?

Thanks

I was wondering if ODE examples should compile, I've got this pspgl error : $ make drawstuff-test psp-ar rc lib/libdrawstuff.a drawstuff/src/drawstuff.o drawstuff/src/psp.o psp-ranlib lib/libdrawstuff.a psp-gcc -c -Wall -fno-rtti -fno-exceptions -Wall -I/usr/local/pspdev/psp/sdk/include -g -Iinclude...

Can somebody tell me what's wrong with this stub ?

STUB_START "sceDmac",0x40010000,0x00010005
STUB_FUNC 0x617f3fe6,sceDmacMemcpy
STUB_END

is the linkage module flag 0x40010000 wrong ?

Calling sceDmacMemcpy, causes a bus error in my app... :(

Congrats Tyranid !

Good work, I'm hurry to get Tmator build the SIO cable... I'm slap him hard if needed !

Good work as usual !

It should but it seems newlib libc is not supported by the pspsdk PRX... (see raf posts)

Perfect :D

Thanks Jim !

I saw that audiolib changed...

Now the callback registration process need one more arg :
What should we put into pdata ????

Can someone provide a short example ?

Using this configuration line : LDFLAGS="-L`psp-config --pspsdk-path`/lib -lz -lc -lpspdebug -lpspdisplay -lpspge -lpspctrl -lpspsdk -lpsputility -lpspuser -lpspkernel" CFLAGS="-G0 -I`psp-config --pspsdk-path`/include -I`psp-config --pspdev-path`/psp/include" ./configure --host p...

Ok found, it was due to this include : -I/usr/local
/pspdev/psp/sdk/include/libc as the pspsdk libc doesn't implement malloc

Is it something missing ? Who's working on the pspsdk libc ? Maybe I can help...