FRONTIER 1337 - a port of FRONTIER: Elite II for PSP

[Ats]

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]

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]

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

[groepaz]

.o(subliminal message: ABUSE_SDL)

:=P

[Ats]

.o(subliminal message: ABUSE_SDL)

Nice try groepaz :)

I've found some new code of a reverse-engineering Frontier Elite 2 here: http://soul-less.pwp.blueyonder.co.uk/glfrontier/

The author says the native frontier 68k code can be compiled either to i386 asm or to C source file, and that it should be trivial to port to other platforms with SDL.
I study all this right now while installing psptoolchain (again). :)

[Ats]

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]

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]

Code: Select all

export CC = gcc
export CFLAGS = -O2 -g -Wall
export LIBS = -lglu32 -lopengl32 -lvorbisfile -lvorbis -logg
export FE2OBJS = ../fe2.part1.o ../fe2.part2.o

THIS = Makefile-C

default:
	$(MAKE) -C as68k/
	$(MAKE) -f $(THIS) fe2obj
	$(MAKE) -C src/

fe2obj:
	as68k/as68k --output-c fe2.s
	$(CC) -DPART1 -O1 -fomit-frame-pointer -Wall -Wno-unused -s `sdl-config --cflags` -c fe2.s.c -o fe2.part1.o
	$(CC) -DPART2 -O0 -fomit-frame-pointer -Wall -Wno-unused -s `sdl-config --cflags` -c fe2.s.c -o fe2.part2.o

and the other one :

[./src/Makefile]

Code: Select all

SDLLIB = $(shell sdl-config --libs) $(LIBS)
SDLFLAGS = $(shell sdl-config --cflags) -L/usr/X11R6/include

SRCS = audio.c hostcall.c keymap.c main.c screen.c shortcut.c input.c

OBJS = $(SRCS:.c=.o)

.c.o:
	$&#40;CC&#41; $&#40;CFLAGS&#41; $&#40;INCFLAGS&#41; $&#40;SDLFLAGS&#41; -c $<

../frontier&#58; $&#40;OBJS&#41;
	$&#40;CC&#41; $&#40;OBJS&#41; $&#40;FE2OBJS&#41; $&#40;SDLLIB&#41; $&#40;LIBFLAGS&#41; -o ../frontier

Can a more advanced user help me to create a Makefile for psp?

[Ats]

Now I have only one Makefile :

Code: Select all

CC = gcc
CFLAGS = -O2 -g -Wall
LIBS = -lglu32 -lopengl32 -lvorbisfile -lvorbis -logg

SDLLIB = $(shell sdl-config --libs) $(LIBS)
SDLFLAGS = $(shell sdl-config --cflags) -L/usr/X11R6/include

FE2OBJS = fe2.part1.o fe2.part2.o
SRCS = src/audio.c src/hostcall.c src/keymap.c src/main.c src/screen.c src/shortcut.c src/input.c

OBJS = $(SRCS:.c=.o)

THIS = Makefile

default:
	$(MAKE) -C as68k/
	$(MAKE) -f $(THIS) fe2obj
	$(MAKE) -f $(THIS) .c.o
	$(MAKE) -f $(THIS) frontier

fe2obj:
	as68k/as68k --output-c fe2.s
	$(CC) -DPART1 -O1 -fomit-frame-pointer -Wall -Wno-unused -s `sdl-config --cflags` -c fe2.s.c -o fe2.part1.o
	$(CC) -DPART2 -O1 -fomit-frame-pointer -Wall -Wno-unused -s `sdl-config --cflags` -c fe2.s.c -o fe2.part2.o

.c.o: $(SRCS)
	# $&#40;CC&#41; $&#40;CFLAGS&#41; $&#40;SDLFLAGS&#41; -c $<
	$&#40;CC&#41; $&#40;CFLAGS&#41; $&#40;SDLFLAGS&#41; -c src/audio.c -o src/audio.o
	$&#40;CC&#41; $&#40;CFLAGS&#41; $&#40;SDLFLAGS&#41; -c src/hostcall.c -o src/hostcall.o
	$&#40;CC&#41; $&#40;CFLAGS&#41; $&#40;SDLFLAGS&#41; -c src/keymap.c -o src/keymap.o
	$&#40;CC&#41; $&#40;CFLAGS&#41; $&#40;SDLFLAGS&#41; -c src/main.c -o src/main.o
	$&#40;CC&#41; $&#40;CFLAGS&#41; $&#40;SDLFLAGS&#41; -c src/screen.c -o src/screen.o
	$&#40;CC&#41; $&#40;CFLAGS&#41; $&#40;SDLFLAGS&#41; -c src/shortcut.c -o src/shortcut.o
	$&#40;CC&#41; $&#40;CFLAGS&#41; $&#40;SDLFLAGS&#41; -c src/input.c -o src/input.o

