A Few Q's..


Downsider

Still Fresh
Joined
Oct 4, 2008
Messages
17
1) Can any Linux game made with libraries that have been ported (I.E., SDL) be ported fairly hassle-free?

2) Is developing for the ARM processor any different than your standard Linux enviornment?
 
1) Pretty much yes, if the app itself isn't assuming too much about the environment

2) Not really. Only minor hassle is setting up and using a cross-compiler rather than the standard host compiler.
 
Do i have to recompile .DLL files even if they are cross-platform?

f.ex.:
i use engineXYZ which runs on linux/windows/mac etc. to build my game
this engine even has open GL ES 2.0 support

if i build binaries for windows, i need to put the engineXYZ.dll in the folder the game.exe is

what if i want to build binaries for pandora? can i just switch to the arm-compiler, recompile my sourcecode and then use the pandoragame.exe (or what ever extension pandora is using) with my engineXYZ.dll???

sorry if this is a dumb question, but i always used windows as dev and target platform.
 
Shared libraries and other binaries have platform-specific formats. PE for windows, ELF for linux/bsd, mach for mac. The extension is also different, but that's not as significant.
 
Linux doesn't use .DLLs, it uses shared objects (.so). The formats are completely different.

However, since you say it's compatible with Linux anyway, as long as you can find an appropriate arm or platform neutral linux library, it may work (depending on other dependancies)
 
i just noticed that you are able to MAKE a engineXYZ.a file, which one should copy in lib/Linux to make the binaries work, what about that solution?
 
GabrielM said:
i just noticed that you are able to MAKE a engineXYZ.a file, which one should copy in lib/Linux to make the binaries work, what about that solution?
.a files are static linkage files. Those would be combined with the executable binary at compile time to make a single binary. Not overly a bad idea, but you wouldn't want to do that with things like SDL, etc. as you'll negate what we're providing on the firmware.

Cross-platform libraries aren't cross-platform in the sense of binary cross-platformness unless you're talking .NET or Java. If your game isn't in an interpreted language or a JIT'ed bytecoded language, you're going to have to compile a version for each system architechture (i.e. Windows, MacOS, x86 Linux, Pandora/Beagleboard, etc...) you want to make a version of the game available for.

Interpreted languages (i.e. Python, Ruby, etc...) are good for something like Frozen Bubble, but start declining in usefulness as you get more complex with the game.

Java/.NET answers will get you further (See Tribal Trouble from Oddlabs for an example of this...), but we've not gotten a JDK or Mono gelled on the platform yet and it still won't bring you something like Q3:A with the system we're running under.

Unless you're doing a Python/Ruby/etc game or app, you're very probably going to need to make separate versions at this time.
 
Last edited by a moderator:
Downsider002 said:
1) Can any Linux game made with libraries that have been ported (I.E., SDL) be ported fairly hassle-free?
As long as the title fits within the resource constraints and it's against known to be present libraries, yes, it should be intrinsically so. You might end up with some hassles with the transition from OpenGL to ES 1.1 or 2.0, but most titles would not step on the issues and should move over with only minimal work in most of the cases where you needed to change more than just #ifdef-ing headers.

QUOTE

2) Is developing for the ARM processor any different than your standard Linux enviornment?



Largely no. There's been gotchas in the past with ARM versions, but the Cortex-A8 in the OMAP3 removes most of them such that the code should just come right on over if you've got the library support set up for the hardware we've got. Keep in mind, though, the SoC is limited to a total of 128Mb of RAM which is shared with the GPU- texture heavy stuff might not play nicely with the system and you may have to re-work some of the stuff if you've got a situation like this in hand. Anything with a minimum spec of 64Mb of RAM should largely work with no issues so long as it's not asking for a 1.5GHz P4/Athlon64 type machine.
 
Last edited by a moderator:
Back
Top