released MHQuake

[MeTcHsteekle]

*ehem* :

[revelator]

looks ok i guess ?

[Baker]

oh forgot it shouldnt be limited to only ati or nvidia only requirement
it has is full opengl 1.4 support on the gfx card i believe most modern cards have that ?

I rarely use my Intel display adapter except for dual monitor purposes, Realm runs fine on my Nvidia laptop and desktop, but won't run on my Intel display adapter ...

Gets Sys_Error "Extension GL_*_generate_mipmap NOT Found!! Aborting Realm ..."

Most Intel laptops and a lot of Intel desktops come with those Intel display adapters.

I believe the drivers I have are OpenGL 1.2 for that Intel display.

This could be the problem he is having.

A cursory search of the Intel site indicates that maybe for a lot of these displays, OpenGL 1.3 is the latest and they have not released OpenGL 2.0 drivers for anything.

[revelator]

ow

[Spike]

There are a lot of cards that have buggy gl_sgis_generate_mipmaps extensions.

Code: Select all

//      gl_config.sgis_generate_mipmap = true;


Damn drivers.

[revelator]

true well sucks unfortunatly i dont have an intel card else i would try to see if i could fix that particular error and others if nessesary.

should someone have the time and nessesary hardware to fix it it would be nice

[xaGe]

Sys_Error: Extension GL_*_vertex_array NOT Found!!!
Aborting Realm...Sys_Error: Extension GL_*_vertex_array NOT Found!!!

I have a Acer Aspire running an Intel 945GM using OpenGL version 1.4.0 - Build 7.14.10.4926

..I'll just stick to the ones that work fine for me DP, FTE, and EZQ... Just wanted to try Realm out. The screen shots look good overlooking the bloom abuse in a few of them, but hopefully bloom intensity is controllable. The lava looked sexy as hell.

..If I get lucky for my upcoming birthday/Xmas Santa(my wife) will buy the new laptop I want with that Nvidia 9800M in it then I could play practically anything I wish..

[revelator]

intel cant handle vertex arrays !!! /facepalm well seems laptops with intel chipsets are a nogo atm will try on my friends when he comes to visit maybe i can fix it.

and yes bloom is controllable via the menu

[revelator]

hmm looking into the intel chipsets i noticed they dont support locking vertex arrays atleast not the 945 - 965 line. unfortunatly that means without rewriting a huge part of the renderer i cant make them work for those cause mhquake uses array locking a lot :S

if it had only been the mipmap generation it would have been doable
but im not really sure what to do about this ?

[xaGe]

..Not a big deal really, just make it known its unsupported on Intel video chipsets in the readme or something...

if it had only been the mipmap generation it would have been doable
but im not really sure what to do about this ?

[Spike]

Vertex arrays are an opengl 1.1 feature.
They are required by all opengl 1.1 implementations. Quake requires 1.1 features anyway, and this is the minimum version supported by any microsoft driver too.

glDrawRangeElements is an opengl 1.2 feature (glDrawRangeElementsExt is GL_EXT_draw_range_elements).
This can be emulated easily enough using 1.1 functionality.

If vertex arrays are not supported then your card is pure shite.

GL_EXT_compiled_vertex_array provides only the functions glLockArraysExt and glUnlockArraysExt. If its not supported, you can use stubs/no-ops for them, or simply not call them.

[revelator]

hmm aye was wondering also vertex arrays have been in opengl allmost from the start Oo.

weirder tho it points to a problem with it getting detected properly
looking at the code CVA isnt even a requirement for it to run the Sys_Error should actually only fire if vertex arrays arent present at all
and i somehow doubt that

the code for checking looks sound enough tho i simply dont get this error

[mh]

Hey nice. I approve.

Keeping the engine name is fine; it's only a poxy executable name, after all.

Vertex arrays should work on any Intel; they certainly have been working on mine for a few years now. Shouldn't be any need to check for them in the extension string either; they're such a standard feature that manufacturers probably expect to get away with not including them in it.

[xaGe]

..Well since I was not able to run this engine with my laptop using Intel graphics I figured I would give it a go on my desktop with my capable ATI RADEON 1950 Pro that I use to play other GlQuake engines and games Oblivion, Doom 3, WOW, etc...

.. mhglqr81 yet again fails to run for long before a crash, but gets further then it does on the laptop. Here is a screen shot of all that prints to console before the crash:



..Seems to die right after displaying, “Map not vis'ed for transparent water”

..mhglqr81.exe does make a whopping 5516 line log dump called mss.log that ends abruptly at the end of it in mid print... Not sure whats happening other than it seems to baulk at the fact that my maps aren't vised for transparent water. I didn't know that was a requirement to run this engine? Ultimately it gives me a windows error, “AppName: mhglqr81.exe crashed along with ModName: atioglxx.dll ModVer: 6.14.10.8201, yadda, yadda, yadda...

..This again is on Windows XP SP3 and pretty recent (with in a few months) ATI drivers. If there is any other information I could provide you with reckless just ask...

[Baker]

I had the same problem, so I had to vis my maps first.

Really ...

One nifty idea would be for this engine to include extern .vis support (rip from QIP source code = here) and include a .pk3 file (this supports that I read, right?) in the download.

Here is a .zip I made of the external .vis files (download) for all id1 maps (I used this to test the QIP engine external .vis data support).