frontier&#58; $&#40;OBJS&#41; $&#40;FE2OBJS&#41;
	$&#40;CC&#41; $&#40;OBJS&#41; $&#40;FE2OBJS&#41; $&#40;SDLLIB&#41; -o frontier

Just for my thirst of knowledge, how can the .c.o part be optimized?
Next stage: translate this Makefile to compile an eboot (a little assistance is always welcome).

[Ats]

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]

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]

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

[Ats]

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.

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

Indeed! I get the blue crash screen, all is "normal" :)

But after correcting four little_endian conversions errors, I get another error that goes like this:

Code: Select all

psp-addr2line -e frontier.elf -f -C 0x8d5ab14 0x408b000 0x8d5aab0
_free_r
../../../../../newlib/libc/stdlib/mallocr.c:2696
??
??:0
_free_r
../../../../../newlib/libc/stdlib/mallocr.c:2632

Do you know if this could come from the RAM needed by the game to be launched? Or is it another kind of problem?
Please, give me a clue so that I can continue to battle on this after a good sleep :)

[PeterM]

Could be trying to free a null pointer?

[Ats]

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]

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.

Code: Select all

*** GL error 0x0500 in glTexImage2D ***
*** GL error 0x0502 in glTexSubImage2D ***

To start, can you help me to find where is the error in Screen_Init function, or give me a hint so that I can get rid of the problem myself?

Code: Select all

#define SCR_TEX_W	512
#define SCR_TEX_H	256

// The SDL screen surface
SDL_Surface *sdlscrn;
                        
// fe2 UI blits are done to old screen memory and copied to this texture.
static unsigned int screen_tex;

// Set window size, I kept the original 1.6 ratio for now
int screen_w = 432;
int screen_h = 270;

void Screen_Init(void)
{
	const SDL_VideoInfo *info = NULL;
	float ratio;
	int _3dview_h;

	info = SDL_GetVideoInfo ();

	assert (info != NULL);

	SDL_GL_SetAttribute (SDL_GL_DOUBLEBUFFER, 1);

	if ((sdlscrn = SDL_SetVideoMode (screen_w, screen_h, info->vfmt->BitsPerPixel, SDL_OPENGL | SDL_DOUBLEBUF)) == 0) {
		fprintf (stderr, "Video mode set failed: %s\n", SDL_GetError ());
		SDL_Quit ();
		exit (-1);
	}

	_3dview_h = screen_h - (32*screen_h)/200;
	ratio = (float) screen_w / (float) _3dview_h;
	
	glDisable (GL_CULL_FACE);
	glShadeModel (GL_FLAT);
	glDisable (GL_DEPTH_TEST);
	glClearColor (0, 0, 0, 0);

	glViewport (0, 32*screen_h/200, screen_w, _3dview_h);
	glMatrixMode (GL_PROJECTION);
	glLoadIdentity ();

	glEnable (GL_TEXTURE_2D);
	glGenTextures (1, &screen_tex);
	glBindTexture (GL_TEXTURE_2D, screen_tex);
	glTexImage2D (GL_TEXTURE_2D, 0, GL_RGBA, SCR_TEX_W, SCR_TEX_H, 0, GL_RGBA, GL_INT, 0);
	glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
	glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
	glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
	glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

	glBlendFunc (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
	glDisable (GL_TEXTURE_2D);

	glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
	glMatrixMode (GL_MODELVIEW);
	glLoadIdentity ();

	// Configure some SDL stuff
	SDL_EventState(SDL_MOUSEMOTION, SDL_ENABLE);
	SDL_EventState(SDL_MOUSEBUTTONDOWN, SDL_ENABLE);
	SDL_EventState(SDL_MOUSEBUTTONUP, SDL_ENABLE);
	SDL_ShowCursor(SDL_ENABLE);
}

Thank you.

[Jim]

From gl.h

Code: Select all

#define GL_INVALID_ENUM				0x0500
#define GL_INVALID_OPERATION			0x0502

So you're passing dud values to glTexImage2D, some unknown pixel format for instance.

Jim

[Ats]

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]

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

[Drakonite]

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

Um... why? Unless there is some major reason to, you're just going to drain the batteries faster...

[Jim]

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

[Ats]

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]

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

Also, is 8MB the stripped exe?

[Ats]

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

Code: Select all

TARGET= frontier
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 = -O2 -g -Wall
CFLAGS = $(DEFAULT_CFLAGS) $(MORE_CFLAGS)

LIBS = -lGL -lpspvfpu $(shell $(SDL_CONFIG) --libs)

THIS = Makefile

OBJS = src/audio.o src/hostcall.o src/keymap.o src/main.o src/screen.o src/shortcut.o src/input.o fe2psp.part1.o fe2psp.part2.o

default:
	# Compile the as68k.exe that will convert as68k to i386 ASM or C file
	# It's got his own makefile as it is a PC program
	$(MAKE) -C as68k/
	# Convert the fe2.s as68k file to fe2.s.c (huge source file)
	# and fe2.s.bin (file needed by the game to be launched)
	$(MAKE) -f $(THIS) fe2obj
	# Compile the SDL/OpenGL/audio/input/display part
	$(MAKE) -f $(THIS) srcobj

fe2obj:
	as68k/as68k --output-c fe2.s
	# Unlike the PC version, I can't optimize this part at all, it gives me an error like
	# cc1: out of memory allocating 1863535968 bytes after a total of 62455800 bytes
	$(CC) -D PART1 -D LITTLE_ENDIAN -O0 -fomit-frame-pointer -Wall -Wno-unused -s $(DEFAULT_CFLAGS) -g -c fe2.s.c -o fe2psp.part1.o
	# This part can be optimized up to O3 but I don't know yet if it is better or not
	$(CC) -D PART2 -D LITTLE_ENDIAN -O2 -fomit-frame-pointer -Wall -Wno-unused -s $(DEFAULT_CFLAGS) -g -c fe2.s.c -o fe2psp.part2.o

srcobj:
	# I didn't try it before, but this part can also be optimized up to O3
	$(CC) $(CFLAGS) -c src/audio.c -o src/audio.o
	$(CC) $(CFLAGS) -c src/hostcall.c -o src/hostcall.o
	$(CC) $(CFLAGS) -c src/keymap.c -o src/keymap.o
	$(CC) $(CFLAGS) -c src/main.c -o src/main.o
	$(CC) $(CFLAGS) -c src/screen.c -o src/screen.o
	$(CC) $(CFLAGS) -c src/shortcut.c -o src/shortcut.o
	$(CC) $(CFLAGS) -c src/input.c -o src/input.o

EXTRA_TARGETS = EBOOT.PBP
PSP_EBOOT_TITLE = FRONTIER - Elite II
PSP_EBOOT_ICON = icon.png

include $(PSPSDK)/lib/build.mak

[Arwin]

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]

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]

congrats site looks very simple and accessible
to users ...good luck with this game

[Erant]

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.

[Drakonite]

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.

-O3 rarely makes anything faster, and in many cases makes code slower.
The primary difference between -O3 and -O2 is that -O3 unrolls just about every loop it can, which trashes the instruction cache in order to possibly save some time by getting rid of the branches from the loop...

In a lot of cases, especially on archs with small instruction caches and/or big hits for cache misses, this can slow things down quite noticably, and except in the very best of cases the gain is rarely noticable.

[PeterM]

-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]

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:

Code: Select all

case SDL_MOUSEMOTION:
	// Relative motion in the X/Y direction
	motion_x += event.motion.xrel;
	motion_y += event.motion.yrel;
	// The X/Y coordinates of the mouse
	abs_x = event.motion.x;
	abs_y = event.motion.y;
break;

by this one:

Code: Select all

case SDL_JOYAXISMOTION:
	if &#40;&#40;event.jaxis.value < -3200&#41; || &#40;event.jaxis.value > 3200&#41;&#41; &#123;
		if &#40;event.jaxis.axis == 0&#41; &#123;
			// some code here using event.jaxis.value to obtain motion_x and abs_x
		&#125;
		if &#40;event.jaxis.axis == 1&#41; &#123;
			// Same code but for motion_y and abs_y
		&#125;
	&#125;
break;

What is the best way to convert joystick motion into mouse coordinates and motion? I didn't find any example.
Thank you!

With the joystick working, I'll then take care of the rendering optimization in order to gain machspeed, because the game is in slooooow motion. :(

EDIT: Ok, so after getting some sleep, i found the solution in 5 seconds...

Code: Select all

case SDL_JOYAXISMOTION:
	switch (event.jaxis.axis) {
		case 0: motion_x = event.jaxis.value / 6500; break;
		case 1: motion_y = event.jaxis.value / 6500; break;
	}
break;

and outside the SDL events:

Code: Select all

abs_x += motion_x;
abs_y += motion_y;

I need to sleep more :D