Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

symbian port

Help
iwanj
2004-11-07
2013-04-17
1 2 > >> (Page 1 of 2)
  • iwanj
    iwanj
    2004-11-07

    Hi all,

    I managed to build ogles lib+test on symbian using UIQ2.1 SDK (emulator only, don't have working device at the moment). Everything was built and run fine, but the texture mapping on the car looks patchy (there are many area not covered with texture). I'm no expert on opengl, so could someone please point me where to start looking at the code? (Is there anyway I could post the screenshot to better explain the problem?)

    Cheers,
    Iwanj

     
    • First of all, it's great that you got that far already. What I would check is what the display format of your device is. 3650 and n-gage, for example, use a 12-bit x444 color format for the framebuffer, which is different from the 565-format that Windows Mobile and newer Symbian devices use.

      Let me knoe how it goes,
      HM

      PS: You can upload images as part of a support request.

       
    • iwanj
      iwanj
      2004-11-07

      Hi,

      I use UIQ emulator and create texture bitmap in EColor64K mode, which according to the docs is 16bpp and the format is supposed to be RGB565.

      Quote from Symbian Developer Library
      "64k-colour displays effectively support RGB values with 5 bits allocated to red, 6 to green and 5 to blue"

      I uploaded the screenshot via support page.

      Cheers,
      Iwanj

       
      • Actually, the texture does not look distorted at all on the car. However, it seems that there are problems with the triangle culling. That's in ContextTriangles.cpp, Context::IsCulled.
        As you can see, the calculation is done using 64-bit numbers, in order to avoid artifacts like the one you. It is very well possible that there are compiler differences in the way 32/64 bit conversions are done.
        I'd first start by turning culling completely off.
        If it renderes correctly, you'll probably have to carefully review this code to see what needs to be adjusted for gcc.

        - HM

         
    • iwanj
      iwanj
      2004-11-08

      Cool!
      I'll try your suggestion and pay more attention to int64 issues. Thanks.

       
    • iwanj
      iwanj
      2004-11-08

      You're right! With culling disabled, it renders correctly.

      Btw, is there anyone in this project maintain the Symbian port? In the meantime I'll see if I can fix this culling/int64 problem in Symbian port.

      Iwanj

       
      • No, so far nobody is maintaining it. I set up the project structure when somebody else was interested, but back then I got no follow up.

        Would you be interested in joining the project?

        - HM

         
    • iwanj
      iwanj
      2004-11-09

      I had no experience in working on open source project, which means I might ask lots of question later :-). If it is okay, I'll be happy to join this project.

      Iwanj

       
    • EJ_Z
      EJ_Z
      2004-11-15

      Hi All,
      I don't know if it's off the topic... but...
      The compiler is complaining about the 64 bit int to 32 bit conversion without an explicit notification when building the uglu.c.  Actually we can define another Macro and give the compiler a clear idea on how to convert it rather than simply cut it by half...

      Regards,
      EJ

       
    • Iwanj, what have you been doing? Adding a simple cast?

      - HM

       
    • iwanj
      iwanj
      2004-11-17

      Hi,

      Sorry for late reply, I was away for couple days.

      Symbian UIQ2.1 uses class TInt64 to deal with 64 bit integer.  I extend this class to allow casting to EGL_Fixed/int which are used in many places.

      As for uglu.c, I am not aware of any warning mentioned by EJ as I didn't build the ug part. I did build the gles_cl,codegen and created test application for Symbian.

      Iwanj

       
      • Hi Iwan,

        this is a clever tricks but it breaks things for ARMI build, as whole TInt64 class is inlined in e32std.h. Therefore, TInt64x must be inlined too to prevent linker errors. After this change, tint64x.lib is no longer needed and can be removed.

        Janusz Gregorczyk

         
        • With gcc fixes and inlined TInt64x class, Vicent compiles  for ARMI. There's a remaining issue of static data - writeable static data (either initialized or not) cannot be used on Symbian.

          There are four places in Vincent where writeable static data is used. Three of them are easily fixed with minor changes (adding a const specifier and turning EGL_FixedFromFloat into a macro); remaining one is s_AllConfigurations table in Config.cpp - it is unimportant and can be hacked away for now.

          There's a similar problem with test code. I'll get back to it later on and see if it runs on a device (can't wait to see it!).

          Janusz Gregorczyk

           
          • Janusz,

            Iwan is just about as far as you (he sent me the diffs, but they are not checked in yet). Maybe the two of you want to coordinate. I proposed to Iwan to set up a branch off 0.83 in which the Symbian version could be finished before being merged down int the head.

            WDYT?

            - Martin

             
            • Great, I'll contact Iwan and ask if he needs help.

              Janusz Gregorczyk

               
    • iwanj
      iwanj
      2004-11-18

      woohoo, culling works fine now!

       
    • Outstanding! Do you currently use the JIT, or are you directly executing the rasterization code?

      - HM

       
    • iwanj
      iwanj
      2004-11-20

      It's not using JIT as it was built for emulator. I tried building for ARM target, but gcc crashed while compiling gles_cl lib. I assume that would be my next task ;).

      Iwanj

       
      • What compiler version have you been using?

        - HM

         
    • iwanj
      iwanj
      2004-11-21

      I was using gcc which comes with Symbian UIQ2.1 SDK. The gcc version is 2.9-psion-98r2.

      This was the last message before it crashed.
      ..\\..\\SRC\\Arrays.h:209: warning: assuming & on `::EGL::VertexArray::FetchFloa
      tValues(int, GLfixed *)'
      (X:\EPOC32\gcc\lib\gcc-lib\thumb-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) Except
      ion: STATUS_ACCESS_VIOLATION
      (X:\EPOC32\gcc\lib\gcc-lib\thumb-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) Dumpin
      g stack trace to cc1plus.exe.core
      thumb-epoc-pe-gcc: Internal compiler error: program cc1plus got fatal signal 0

      And this is the stack trace:
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) Exceptio
      n trapped!
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) exceptio
      n C0000005 at 424530
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) exceptio
      n: ax 108A3B04 bx 10D8CBB0 cx 0 dx 20
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) exceptio
      n: si 108A3B8C di 108A3B8C bp 25EF2A0 sp 25EF248
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) exceptio
      n is: STATUS_ACCESS_VIOLATION
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) Stack tr
      ace:
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 0:
      sp = 0x25EEE3C, pc = 0x1000947D
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 1:
      sp = 0x25EEE74, pc = 0x7C9037BF
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 2:
      sp = 0x25EEE98, pc = 0x7C90378B
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 3:
      sp = 0x25EEF48, pc = 0x7C90EAFA
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 4:
      sp = 0x25EF2A0, pc = 0x422F18
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 5:
      sp = 0x25EF2F4, pc = 0x464F0F
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 6:
      sp = 0x25EF308, pc = 0x4231E5
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 7:
      sp = 0x25EF31C, pc = 0x421BD7
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 8:
      sp = 0x25EF348, pc = 0x423886
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 9:
      sp = 0x25EF3B8, pc = 0x422EF3
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 10
      : sp = 0x25EF40C, pc = 0x464F0F
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 11
      : sp = 0x25EF420, pc = 0x417970
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 12
      : sp = 0x25EF4D4, pc = 0x4365ED
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 13
      : sp = 0x25EF504, pc = 0x4601AA
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 14
      : sp = 0x25EFD70, pc = 0x48F4E2
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) frame 15
      : sp = 0x25EFD98, pc = 0x492E85
      (X:\EPOC32\gcc\lib\gcc-lib\arm-epoc-pe\2.9-psion-98r2\cc1plus.exe 1002) End of s
      tack trace (more stack frames may be present)

      Iwanj

       
      • I see. I have been using the compiler from the 1.2 SDK (last time I tried compiling was back in summer), and that one did not seem to have this problem.

        - HM

         
        • Hi!

          I've downloaded Vincent just today and successfully ran it on the Series60 emulator. The only issue I've encountered was that of test code being UIQ specific so  I had to slightly modify it.

          ARMI build doesn't compile though, with gcc crashing just as Iwan described. I may investigate it further later on.

          Great job!

           
    • iwanj
      iwanj
      2004-11-26

      I upgraded symbian gcc with latest version from
      http://www.inf.u-szeged.hu/symbian-gcc/

      Now I am making progress, as the new compiler give errors instead of crashing ;).

      Iwanj

       
    • iwanj
      iwanj
      2004-12-01

      The linking problem in ARMI build can be solved by statically linked tint64x.lib. But Janusz suggestion to make the class inlined sounds good to me.

      Iwanj

       
    • case04
      case04
      2005-11-02

      Hi all,

      can someone tell me whether the redbook examples (which use the ug-library)  are running in the symbian build ?  I was able to compile them, but when starting on my s60-device the program crashed with the error-msg "program closed: Main!"

      best regards,
      os

       
1 2 > >> (Page 1 of 2)