forums.ps2dev.org

evilo sent me a private email alerting me to this thread. Obviously I have to monitor the forums more closely! [Sorry for the length - got carried away.]

FWIW, I'm a senior instructor/curriculum designer for both J2EE and Game Development at NextGen Education (www.nextgened.com) and a system architect/project manager for DragonTale Productions (www.dragontale.com) in Detroit. (We make more than cars here... :-)

We're currently in the middle of a Game Development track which focuses on using PS2DEV for console development. The students started off learning game mechanics and fundamentals (like C/C++, objects, threads, events) using SDL in x86/Linux. They were also beginning their portfolio of relatively simple games in this stage. The next stage was porting it to the PS2. They had the option to either rewrite the low-level access in PS2DEV, or to port SDL to PS2DEV. We looked at the PS2LINUX port, and knew that it wasn't going to be straightforward from that perspective.

The universal consensus was to port SDL. It turned out to be more straightforward than we thought - although there was nothing in the PS2LINUX code we could use. We're about a month and a half into the project, and we hope to have some of the core available for porting in the next week or so.

We had many of the same discussions you've had here, which led to some of the design choices. I've personally had a heavy hand in this because it could take new students a year to accomplish it otherwise. I've been working with and watching PS2DEV grow up for two years now, and SDL for several more, and my architectural experience weighed in a lot as well. Here are some of the results:

There is no simple way to port SDL. Because there are multiple processors, there are multiple paths to porting.

Although we're focusing on portability, reconfigurability, and optional options (SDL is great for this - take what you need, leave the rest behind), we really only have time to get one path working well. We will probably also end up with an "everything on EE" path first, though, although we consider that far from ideal.

Our main focus right now is to get a lot of the low-level (threads, events, pad/joystick control, audio, cdrom) to work as an IRX on the IOP, and free up as much of the EE/VU as possible for regular gameplay.

SDLnet will also run on the IOP (keeps it closer to the TCP/IP and Ethernet stacks, freeing up more EE)

SDLttf and SDLgfx will probably run on the EE at first. These will eventually be flexible depending on usage - I'd ultimately prefer them on the IOP.

I'd also like to leave some CPU horsepower room open on the IOP for networked GSM conversations, speech synthesis and possibly recognition, but that's much farther down the road. We're looking at the possibility of using gameCoda (www.gamecoda.com) (a commercial library) later on as well.

Communication between EE and IOP will be done seemlessly through RPC so the effects of splitting the functionality on different processors won't be seen. We're not at this point yet, but we're getting there.

SDLopenGL is really up in the air at the moment. We chose to do 2D graphics before PS2 then 3D afterwards in the class, so we haven't had the need for it yet. We'll be tackling that in one of the upcoming segments.

We'll post the source as soon as we reasonably can. I'd like to see it eventually become a part of PS2SDK as an optional slightly-higher-than-bare-metal library to ease entry into PS2DEV coding. There are definitely times when coding to the bare-metal is necessary, but I only want to have to do that when it's really important - not for every little thing! And besides, portability is a good thing - especially if you can minimize performance loss. We think we've done/will do this in our split-processor port.

Calvin Vette

calvin-dragontale_com
calvin-nextgened_com

Calvin,

I think that it's excellent that you & your students are porting SDL to the PS2. I really believe that SDL can help ease the development pains associated with programming the PS2. Basically, IMO, a SDL port would enable people to port games, applications (music players, emulators), et al to PS2. In fact, there are currently 419 games written using SDL at http://www.libsdl.org/games.php & 99 aplications (music players, emulators, programmming software, video players. et al) at http://www.libsdl.org/applications.php .

Also Calvin, I saw that you mentioned that "Our main focus right now is to get a lot of the low-level (threads, events, pad/joystick control, audio, cdrom) to work as an IRX on the IOP, and free up as much of the EE/VU as possible for regular gameplay. ". I think that you should include memory card, HDD support (using LIBHDD) & Network adapter in the IRX section as well since there are a good amount of people who own the Network adpater & HDD (I own both).

Also Calvin, I saw that you mentioned that "Our main focus right now is to get a lot of the low-level (threads, events, pad/joystick control, audio, cdrom) to work as an IRX on the IOP, and free up as much of the EE/VU as possible for regular gameplay. ". I think that you should include memory card, HDD support (using LIBHDD) & Network adapter in the IRX section as well since there are a good amount of people who own the Network adpater & HDD (I own both).

Networking (SDLnet) is an essential part of the port in for our games (which are all network multiplayer), and will go into the IRX on top of SMAP (and other ethernet drivers as they become available) and TCPIP.

For the moment, there is no immediate plan to include libHDD. There is no SDL code to open or manage files. I personally would like to see this in SDL 2.0, as I think it could make a lot more code a lot more portable. But ANSI C isn't too bad from an SDL perspective. However, we're building on top of PS2SDK, so libHDD will be in there.

-cv

Calvin, great work. If you need a CVS repository to store the code in progress I'm happy for you to put it online here. *hint* *hint*

I'm also glad you're building on top of PS2SDK. It is still growing at the moment, and there are a few more features to be put in when I (or anyone else) gets time. The high priority list includes:

