Page 5 of 8 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 76

Thread: Hurrican SDL Port

  1. #41
    Join Date
    Jun 2008
    Posts
    74

    Default

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

  2. #42
    Join Date
    Aug 2012
    Posts
    1

    Default

    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

  3. #43
    Join Date
    Jun 2008
    Posts
    74

    Default

    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.

  4. #44
    Join Date
    Apr 2013
    Posts
    2

    Smile

    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.

  5. #45
    Join Date
    Jun 2008
    Posts
    74

    Default

    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.

  6. #46
    Join Date
    Apr 2013
    Posts
    2

    Default

    Quote Originally Posted by Pickle View Post
    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.

  7. #47
    Join Date
    Jun 2008
    Posts
    74

    Default

    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.

  8. #48
    Join Date
    Jan 2009
    Location
    England
    Posts
    125

    Talking Great work Pickle! Good to play Hurrican with a joypad!

    I'd almost forgotten about Hurrican until today when I thought it was time to compile it and see if Pickle ever fixed the joypad support under Linux and indeed he did - exactly one year ago today as it turns out! What are the chances I'd try it again exactly one year after he implemented the one feature I wanted to see!?

    I've compiled it under buntu 12.04 (KXStudio amd64) - I'm getting some visual artifacts but I'm not sure if I was running it in GL or GLES mode - must try playing with the options.

    Might we be able to get Hurrican into Debian Pickle?

    Thanks for bringing such a polished free game to Linux!

  9. #49
    Join Date
    Jun 2008
    Posts
    74

    Default

    Quote Originally Posted by danboid View Post
    I'd almost forgotten about Hurrican until today when I thought it was time to compile it and see if Pickle ever fixed the joypad support under Linux and indeed he did - exactly one year ago today as it turns out! What are the chances I'd try it again exactly one year after he implemented the one feature I wanted to see!?

    I've compiled it under buntu 12.04 (KXStudio amd64) - I'm getting some visual artifacts but I'm not sure if I was running it in GL or GLES mode - must try playing with the options.

    Might we be able to get Hurrican into Debian Pickle?

    Thanks for bringing such a polished free game to Linux!
    Thanks for trying and posting some feedback. The primary difference in rendering is choice between GL1 and GL2. The ES variant of either is not very much different from the normal desktop GL.

    The only graphical issues ive heard of is lines between tiles or maybe an bad line in tile. You can find some ideas i had about it a couple post back. I havnt had the problem occur on any of my devices.

    Its all open source so anyone can package it for debian, if thats what you mean ;-)

  10. #50
    Join Date
    Jan 2009
    Location
    England
    Posts
    125

    Default

    Code:
    Initializing SDL.
    SDL initialized.
    EGL Opening EGL display
    EGL Opening X11 display
    EGL Initializing
    libEGL warning: DRI2: failed to authenticate
    EGL Implementation Version: Major 1 Minor 4
    EGL_VENDOR: Mesa Project
    EGL_VERSION: 1.4 (DRI2)
    EGL_EXTENSIONS: EGL_KHR_surfaceless_gles1 EGL_KHR_surfaceless_gles2 EGL_KHR_surfaceless_opengl 
    EGL Found 18 available configs
    EGL Using Config 0
    EGL Binding API
    EGL Creating Context
    EGL Creating window surface
    EGL Making Current
    EGL Complete
    GL_VENDOR: VMware, Inc.
    GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 0x300)
    GL_VERSION: OpenGL ES 2.0 Mesa 8.0.4
    GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 1.0.16
    GL_EXTENSIONS: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_OES_draw_texture GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_npot GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_NV_draw_buffers 
    Shader: Compiling data/shaders/shader_color.vert
    Shader: Compiled data/shaders/shader_color.vert
    Shader: Compiling data/shaders/shader_color.frag
    Shader: Compiled data/shaders/shader_color.frag
    Shader: Compiling data/shaders/shader_texture.vert
    Shader: Compiled data/shaders/shader_texture.vert
    Shader: Compiling data/shaders/shader_texture.frag
    Shader: Compiled data/shaders/shader_texture.frag
    EGL Closed
    I'm using the non-free NV drivers btw.

    Can I set the renderer from the command line or must I recompile with specific defs? If so, what?

    The main artifact I see are a few thin rows of pixels floating below platforms. I'll do a screenshot if switching renderer backend doesn't fix it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •