Xreal - Most Advanced Open Source Engine Based On Q3 Engine


streak

Active Member
Joined
Jul 29, 2007
Messages
690
Age
42
Location
Poland & UK // Currently: Ipswich
Website
www.openpandora.pl
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



shot0082.jpg


shot0009.jpg


shot0010.jpg


Butterman, Your opinion please :)
 
Last edited by a moderator:
To be specific --

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

;)

jeff
 
Last edited by a moderator:
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.
 
Last edited by a moderator:
Still, if it's comparable to Nexuiz and already is basically OGLES2.0 compatible, it's a winner in my book.
 
Last edited by a moderator:
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.
 
Pickle said:
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)
 
Last edited by a moderator:
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 :)
 
Last edited by a moderator:
Pickle said:
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?
 
Last edited by a moderator:
'Exophase' said:
'Pickle' said:
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...?
 
Last edited by a moderator:
borgqueenx said:
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.
 
Last edited by a moderator:
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.
 
Last edited by a moderator:
Wolfsclaw said:
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.
 
Last edited by a moderator:
Exophase said:
borgqueenx said:
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 :p ... Maybe borgqueenx also didn't know...
 
Last edited by a moderator:
'Wolfsclaw' said:
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.
 
Last edited by a moderator:
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
 
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.
 
Last edited by a moderator:
'zacaj' said:
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).
 
Last edited by a moderator:
'ledow' said:
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*
 
Last edited by a moderator:
'Tinnus' said:
'zacaj' said:
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. :p 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:
 
Last edited by a moderator:
'Wolfsclaw' said:
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 :p

i hope so exophase, the first screenshot of the engine in the first post looks awesome. the shadows and stuff.
 
Last edited by a moderator:
Back
Top