forums.ps2dev.org

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

Hi everyone!
I'm pretty new to c development but lately, I've managed to compile rRootage for PSP following Deniska's rRootage fast porting tutorial. Easy and cool!
So I think to myself "Let's go on, cut some corners and try to port Frontier: First Encounters..."

I used JJFFE sources, a recompiled replacement executables that can be found at http://www.eliteclub.org.uk/
After some tries, I recognize that porting a game is not as easy as Deniska claims it. In fact, I've got problems with the Makefile and with some mismatch in operand sizes in ASM file...
Can someone more experienced than me put an eye on JJFFE sources and tell me if it is possible to port it, or if I'm wasting my time?
Thank you.

Jabberwocky · Joined: 03 Aug 2005 Posts: 43

With a brief scan through the source distribution, I would say this would be a big job. There's lots of decompiled x86 assembly from the original game (I'm guessing), which you need an x86 compatable processor to run. As the PSP uses a MIPS, you're out of luck unless you rewrite all the assembly code. Not something I'd want to do... look for a game which already runs on multiple processors if you want something to port.

-Jw

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

Ok, thanks for the quick reply.
Never mind, I will find something else to work on :)

groepaz · Joined: 01 Sep 2005 Posts: 305

.o(subliminal message: ABUSE_SDL)

:=P
_________________
http://www.hitmen-console.org
http://hitmen.c02.at/files/yapspd/

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

I wrote to the author of FrontierVM to ask him some questions. Thanks for his quick reply.

Can the 68k assembly language be compiled to MIPS processor (PSP) by generating the huge C source file?

> Yes. The C output mode should compile for any CPU although this hasn't been tested and there may be endian issues to be debugged. Of course the ideal solution would be for someone to write a MIPS asm generating bit for as68k, like x86 has.

When I try to compile frontvm3-20060226 Makefile-C (not for PSP), I'm having some troubles with fe2.part2.o
For example:
fe2.s.c: In function `__F28ed2':
fe2.s.c:35091: error: parse error before "s32"
fe2.s.c: In function `__F28ed8':
fe2.s.c:35124: error: parse error before "s32"
... and so on

> What exactly is at fe2.s.c at these line numbers?
s32 should be defined 'typedef signed int s32' somewhere in _host.c iirc.
I can't check because I'm not at my usual computer.

I'm working under Cygwin with SDL, openGL and other libs properly installed. Can you give me a clue to pass through this?

> Is this some weird cross-compiler setup for building PSP binaries, or a question related to building a win32 binary? For win32 I used mingw not cygwin, and there is a makefile in the archive for mingw. Otherwise I'm not sure but try adding the typedef (which is there anyway and surely this couldn't possibly happen...) or find out what is at those lines that it pukes at.

I continue my research :)

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

Hi.
Today I had time to take a new look at Frontier code. With the help of Tom Morton, I manage to compile the game correctly for win32 using the 68k to C source file.

Now I'm trying to compile it as an eboot.
I changed the screen.c and input.c to fit them for the psp. This should work but I'm not very at ease with Makefile, especially when there are several of them. In fact, there is a Makefile for the project itself and another for the c files that are in another folder.

Here's the first one :

[Makefile-C]

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

Now I have only one Makefile :

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

Welcome back in my topic where I speak all alone and nobody seems to care. :D

Today I have translated the win32 Makefile-C into PSP Makefile. The compilation is working fine until it's reaching the objects linking.
screen.o is asking some OpenGL functions that are not implemented yet in PSPGL.

Those are:

glColor3ui
glLightiv
glPointSize
glVertex3iv

gluCylinder
gluDisk
gluErrorString
gluNewQuadric
gluNewTess
gluTessBeginContour
gluTessEndContour
gluTessBeginPolygon
gluTessEndPolygon
gluTessCallback
gluTessProperty
gluTessVertex

After spending some search time here and there, I still dont know if those functions will be implemented to PSPGL in the future.
Since I am new to OpenGL, I think I will wait for this functions to come out...
But I will also improve my skills to try to bypass this problem.

Next stage: Compile the game without screen display to see if I can get an eboot.

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

I care, I care!

I would recommend replacing the missing functions with appropriate (usually empty) stubs just to get it compiling.

By the sounds of it, you've got a lot of code there. With the PSP being as tricky to code for as it is, and you being as new to this as you are, you need to get a simple version running on hardware before it gets too complex to debug.

Because it will crash when you run it, and you'll need to find out why.

Pete

crowba · Joined: 15 Oct 2005 Posts: 13

I care too, really looking forward to an Elite II port.. i wish you all the luck !!!

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

For the moment, I totally disabled the rendering of the screen to compile the eboot.
On the PSP, the game itself can't be launched without the data file fe2.s.bin in the same folder, so this is a good point.

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

Could be trying to free a null pointer?

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

Apparently, the problem comes from audio.c

With the audio totally disabled, the eboot is working correctly without blue screen. But as the screen display is still disabled, the game is nothing more than a black screen...

Next stage: Try to get screen.c works (a little) without the missing OpenGL functions.

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

