SDL: Compiling for 3.xx and Video Modes

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
Saracchini
Posts: 3
Joined: Wed Aug 22, 2007 10:26 am

SDL: Compiling for 3.xx and Video Modes

Post by Saracchini »

Hy, i new here and i trying to port my SDL aplications to PSP.
I sucessfully installed the SDK and SDL and tried port my first test application, an BOx2D debug renderer and it worked fine ...in fact it is more faster than i expected !

The problem is that the EBOOT runs only in kernel 1.50 code... i tried run the patch found in one post here with the last revision (2380) but no succes... the patch says that some HUNKS failed and when i compile SDL and my application it wont run in 3.xx mode.

Another problem that i found is some video modes crashes my PSP. I´m using these videoflags:

Code: Select all

SDL_SWSURFACE|SDL_FULLSCREEN|SDL_HWPALETTE
And 320x240 resolution with 8 bit depth.
but i want know the resolutions and flags supported by PSP SDL.

Thanks for the attention.
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

The problem is that the EBOOT runs only in kernel 1.50 code... i tried run the patch found in one post here with the last revision (2380) but no succes... the patch says that some HUNKS failed and when i compile SDL and my application it wont run in 3.xx mode.
If you have hunks failing, you're not patching it right, and so it's not a surprise that it doesn't work. Just update your svn to the latest version, there's no reason to patch it yourself anyway.
Another problem that i found is some video modes crashes my PSP
What do you mean crashes? SetVideoMode will return an error if you pass it something invalid, so just check the return values and you should be able to catch that.
And 320x240 resolution with 8 bit depth.
but i want know the resolutions and flags supported by PSP SDL.
Lots of resolutions should be supported (check the source) but in practice it doesn't make much sense to do anything other than 480x272.
Saracchini
Posts: 3
Joined: Wed Aug 22, 2007 10:26 am

Post by Saracchini »

I´ve just updated and recompiled entire toolchain and SDL library with the latest sources. And looking in the patch it´s clear that is not necessary patch the latest revision. But the 3.xx kernel problem remains yet...

This is my MakeFile:

Code: Select all

