Games [Non Emu]

[Fzero]

ok im starting to get itchy fingers now, not the only one im sure

Course im well looking forward to playing the typical games, old console classics, ultimately thats whats its all about for me!

I am looking forward to playing some old non-console titles too though, hopefully some old Spectrum games [I grew up on the 48k/128k Speccy, rather than the Amiga which seems to be popular around here]

BUT - I also want to delve into the unknown with my pandora, and try some of these linux games, the Megaman clone thats mentioned in the other post for example, looking forward to that, and the turn based cyborg astronaught war game thats being talked about..

So for these type of games, im clueless, I dont really understand what type of spec i have to be looking for etc, and pretty much just going to see what you guys talk about playing here, and i will try them, and of course will be checking EDs resource page often as that will grow once released im sure [http://dl.openhandhelds.org/cgi-bin/pandora.cgi]

How can i know what linux games will work on pandora, is there a simple way of checking?
[for example on windows you just check the OS platform and that your graphics and RAM can handle it, thats about it really - then you know it will work]
How do you know for linux though?

Basically i was just looking around linux game sites, something ive never done before as never had the need to, and seen some nice stuff, but im not sure if they require certain type of linux, or what have you [all new to me!]

Something like this page, with lots of games on, could these run?
http://www.linux.org/apps/all/Entertainment/Action_Games.html
If not, can you advice me on what type of criteria i should be searching linux games for, when it comes to supported on pandora?

a little game on those very pages called 'Super Tux' looks really nice!
Im sure this is a well known title for linux heads [seeing as its a mario type game], but this is the first time iv heard/seen of it.

can i d/l that?

Or is it a case of, any linux game out there would still need to be ported to work on pandora? [in which case i would have to just wait for others to do the porting magic, and then just get what i can]

just wondering, id like to source a few games in advance to having my pandora, something else to look forward to


any help advice please guys, cheers!

 

[hal9000]

You need at least to cross-compile your game from source to ARM architecture. In the best case it can be really straightforward, but still it is not the job of the end user.

Often you will want to tweak the controls, too.

 

[Sugar_Kane]

I think that the main issue is that if the game was made for an x86 processor then it would have to be ported to work on the pandora anyway, whether it is a linux game or not. I may be wrong but I would have thought that any linux game that has already been compiled for ARM would stand a good chance of running well.

 

[hal9000]

I think that the main issue is that if the game was made for an x86 processor then it would have to be ported to work on the pandora anyway, whether it is a linux game or not.

No, it makes a big difference whether it is a linux game or not.

If it is a linux game, if you have the source, and if your machine is powerfull enough, it should always be easy to port a game.

If it is a windows game, even if you have the source, they are likely to depend on libs which have not and cannot be ported to Linux.

 

[elwing]

If it is a windows game, even if you have the source, they are likely to depend on libs which have not and cannot be ported to Linux.

sorry, but couldn't wine be ported to the pandora for that purpose? (please no flame, I mean not for running x86 binaries, but to offer the library calls for a strait ARM recompiled binary)

 

[kuru]

Pandora games roundup and some keyboard action http://www.youtube.com/watch?v=NL4VtAg_xzo

Determine if a program can be ported http://www.gliffy.com/publish/1448256/

Pandora Port Request Wiki Page http://pandorawiki.org/Port_Requests

Edit: Generally use google with "site:gp32x.de/board [terms]" rather than the forum's search function.

 

[hal9000]

If it is a windows game, even if you have the source, they are likely to depend on libs which have not and cannot be ported to Linux.

sorry, but couldn't wine be ported to the pandora for that purpose? (please no flame, I mean not for running x86 binaries, but to offer the library calls for a strait ARM recompiled binary)

No. Wine works only on x86. It does emulate a system, not the hardware.

 

[Fzero]

excellent thanks guys, i see now that as well as it being linux, the arcitecture is also important, of course, i had overlooked that though, x86 ones are not going to run clearly.

love that diagram!

will maybe put a couple titles that i really like the look of then in the port request thread and see if any of them come to be


I guess my next step is to look for games that are already running on ARM devices, and are linux, and then it should just be a case of porting it over - i might even look into the process of doing that, but i suspect it will be beyond me, so will then move onto that port request thread


nice info though, cheers!

 

[elwing]

If it is a windows game, even if you have the source, they are likely to depend on libs which have not and cannot be ported to Linux.

sorry, but couldn't wine be ported to the pandora for that purpose? (please no flame, I mean not for running x86 binaries, but to offer the library calls for a strait ARM recompiled binary)

No. Wine works only on x86. It does emulate a system, not the hardware.

I repeat "couldn't wine be ported to the pandora" I know that vanila wine is for X86, but isn't it open source?

and I repeat once more, to offer required library call for an ARM recompile, not to run strait x86 binary as this will not work

 

[paulguy]

Another thing is most plain OpenGL stuff won't work. They need to be made for OpenGL es.

Also I'm not sure if this would work, but I wonder if an open source windows game could be compiled against winelib. You'd end up with an arm binary but with emulated windows libraries... As long as it doesn't need OpenGL or likely direct3d or has any assembly language. That depends on the ability of winelib to compile on arm...

 

[hal9000]

Also I'm not sure if this would work, but I wonder if an open source windows game could be compiled against winelib. You'd end up with an arm binary but with emulated windows libraries... As long as it doesn't need OpenGL or likely direct3d or has any assembly language. That depends on the ability of winelib to compile on arm...

It has been said, Wine does not emulate CPU. So it makes no sense to compile it on other architecture than x86

 

[elwing]

Also I'm not sure if this would work, but I wonder if an open source windows game could be compiled against winelib. You'd end up with an arm binary but with emulated windows libraries... As long as it doesn't need OpenGL or likely direct3d or has any assembly language. That depends on the ability of winelib to compile on arm...

It has been said, Wine does not emulate CPU. So it makes no sense to compile it on other architecture than x86

yes it would make sense... to ease the port of open source windows app (through most open source apps seems to be avaible for linux too...)

it would be the general windows library equivalent of nanoGL and such for the openGL part...

 

[hal9000]

Come on, people, this thread is a joke, I repeated 3 times the same thing, I don't see how I can be more clear. It looks like a Monty Python sketch.

Porting wine on non-x86 is not possible, because it does not emulate hardware and therefore should be run on the same hardware as windows does, namely x86. Whether you want to use it for libs or apps makes no difference.

I really don't know how to be more clear, check on the web, on Wine forums, you will find many occurences of the same explanation.

 

[WizardStan]

yes it would make sense... to ease the port of open source windows app (through most open source apps seems to be avaible for linux too...)

it would be the general windows library equivalent of nanoGL and such for the openGL part...

Long story short: it's more complex than you think.
When you compile a program for Windows, bits of code go into the program that tell it how to do things in Windows: creating a window or button, loading a library, etc... Wine intercepts these instructions and interrupts them with the Linux equivalent.
But the program still needs to be compiled with these in them. These bits of code are usually included in the library that you compile into your program. The library that is x86 instructions. How do you put these x86 "open a window", "draw a button", "load a library" instructions into an ARM compiler, and have any sort of Wine-like wrapper recognize them? You would need to have some sort of compile time wrapper library for every x86 library that you want to include, otherwise it just won't compile.

edit:

Come on, people, this thread is a joke, I repeated 3 times the same thing, I don't see how I can be more clear. It looks like a Monty Python sketch.

Porting wine on non-x86 is not possible, because it does not emulate hardware and therefore should be run on the same hardware as windows does, namely x86. Whether you want to use it for libs or apps makes no difference.

He wasn't talking about using Wine to run x86 applications, he wants to use Wine to wrap Windows calls in an ARM compiled application, similar to the way nanoGL wraps openGL calls in an openGLES environment.
The idea has merit. I can appreciate someone who doesn't fully understand how every piece of the puzzle fits together to think it's a good idea. It's possible that something could be done to accomplish that, but it would take a lot of work, probably more work than porting 100 games individually.

 

[paulguy]

Except nobody paid attention that I said winelib, not wine. http://www.winehq.org/winelib

similar idea but completely different in an important way. This could be used in such a way that, given an open source windows program and given winelib compiles for arm because it DOESNT RUN x86 WINDOWS BINARIES ANYWAY, the open source windows program could be compiled against the arm build of winelib. Jesus god, it's like people don't read.

Edit: ninja

 

[elwing]

Long story short: it's more complex than you think.
When you compile a program for Windows, bits of code go into the program that tell it how to do things in Windows: creating a window or button, loading a library, etc... Wine intercepts these instructions and interrupts them with the Linux equivalent.
But the program still needs to be compiled with these in them. These bits of code are usually included in the library that you compile into your program. The library that is x86 instructions. How do you put these x86 "open a window", "draw a button", "load a library" instructions into an ARM compiler, and have any sort of Wine-like wrapper recognize them? You would need to have some sort of compile time wrapper library for every x86 library that you want to include, otherwise it just won't compile.

doh, you do mean the proxy/stub .lib that are compiled with? doh, you're quite right... wouldn't generating some equivalent be quite possible assuming we have the whole .dll equivalent?

edit: hum winelib sound great, wasn't knowing that... I was just assuming it was a part of wine...

 

[ssj195]

Looks like the WINE guys have made a stab at an ARM version of winelib:

http://wiki.winehq.org/ARM