Username
Fuckass
Are the nubs pressure sensitive? I imagine that they would be.
It's already been, for all intents and purposes, ported... It's just that there's some hardware accel rendering work needing to be re-done for OpenGL ES once we get drivers, etc...dentrado said:Has someone said they will port Quake 3 yet? I know it should be relatively easy, but have somone actually said that they are going to do it?
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.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.
OrR said: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.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.
yub, thats what I wanted to say!
the xbox does it right.
its the only gamepad its possible to play 1stperson shooters with
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.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.
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.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.
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.
...and considering that the subject in question allows this...Eniko said:Especially when the only proper way to do it is to let people define their own bindings.
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.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:Yod4z said:I have hear that the Q3 port for WinCe or Iphone is ugly and note realy done in the good way
Yes, but is the underlying engine ioQuake3? I know NanoGL is a wrapper; is this just a straight recompile for ARMEL?'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
Most excellent! Are we going to have both on launch?'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.
MDave said:Most excellent! Are we going to have both on launch?'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.
Both what?