Yesterday, I made the mouse pointer to show up during the game, but nothing more because all the openGL functions gave me a blue screen. So after a lot of tries and searching through the forum, I found this post.
As I had installed SDL before PSPGL, I didn't know if -D HAVE_OPENGL was automatically added in the CFLAGS of SDL makefile. So I decided to install SDL once again, and check if this flag was there.

Now all openGL functions seems to be working on the PSP, no blue screen anymore :)
But all I get is a black window on a nightblue screen, and the mouse pointer that appears at the end of the introduction time.
A log.txt is automatically created by PSPGL at the root of memory card to tell what's wrong: the problem comes from glTexImage2D and glTexSubImage2D, that are only used once respectively in the Screen_Init and draw_control_panel function.

Jim · Joined: 02 Jul 2005 Posts: 487 Location: Sydney

From gl.h

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

Thank you Jim :D
Now I know where the PSPGL error list was hiden.

The error was :
glTexImage2D (GL_TEXTURE_2D, 0, GL_RGBA, SCR_TEX_W, SCR_TEX_H, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0);
instead of GL_INT.

Now the game is working on the PSP!
The framerate is slow and there is no button input yet, but the introduction sequence is playing fine without any graphical glitches!
Do you have some advises to give me for the framerate improvement?

I will make a special page for the game on my website when I'll have the time.

Next stage: Allow the joystick input.

Mike/Pippin · Joined: 05 Jun 2005 Posts: 40

Is the PSP CPU on 222mhz or at 333mhz. If its at 222mhz then change to 333mhz.

Drakonite · Site Admin Joined: 17 Jan 2004 Posts: 989

Jim · Joined: 02 Jul 2005 Posts: 487 Location: Sydney

Pre-swizzling textures, storing/caching textures in vram, using smaller vertex formats, using display lists instead of banging away at glVertex - these are all ways of speeding it up. Look at pspgl and see where the optimal path is...

Jim
_________________
http://www.dbfinteractive.com

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

Thanks for your answers.

I tried Frontier at 333Mhz using iR Shell. The framerate is a little faster than before, but I don't think this is the good solution.

For the moment, the original as68k sourcecode from the Atari game can be converted either to i386 ASM (very good for x86 PC but does not work on PSP) or C (huge 8Mo file that is not optimized at all). I talked with Tom Morton (the author of GLFrontier) and the best way to have direct results in speed increase would be to write an as68k converter to MIPS ASM... Too difficult for me as I know almost nothing in ASM.

So I can only improve the SDL/OpenGL part by following the advices of Jim, and I hope it will be enough...

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

Have you tried compiling with -Os, -O2 or -O3 if that doesn't break it?

Also, is 8MB the stripped exe?

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

Here's the Makefile that I made with commentaries inside.
I compile the game by typing: make default kxploit

Arwin · Joined: 12 Jul 2005 Posts: 426

Congrats on your progress!

By the way, have you looked at Frontier: Elite 2 for the Atari ST running on CaSTaway PSP also? That should give you an indication of the kind of speed you should at the very least be able to manage, I think. My experience so far is that this Atari ST emulator is able to run nearly all games at pretty much full speed - I use and enjoy it a lot.

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

Thank you, although I got a lot more to do...
I tried Frontier on CaSTaway (Atari ST) and even on PSP-UAE (Amiga) months ago. For now, the Atari emulator is faster than my port :( but has a lot of graphical glitches :)
Anyway, I started to make a mini-site for the game. It's explaining the futur features and you can try the game controls on a Flash mockup.
Here it is: http://atien.free.fr/jeux/1337/index.htm

dot_blank · Joined: 28 Sep 2005 Posts: 498 Location: Brasil

congrats site looks very simple and accessible
to users ...good luck with this game
_________________
10011011 00101010 11010111 10001001 10111010

Erant · Joined: 13 May 2005 Posts: 33

Looks like an amazing effort. I really liked Frontier, back in the days. I hope you get it to go a bit faster, as I'd be really interested in playing this!

Edit:

You could ofcourse try compiling everything with -O3. If it doesn't break it.
_________________
Live free, prosper, and under my rule.

Drakonite · Site Admin Joined: 17 Jan 2004 Posts: 989

PeterM · Joined: 31 Dec 2005 Posts: 125 Location: Edinburgh, UK

-O3 provided a visible speed-up over -O2 and -Os in Quake, but I accept that it doesn't guarantee better performance for other projects.

So Quake is definitely one of the "very best of cases" ;-)

Ats · Joined: 05 Dec 2005 Posts: 37 Location: Biarritz - France

In fact, part2 optimized to -O3 makes the game slower. But it would be very good if I was able to optimize the part1.
This leads me to some questions ^^'

First, is the cc1: out of memory allocating can be bypassed for optimising the part1?
I'm using cygwin under winXP with a 2.16GHz AMD Athlon and 512Mo of RAM.
Should I buy another memory chip? Freeing some memory by shuting down every win32 little things? Get rid of windows :D ?
I need to compile it only once because it is a lot of little ASM functions and I don't want to touch it for now.

Second: I finished to map all the PSP buttons and it works great. The only thing which lack is the joystick.
I need to replace this code: