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

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

Moderators: cheriff, TyRaNiD

Ats
Posts: 37
Joined: Mon Dec 05, 2005 6:08 am
Location: Biarritz - France
Contact:

Post by Ats »

I've made a little test program to find the best calculation for a fluid mouse movement using the analogic pad.
The mouse cursor is the SDL one and I'm moving it with: SDL_WarpMouse(abs_x, abs_y);
Everything is fine but when I'm using this code in Frontier, I get a blue screen telling me that there is a problem with SDL_WarpMouse,
and precisely in file sdl/src/video/SDL_cursor.c line 304:

Code: Select all

/* If we have an offset video mode, offset the mouse coordinates */
x += (this->screen->offset % this->screen->pitch) /
      this->screen->format->BytesPerPixel;
y += (this->screen->offset / this->screen->pitch);
After some tests, it seems that I can't get the SDL_WarpMouse function to run if I'm using the flag SDL_OPENGL in SDL_SetVideoMode.
(I'm also using the SDL_DOUBLEBUF flag.)

What do you suggest me so that I can display the mouse cursor ?
User avatar
Jim
Posts: 476
Joined: Sat Jul 02, 2005 10:06 pm
Location: Sydney
Contact:

Post by Jim »

Possible problems are either screen is a null pointer, or screen->pitch is 0 or screen->format is a null pointer or screen->format->BytesPerPixel is 0.

Jim
Ats
Posts: 37
Joined: Mon Dec 05, 2005 6:08 am
Location: Biarritz - France
Contact:

Post by Ats »

Effectively, when the SDL_OPENGL flag is enabled in SDL_SetVideoMode function, the screen->pitch is equal to 0.
But I need both OPENGL and a mouse cursor, so I don't really know what to do...
Do you have some answers for me? I'm kind of stuck with this one.
Or maybe I don't have to use a SDL cursor but instead, draw a cursor with OPENGL?
User avatar
Jim
Posts: 476
Joined: Sat Jul 02, 2005 10:06 pm
Location: Sydney
Contact:

Post by Jim »

Draw your own. No reason to use SDL.

Jim
Ats
Posts: 37
Joined: Mon Dec 05, 2005 6:08 am
Location: Biarritz - France
Contact:

Post by Ats »

Today is the first beta release!

The game is slow when there is a lot of stuff drawn in the 3Dview, but is almost playable when you are in space.
You can save/load your commander, but don't try to rename your save file in the game: there is no OSK implemented yet so it will freeze your PSP.

You can download FRONTIER 1337 on my dedicated website.

I didn't really know the C language when I began the project, I'm glad that it has reached this point. Big thanks for all those which helped me!

Now, I'm taking a little break for my exams and then I'll start to speed the game up... and I will surely have a lot more questions to ask you :D
User avatar
dot_blank
Posts: 498
Joined: Wed Sep 28, 2005 8:47 am
Location: Brasil

Post by dot_blank »

nicely down for you not knowing C ;)
10011011 00101010 11010111 10001001 10111010
johnsto
Posts: 30
Joined: Wed Jan 18, 2006 8:52 am

Post by johnsto »

Just a note to mention it does not load on 2.00 using the eLoader. The PSP just hangs and turns off (like most non-2.00 homebrew stuff)
Ats
Posts: 37
Joined: Mon Dec 05, 2005 6:08 am
Location: Biarritz - France
Contact:

Post by Ats »

Back from my exams.

I've made a quick update to the game so you can continue playing after the police arrest you when you land on a spaceport. Now you only have to press the select button to get rid of the police.
The 1.00 firmware version is also included in the package: FRONTIER_1337_v0.1b.rar


Now I'm trying to optimize the game speed. I would like to test the fe2.s.part1 optimisation up to -O1 or -O2.
Can someone with a HUGE amount of RAM (1978708224 bytes...) contacts me so that I send him the fe2.s.c file and the corresponding makefile needed to obtain the fe2.s.part1 optimized? Thanks.

