released MHQuake

[xaGe]

..Alrighty then...

[skiller3000]

links are dead, re-up please

[revelator]

links should be up again .

the ati error i can confirm tried it on my old x1900xt and it bails there also. looking at mh's gfx card checks it seems a required function it uses isnt supported by ati weirdly enough this function is standard opengl 1.4 spec jeez sometimes i hate gfx producers.

should be fixable tho ill look at it.

[mh]

links should be up again .

the ati error i can confirm tried it on my old x1900xt and it bails there also. looking at mh's gfx card checks it seems a required function it uses isnt supported by ati weirdly enough this function is standard opengl 1.4 spec jeez sometimes i hate gfx producers.

should be fixable tho ill look at it.

One of the Point Parameters entry points? The "i" versions of them?

Yup, certain ATI cards don't support them, and so are really only "OpenGL 1.3 with extensions" rather than OpenGL 1.4 or above.

If memory serves, those functions aren't even used in the engine, and if they are, you can just as easily replace them with the "f" versions.

[revelator]

yep noticed but thx for confirming

hmm any ideas as to why intel onboard gfx cards go nuts on this one also ?.

atm im trying to get norm mapping on alias models but not sure i can use the same method as on brushmodels hmm ...

[mh]

hmm any ideas as to why intel onboard gfx cards go nuts on this one also ?.

A couple of things in the standard Q1 source cause that. The load disc drawing is the main culprit, but I've found that you'll also need gl_clear 1 and gl_finish 1 to get it to behave, and you may even need to scatter glFinish calls throughout your code. I've the latter in my current codebase (set for Intel only) and it seems to work fine.

Cause of it seems to be that something in the driver goes into an infinite loop, probably caused by the command buffer overflowing (don't ask me where I found that one out, but it is suggested in some obscure corner of a developer forum somewhere). The glFinish calls ensure that it keeps emptying at at least something approaching a steady rate.

[Baker]

The load disc drawing is the main culprit, but I've found that you'll also need gl_clear 1 and gl_finish 1 to get it to behave, and you may even need to scatter glFinish

For certain, on Intels you need to have gl_clear 1 and gl_ztrick 0. (This may be the same as the gl_finish you describe, but I don't have direct access to the one I ran across to play with it right now.)

Something that sucks, the different Intel display adapters have different problems with stock glquake

With stock glquake, if you fix the disc thing, it'll run on all of them.

But on some of them, you need gl_clear 1 and gl_ztrick 0 otherwise the status bar will constantly flicker .. at least.

(I'd like to play with gl_finish 1|0 on one of the Intel display adapters I ran across and see the effect of that on rendering.)

[revelator]

hmm gl_ztrick is removed from source so should be ok.

ill try the gl_finish thing but since i got no intel board i will need someone to test it out any takers ?.

seems nvidia is atm the only company who has a clue to opengl quirks sigh

which reminds me ... anyone tried using glew for opengl handling ?
it makes things quite a tad easier since you dont have to check using PROC but can instead just call the function directly it handles
missing extentions by itself

Code: Select all

if (GLEW_ARB_vertex_program)
{
  /* It is safe to use the ARB_vertex_program extension here. */
  glGenProgramsARB(...);
}


[revelator]

changed the i extentions to normal float works fine on my card but then again it did before also ...

the more i toy with glew the more im impressed its a really nice library to have.

new build soonish .

btw if anyone is interrested im working on the open watcom compiler also "free as in beer" recently a new w32api was made for it to get away from mingw's win 32 sdk and improve compatibility with standard msvc compilers.

using codeblocks ide as a frontend for it i can compile a working darkplaces whereas realm weirdly enough fails in gl_screen on the function mh made as a replacement for software gamma ?!? the failing function is the array float brightcolor[4] = {0, 0, 0, brightblendfactor / 2}; parameter 4 needs to be a constant according to watcom ouch and it doesnt fall for typedefining it as constant but this error is really weird as every other compiler treats it as legid wtf.

[revelator]

ok new build up intel and ati users try it out

ftp://217.157.186.180/Realm_2008_engine.rar

let me hear if it works

[MeTcHsteekle]

just crashes after the picture of the shambler. im using stock Intel stuff (as in it came with the laptop). the image looks nice though

[revelator]

oki getting somewhere then

can you post error if any ?

[Baker]

Doesn't run on my intel.

I get the Shambler. The screen goes fullscreen to entirely black window (I never see the console background). Some hard drive disk action with the black screen.

Then after a few seconds, I get:

"Realm.exe has encountered a problem and needs to close." etc. etc.

No error messages of any type.

On the crash screen with more info, I get "Offset 0007833F" as the code that caused the crash.

[revelator]

oh btw links to the open watcom compiler i worked on .

C/C++ ftp://217.157.186.180/open-watcom-c-win32-1.9 beta.exe
Fortran ftp://217.157.186.180/open-watcom-f77-win32-1.9 beta.exe

it doesnt work well if msvc has its environment variables set globally "tries to use msvc's libraries then" is better if developing in console mode to use the batch file for it anyway newer msvc compilers also do that.

it has basic directx libraries but if you need something a bit more fancy you need the directx sdk.

support on vista x64 is limited to 32 bit executables the 16 bit compiler wont run on vista x64 "not the compilers fault tho".

it does have some limited x64 support.

atm xp works best.

the compiler has some hefty optimization switches and produces
extremly fast executables but the learning curve is a bit steep as it doesnt bode well with less ideal code "HACKS".

the two executables in the link are packed with winrar so you dont have to download the entire folder. it does take a little while before the setup program executes cause it extracts the content to temp before executing setup just in case you wonder why nothing shows up instantly

you can use platform sdk with it.

its still in beta but works rather well allready, expect a few bugs though.

not a bug old watcom code doesnt compile with this.
old watcom loaded and unloaded the runtime dll's to speed up compilation time this was defined in the makefiles on previous versions and is not needed anymore infact you get an error if you try

[revelator]

hmm ok.

i compiled it with msvc 2008 it might need the NET runtimes.

one way to get some debug info from it is to start it with Realm.exe -condebug it will create a log with where in the code it crashes could you try that ?