* Math Library (will use the port of Cephes library. http://ps2dev.org/kb.x?T=272)
* DmaLibrary (will use the code by ooPo. http://www.oopo.net/consoledev/)

With these in place I'd like to include some low level function to access GS, and then using these provide a very minimal sample graphics library. This could involve taking the BreakPoint demo library and splitting into low level and higher level functions. ( http://cvs.ps2dev.org/BPDemoHarness/PbDemoLib/ )

For graphics, my current preference is to have PS2SDK provide the base function which can be used to build a more comprehensive graphics library. This should allow multiple engines to be build ontop of the common base.

If you can suggest anything else that should be put in PS2SDK, let me know. I am yet to get much feedback on people using the SDK (even though there has been 1000+ downloads this month already), so don't know what is being done right/wrong..

Oobles.

PS The Turnip game written by dreamtime consistantly gets a lot of downloads every month. 500 this month already. The potential for that number to go up by multiples is there for some better quality games (sorry Dreamtime :)

Calvin, great work. If you need a CVS repository to store the code in progress I'm happy for you to put it online here. *hint* *hint*

I was hoping you'd take possession of it after I was done. It's really where it belongs. We have a CVS repository, but we're not interested in making it publically available. I'll send Sam and the SDL team diffs as well, but we (the PS2DEV community) will be the ones maintaining it, I'm sure.

With these in place I'd like to include some low level function to access GS, and then using these provide a very minimal sample graphics library.

We're using a modified version of GSLib as found in the nPort source, which was derived from Tony's/Dreamtime's tutorials. It wasn't too bad a place to start off, but it will need some cleaning to make things flow in a similar prose to PS2SDK.

I'd add tutorials (similar to Dreamtime's, but updated for PS2SDK's current reality) to the list of things PS2SDK needs. It's starting to get very unwieldy for the beginner, as my students have proven to me...

[And I'm not volunteering... yet. :-]

calvin wrote: I was hoping you'd take possession of it after I was done. It's really where it belongs. We have a CVS repository, but we're not interested in making it publically available. I'll send Sam and the SDL team diffs as well, but we (the PS2DEV community) will be the ones maintaining it, I'm sure.

Hi,

I'd like to know if a PS2 SDL port (even at an embryo stage) is publicly available somewhere ?
That would be great !

Thanks

spooo wrote:
Hi,

I'd like to know if a PS2 SDL port (even at an embryo stage) is publicly available somewhere ?
That would be great !

Thanks

Slightly-better-than-embryonic will be release to CVS in the next week or so. End of July at the latest. I have embryonic now, but I think I can push it just a bit farther now that my schedule's opened up a bit.

Sorry for the delay.

-cv

July 17th was a ways back anything new to report calvin?

So what's new ??????

I'm waiting for the SDL with pleasure to port CaSTaway emulator on the ps2 !

Hi shazz,

if you plan to port CaSTaway to ps2 (and god know if it would be a great thing) i would not use SDL but directly address the GS for better performance in that case....
Furthermore if you are new to ps2 dev, there are a few open-source emulators (to stay in the same subject) that could help you understand how to program directly the beast : ps2vic, psms, neocd

for my project (neocd/ps2), I removed all SDL portions and replaced them with ps2 "native" code, and it's really not so difficult ;)

Heloo Evilo,

What an interesting feedback !

I was thinking in replacing those SDL/Video call to my existing graphic libs (or gsLib, whatever...) so mostly "simply" get a kind of videobuffer and send it (as a texture ?) to the GS framebuffer...

But I saw CaSTaway uses much of DSL/Video and heavily SDL Threads, SDL I/O (joysticks, keyboard...) so I really don't know what would be the smarter effort... wait for the SDL or go in deep into the CaSTaway code..

But your post "plottered" my curiosity so I'll take a look to other emulators and more into the CaSTaway code... (http://sourceforge.net/projects/castaway)

héhé ;)

Additionnaly to the gs lib, you will find everything you need in the ps2sdk : thread, joystick, keyboard, I/O, etc... (also if you have a look at ps2vice and ask to the authors, he will certainely agree to let you use his virtual keyboard code)

I think (now maybe I'm wrong), that it's better to start something concrete today, then wait for something not sure... ? no ?

very usefull source of information :
http://cvs.ps2dev.org/
http://ps2dev.org/kb.x?T=706

good luck ;)

I still think that the idea of a middleware not too far away from the SDL could be a good idea. Things like gsKit and other stuff might help in that direction. In order to "port" simple "one frame buffer" softwares, one doesn't ideally need all the functionnalities of the full SDL, only a few parts of it.

Moreover, as mrbrown stated elsewhere, the threading system of the PS2 is a bit different than what one could await from a normal system: the kernel is not preemptive. It means that in no way, a thread will get stopped arbitrary for threading purpose (that is, it will get stopped by an interrupt for example, but not to switch to another thread)

So, either one has to implement a posix threading system ontop of that, which would add a new load of bloats to the whole, introducing what Joel called leaking abstractions (http://www.joelonsoftware.com/articles/ ... tions.html), or people might try to adapt themselves to the PS2, and put efficiently callbacks and sleeping points in their code.

Personnaly, I will prefer the second solution. I prefer having several similar portions of my code, each of them adapted for each platform, rather than a single, monolithic and unefficently abstractive platform independant code.

Please Calvin wake up and release what you have so far!!!!!!!!

pixel: there is ps2frame however it's not been updated in ages http://sourceforge.net/projects/ps2frame
Something like this with ps2sdk,gskit and ps2drv would be ideal.