This topic contains 5 replies, has 0 voices, and was last updated by  hobbesme 13 years, 3 months ago.

  • Author
    Posts
  • #2715

    omschaub
    Participant

    Hello.. just found this game and I would love to play it!!

    Problem is this:

    It configs and compiles

    Then I run it .. and the menu pops up .. cool so far..

    Then I try to start a game.. a screen pops up and I can see a red progress bar flash by a couple of times and then poof.. away it goes with the following error:

    terminated unexpectedly
    error given was:
    Program Assert: size==bufferSize_47:…/common/RandomGenerator.cpp

    This is on a brand new AMD64 computer with Geforce MX 5200 card.. opengl works fine on it. I am running 64bit version of Suse 9.1

    I get the same error no matter what options I enable and disable in the settings.

    Any ideas?? Is this because I am using a 64bit computer?? Any help would be appreciated since this game looks like it rocks!!

    Thanks

    #12260

    imported_gcamp
    Participant

    Yes this is 64 bit problem. The program has not been tested with 64 bit portability in mind. It uses longs al over the place (and not just in my code).

    If possible can you compile in 32bit mode?
    Or perhaps changing the occurences of “unsigned long” with “unsigned int” in src/common/RandomGenerator.cpp and
    src/common/RandomGenerator.h MAY fix it.

    #12261

    omschaub
    Participant

    I have been really trying to understand all of this and I have made headway..

    As expected, changing long to int failed to compile

    BUT

    searching the internet for forcing 32bit compiling revealed some insights….

    OK, here we go.. I can force the gcc to go 32 bit with the -m32 option which works.. I can force ld to go 32 bit with the -melf_i386 option and this works..

    I know this works because I can now compile MPlayer which I could not before. So this works really well.

    but what does not work for scorched3d is the freetype2.. even though in Suse, I have the 32 bit version installed, it is still looking in the /usr/lib64 directory instead of the /usr/lib directory where the 32 bit versions should be.

    Just to play around some, I disabled the freetype test and everything compiled, but when I went to run it, I got a segmentation fault

    Also when I am compiling, I am seeing a lot of warnings about ‘cast from point to integer of different size’ and also many like these:

    ld.orig: warning: i386 architecture of input file `fastldlt.o’ is incompatible with i386:x86-64 output
    ld.orig: warning: i386 architecture of input file `fastlsolve.o’ is incompatible with i386:x86-64 output
    ld.orig: warning: i386 architecture of input file `fastltsolve.o’ is incompatible with i386:x86-64 output
    ld.orig: warning: i386 architecture of input file `xmlparse.o’ is incompatible with i386:x86-64 output
    ld.orig: warning: i386 architecture of input file `xmlrole.o’ is incompatible with i386:x86-64 output
    ld.orig: warning: i386 architecture of input file `xmltok.o’ is incompatible with i386:x86-64 output
    ld.orig: warning: i386 architecture of input file `adler32.o’ is incompatible with i386:x86-64 output
    ld.orig: warning: i386 architecture of input file `compress.o’ is incompatible with i386:x86-64 output
    ld.orig: warning: i386 architecture of input file `crc32.o’ is incompatible with i386:x86-64 output
    ld.orig: warning: i386 architecture of input file `deflate.o’ is incompatible with i386:x86-64 output
    ld.orig: warning: i386 architecture of input file `gzio.o’ is incompatible with i386:x86-64 output

    I do not know if I can ever get this program to compile correctly on my system, but I will add my ‘2 cents’ here: More and more people are getting 64 bit computers for ‘personal’ use… I just bought the MB and CPU for $223… that is cheap and many are jumping to this format. Most of the major linux distributors have a 64 bit version out there.. so my point is that this active project should consider starting to reformat the code some to accomadate the newer computer hardware that is out there. I am not bashing / angry / etc. .. I am just honestly saying that I will not be the only one looking through this forum from a 64bit computer wondering why I can look at those cool screenshots and not compile it correctly 🙁

    Thanks for the help gcamp. At least we tried 🙂

    #12262

    hobbesme
    Participant

    @omschaub wrote:

    Also when I am compiling, I am seeing a lot of warnings about ‘cast from point to integer of different size’ … I do not know if I can ever get this program to compile correctly on my system

    @gcamp wrote:

    Yes this is 64 bit problem. The program has not been tested with 64 bit portability in mind. It uses longs al over the place (and not just in my code).

    Depending on the use of absolute or relative pointers in the code base, the warnings about casting from 64-bit pointers to 32-bit pointers may NOT allow the program to run correctly. Can’t say that for certain, but it’s a possibility.

    @omschaub wrote:

    I do not know if I can ever get this program to compile correctly on my system, but I will add my ‘2 cents’ here: More and more people are getting 64 bit computers for ‘personal’ use…

    @gcamp wrote:

    The program has not been tested with 64 bit portability in mind. It uses longs al over the place (and not just in my code).

    The portability, or rather lack of portability, of all the components in the code base is probably the most aggravating factor in failing to correctly upscale the Scorched3D code base to 64-bit CPUs/OSs. And hopefully, the Scorched3D code base has been designed with current AND future portability in mind.

    For instance, language-provided data types like ‘int’ for integer or ‘float’ for floating point values should NEVER be used in application code bases. Instead, all applications SHOULD use user-defined data types like ‘INT32U’ for 32-bit unsigned integer or ‘FP32’ for 32-bit floating point value. These data types would be located in a CPU-/compiler-specific file that is selectively customized for each CPU/compiler. This is a first step to removing CPU-/compiler-dependencies from the code base.

    Even further, data types that MAY need to be expanded for future portability should be application-defined to allow for future upscalability or expandability. For instance, a buffer for a current version of an application may only need to be 16-bit; but future PCs with larger data buffers may require that the buffer size be increased to 32-bit, 64-bit, or higher! Therefore, the buffer size should be its own data type, like ‘SCORCHED_BUF_SIZE’ that should be configured for the application at compile-time. By default, it might initially be configured for 16-bit buffer sizes but easily scalable to 32-bit, 64-bit, etc.

    Also, as Gavin stated — “(and not just in my code)” — the Scorched3D code base may need to make use or include code from other CPU-, OS-, or compiler-libraries. Unfortunately, without modifying the libraries themselves (which may not always be possible), one cannot ensure that the code base is portable or even configurable to be portable.

    Hopefully, the Scorched3D code base is as portable as possible. It must have some high level of portability since it has been designed to run on multiple CPU-, OS-, & compiler-platforms. And if it has a well-designed, portable library & hardware-abstraction-layer API, it’s possible that it could easily change to more portable libraries or eventually be 100% independent of all external libraries or modules (for instance, use NO compiler-supplied functions, libraries, etc.).

    Good luck, though, omschaub, on getting Scorched3D up & running. It IS a great game! 😮

    #12263

    omschaub
    Participant

    Amusingly (and probably because of the portability of this game), I got it to work with Cedega (winex 4.0.1) with no tweaking. I can finally play this game on my AMD64 Linux box — but only using the Windows exe 😯

    It is a GREAT game.. I hope one day I can play it natively, but for now — it plays great with everthing turned on and high… thanks!!!

    #12264

    imported_gcamp
    Participant

    The portability, or rather lack of portability, of all the components in the code base is probably the most aggravating factor in failing to correctly upscale the Scorched3D code base to 64-bit CPUs/OSs. And hopefully, the Scorched3D code base has been designed with current AND future portability in mind.

    Cross platform portability yes, 64 bit portability unfortunately no.

    For instance, language-provided data types like ‘int’ for integer or ‘float’ for floating point values should NEVER be used in application code bases. Instead, all applications SHOULD use user-defined data types like ‘INT32U’ for 32-bit unsigned integer or ‘FP32’ for 32-bit floating point value. These data types would be located in a CPU-/compiler-specific file that is selectively customized for each CPU/compiler. This is a first step to removing CPU-/compiler-dependencies from the code base.

    Good idea. The only area this is done at the moment is the COMs subsystem. I am thinking that it should not matter if the program uses different sized data types internally (provided it runs 🙂 ) just so long as the COMs system allows it to talk to other 32bit systems.

    Even further, data types that MAY need to be expanded for future portability should be application-defined to allow for future upscalability or expandability. For instance, a buffer for a current version of an application may only need to be 16-bit; but future PCs with larger data buffers may require that the buffer size be increased to 32-bit, 64-bit, or higher! Therefore, the buffer size should be its own data type, like ‘SCORCHED_BUF_SIZE’ that should be configured for the application at compile-time. By default, it might initially be configured for 16-bit buffer sizes but easily scalable to 32-bit, 64-bit, etc.

    Don’t think this is an issue as I use sizeof to determine the buffer size in these cases.

    Also, as Gavin stated — “(and not just in my code)” — the Scorched3D code base may need to make use or include code from other CPU-, OS-, or compiler-libraries. Unfortunately, without modifying the libraries themselves (which may not always be possible), one cannot ensure that the code base is portable or even configurable to be portable.

    Yes I have already had quite a lot of issues on this point just from platform compatability.

    #12265

    hobbesme
    Participant

    @gcamp wrote:

    @hobbesme wrote:

    Hopefully, the Scorched3D code base has been designed with current AND future portability in mind.

    Cross platform portability yes, 64 bit portability unfortunately no.

    How difficult would it be to redesign OS/CPU/HW/SW API [data types (CPU API), HAL (HW API), & BSP (CPU/HW API)] to implement a fully portable design?

    @gcamp wrote:

    @hobbesme wrote:

    Even further, data types that MAY need to be expanded for future portability should be application-defined to allow for future upscalability or expandability. For instance, a … buffer size should be its own data type, like ‘SCORCHED_BUF_SIZE’ that should be … easily scalable to 32-bit, 64-bit, etc.

    Don’t think this is an issue as I use sizeof to determine the buffer size in these cases.

    I was using buffer size only as an example. There may be other values that may need to scale to much larger values in the future, while some data types may remain fixed in size/resolution. Here are some other examples :

    Maybe the game only supports 24 players right now because the maps are small & too many players would be ridiculous. So the maximum & current number of players in a game (server) MIGHT be stored in an 8-bit integer (INT08U).

    But what if a few years from now, the game world becomes much more massive, with scattered battles across a large terrain map — tanks & units moving all over the place, coordinating movement & attacks, firing in real-time, etc. ? The game might potentially support 100s of players in the same game environment. Therefore, the data type ‘SCORCHED_NBR_PLAYERS’ may need to be scaled from 8-bit up to 16-bit (INT16U).

    This is of course just a hypothetical example, but I think a very plausible one.

    However, some values may NEVER change. For instance, if you are using integer-math on the turret rotation & elevation angles in tenths of degrees & you suspect that it will never change then ‘SCORCHED_ANGLE_DEGS_TENTH’ may never need to be changed from 16-bit (INT16U).

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.