Another thing, after a lot of optimization, the only OpenGL thing that remains in the source code screen section is a GLtexture of the size you want (fullscreen), and where the FRONTIER screen is drawn. Is there a quicker way to obtain the same thing using the GU?
If I can get rid of OpenGL, I don't think I need to initialise SDL too. So is the pspctrl.h faster than the SDL one?

Thanks for your advises.
ector
Posts: 195
Joined: Thu May 12, 2005 10:22 pm

Post by ector »

My guess would be that it's the huge converted 68k asm->c file that's using most of the CPU power. Getting rid of OpenGL wouldn't be hard at all, gu can do textures too you know, but probably won't give you much in the way of additional speed, unless you're building new textures every frame unnecessarily or something.

Yeah, optimizing GCC is one SERIOUS memory hog..
http://www.dtek.chalmers.se/~tronic/PSPTexTool.zip Free texture converter for PSP with source. More to come.
danzel
Posts: 182
Joined: Fri Nov 04, 2005 11:03 pm

Post by danzel »

I have access to a 64bit linux machine with 8gig of ram, so I could run it for you :)
PM me or post a link to what you want built and I can run it.

You could probably get a better speed up by reading through the code and restructuring some of it since it is built from assembly. Or making an assembly converter like the original dev said (could be difficult due to mips reordering).

Edit: Compiled and sent :)

O1: 8minutes 3GB ram!! :)
O2: 15 minutes, only 1.5GB ram.
Ats
Posts: 37
Joined: Mon Dec 05, 2005 6:08 am
Location: Biarritz - France
Contact:

Post by Ats »

Thank you Danzel with your NASA machine :D

I made some benchmark with every optimized part1. The FPS are calculated by the game itself at the Ross154 spacestation when all the clouds appeared.
Here are the results:

O0 -> 25 - before :(
O1 -> 39
O2 -> 45 - now :)
O3 -> 25 - ...

With the part1 optimized up to O2 and all the details set to low in the setup screen, the game is now very playable when you are on a planet.

But while the game engine shows 45FPS, it is obvious that the real framerate is near 12FPS. I think this must come from the screen rendering or maybe the sounds... I'm going to make some more tests.
User avatar
groepaz
Posts: 305
Joined: Thu Sep 01, 2005 7:44 am
Contact:

Post by groepaz »

you should try -Os aswell, in some cases that results in faster code than -O2.
danzel
Posts: 182
Joined: Fri Nov 04, 2005 11:03 pm

Post by danzel »

Nice to see there are some speed improvements :)

Os compiled version PM'd now.
Ats
Posts: 37
Joined: Mon Dec 05, 2005 6:08 am
Location: Biarritz - France
Contact:

Post by Ats »

Thanks again Danzel!
Up to 50FPS (engine, not real...) with part1 optimized to Os. I tried to optimize part2 with Os too but it gave me 25FPS, so I keep O2 for part2.

=> FRONTIER_1337_v0.1c.rar

The game is now playable when you are on a spaceport. You have to set the level of shape detail to 'low' in the setup screen (start button).
You can also disable the 'Space dust, clouds etc' and 'Background stars' if you want.
Ats
Posts: 37
Joined: Mon Dec 05, 2005 6:08 am
Location: Biarritz - France
Contact:

Post by Ats »

Hi everyone!
After a good break and some code cleaning, I released the Frontier sourcecode so anyone who have the time and the skills to speed it up can take a look at it.
If anyone is interested, please tell me!

Frontier 1337 v0.1c sourcecode
monkeymagic
Posts: 6
Joined: Wed Oct 05, 2005 6:09 am

Ok folks, now we have the source, where too next?

Post by monkeymagic »

Atien,

Thanks for providing the source code. Hopefully people can contribute to it. Having a brief look, the following spring to mind as places to start:

FE2 is still emulating 68k. As long as it's doing that it's always going to be slower than native C, let alone MIPS. So we can work on optimizing the emulation for the PSP, or reducing the amount of stuff that's emulated.

