Release Quake2 Nanogl

[ldesnogu]

Without any actual experience using the DSP core, I can only ask why it would. The DSP core is separate from the ARM core. Why would it matter? Using NEON could affect overclocking. I can see how that makes sense but not with DSP. As long as the bridge between the ARM and DSP is divided down to a normal clock speed I would speculate that each one doesn't really care what the other is doing.

I keep on forgetting what clock generates what :unsure: If the DSP clock is independent from the MPU clock, then what you say is probably true; however I wonder if the voltage increase needed for MPU overdrive couldn't cause problems to the DSP.
QUOTE
Again, I can only make guesses as the DSP is uncharted territory on Pandora (as far as I know no one has looked at it yet). I don't think it gets much use yet on Beagle does it?

Some people have started playing with it, though I don't know how far they went.
I think the DSP could be put to very good use for sound (both for emulators and games in general). I really hope we'll soon see its power on Pandora and Beagle

 

[EdCa22]

What exactly is nanogl? The web page says a lot of stuff about windows ce. Is it really an opegl to opengl es translator? ES 1.1 or 2.)? That will be very handy indeed for other ports!

Looks great, keep up the good work!

 

[lulzfish]

It's sort of like an OpenGL library that translates any calls it gets into OpenGL ES.
It makes porting a lot easier, but I think the extra layer of interpretation slows it down a bit.

 

[ldesnogu]

What exactly is nanogl? The web page says a lot of stuff about windows ce. Is it really an opegl to opengl es translator? ES 1.1 or 2.)?

My understanding is that this is part of the port of Quake[123] to Symbian. Look here:
CODE
http://koti.mbnet.fi/hinkka/index.html

It's an OpenGL to OpenGL ES 1.1 translator.

QUOTE
That will be very handy indeed for other ports!

Certainly. But I guess that to get the maximum out of SGX one needs to use OpenGL ES 2.0.

 

[fusion_power]

There is no need to render at anything less than 800*480 because it runs fine, we were just hoping to see some silly 100+ frame rates at lower resolutions.

Well, the Pandora is a battery powered Handheld. If I can increase my battery-time by reducing the resolution and clocking down the CPU, of course I will play at 480x240 IF this increases Battery Time.
I hope the Game will run full speed at STANDARD clocking (or less), I don't plan to overclock my Pandora, the Battery Lifetime is more important for me. \^_\^
IMHO Overclocking fits for a PC but not for a battery driven Handheld. Here I prefer underclocking.

 

[Pickle]

Try adding "eglSwapInterval(glDisplay, 0);" after eglMakeCurrent() in the function GL_Init().

I did try this, maybe I put it in the wrong location.

I have some controls working now using the event devices, this was holding us back on q3a. I will try and add these in tonight.

Edit: I did run quake2 with fsaa enabled. There is a hit, but still playable.

At 55 Mhz no fsaa we get fps in the 30 range
At 110 Mhz no fsaa we get fps in the 60 range
At 110 Mhz with fsaa we get fps in the 30 range

Thats what I remember, I dont remember what resolution I did it at. I think i was 800x480.

 

[Spirit]

Nice, looks like that particular port you based the Quake port on has fullbright support!

 

[MDave]

Can't wait to see how crisp and smooth it looks for real

Just wondering Pickle, are you eventually going to convert the gl code to gles 1.1 eventually? This could help performance by a lot

 

[ldesnogu]

Just wondering Pickle, are you eventually going to convert the gl code to gles 1.1 eventually? This could help performance by a lot