TARGET = Box
#OBJS = main.o
OBJS  =main.o Render.o Box2D/Source/Collision/b2TimeOfImpact.o Box2D/Source/Collision/b2BroadPhase.o Box2D/Source/Collision/b2CollideCircle.o Box2D/Source/Collision/b2CollidePoly.o Box2D/Source/Collision/b2Collision.o Box2D/Source/Collision/b2Distance.o Box2D/Source/Collision/b2PairManager.o Box2D/Source/Collision/Shapes/b2CircleShape.o Box2D/Source/Collision/Shapes/b2PolygonShape.o Box2D/Source/Collision/Shapes/b2Shape.o Box2D/Source/Common/b2BlockAllocator.o Box2D/Source/Common/b2Math.o Box2D/Source/Common/b2Settings.o Box2D/Source/Common/b2StackAllocator.o Box2D/Source/Dynamics/b2Body.o Box2D/Source/Dynamics/b2ContactManager.o Box2D/Source/Dynamics/b2Island.o Box2D/Source/Dynamics/b2World.o Box2D/Source/Dynamics/b2WorldCallbacks.o Box2D/Source/Dynamics/Joints/b2DistanceJoint.o Box2D/Source/Dynamics/Joints/b2GearJoint.o Box2D/Source/Dynamics/Joints/b2Joint.o Box2D/Source/Dynamics/Joints/b2MouseJoint.o Box2D/Source/Dynamics/Joints/b2PrismaticJoint.o Box2D/Source/Dynamics/Joints/b2PulleyJoint.o Box2D/Source/Dynamics/Joints/b2RevoluteJoint.o Box2D/Source/Dynamics/Contacts/b2CircleContact.o Box2D/Source/Dynamics/Contacts/b2Contact.o Box2D/Source/Dynamics/Contacts/b2ContactSolver.o Box2D/Source/Dynamics/Contacts/b2PolyAndCircleContact.o Box2D/Source/Dynamics/Contacts/b2PolyContact.o 
LINKOBJ  = main.o Render.o Box2D/Source/Collision/b2TimeOfImpact.o Box2D/Source/Collision/b2BroadPhase.o Box2D/Source/Collision/b2CollideCircle.o Box2D/Source/Collision/b2CollidePoly.o Box2D/Source/Collision/b2Collision.o Box2D/Source/Collision/b2Distance.o Box2D/Source/Collision/b2PairManager.o Box2D/Source/Collision/Shapes/b2CircleShape.o Box2D/Source/Collision/Shapes/b2PolygonShape.o Box2D/Source/Collision/Shapes/b2Shape.o Box2D/Source/Common/b2BlockAllocator.o Box2D/Source/Common/b2Math.o Box2D/Source/Common/b2Settings.o Box2D/Source/Common/b2StackAllocator.o Box2D/Source/Dynamics/b2Body.o Box2D/Source/Dynamics/b2ContactManager.o Box2D/Source/Dynamics/b2Island.o Box2D/Source/Dynamics/b2World.o Box2D/Source/Dynamics/b2WorldCallbacks.o Box2D/Source/Dynamics/Joints/b2DistanceJoint.o Box2D/Source/Dynamics/Joints/b2GearJoint.o Box2D/Source/Dynamics/Joints/b2Joint.o Box2D/Source/Dynamics/Joints/b2MouseJoint.o Box2D/Source/Dynamics/Joints/b2PrismaticJoint.o Box2D/Source/Dynamics/Joints/b2PulleyJoint.o Box2D/Source/Dynamics/Joints/b2RevoluteJoint.o Box2D/Source/Dynamics/Contacts/b2CircleContact.o Box2D/Source/Dynamics/Contacts/b2Contact.o Box2D/Source/Dynamics/Contacts/b2ContactSolver.o Box2D/Source/Dynamics/Contacts/b2PolyAndCircleContact.o Box2D/Source/Dynamics/Contacts/b2PolyContact.o
PSPSDK_LIBC_LIB = -lm -lstdc++ -lpsplibc -lpspglue -lc 

PSPSDK = $(shell psp-config --pspsdk-path)
PSPBIN = $(shell psp-config --psp-prefix)/bin
SDL_CONFIG = $(PSPBIN)/sdl-config
DEFAULT_CFLAGS = $(shell $(SDL_CONFIG) --cflags)

MORE_CFLAGS = -g -O2


BUILD_PRX = 1
PSP_FW_VERSION = 352 

CFLAGS = $(DEFAULT_CFLAGS) $(MORE_CFLAGS) 
CXXFLAGS = $(DEFAULT_CFLAGS) $(MORE_CFLAGS) -fno-exceptions 

LIBS = -lSDL $(shell $(SDL_CONFIG) --libs) -lstdc++

EXTRA_TARGETS = EBOOT.PBP

include $(PSPSDK)/lib/build.mak
If i comment the BUILD_PRX and PSP_FW_VERSION the aplication runs fine in kernel 150 mode, but when these flags are enabled it compiles fine but my PSP gives me an 800200D9 error.

Entire project can be downloaded HERE, but BOX2D library is fully portable and Render.cpp is only the callbacks provided to the class DebugDraw with SDL functions. I think that the problem is in main.cpp
What do you mean crashes? SetVideoMode will return an error if you pass it something invalid, so just check the return values and you should be able to catch that.
It showed me a ble screen with "Sorry, but your PSP has crashed..." and etc... but i checked and it was fault of my code, not of SDL. Now it runs without problems with 480x272 screen mode.

Thanks for the response.
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

I just build a new copy of the toolchain and libraries (using psptoolchain and psplibraries) on a new machine, and I don't get the 800200D9 error when I compile your application and run it on 3.90M33-2. It doesn't display anything and eventually powers off the PSP, but I don't get that error, so there must be something different or still not fully updated in your toolchain.

About the crash, other SDL applications work fine, so I think it' ssomething in the Box code...
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