I've read somewhere that CaSTaway PSP has a very quick 68k emulation engine, maybe we can take fe2.s.c and compare it with that to see if there's anywhere we could speed things up.

It's damned ugly in there, but if we can find the slowest or even most called functions, then that might give us an idea of where to start. This might mean altering as68k to dump the code necessary to log the start of each function call.

There's also a lot of stuff that is emulated that maybe doesn't need to be. For example, the DrawTriangle function should be fairly straightforward to replace with something reasonable in C so we aren't jumping all over the place.

I've already told Ats via email that I don't really have much time to work on this, but If I get some time to look, then I'll give it a try.

Anyone else have any ideas on how we might improve the speed of this?
Ats
Posts: 37
Joined: Mon Dec 05, 2005 6:08 am
Location: Biarritz - France
Contact:

Post by Ats »

Hi! It's been a long time since I have worked on Frontier.
Now that I have the time to add an OSK, I've reinstalled Cygwin and everything as it was before on my computer. I use the same code that I sent online for v0.1c and...
I can't compile my own code anymore.

I've tried everything and all that I get is:

Code: Select all

make: Warning: File 'src/input.o' has modification time 1.6 s in the future
...
make: warning: Clock skew detected. Your build may be incomplete.
Each time I compile the sourcecode, I get a different obj that has modification time. Sometimes (1 out of 10) the game compiles properly...
I tried the "touch" utility to fix them, or to remove the obj and elf files before compiling the game. I tried to reinstall the libs, even Cygwin... but nothing seems to work.

Do you have an idea where does this problem comes from?
User avatar
Wally
Posts: 663
Joined: Mon Sep 26, 2005 11:25 am

Post by Wally »

Tried make clean and recompiling??

Wierd bug..
Ats
Posts: 37
Joined: Mon Dec 05, 2005 6:08 am
Location: Biarritz - France
Contact:

Post by Ats »

After some more tries, I've discovered that I have two problems at the same time. The 'clock skew' thing don't seems to cause much trouble. The big problem comes from the initialization function in audio.c

The worst thing is that I already had the same problem when I started the project several month ago, and now I don't remember how did I fixed it...

Here is the function with the problem highlited inside:

Code: Select all

