Xreal - Most Advanced Open Source Engine Based On Q3 Engine

[streak]

Look what i found today

An engine called XreaL based on ID Tech Q3 Engine, full opensource and WITH openGL ES 2.0 full support. Hell yeah. Some good people said that its most advanced oipensource engine out there for FPP games [ but not only ].

Some links for your pleasure:

CODE

http://xreal.sourceforge.net/xrealwiki/ -> more detailed infos
http://xreal.sourceforge.net/xrealwiki/Features -> features
http://sourceforge.net/projects/xreal -> Downloads
http://www.xreal-project.net/wordpress/ -> Main news

Butterman, Your opinion please

 

[skeezix]

To be specific --

The author of that port claims its the most advanced engine around.



jeff

 

[sindbad]

It's comparable to Nexuiz in its 'advancement'. It does have much cleaner code, and only uses an OpenGL subset compatible with OpenGL ES 2.0.

 

[Vorporeal]

Still, if it's comparable to Nexuiz and already is basically OGLES2.0 compatible, it's a winner in my book.

 

[Pickle]

In fact I tried to port it yesterday, but Im running into memory requirement problems. I got it to build and everything, but its killed instantly.
With some help with darkblu he found that the binary was looking to grab 170 mb for static variables.

 

[bzar]

In fact I tried to port it yesterday, but Im running into memory requirement problems. I got it to build and everything, but its killed instantly.
With some help with darkblu he found that the binary was looking to grab 170 mb for static variables.


That's a lotta static variables! I wonder what they're all for. Maybe it's for preloaded textures and such, that could be shrinked to fit? I honestly have no idea, but I hope this can be ported B)

 

[borgqueenx]

it looks damn nice!
we need a port like this. or something else that has desame kind of screenshots. glad you gave it a shot Pickle. It would be very cool to have a engine capeable to have that kind of graphics

 

[Exophase]

In fact I tried to port it yesterday, but Im running into memory requirement problems. I got it to build and everything, but its killed instantly.
With some help with darkblu he found that the binary was looking to grab 170 mb for static variables.

Too bad we don't have Pandora boards with 256MB of RAM eh?

 

[borgqueenx]

In fact I tried to port it yesterday, but Im running into memory requirement problems. I got it to build and everything, but its killed instantly.
With some help with darkblu he found that the binary was looking to grab 170 mb for static variables.

Too bad we don't have Pandora boards with 256MB of RAM eh?

only for static variables right?
so i guess it should the whole engine, every piece, takes more then 256mb ram...?

 

[Exophase]

so i guess it should the whole engine, every piece, takes more then 256mb ram...?

I don't think you understand, I wasn't being sarcastic. Our Pandora boards (the MK2's) only have 128MB of RAM. Apps will be killed (and deliver the message "Killed") if their static memory can't even be allocated.

 

[Wolfsclaw]

I'm sure borgqueenx understood that.
What he meant was that, when the static variables already take up 170MB of RAM, the whole game/engine could take up >256MB. Which would be a bummer.

 

[Exophase]

I'm sure borgqueenx understood that.
What he meant was that, when the static variables already take up 170MB of RAM, the whole game/engine could take up >256MB. Which would be a bummer.
Could, or maybe not. Or maybe it'd take up more than 256MB regardless of whether or not it took so much static. If we had 256MB Pandora's then we'd be able to find out.

I don't have a lot to base this on, but I think when a game has so much space in global arrays it probably allocates very little on the heap afterwards.

 

[gp2.eXe]

so i guess it should the whole engine, every piece, takes more then 256mb ram...?

I don't think you understand, I wasn't being sarcastic. Our Pandora boards (the MK2's) only have 128MB of RAM. Apps will be killed (and deliver the message "Killed") if their static memory can't even be allocated.


Well, I had to go to the Pandorawiki to understand that ... Maybe borgqueenx also didn't know...

 

[darkblu]

I'm sure borgqueenx understood that.
What he meant was that, when the static variables already take up 170MB of RAM, the whole game/engine could take up >256MB. Which would be a bummer.

frankly, i am still puzzled what might be the need for so much statics (without having looked at the source, that is). as Picke and i discussed yesterday, my wild guess is that they have some sort of a custom allocator/resource manager, for which they allocate statically. clearly it's not some actual data as it would not have ended up in the bss.

 

[zacaj]

Well, run it in windows and look at mem usage in task manager, that will give you a basic idea how much memory it needs

 

[ledow]

Or, seeing as it's Linux-based, wouldn't a 128Mb swapfile on an SD or something tell you if it's able to run in 128 real + 128 virtual RAM? It'd be dog-slow, but it'd only be a test to see if the optimisation is necessary at all.

 

[Tinnus]

Well, run it in windows and look at mem usage in task manager, that will give you a basic idea how much memory it needs

Well, not exactly. Windows' Task Manager can give you an idea most of the time, but it's not exactly known for its accuracy (it usulally reports less than the app is really using).

 

[darkblu]

Or, seeing as it's Linux-based, wouldn't a 128Mb swapfile on an SD or something tell you if it's able to run in 128 real + 128 virtual RAM? It'd be dog-slow, but it'd only be a test to see if the optimisation is necessary at all.

a reckless hack that might work is to hex-edit the elf header, fixing the respective section's memsz field (i.e. the one specifying 170MB) to something allocatable - say, 50-80MB. if the app actually uses that bss area for its internal allocations, as i suspect, one could hope that high addresses in that area will be accessed sufficiently later in the app lifespan, so we could get some "free ride" till then. either that or the app will quickly crash with a SIGSEGV as some unsuspecting access runs out of bss and right into unallocated heap space ; ) but at least the app will have progressed past the elf loader stage *grin*

 

[Kramy]

Well, run it in windows and look at mem usage in task manager, that will give you a basic idea how much memory it needs

Well, not exactly. Windows' Task Manager can give you an idea most of the time, but it's not exactly known for its accuracy (it usulally reports less than the app is really using).

Hey, it's more accurate than Gnome's task manager. You can also display the VRAM column to get an idea of how much RAM the application is prepared to consume.

But if you're worried, use Process Explorer. It displays all that fancy stuff like shared RAM, protected RAM, mapped memory, etc. :lol:

 

[borgqueenx]

I'm sure borgqueenx understood that.
What he meant was that, when the static variables already take up 170MB of RAM, the whole game/engine could take up >256MB. Which would be a bummer.

yep, what he said. sorry for my not so great english

i hope so exophase, the first screenshot of the engine in the first post looks awesome. the shadows and stuff.