Horde3D

Next-Generation Graphics Engine
It is currently 22.02.2025, 09:27

View unanswered posts | View active topics


Board index » Horde3D Usage » Bug Reports

All times are UTC + 1 hour




Post new topic Reply to topic  Page 1 of 1
  [ 11 posts ] 
  Print view Previous topic | Next topic 
Author Message
cefwyn
PostPosted: 08.09.2009, 17:00 
Offline

Joined: 08.09.2009, 16:45
Posts: 2
I was surprised at how easily Horde3D compiles on 64-bit Linux considering how much effort it was with older versions. There is however one issue which is pretty easy to fix and I didn't see it mentioned on this forum.

In the file egShader.cpp at around line 266 in the class Tokenizer:
Code:
static const int tokenSize = 128;

should be
Code:
static const long tokenSize = 128;

otherwise you will probably get errors around line 339 and 340 from this bit of code:
Code:
std::min( _p - p0, tokenSize-1 )

because _p - p0 becomes a long int, while tokenSize-1 is an int and apparently GCC 64-bit doesn't like that.

To maintain 64-bit compliance without breaking 32-bit support it's pretty easy to just replace int with long when not dealing with pointers since on 32-bit they are identical width datatypes on most architectures and on 64-bit a long is usually what the programmer is really wanting when they type "int". It does get a bit messy though as on Windows "int" and "long" are identical even on 64-bit so they are both 32-bit datatypes but on Linux int is 32-bit and long is 64-bit, but since most of the stl code like std::min use long in place of int, long is the safer bet and just means more accuracy on 64-bit linux.
Top
 Profile  
Reply with quote  
marciano
PostPosted: 08.09.2009, 21:52 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Thanks a lot for the hint, the line you mention needs to be fixed.

When using int, I always assume 32 bits, even on 64 bit systems. I would not replace int32 by long in general because usually you don't need the additional bits and in that case long64 would just waste memory and worsen the cache behavior.
Top
 Profile  
Reply with quote  
cefwyn
PostPosted: 09.09.2009, 19:36 
Offline

Joined: 08.09.2009, 16:45
Posts: 2
Yeah, if your really wanting a 32-bit int then that line should remain as it is, but unfortunately much of STL appears to use long in place of int and so you need to at least type-cast to long when passing to std::min just so it doesn't confuse the compiler.
Top
 Profile  
Reply with quote  
mihai
PostPosted: 02.10.2009, 19:31 
Offline

Joined: 02.10.2009, 19:26
Posts: 5
I have the following problem when building on Linux 64 (Arch):
Code:
/home/mihai/builds/Horde3D/Horde3D_SDK_1.0.0_Beta4/Horde3D/Source/Horde3DEngine/egRenderer.cpp: In member function ‘unsigned char* Renderer::useScratchBuf(uint32)’:
/home/mihai/builds/Horde3D/Horde3D_SDK_1.0.0_Beta4/Horde3D/Source/Horde3DEngine/egRenderer.cpp:94: error: ‘uintptr_t’ was not declared in this scope
/home/mihai/builds/Horde3D/Horde3D_SDK_1.0.0_Beta4/Horde3D/Source/Horde3DEngine/egRenderer.cpp:94: error: expected ‘;’ before ‘_scratchBuf’
/home/mihai/builds/Horde3D/Horde3D_SDK_1.0.0_Beta4/Horde3D/Source/Horde3DEngine/egRenderer.cpp:94: error: invalid operands of types ‘unsigned char*’ and ‘int’ to binary ‘operator%’
Top
 Profile  
Reply with quote  
marciano
PostPosted: 03.10.2009, 10:28 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Could you check where (in which header) uintptr_t is defined on your system? Actually the whole statement could be reduced to "return _scratchBuf;". The rest is just to align the pointer to 16 bytes so that memory accesses are a little faster (at least in theory).
Top
 Profile  
Reply with quote  
mihai
PostPosted: 03.10.2009, 11:59 
Offline

Joined: 02.10.2009, 19:26
Posts: 5
marciano wrote:
Could you check where (in which header) uintptr_t is defined on your system? Actually the whole statement could be reduced to "return _scratchBuf;". The rest is just to align the pointer to 16 bytes so that memory accesses are a little faster (at least in theory).