void Audio_Init(void) {
	int i;
	char filename[32];
	SDL_AudioSpec desiredAudioSpec;

	if (SDL_WasInit(SDL_INIT_AUDIO) == 0) {
		if &#40;SDL_InitSubSystem&#40;SDL_INIT_AUDIO&#41; < 0&#41; &#123;
			fprintf&#40;stderr, "Could not init audio&#58; %s\n", SDL_GetError&#40;&#41; &#41;;
			bSoundWorking = FALSE;
			return;
		&#125;
	&#125;

	desiredAudioSpec.freq = SND_FREQ;
	desiredAudioSpec.format = AUDIO_S16;
	desiredAudioSpec.channels = 2;
	desiredAudioSpec.samples = 1024;
	desiredAudioSpec.callback = Audio_CallBack;
	desiredAudioSpec.userdata = NULL;

	if &#40;SDL_OpenAudio&#40;&desiredAudioSpec, NULL&#41;&#41; &#123;
		fprintf&#40;stderr, "Can't use audio&#58; %s\n", SDL_GetError&#40;&#41;&#41;;
		bSoundWorking = FALSE;
		return;
	&#125;

	SoundBufferSize = desiredAudioSpec.size;

	for &#40;i=0; i<MAX_SAMPLES; i++&#41; &#123;
		snprintf &#40;filename, sizeof &#40;filename&#41;, "sfx/sfx_%02d.wav", i&#41;;

		// -------------------------------------------
		// THE PROBLEM COMES FROM THE SDL_loadWAV LINE
		if &#40;SDL_LoadWAV &#40;filename, &desiredAudioSpec, &sfx_buf&#91;i&#93;.buf, &sfx_buf&#91;i&#93;.buf_len&#41; == NULL&#41; &#123;

			printf &#40;"Error loading %s&#58; %s\n", filename, SDL_GetError &#40;&#41;&#41;;
			sfx_buf&#91;i&#93;.buf = NULL;
		&#125;
		check_sample_format &#40;&desiredAudioSpec, &sfx_buf&#91;i&#93;.buf, &sfx_buf&#91;i&#93;.buf_len, filename&#41;;
	  
		if &#40;i == 19&#41; sfx_buf&#91;i&#93;.loop = SND_FREQ; // loop to about 0.5 sec in
		else if &#40;i == 23&#41; sfx_buf&#91;i&#93;.loop = 0;
		else sfx_buf&#91;i&#93;.loop = -1;
		
	&#125;

	bSoundWorking = TRUE;
	Audio_EnableAudio&#40;TRUE&#41;;
&#125;
And the blue screen returns this:

Code: Select all

psp-addr2line -e frontier.elf -f -C 0x8d5ab14 0x408b000 0x8d5aab0
_free_r
../../../../../newlib/libc/stdlib/mallocr.c&#58;2696
??
??&#58;0
_free_r
../../../../../newlib/libc/stdlib/mallocr.c&#58;2632
SOS!
User avatar
Jim
Posts: 476
Joined: Sat Jul 02, 2005 10:06 pm
Location: Sydney
Contact:

Post by Jim »

Check your buffer size for sfx_buf. A common reason for free() to complain is someone wrote over the end of an allocation and corrupted the heap.

Jim
Ats
Posts: 37
Joined: Mon Dec 05, 2005 6:08 am
Location: Biarritz - France
Contact:

Post by Ats »

I'm still working from time to time on this game.
I've found why the wav file loading wasn't working: at the beginning of audio.c, #define MAX_CHANNELS was equal to 4 instead of 2...
I gained some speed and finally enabled the ogg music, but this last one is quite crappy. The frequency is twice higher than normal and there is a lot of noise.
Can somehone take a look at the #ifdef OGG_MUSIC parts in my audio.c to give me clues why it is like this?
Thanks!

Source code for audio.c
RCON
Posts: 16
Joined: Wed Aug 03, 2005 1:02 am
Contact:

Post by RCON »

It looks like the music you are playing is 22050 hz while the audio callback runs at 44100. That would cause the sounds to play at double speed. You will probably need to resample it to 44100 for it to sound right.

-Louie
Ats
Posts: 37
Joined: Mon Dec 05, 2005 6:08 am
Location: Biarritz - France
Contact:

Post by Ats »

So I resampled all the wav sounds and ogg music to 44100Hz and now all the sounds work perfectly, thank you!

I have two more things to do before the next release:
- Launch the game at 333Mhz without using IRshell.
- Try to implement Danzeff keyboard for changing savefile name.
Ats
Posts: 37
Joined: Mon Dec 05, 2005 6:08 am
Location: Biarritz - France
Contact:

Post by Ats »

Hi! Here's the latest version of the game with some new things:
version 0.2a :
- The game is now running at 333MHz.
- The music has been enabled.
- All wav sounds and ogg music have been resampled to 44100Hz and are now working perfectly.
- All sub-folders (but savs) have been moved to data folder.
- The Fkeys highliter has been turned from red to black for not interfering with the intro and outro of the game.
The package contains the kxploited game and the sources. Download the MUSIC and SFX packs if you want, and place them in the FRONTIER/data folder.
- FRONTIER1337 v0.2a
- SFX pack
- MUSIC pack

I'm advancing very slowly so any help is still welcome ;)

Edit: Sorry, I forget to add fe2.s.bin file in the package yesterday. Everything should work fine now!
By the way, at the end of the compilation, how can I move fe2.s.bin from a directory to another using the Makefile?
This would help me to avoid this kind of mistakes in the futur...
Post Reply