One thing I noticed in the new SDL code is that it sets the thread stack size to be TINY (32 kB). That's not good... not good at all. I've seen programs that need a stack that's at least 1 MB to run correctly. The PSP header stuff needs to be removed from SDL main and into the dev's program. Setting the heap size and thread stack size inside SDL main is bad - the dev has no control over something he needs full control over. For example, the heap size is hard coded in SDL main to 20 MB. But suppose the program is too big to allow that - SNES9xTYL uses a heap size of 14 MB. You certainly couldn't do an SDL version using SDL main the way it is now. As it stands, you STILL need to not use SDL main for SDL programs on the PSP unless it's something simple (i.e., not useful).
Saracchini
Posts: 3
Joined: Wed Aug 22, 2007 10:26 am

Post by Saracchini »

The thing that i dont understant it's why this program runs perfectly when i compile it for kernel 1.50... the animation and BOX2D library calls works without problems... i tried change the heap size and thread stack size but it aways gave me the same error... if i remove the SDL_main reference and set these settings (sdl_psp_exit_callback,sdl_psp_callback_thread,PSP_HEAP_SIZE_KB,etc...) in main.cpp it shows black screen and resets PSP.
With simple SDL programs (including one posted in another "SDL with 3.xx" thread of this forum) i have exactly the same problem... PSP resets with black screen.

I updated everything in PSP toolchain and SDL with the latest sources of the repository...

The programs running in x86 platfomrs (Windows & Linux) uses about 5 MB of memory... i dont know if it will be the same for PSP , but i think that BOX2D is not the main problem... it worked even in my port for old Symbian phones...

-----------EDIT---------------------


I fixed my makefile... i just removed entire references to SDL_main from the makefile, corrected my implemetations of CallbackThread and ExitCallback and called PSP_HEAP_SIZE_MAX withou parameters... it compiled and worked perfectly...

my makefile now is like this:

Code: Select all

TARGET = Box

OBJS  =main.o Render.o Box2D/Source/Collision/b2TimeOfImpact.o Box2D/Source/Collision/b2BroadPhase.o Box2D/Source/Collision/b2CollideCircle.o Box2D/Source/Collision/b2CollidePoly.o Box2D/Source/Collision/b2Collision.o Box2D/Source/Collision/b2Distance.o Box2D/Source/Collision/b2PairManager.o Box2D/Source/Collision/Shapes/b2CircleShape.o Box2D/Source/Collision/Shapes/b2PolygonShape.o Box2D/Source/Collision/Shapes/b2Shape.o Box2D/Source/Common/b2BlockAllocator.o Box2D/Source/Common/b2Math.o Box2D/Source/Common/b2Settings.o Box2D/Source/Common/b2StackAllocator.o Box2D/Source/Dynamics/b2Body.o Box2D/Source/Dynamics/b2ContactManager.o Box2D/Source/Dynamics/b2Island.o Box2D/Source/Dynamics/b2World.o Box2D/Source/Dynamics/b2WorldCallbacks.o Box2D/Source/Dynamics/Joints/b2DistanceJoint.o Box2D/Source/Dynamics/Joints/b2GearJoint.o Box2D/Source/Dynamics/Joints/b2Joint.o Box2D/Source/Dynamics/Joints/b2MouseJoint.o Box2D/Source/Dynamics/Joints/b2PrismaticJoint.o Box2D/Source/Dynamics/Joints/b2PulleyJoint.o Box2D/Source/Dynamics/Joints/b2RevoluteJoint.o Box2D/Source/Dynamics/Contacts/b2CircleContact.o Box2D/Source/Dynamics/Contacts/b2Contact.o Box2D/Source/Dynamics/Contacts/b2ContactSolver.o Box2D/Source/Dynamics/Contacts/b2PolyAndCircleContact.o Box2D/Source/Dynamics/Contacts/b2PolyContact.o 
LINKOBJ  = main.o Render.o Box2D/Source/Collision/b2TimeOfImpact.o Box2D/Source/Collision/b2BroadPhase.o Box2D/Source/Collision/b2CollideCircle.o Box2D/Source/Collision/b2CollidePoly.o Box2D/Source/Collision/b2Collision.o Box2D/Source/Collision/b2Distance.o Box2D/Source/Collision/b2PairManager.o Box2D/Source/Collision/Shapes/b2CircleShape.o Box2D/Source/Collision/Shapes/b2PolygonShape.o Box2D/Source/Collision/Shapes/b2Shape.o Box2D/Source/Common/b2BlockAllocator.o Box2D/Source/Common/b2Math.o Box2D/Source/Common/b2Settings.o Box2D/Source/Common/b2StackAllocator.o Box2D/Source/Dynamics/b2Body.o Box2D/Source/Dynamics/b2ContactManager.o Box2D/Source/Dynamics/b2Island.o Box2D/Source/Dynamics/b2World.o Box2D/Source/Dynamics/b2WorldCallbacks.o Box2D/Source/Dynamics/Joints/b2DistanceJoint.o Box2D/Source/Dynamics/Joints/b2GearJoint.o Box2D/Source/Dynamics/Joints/b2Joint.o Box2D/Source/Dynamics/Joints/b2MouseJoint.o Box2D/Source/Dynamics/Joints/b2PrismaticJoint.o Box2D/Source/Dynamics/Joints/b2PulleyJoint.o Box2D/Source/Dynamics/Joints/b2RevoluteJoint.o Box2D/Source/Dynamics/Contacts/b2CircleContact.o Box2D/Source/Dynamics/Contacts/b2Contact.o Box2D/Source/Dynamics/Contacts/b2ContactSolver.o Box2D/Source/Dynamics/Contacts/b2PolyAndCircleContact.o Box2D/Source/Dynamics/Contacts/b2PolyContact.o

PSPSDK_LIBC_LIB = -lm -lstdc++ -lpsplibc -lpspglue -lc 

PSPSDK = $(shell psp-config --pspsdk-path)
PSPBIN = $(shell psp-config --psp-prefix)/bin
DEFAULT_CFLAGS = -I/usr/local/pspdev/psp/include/SDL
MORE_CFLAGS = -O2 -G0 -Wall -fno-exceptions 


BUILD_PRX = 1
PSP_FW_VERSION = 352 

CFLAGS = $(DEFAULT_CFLAGS) $(MORE_CFLAGS) 
CXXFLAGS = $(DEFAULT_CFLAGS) $(MORE_CFLAGS) -fno-exceptions 

#LIBS = -lSDL $(shell $(SDL_CONFIG) --libs) -lstdc++
LIBS = -lstdc++ -L/usr/local/pspdev/psp/lib -lSDL -lm -L/usr/local/pspdev/psp/sdk/lib -lpspdebug -lpspgu -lpspctrl -lpspge -lpspdisplay -lpsphprm -lpspsdk -lpsprtc -lpspaudio -lc -lpspuser -lpsputility -lpspkernel -lpspnet_inet

EXTRA_TARGETS = EBOOT.PBP

include $(PSPSDK)/lib/build.mak
Now i can think in some type of optmization for BOX2d library

Thanks for all the attention. !
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

It's EXACTLY what I said it was... not enough stack. I bumped the PSP_MAIN_THREAD_STACK_SIZE_KB to 1024 in SDL_main.cpp, recompiled SDL, then recompiled this test, and it works fine. I have no idea how it would work in 1.50 with the small stack... must be the stack in 1.50 is someplace where it doesn't crash immediately when you walk on the stack.

By the way, you aren't using sprintf right in your main. You don't have a buffer as msg is just a pointer, not a character array. You could allocate some memory for it, but you don't - then you free msg after the sprintf when it's not been initialize to begin with. I guess it's lucky that those SDL functions weren't failing. :)
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

J.F. wrote:One thing I noticed in the new SDL code is that it sets the thread stack size to be TINY (32 kB). That's not good... not good at all. I've seen programs that need a stack that's at least 1 MB to run correctly.
Agreed, it should just not specify it and use the default (256KB).
The PSP header stuff needs to be removed from SDL main and into the dev's program. Setting the heap size and thread stack size inside SDL main is bad - the dev has no control over something he needs full control over. For example, the heap size is hard coded in SDL main to 20 MB. But suppose the program is too big to allow that - SNES9xTYL uses a heap size of 14 MB. You certainly couldn't do an SDL version using SDL main the way it is now. As it stands, you STILL need to not use SDL main for SDL programs on the PSP unless it's something simple (i.e., not useful).
The idea of libSDLmain is to assist porting. In general, an application compiled to use SDL on a another platform can be recompiled "out of the box" and still work on the PSP (if it was written well) without modification.

