forums.ps2dev.org

[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:

[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
_________________
http://www.dbfinteractive.com

[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?

[Jim]

Draw your own. No reason to use SDL.

Jim
_________________
http://www.dbfinteractive.com

[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

[dot_blank]

nicely down for you not knowing C ;)
_________________
10011011 00101010 11010111 10001001 10111010

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

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]

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]

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]

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.

[groepaz]

you should try -Os aswell, in some cases that results in faster code than -O2.
_________________
http://www.hitmen-console.org
http://hitmen.c02.at/files/yapspd/

[danzel]

Nice to see there are some speed improvements :)

Os compiled version PM'd now.

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

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]

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]

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:

[Wally]

Tried make clean and recompiling??

Wierd bug..

[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:

[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
_________________
http://www.dbfinteractive.com

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

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]

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]

Hi! Here's the latest version of the game with some new things:

[Ats]

Hi everyone! Good to see that this forum is back.
It's been literaly years since I worked on that game, and right now, I'm trying to port it to 5.xx kernel.

I'm following this tutorial : http://forums.ps2dev.org/viewtopic.php?p=59266#59266
At first, it seemed to be quite simple...

I had to reinstall everything, so this time I tried the Minimalist PSPSDK instead of Cygwin/PSPToolchain. The game is compiling good, but don't works on the PSP. It only shows a SDL cursor on a blackscreen for a few seconds and then shuts down.
After some code striping, I figured that the problem comes form the openGL init. The GL function are not working at all! So I was wondering if one of you guys had any clue about this?
Without the added lines for 5.xx kernel and the old 'make default kxploit', the game is working...

Thanks for your help !

[Wally]

You have to define a heapsize in your main.cpp file, that should fix it.

We generally use a negative value to use all available memory except the defined value.

[Ats]

Hi Wally, I just saw your response today:
I tried PSP_HEAP_SIZE_KB(20480) and PSP_HEAP_SIZE_MAX() without success, but PSP_HEAP_SIZE_KB(-1) is working fine. THANK YOU!!!

I also had to set the callbacks to be able to quit the game. Now everything is ok but I didn't remembered the fps was that slow... Crazy memory :)
New release soon!

[Salvy]

@Ats : I would recommend to set the heapsize -256 instead of -1.

Also you should let the compiler help you optimize your code, try adding -ffast-math to your CFLAGS and see if it helps.

[Ats]

@Salvy : Ok for the -256. I didn't notice a big difference by adding -ffast-math but at least it didn't break the game!

By the way (Heimdall if you read this), the game don't run on the psp when compiled with MINPSPW 0.11.1. It gives me the same problem as before adding PSP_HEAP_SIZE_KB(-256) linecode: a black screen with a SDL cursor and no OpenGL init. I had to revert to MINPSPW 0.10.0. Still MINPSPW is a great tool :)

I contacted the man who ported the same Frontier sourcecode to GP2X and he told me that besides optimising the C files, there's not much we can do on the asm part to optimise the game speed...

So the new version is out. Not much improvement. I got rid of some warnings and the game works on firmwares > 1.50
I didn't provided the sourcecode this time though because some parts of the game cannot be compiled with MINPSPW... I had to use the object generated from as68k to C from an old cygwin compilation. I'm working on that.

You can grab Frontier 0.2.1 on my website.

[Ats]

Today I was cleaning the sourcecode in order to release it, and I found how to improve the fps greatly: the game emulation was called every 20ms! I dropped it to 1ms and now the fps is easily twice better. But is it safe? I read here that 10ms is a most commun number. What do you think of that?

In the main function :