OldUnreal (Engine)

Well, the title says it all.
I'm interested specifically on the pandora, though the beagleboard or any future arm device should run it (or even past depending on how it is compiled).
Considering the interest of ARM to get into the lowpower laptop market  these should, hopefully, become more common.

Sadly the game will probably have it's fair deal of x86 assembler code and will make porting difficult.
To top it off, the SGX inside these two devices only support OpenGL ES 2, but a wrapper exists to map OpenGL calls to OpenGL ES ones and replace the missing functionality (basically the fixed pipeline of the earlier versions of OpenGL).

However, make no mistake about it's power, it is capable of running a psx emulator much faster than it should as well as passing with flying colors the Quake 2 benchmarks with no hardware acceleration whatsoever.

The SGX is also quite powerful, moving Quake 3 at 800x480 at almost full 60fps with a quick and dirty port using only the aftermentioned wrapper which is far from optimal.
There is speculation that the device is powerful enough to run Doom 3, at least at 400x240 but with full quality (shadows included). Let's hope ID releases the Doom 3 sources at the next QuakeCon so we can check it out.

But even without hardware acceleration, software mode shouldn't be all that troublesome for the device (minus mmx acceleration, though the neon instructions should be able to replace them).


Please escuse me if this sounds to much like an advert, but I've preordered a pandora and just the thought of running unreal on the go makes me drool.  :D

PS: If this thread is in the wrong place, please move it, and sorry for the inconvenience.

according to smirf, fire texures are almost soley coded in ASM, and there are a few other minor things that use ASM in the pub headers, but I dont know of anything else.

So...
Is Casey's answer pretty much final?
I remember that the dynamic textures are pure assembly, but since it isn't compiler assembly, perhaps it wouldn't be that much work.
Well, even if it were, it won't lose much if the game doesn't have them, at least intially.

Perhaps someone else could help you with it (even me, though I'm still starting with C and ninja ASM can make my brain implode but I could try) since the Unreal Engine 3 deprecated them long time ago and the UE2 barely used them.
I don't think Epic has that much interest in the IP of the code anymore.

Of course, I'm speaking on the ignorance, and the engine code might be riddled with ASM making it too much time consuming, but still,

pretty please?  :D

Thanks nonetheless.

Sorry, I have to admit that I read this message and forgot it again very soon after reading it.
Well, actually the problem isn't coding- most of the ASM stuff is indeed already having c++ counterparts (while I tested not all of it I'm pretty sure most of it is completely functional).

The real problem is, I am the only one who is having the sources and is still actively working and maintaining the game.
You can be assured that Epic is not interested to make the code freely available and they won't give anyone else the code again. That's are things which were made pretty clear already by them and I don't see much chances that they will change their opinion.
Of course I have a very reliable team here and I really can say that without them many things wouldn't have been possible, but the Linux port I made almost completely alone and so it will be for any other port (because of that).

This leads again to the core of the problem. To make such a port I'd need at least such a machine then again and even if someone would donate me one (or the money for it) I can't predict how much time it would consume to make the port- currently I'm still having major health problems, I can't even assure to be able to make it. And once recovered (if at all) I need to work again like anyone else to pay my bills.
Or in other words, I'm doing all this is my free spare time mostly on my costs. The donations I get are hardly enough to pay the page itself...

So I really would love to make it and if possible I'm sure I would make it, but at the moment it seems not to be very likely.

Thanks for the replay, and definitely no hurries, the pandora has been delayed for 7 months after paying and I'm still waiting, so this is no issue.
Besides, better get the final 227 out of the door before thinking about anything else, and specially you should get better soon.

The reason I was suggesting this, is because I (perhaps mistakenly) believe that once a linux port is made in a rather portable way, it should compile with barely any hassles anywhere the same compiler exists (in this case and the defacto standard, gcc, should you use that).

Since both of these machines are full blown computers with complete and uncut linux distros I figured it could be even as easy as recompile with a crosscompiler or on the machine itself. Perhaps a bit naive on my side.

Finally, I'm aware that Epic really likes his code, and will keep an iron grip on it. However, I was suggesting the extra help on the fire engine since, it will probably be completly in asm with no C/C++ alternative and because the fire engine has not been used by Epic for a long time, and probably will stay the same for the rest of its life (or that's what I hope) perhaps they don't have that much of an issue with THAT particular piece of code, as long as it isn't too tightly connected with the rest of the code.

By the way, thanks for all the time and effort to keep Unreal in good shape.

Fire is actually still in UT2k4 with more effects, believe it or not. I don't have UT3 so I couldn't tell you there.. but apparently they liked it

I have an ARM device, so I'm interested in ARM port too. But I have no hope for now. May be wine will help, but I'm not sure that wine works on ARM platform.

Fire is actually still in UT2k4 with more effects, believe it or not. I don't have UT3 so I couldn't tell you there.. but apparently they liked it

Yes, I'm aware in UE2 is still there, heck, I've even made a map once in UT2004 where the shimmer effect from a pool was a wave texture, and it looked seriously cool. There where also an other map (can't remember which) that was included in an important pack with a similar effect. But my point is that that's it, Epic hasn't used it on any map and neither did the community.
I get the feeling that it's not that they included it because they liked it, but because it was already there to begin with, as legacy code from early builds of the engine, and was a waste to just throw it away.

However I think they just scrapped it altogether with the UE3, considering it should be a hell to maintain, and the 256x256 limitation at this age is quite shameful.
At least I haven't found it at the editor of UT3.
A pity actually since you could have done interesting tricks using the wave texture and bumpmaps.

But no professional game actually used it when it was in UE2, considering there where a full blown particle effect to replace fire textures, a pool simulator to replace the wave textures and wet textures, and with the possibility of proper bumpmaps to replace ice textures.
The only one I can remember that PERHAPS used them was Devastation but no more, and perhaps because it used and insanely early build of the engine and it didn't have the pool sheet or whatever it was called, I can't remember.

Now I think about it, could be cool to increase the 256x256 limitation and do some wave and fire textures at 1024x1024 with S3TC textures

I have an ARM device, so I'm interested in ARM port too. But I have no hope for now. May be wine will help, but I'm not sure that wine works on ARM platform.

Wine won't help you there because Wine Is Not an Emulator, which means all it does is recreate the missing windows libraries for a linux installation and add a loader for exes so the windows program feels just like home. That's the only reason linux doesn't have windows applications.
On other architectures, this is no longer that simple, because the game/program is compiled for x86 and it won't even try to execute. To be able to do so, you would have to simulate a full blown x86 processor.
Something like this was done with the Darwine project, where they have a stock Wine installation AND an x86 virtual machine to run windows programs on the now old PowerPC macs.
While this might work with somewhat simple programs on those macs and perhaps on PS3 cell (since it's just a PPC with some extras) this isn't feasible on the usual ARM devices which are very limited on power.

For the record, the pandora and beagleboard have 600 mhz Cortex-A8 processors which are the most powerful ARMs out there (that can be bought right now).

Woa, long post.  ;D
Well, as long as it gets clear.

On other architectures, this is no longer that simple, because the game/program is compiled for x86 and it won't even try to execute. To be able to do so, you would have to simulate a full blown x86 processor.

Thanks, that's why I couldn't compile wine on amd64

You need x86 libs and you should be able to install it.