I know most of these results are unrelated to your question, but maybe something can ring a bell.
Code:
$ grep -nrHE *typedef.+uintptr_t\;+ /usr/include
/usr/include/sofia-sip-1.12/sofia-sip/su_types.h:79:typedef unsigned SU_INTPTR_T uintptr_t;
/usr/include/caca_types.h:85:typedef unsigned long int _caca_uintptr_t;
/usr/include/xulrunner-1.9.1/unstable/qcmstypes.h:29:typedef PRUptrdiff uintptr_t;
/usr/include/xulrunner-1.9.1/unstable/qcmstypes.h:67:typedef unsigned __int64 uintptr_t;
/usr/include/xulrunner-1.9.1/unstable/qcmstypes.h:69:typedef unsigned long uintptr_t;
/usr/include/xulrunner-1.9.1/unstable/jsstdint.h:66:typedef unsigned JS_INTPTR_TYPE uintptr_t;
/usr/include/boost/test/impl/execution_monitor.ipp:82:    typedef unsigned uintptr_t;
/usr/include/boost/test/impl/execution_monitor.ipp:86:typedef void* uintptr_t;
/usr/include/wine/msvcrt/crtdefs.h:101:typedef unsigned __int64 uintptr_t;
/usr/include/wine/msvcrt/crtdefs.h:103:typedef unsigned int uintptr_t;
/usr/include/c++/4.4.1/stdatomic.h:112:  typedef atomic_ulong       atomic_uintptr_t;
/usr/include/apr-1/apr.h:292:typedef  apr_uint64_t            apr_uintptr_t;
/usr/include/apr-1/apr.h:294:typedef  apr_uint32_t            apr_uintptr_t;
/usr/include/python2.6/pyport.h:89:typedef uintptr_t   Py_uintptr_t;
/usr/include/python2.6/pyport.h:93:typedef unsigned int   Py_uintptr_t;
/usr/include/python2.6/pyport.h:97:typedef unsigned long   Py_uintptr_t;
/usr/include/python2.6/pyport.h:101:typedef unsigned PY_LONG_LONG   Py_uintptr_t;
/usr/include/gc/gc.h:1046:     typedef unsigned long uintptr_t;
/usr/include/php/TSRM/TSRM.h:37:typedef unsigned __int64 tsrm_uintptr_t;
/usr/include/php/TSRM/TSRM.h:40:typedef unsigned long tsrm_uintptr_t;
/usr/include/php/Zend/zend_types.h:47:typedef unsigned __int64 zend_uintptr_t;
/usr/include/php/Zend/zend_types.h:50:typedef unsigned long zend_uintptr_t;
/usr/include/stdint.h:123:typedef unsigned long int   uintptr_t;
/usr/include/stdint.h:129:typedef unsigned int      uintptr_t;

The code in the last file is:
Code:
/* Types for `void *' pointers.  */
#if __WORDSIZE == 64
# ifndef __intptr_t_defined
typedef long int      intptr_t;
#  define __intptr_t_defined
# endif
typedef unsigned long int   uintptr_t;
#else
# ifndef __intptr_t_defined
typedef int         intptr_t;
#  define __intptr_t_defined
# endif
typedef unsigned int      uintptr_t;
#endif
Top
 Profile  
Reply with quote  
phoenix64
PostPosted: 04.10.2009, 00:02 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
This is how I just got horde3d to compile on 64bit ubuntu karmic. Everything except including stdint.h (header for uintptr_t) should be safe on all other platforms I can think of. There you can use some hack though like ifndef-ing for MSC_VER around it.

stdint.h however is *not* available on msvc as they don't support C99 (hey - that was 10 years ago -.-).

The thing about stdio.h is about sprintf not being found when using gcc 4.4.

Code:
Index: Extensions/Terrain/Sample/main.cpp
===================================================================
--- Extensions/Terrain/Sample/main.cpp   (Revision 193)
+++ Extensions/Terrain/Sample/main.cpp   (Arbeitskopie)
@@ -19,6 +19,7 @@
 #include <iostream>
 #include <cstdlib>
 #include <cstring>
