Hurrican SDL Port

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

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

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]

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]

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.

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

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

[peter10]

Hurrican SDL Port

Hurrican has USB joystick/pad support under the Windows version and apparently this should work under the SDL port too but I've not got that to work so please test that if you can and let us know if you get your controller to work please!

[danboid]

Hurrican running on Pandaboard

Hi Pickle!

You were right - after adding SDLport/eglport into the Makefile that got Hurrican to compile with OGLES/EGL but for me to see anything on my Panda I had to apply the previously mentioned window mode hack as otherwise I just got a black screen. I was expecting this as thats what happens for me under d1x and d2x (Descent rebirth) and so it has confirmed a bug in the current drivers.

I THINK Hurrican should run now but since last night my Panda has become more unstable than it usually is running 12.04 and now I can barely open a xterm without it dieing and so I've only actually seen Hurrican run as far as the loading screen that comes after the game menu. I'm not going to bother with the Panda again until TI get some more stable drivers out as I'm lucky if I get an hour out of it at the best of times right now before it tanks.

[Pickle]

you have to add the eglport.c to the file list. If I didnt mention it before I didnt use the makefile, I used codeblocks to build. The makefile was added by someone else for a desktop build.

when i get to the rpi version, I will try to clean up the makefiles and add some basic build docs.