Hurrican SDL Port

[Pickle]

Ok joystick support should work now with revision 81. Remember to map the desired buttons in the control prefs

[blcollier]

Hullo there!

First post here

I found this thread from the Raspberry Pi forums; danboid had posted a link to his pandaboard compilation instructions and wondered if anyone had tried it on the Pi... I decided to take a crack at it this evening - you can see my progress here http://www.raspberrypi.org/phpBB3/vi...p?f=35&t=12932 - and I was rather glad to see a revision to the Makefile to include Raspberry Pi support .

I'm now trying the updated makefile on my Pi - I haven't modified a single thing - and I'll update with the progress. I mentioned this in the thread at the Raspberry Pi forums, but I don't know how much help I'll be in the case of additional development or porting work - I'm no programmer!

Many thanks for all your effort on this - looking forward to seeing if I can get it working on the Pi

[Pickle]

blcollier the modifications to the makefile and other stuff was the final changes needed to run on the rpi. Unfortunately hurrican really puts the rpi memory at its limit. While I did get in game it was very slow and unplayable.
I think the only way to get this running may be be with the highest memory slice for the gpu and running a swap.

[Slamy]

Hello there. My first post here too.
I want to address some bugs.
1)First the rpi port should have it's own seperate makefile. This makes compiling less confusing.

2)The lines

#include "gl2.h"
#include "gl2ext.h"

in opengl.h:21 must be converted to

#include "GLES2/gl2.h"
#include "GLES2/gl2ext.h"

to be able to compile on Debian Wheezy.

3) There is a rendering bug for the tilemaps. It appears there are clipping erros but I'm really not sure what is causing this. I made a screenshot to help explaining it.



4) Also there is a problem with the fullscreen mode as the 640x480 windows appears in the lower left of my monitors native resolution. The rest is black. I'm not sure if this is caused by the by ATI driver or not... so maybe this is my fault.

Appart from that the port is very good.

[Pickle]

1) I support many devices and for me its easier to maintain one file and have one var to select the device and its specific settings.

2) I took the approach of leaving the folder path out in case some systems did not use the typical path. I used the makefile to specify the include path to look in. i.e. -I/usr/include/GLES2

3) I dont know exactly, i have seen bugs like this on other systems but none of the ones I own. I would suspect it might be something with the texcoords. You could try the 1.X render for kicks for the same issue.

4) I think this makes sense if the window system is forcing a higher resolution window. OpenGL viewport is origin is in the lower left corner. Does SDL report the full resolution? If so I could be possible to try and use it to change the viewport origin to
x = (ScreenWidth - WindowWidth) / 2
y = (ScreenHeight - WindowHeight) / 2

Although I would have thought SDL would have controlled the resolution to 640x480

Did you try on your rpi? Which model do you have? I have a 256 mb and I could hardly get Hurrican to run with the memory constraints. One reason i never publicly released it.

Thanks for trying and giving feedback, it is appropriated.

[Slamy]

1) I support many devices and for me its easier to maintain one file and have one var to select the device and its specific settings.

2) I took the approach of leaving the folder path out in case some systems did not use the typical path. I used the makefile to specify the include path to look in. i.e. -I/usr/include/GLES2

3) I dont know exactly, i have seen bugs like this on other systems but none of the ones I own. I would suspect it might be something with the texcoords. You could try the 1.X render for kicks for the same issue.

4) I think this makes sense if the window system is forcing a higher resolution window. OpenGL viewport is origin is in the lower left corner. Does SDL report the full resolution? If so I could be possible to try and use it to change the viewport origin to
x = (ScreenWidth - WindowWidth) / 2
y = (ScreenHeight - WindowHeight) / 2

Although I would have thought SDL would have controlled the resolution to 640x480

Did you try on your rpi? Which model do you have? I have a 256 mb and I could hardly get Hurrican to run with the memory constraints. One reason i never publicly released it.

Thanks for trying and giving feedback, it is appropriated.

The problem with the tiles (and also the sprites on the main menu) is indeed caused by the texture coordinates as I can see pixels of the next tile. The strange thing is that
this is not quite deterministic. Some tiles seem to be correct. Others, which are handled by the same rendering functions are not. I can't see a pattern.
The error that it's not real fullscreen disappeared somehow.
At one point you specify NEAREST as the algorithm for textures. I tried LINEAR and had better results, especially in the main menu. Also in the game this reduces "wobbeling" of sprites.

I borrowed a 512 MB Raspberry Pi from a friend as I don't own one and installed Raspbian on it. It's really a mess. The ingame graphics are only random tiles of font tiles. Music is only working for about 10 seconds. It stops shortly after beginning the loading screen. The intro only shows the text at the bottom and none of the images. Last but not least the load times are a little bit long. But this is the smallest problem it has.

I don't know how well this is running on the Pandora but the Pi Version has some faults. But maybe this device is just not good enough to handle a game like that. At the moment I also couldn't recommend the linux port to a person that just wants to play hurrican as It isn't the true experience yet. Apart from the texture bug I think that still existing graphical problems can only be seen by Eiswuxe himself as he knows how it shoud look like to be authentic.

[Pickle]

switching to LINEAR is probably hiding the issue since it is blending the edges, im sure if you looked close there would be some artifacts.
im not sure what you meant by "wobbling" sprites.
the texture problem could come down to the hardware, ive havnt seem it on my hardware.

The code to look at I think is in DX8Sprite.cpp DirectGraphicsSprite::Render*
The texcoords are calculated like this:
tl = itsRect.left /itsXSize; // Links
tr = itsRect.right /itsXSize; // Rechts
to = itsRect.top /itsYSize; // Oben
tu = itsRect.bottom/itsYSize; // Unten

Maybe in the code above when textures are increased to be a POT texture it creates fractional coordinates and depends how the result is rounded by the hardware.

for the rpi the memory slice for the gpu is critical (I would try 256/256). I also created a command line args to shrink the texture resolutions. A certain combination of these should improve it.

Pandora is working perfect, I was saved by the fact that it had pvrtc support saving gpu memory space.

Loading is slow with the loading of all the images, not much that can be done. Plus the ARM chip in the RPI isnt exactly breaking speed records.