What makes you think so? If there are not many GL calls per frame (and I think it's the case for Q2) then the cost of the wrapper will be rather low. OTOH again full conversion to GL ES 2.0 might be better.

 

[Pickle]

Can't wait to see how crisp and smooth it looks for real

Just wondering Pickle, are you eventually going to convert the gl code to gles 1.1 eventually? This could help performance by a lot

It probably wont be me if it happens, my opengl knowledge is actually quite limited.
A lot of the functions are simple pass through. But functions like glbegin/glend have some wrapper code. I really wonder if theres that much of performance cost to using it, if there is any cost its on the cpu side not the sgx. If the hit was the cpu side I would think higher clocks would have a greater impact?
If you went straight opengles I suspect the render code would need a major overhaul, and at that it would be better I think if opengles 2.0 was used.

Spirit: what is fullbright support? The ports are actually really the original source from ID. There is one quake engine that isnt, but I havnt shown that.

 

[lulzfish]

I think fullbright is where the player models have lighting turned off, so their color is just determined by their texture maps, not the surrounding lights.

It makes them easier to see, I guess.

 

[ldesnogu]

A lot of the functions are simple pass through. But functions like glbegin/glend have some wrapper code. I really wonder if theres that much of performance cost to using it, if there is any cost its on the cpu side not the sgx. If the hit was the cpu side I would think higher clocks would have a greater impact?

You can see by running oprofile

 

[Xmas]

Edit: I did run quake2 with fsaa enabled. There is a hit, but still playable.

At 55 Mhz no fsaa we get fps in the 30 range
At 110 Mhz no fsaa we get fps in the 60 range
At 110 Mhz with fsaa we get fps in the 30 range

Thats what I remember, I dont remember what resolution I did it at. I think i was 800x480.

Those numbers seem very much vsync-limited.

What makes you think so? If there are not many GL calls per frame (and I think it's the case for Q2) then the cost of the wrapper will be rather low. OTOH again full conversion to GL ES 2.0 might be better.

Porting a fixed function engine to ES 2.0 is usually not worth the effort, unless it has some complex vertex processing on the CPU that could be moved to a vertex shader. Simple multitexturing won't be any faster when expressed as a fragment shader.

The biggest performance gain can probably be had by using texture compression.

 

[ldesnogu]

What makes you think so? If there are not many GL calls per frame (and I think it's the case for Q2) then the cost of the wrapper will be rather low. OTOH again full conversion to GL ES 2.0 might be better.

Porting a fixed function engine to ES 2.0 is usually not worth the effort, unless it has some complex vertex processing on the CPU that could be moved to a vertex shader. Simple multitexturing won't be any faster when expressed as a fragment shader.
Ha that's very interesting, and I'm glad I was cautious when saying 2.0 could be faster
I'm not very familiar with OpenGL ES or SGX, but I thought SGX had to rely on vertex shaders to handle the fixed pipeline of ES 1.1. If this indeed is the case, then what you say means that SGX driver is well optimized to handle 1.1 on 2.0 hardware with appropriate vertex shaders. Is that a correct guess?

QUOTE
The biggest performance gain can probably be had by using texture compression.

Because that'd reduce memory bandwidth and/or help texture staying in SGX cache?

 

[Spirit]

Spirit: what is fullbright support? The ports are actually really the original source from ID. There is one quake engine that isnt, but I havnt shown that.

edit: Sweet jesus, here you go for a properly linked version: CODE
http://www.quaddicted.com/stuff/temp/arghdora.html


I was the guy who proposed porting the excellent engine Fitzquake in IRC once (dunno if they reposted it when you were there).

There are two things called "Fullbrights". QW/Multiplayer people will mean fullbright coloured skins for enemies (and items), for example: http://gfx.quakeworld.nu/details/210/

I mean fullbright support for textures though. The last 32 colours in the Quake palette are meant to be rendered at full bright regardless of the surroundings. GLQuake did not do that for some sad reason and thus most ports don't either. http://www.celephais.net/stuff/texturefaq.htm

I made this crude image to show the difference: http://www.quaddicted.com/stuff/quake_fullbrights.jpg (start.bsp, don't mind the shadow behind the slipgate, there is a flickering light source...)

There is also overbright lighting. Another reason why software rendered Quake looks much more vibrant than vanilla GLQuake: http://www.quaddicted.com/stuff/quake_overbright.jpg (sm139_spd from http://www.quaddicted.com/filebase/sm139_pack.zip)
Post #15 in http://www.celephais.net/board/view_thread.php?id=60133


Fitzquake is THE (very faithful) standard for modern singleplayer maps. It's awesome.
If you are interested take a look at the (quite outdated now) http://www.quaddicted.com/engines/engine_comparison.html for ideas. Fitzquake would get the sole recommendation nowadays, a new version was released in the meantime.

PS: I should add that I am a Quake addict and cannot code anything. Otherwise I'd have a go on it. =(

 

[Xmas]

Ha that's very interesting, and I'm glad I was cautious when saying 2.0 could be faster
I'm not very familiar with OpenGL ES or SGX, but I thought SGX had to rely on vertex shaders to handle the fixed pipeline of ES 1.1. If this indeed is the case, then what you say means that SGX driver is well optimized to handle 1.1 on 2.0 hardware with appropriate vertex shaders. Is that a correct guess?

The ES 1.1 driver generates pretty optimized hardware shader code for each fixed pipeline setup. Using ES 2.0 only pays off if you want to do something different from the fixed pipeline (or if you need one of the additional API features). If you tried to replicate the fixed function pipeline with GLSL ES shaders you'd probably end up with lower performance.

QUOTE
QUOTE
The biggest performance gain can probably be had by using texture compression.

Because that'd reduce memory bandwidth and/or help texture staying in SGX cache?
Yes, less bits per texel means more texels fit in the cache for better re-use, and of course textures are smaller.

 

[MDave]

Pardon my ignorance, but would swizziling textures help?

 

[Pickle]

Spirit: what is fullbright support? The ports are actually really the original source from ID. There is one quake engine that isnt, but I havnt shown that.

Fitzquake is THE (very faithful) standard for modern singleplayer maps. Its awesome.
PS: I should add that I am a Quake addict and cannot code anything. Otherwise Id have a go on it. =(

I will look into it, the other engine ive used is tyr-quake. Its just trying different engines takes time.
Goal #1: Get some form of q1/q2/q3 running. Nanogl was written to support the original source, thats the reason im staying that way for now, it makes it easier for me to see what was changed for the symbian versions.

First priority for me is getting solid keyboard/mouse support. I did the intial work last night and successfully started (and played ) a q2 games. I need enhance the code a bit more and then add it to q3. q3 is compiled, but we cant get any farther cause the game needs a cd-key. And you cant enter in the cd-key without the keyboard.

 

[(naw)mcx]

Spirit: what is fullbright support? The ports are actually really the original source from ID. There is one quake engine that isnt, but I havnt shown that.

Fitzquake is THE (very faithful) standard for modern singleplayer maps. Its awesome.
PS: I should add that I am a Quake addict and cannot code anything. Otherwise Id have a go on it. =(

I will look into it, the other engine ive used is tyr-quake. Its just trying different engines takes time.
Goal #1: Get some form of q1/q2/q3 running. Nanogl was written to support the original source, thats the reason im staying that way for now, it makes it easier for me to see what was changed for the symbian versions.

First priority for me is getting solid keyboard/mouse support. I did the intial work last night and successfully started (and played ) a q2 games. I need enhance the code a bit more and then add it to q3. q3 is compiled, but we cant get any farther cause the game needs a cd-key. And you cant enter in the cd-key without the keyboard.

You do? From my experience, you don't have to shove one in.

Try with the demo?

 

[Spirit]

Tyrquake is a very nice Linux glquake port.
Definitely a big step in the right direction (10 times better than plain glquake)

There is a SDL port of the previous Fitzquake version at http://www.kristianduske.com/fitzquake/
I am sure the latest version (0.85) will get ported some day, the goal was to merge the SDL port and the official one from what I know. Maybe it would be wise to wait for that.

Fitzquake is the target for most maps nowadays, that's why I am so after it.