Quake 3


Last edited by a moderator:
I kinda got side-tracked by other projects and didn't really get too far. All I've basically done so far is port ioquake3 to QGLWidget & qmake and nearly got it to work. That was months ago though. :-(

Just waiting for someone to carry on the work. I found a patch sitting in ioquake3's bug tracker which re-factors ioquake3's renderer to replace glBegin & friends with OpenGL ES 1.1 friendly calls.

The work break-down as I see it is:

1) Port ioquake's renderer to OpenGL ES 1.1 (probably using patch in bug-tracker as a start)
2) Adapt input system to use the Pandora's controls
3) Add an EGL/X11 back end to SDL so it can do context management
4) Polish, play with different texture compression, etc.

I think (3) will have to be done anyway as I guess most people will be wanting to use SDL for OpenGL context management.
 
sindbad said:
I think I would prefer dpad+analog. The xbox controller always bugged be because of the reverse placement of the left analog and dpad.
Reverse? It's actually the right way to do it. It prevents your thumbs from colliding like on the crappy Playstation controllers where the analog sticks were added as an afterthought. There is a reason both Nintendo and Microsoft did it this way.
 
Last edited by a moderator:
OrR said:
sindbad said:
I think I would prefer dpad+analog. The xbox controller always bugged be because of the reverse placement of the left analog and dpad.
Reverse? It's actually the right way to do it. It prevents your thumbs from colliding like on the crappy Playstation controllers where the analog sticks were added as an afterthought. There is a reason both Nintendo and Microsoft did it this way.



yub, thats what I wanted to say!
the xbox does it right.
its the only gamepad its possible to play 1stperson shooters with
 
Last edited by a moderator:
Tom Cooksey said:
I kinda got side-tracked by other projects and didn't really get too far. All I've basically done so far is port ioquake3 to QGLWidget & qmake and nearly got it to work. That was months ago though. :-(

Just waiting for someone to carry on the work. I found a patch sitting in ioquake3's bug tracker which re-factors ioquake3's renderer to replace glBegin & friends with OpenGL ES 1.1 friendly calls.

The work break-down as I see it is:

1) Port ioquake's renderer to OpenGL ES 1.1 (probably using patch in bug-tracker as a start)
2) Adapt input system to use the Pandora's controls
3) Add an EGL/X11 back end to SDL so it can do context management
4) Polish, play with different texture compression, etc.

I think (3) will have to be done anyway as I guess most people will be wanting to use SDL for OpenGL context management.
Why re-invent the wheel when you can use the Angstrom code-base and the renderer code used in the iPhone and Pocket PC ports? Check my post on the previous page back for the links.

That is where I would start. Oh and I don't think you need to worry about texture compression too much, we do have 256 MB ram now which is plenty to run Quake with highest texture detail settings. It played it on my 1998 PC which ran Quake 3 with 128MB RAM :p

And can people talk about the best ideal control scheme for fps games on the pandora in another thread? It's becoming a real eye-sore seeing it for pages, when its such a trivial thing.
 
Last edited by a moderator:
MDave said:
Why re-invent the wheel when you can use the Angstrom code-base and the renderer code used in the iPhone and Pocket PC ports? Check my post on the previous page back for the links.
Yeah, that's kinda what I meant by use the patch in the ioquake bugzilla. Personally, I'd like to see the changes to the renderer get accepted upstream as there's still a log of development going on in ioquake3. It's time consuming to track upstream changes (like VoIP landing 3 weeks after I stated working on it). Using the WinCE port is also a possibility (but I think it's pretty old) and the guy who did the iPhone port is the one who posted the patch I'm talking about.

Less wheel-re-inventing is always a good thing IMO, but then I'm lazy (hense the lack of progress on Quake 3!)
 
Last edited by a moderator:
I have hear that the Q3 port for WinCe or Iphone is ugly and note realy done in the good way
 
MDave said:
And can people talk about the best ideal control scheme for fps games on the pandora in another thread? It's becoming a real eye-sore seeing it for pages, when its such a trivial thing.

Especially when the only proper way to do it is to let people define their own bindings. ;)
 
Last edited by a moderator:
Eniko said:
Especially when the only proper way to do it is to let people define their own bindings. ;)
...and considering that the subject in question allows this... :D




Yod4z said:
I have hear that the Q3 port for WinCe or Iphone is ugly and note realy done in the good way
Relative concept. Looking at the videos for the iPhone/iPod-touch, it looks like they're working with lowest possible resolution and reduced quality textures that would be required because of RAM pressures on the devices in question. Ditto the WinCE versions' looks, based on what I'm seeing on the Google Code website for the Q3CE project. Moreover, I'm not wholly sure what people mean by "not really done in the good way" either.
 
Last edited by a moderator:
Yod4z said:
I have hear that the Q3 port for WinCe or Iphone is ugly and note realy done in the good way
I stopped looking at it, when I saw the guy thought it was clever to rename .c files to .cpp. Certainly not a good sign :rolleyes:
 
Last edited by a moderator:
Well, now that Quake 3 is running on the Pandora, I have the ask:

Is this ioQuake3? If so, will you(whoever ported it) contribute the patches back to the ioQuake3 devs?
 
no the quake3 that you have seen is using nanogl which is just a wrapper to opengles and not a native port therefore probaby not wanted for inclusion in ioQuake3
 
'cb88' said:
no the quake3 that you have seen is using nanogl which is just a wrapper to opengles and not a native port therefore probaby not wanted for inclusion in ioQuake3
Yes, but is the underlying engine ioQuake3? I know NanoGL is a wrapper; is this just a straight recompile for ARMEL?
 
Last edited by a moderator:
Shouldn't be too hard to get ioquake ported over now that vanilla Quake 3 is.

Just do a diff on the Pandora port and the original PC source to see where the changes are, and then apply those changes to the ioquake source (obviously not a simple copy and paste job) :)
 
Last edited by a moderator:
Well to save some people some time talking......

ioquake works, I played it last night :)
cpasjuste found a maemo patch for SDL that interfaces with EGL and modified the exisiting . We tweaked nanogl to add some missing gl calls and presto working ioquake.
 
'Pickle' said:
Well to save some people some time talking......

ioquake works, I played it last night :)
cpasjuste found a maemo patch for SDL that interfaces with EGL and modified the exisiting . We tweaked nanogl to add some missing gl calls and presto working ioquake.
Most excellent! Are we going to have both on launch? :)
 
Last edited by a moderator:
MDave said:
'Pickle' said:
Well to save some people some time talking......

ioquake works, I played it last night :)
cpasjuste found a maemo patch for SDL that interfaces with EGL and modified the exisiting . We tweaked nanogl to add some missing gl calls and presto working ioquake.
Most excellent! Are we going to have both on launch? :)

Both what?
 
Last edited by a moderator:
Back
Top