+#include <cstdio>
 #include "glfw.h"
 #include "app.h"
 
Index: Horde3D/Source/Horde3DEngine/egShader.cpp
===================================================================
--- Horde3D/Source/Horde3DEngine/egShader.cpp   (Revision 193)
+++ Horde3D/Source/Horde3DEngine/egShader.cpp   (Arbeitskopie)
@@ -335,8 +335,8 @@
       const char *p0 = _p;
       seekChar( " \t\n\r{}()<>=,;" );  // Advanve until whitespace or special char found
       if( _p == p0 && *_p != '\0' ) ++_p;  // Handle special char
-      memcpy( _token, p0, std::min( _p - p0, tokenSize-1 ) );
-      _token[std::min( _p - p0, tokenSize-1 )] = '\0';
+      memcpy( _token, p0, std::min( _p - p0, (long)tokenSize-1 ) );
+      _token[std::min( _p - p0, (long)tokenSize-1 )] = '\0';
    }
 
 public:
Index: Horde3D/Source/Horde3DEngine/egRenderer.cpp
===================================================================
--- Horde3D/Source/Horde3DEngine/egRenderer.cpp   (Revision 193)
+++ Horde3D/Source/Horde3DEngine/egRenderer.cpp   (Arbeitskopie)
@@ -20,6 +20,7 @@
 #include "egTexture.h"
 #include "egShader.h"
 #include "egLight.h"
+#include <stdint.h>
 
 #include "utDebug.h"
 
Index: Horde3D/Samples/Knight/main.cpp
===================================================================
--- Horde3D/Samples/Knight/main.cpp   (Revision 193)
+++ Horde3D/Samples/Knight/main.cpp   (Arbeitskopie)
@@ -19,6 +19,7 @@
 #include <iostream>
 #include <cstdlib>
 #include <cstring>
+#include <cstdio>
 #include "glfw.h"
 #include "app.h"
 
Index: Horde3D/Samples/Chicago/main.cpp
===================================================================
--- Horde3D/Samples/Chicago/main.cpp   (Revision 193)
+++ Horde3D/Samples/Chicago/main.cpp   (Arbeitskopie)
@@ -19,6 +19,7 @@
 #include <iostream>
 #include <cstdlib>
 #include <cstring>
+#include <cstdio>
 #include "glfw.h"
 #include "app.h"
 



Edit: Stupid phpBB removes spaces in front of lines even in code blocks. This probably breaks the patch, so I attached it manually again.


Attachments:
File comment: Patch to fix compilation under x64 ubuntu karmic.
fix_compilation.patch [2.06 KiB]
Downloaded 1090 times


Last edited by phoenix64 on 04.10.2009, 11:23, edited 1 time in total.
Top
 Profile  
Reply with quote  
mihai
PostPosted: 04.10.2009, 03:31 
Offline

Joined: 02.10.2009, 19:26
Posts: 5
Thanks for the patch!
Top
 Profile  
Reply with quote  
mihai
PostPosted: 04.10.2009, 14:11 
Offline

Joined: 02.10.2009, 19:26
Posts: 5
The patch did not work for me, and it also has something that I can't find in my sources: Extensions/Terrain/Sample/main.cpp.

I attach the patch I used to build my Arch package. It should be used from above the source dir (Horde3D_SDK_1.0.0_Beta4/) with
Code:
patch -Np0 -i fix.patch
Maybe this would help someone else who like me, has a hard time using its command-line options.


Attachments:
fix.patch [2.23 KiB]
Downloaded 1070 times
Top
 Profile  
Reply with quote  
phoenix64
PostPosted: 04.10.2009, 17:18 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
My patch is for the current sf.net SVN (with terrain extension).
Top
 Profile  
Reply with quote  
Volker
PostPosted: 03.11.2009, 11:15 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
Seems like this patch hasn't been integrated yet, so I did it now. But I wonder why you had to add #include <stdint.h> to egRenderer.cpp. I just compiled it under Ubuntu 9.10 and didn't need that. And VS2005 does not provide a stdint.h
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 1
  [ 11 posts ] 

Board index » Horde3D Usage » Bug Reports

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 57 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group