Of course, if you need more control, then yeah, you just need to get rid of SDLmain and do it yourself. I don't think there's any other way to do it.
Well, let's see... The only thing we really need to specify is the PSP_MODULE_INFO. The PSP_HEAP_SIZE and PSP_MAIN_THREAD attributes are weakly linked and could be left out (and overridden by the user if they desire).

How about that solution? Just specify the bare minimum (PSP_MODULE_INFO) which should be right for 99.9% of the cases anyway (just a normal a user mode app).
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

jimparis wrote:
J.F. wrote:One thing I noticed in the new SDL code is that it sets the thread stack size to be TINY (32 kB). That's not good... not good at all. I've seen programs that need a stack that's at least 1 MB to run correctly.
Agreed, it should just not specify it and use the default (256KB).
The PSP header stuff needs to be removed from SDL main and into the dev's program. Setting the heap size and thread stack size inside SDL main is bad - the dev has no control over something he needs full control over. For example, the heap size is hard coded in SDL main to 20 MB. But suppose the program is too big to allow that - SNES9xTYL uses a heap size of 14 MB. You certainly couldn't do an SDL version using SDL main the way it is now. As it stands, you STILL need to not use SDL main for SDL programs on the PSP unless it's something simple (i.e., not useful).
The idea of libSDLmain is to assist porting. In general, an application compiled to use SDL on a another platform can be recompiled "out of the box" and still work on the PSP (if it was written well) without modification.

Of course, if you need more control, then yeah, you just need to get rid of SDLmain and do it yourself. I don't think there's any other way to do it.
Well, let's see... The only thing we really need to specify is the PSP_MODULE_INFO. The PSP_HEAP_SIZE and PSP_MAIN_THREAD attributes are weakly linked and could be left out (and overridden by the user if they desire).

How about that solution? Just specify the bare minimum (PSP_MODULE_INFO) which should be right for 99.9% of the cases anyway (just a normal a user mode app).
Sounds good to me. Leave it out of libSDLmain for weakly linked defaults, and the dev can add those PSP specific macros if and when needed.
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

Code: Select all

------------------------------------------------------------------------
r2381 | jim | 2008-04-15 01:27:52 -0400 (Tue, 15 Apr 2008) | 3 lines
Changed paths:
   M /trunk/SDL/src/main/psp/SDL_psp_main.c

Leave out anything that has a weakly-linked default, so the user can
override it if necessary.

------------------------------------------------------------------------
edit: Hmm, I just realized that this means that the defaults are no longer really usable, because DEFAULT_PRX_HEAP_SIZE_KB = 64, which is just too tiny for SDL. I really want the default to be (max-1024) unless the user specifies otherwise. Any ideas how to best implement that? I guess I could add a second weak export that just specifies what the default should be -- ie. libSDLmain defines

Code: Select all

int __pspsdk_default_heap_size = -1024;
and then newlib says (roughly)

Code: Select all

int heap_size = -1;
if (&__pspsdk_is_prx)
    heap_size = 64;
if (&__pspsdk_default_heap_size)
    heap_size = __pspsdk_default_heap_size;
if (&sce_newlib_heap_kb_size)
    heap_size = sce_newlib_heap_kb_size;
if (heap_size == -1)
    heap_size = sceKernelMaxFreeMemSize();
else if &#40;heap_size < -1&#41;
    heap_size = sceKernelMaxFreeMemSize&#40;&#41; + heap_size * 1024;
else
    heap_size *= 1024;
sceKernelAllocPartitionMemory&#40;..., heap_size, ... &#41;;
thoughts?
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

Yeah, it's time to add that (MAX - reserve) code to the heap size. That would be good for this SDL issue. I already posted some code on that earlier, but there's always another way to do it.
Post Reply