Quake 2 freezes.


Silent-Hunter

Hardcore Member
Joined
May 29, 2010
Messages
3,485
The first time I played it, it lasted about 10 minutes. But the second time, it froze after about 40 seconds.
 
Happens to me from time to time as well. My aid is to reboot and no OC over 600.
 
Last edited by a moderator:
It happened to me a lot with old firmware, but since RC3 or RC4 (I can't remember) is a lot more stable for me.
 
I am not sure but ive read some devs say that it's because of the driver for the GPU it sometimes hangs. (I hope imgtec will release a better driver! )


Then again I could be completely wrong.
 
I'm bumping this topic because I really love Quake 1 and 2 and would like to be able to complete the game on Pandora without crashing twice in each level. (Controls aren't a problem for me.)
 
I'm bumping this topic because I really love Quake 1 and 2 and would like to be able to complete the game on Pandora without crashing twice in each level. (Controls aren't a problem for me.)

I've seen the Quake 2 freezes, It's new to me as of Hotfix 7 Beta 1.. But never seen Quake 1 freeze.
 
I'm bumping this topic because I really love Quake 1 and 2 and would like to be able to complete the game on Pandora without crashing twice in each level. (Controls aren't a problem for me.)

I've seen the Quake 2 freezes, It's new to me as of Hotfix 7 Beta 1.. But never seen Quake 1 freeze.

Quake 1 doesn't freeze, I probably shouldn't have mentioned the game at all in my post. I still do think that zQuake was a bad engine choice to port, since it's a QuakeWorld engine with NetQuake progs.dat support added afterwards. It's also not so true to the original when you look at the new HUD (can be switched off) and new view model placement.
 
Have a response about yamagi :

> I enjoy your PC port, but i wonder if it works on ARM, or if you have plans for it.
>


> I own this machine :


> http://openpandora.org/


>


> and the q2 port isn't stable.


Since I haven't access to any non-x86-cpus it's untested on ARM. But


the OpenPandora has a little endian ARM cpu (there are some problems


with big endian, they're on our todo list) and yQ2 is written in pure


C without any assembler so chances are good that it'll work with no or


small changes. Things to consider are:


- Other architectures than i386 and amd64 (x86_64) are disabled in


the Makefile. You'll have to remove lines 31 - 35 of the Makefile.


- There are no platform strings for ARM, the game will detect the


platform as "unkown". You can add the strings to the following


source files:


- src/common/header/common.h


- src/game/savegame/savegame.c


But that's not necessary for the game to work.


Ciao,


Yamagi
 
If someone gets time to make a go at compiling this for the Pandora, can I put in a request for mouse control (so I can use an external mouse)?. It's still the one thing that's lacking from the other Quake ports so far (I think) :)
 
Wait for the release of the Slackware port, a build script already exists for yq2.


I tried to compile it some weeks ago, but it failed (makes sense with the dev explanations ^^).
 
I may of got it compiled, but with everything I do with cross-compiling, I need to check if it actually works. I'm using Notaz's new SDL.. so hopefully that will allow external mouse support.. I need to check on how to use the NanoGL.. I take it I just compile it and plop it in and select it as the default quake 2 video driver.
 
Cool, looking forward to seeing the progress on this! Thanks everyone for the hard work(I know nowt about coding!!)


(null)
 
The nanogl ports have been problematic, with the freezes. I dont know really where the problem is since its basically impossible to debug. That was one reason I took the time to convert zquake, which i choose because it used SDL and opengl in a reasonable manner.


I took at quick look at the yamagi q2 and thats look nice, the files are organized and so far the opengl calls look reasonable. At the time of the quake2 port with nanogl I really had no concept of opengl API. But today is different, I could convert yamagi and I would expect it may be more stable as zquake was. I like that it was based on ioquake2.
 
Response about GLES :

Good morning :)

OpenGL ES is a graphics library for embedded device, loosely based on


the normale OpenGL. There are 2 versions:


- OpenGL ES 1.x is based upon the fixed function pipeline of OpenGL 1.x


and 2.x, like it's used by Quake I to III.


- OpenGL ES 2.x is based upon the free programable pipeline of OpenGL


2.x to 4.2. While it allows the usage of modern features like shader


and tesselation it's a complete distinct approach to the old OpenGL


1.x


If the OpenPandora doesn't support the normal OpenGL 1.x, but only


OpenGL ES, porting is not that easy. There are 3 possible approches:


1. Use an OpenGL to OpenGL ES wrapper library. With the wrapper no


changes need to be done to Quake II itself. The problem is, that


wrappers are slow and often slighty incompatible, leading to


problems. NanoGL is such a wrapper.


2. Port Quake II to OpenGL ES 1.1. Since it's based upon the old OpenGL


1.x used by Quake II and Quake II has a _very_ simple renderer, this


should be easy.


3. Port Quake II to OpenGL ES 2.0. This would be nice, but requires a


rewrite of the renderer.


What ever you do, patches are welcome. :)


Ciao,


Yamagi
 
Back
Top