realm test

[revelator]

completly forgot to upload the "hopefully fixed" realm engine.

i set blooms initial value to something not as obtrusive.
added on the fly video res changing "needs a tweak to the menu offsets but works".
ARB fragment shaded lava haze replacing the nvidia only code "newer worked right anyway weird blend artifacts" the code may make it into slime haze to perhaps using entity scripts. i have an idea for something but atm its hush hush

http://www.savefile.com/files/2006905

sorry it took so long but i caught a nasty infection after getting a root canal so been "out of order for a while".

[MeTcHsteekle]

ouch i hear root canal is really painful, and an infection on top :S

but the engine works and i get reasonable frame rate for all the sweetness going on, a good cool:fps ratio

also perhaps you should put it on www.quaketastic.com so it wont get lost to the void

GJ :O

//id make comments but then again im the guy who likes to play quake with extremely low gamma/brightness with square alpha'd partials that linger for a bit...i also like stainmaps

[revelator]

sure m8 and glad to hear it works yay.

and for those who dont know it supports compressed pk3 so if you have a sheetload of textures and or models you can save quite some space using that the performance hit isnt to bad actually i only feel it on load times.

the engine loads pretty much any map regardless of size yes even marcher no extra commandlines needed the memory handling was totally rewritten it now uses what is nessesary automatically.

it also frees up the loaded memory at map change "everything gets cleared".

surfs are bumpmapped using a technique to calculate the cubemap origin based on player position mh can fill you in on it its also way way faster than normal bumpmapping unfortunatly havent got around making code for alias models yet its in the drawer though i hope mh can give me a hand with it sometimes cause i dunno if my skills are sufficient.

the engine doesnt need any external data but will load it if present im working on an idea to use entity scripts to fill in gaps where quake's bsp format falls short "like data for stainmaps decals etc" without them the game will run like normal with them you could define things the bsp doesnt normally hold the info for and hence make effects that would normally be impossible.

so off to code some more

and aye root canal is nasty

[revelator]

uploaded source and compiled engine + dll's its in singleplayer.

http://www.quaketastic.com/upload/files ... 9_2_17.zip

[Error]

ok, am I living under a rock?

what is "realm"?

[revelator]

its a project i been working on based on one of mh's older engines
that supported bumpmaps.

i changed it quite a bit over time but still called it mhquake some users felt i should give it my own feel tho cause i pretty much rewrote the entire engine so being the mmo nut i am i called it realm

its a quake engine simple doesnt use any fancy models like md3 and such just plain ol mdl and some nifty feats to please the eye.

it also has some rather scary limits as to what a mapper can do with it since the vm is based on aquires code it can litterally take maps the size of stuff that would frighten godzilla. models to .

[MeTcHsteekle]

hehe turn the bloom alpha all the way up, Trippe disco quake

[revelator]

aye it can be a bit over the top

currently working on destroying mh's mp3 player well not destroying but since dx is more or less win only peeps who might want to port this will have a tough time so im looking at alternatives hmm lamemp3 im looking at you!!!

also trying to figure out a way to dynamically allocate handles for pk3 atm it uses a static array with a max size of 1gb which may spell trouble on lower end machines heh.

also need to get rid of the old demo code which is the only part i still miss from being able to load the entire game from pk3 "pretty massive rewrite ahead umf".

and if anyone is fluent in ARB fragment shaders i could use a hand on the water slime lava etc. i tried porting kmquake2's water shaders but the engine crashes not quite sure whats up with that the port i made for heat haze works so im a bit puzzled maybe the dsttexture code hmmm ?

[hondobondo]

if it's based on aguirre's quake then i can play super duper quake on it. not even the new fitzquake can handle it

[revelator]

the vm and most of the model code is, so unless it uses anything outside of that then aye it should run

it cant run mods that require specialized engines like some telejano mods "lack of scripting etc."

in excempt its a just a solid glquake engine with its limits upped "or removed" with some better gfx and a more stable renderer for modern cards it doesnt support md2 nor md3 models only plain ol mdl it does have its poly limits upped considerably though so can actually make some pretty detailed mdl's for it.

trying to stay as close as possible to normal quake with it but i guess i could add in md2 and md3 support without breaking anything but only if people want it ?.

things that are planned are nehahra support atleast since aquires engine supports that mod also.

[revelator]

well tried it and no doesnt run alltho i use some of aquires code i dont have frikbot support in yet. sdquake also uses some nehahra extensions it seems from looking at the code im working on that part .

but atm the vm will bitch LOUDLY!!! if you try it on realm

ill see what can be done.

[xaGe]

..Well this latest one works on my new laptop. I couldn't afford a great one so this one has another Intel video chipset. This one sports a GMA 4500MHD..

[hondobondo]

the nehahra requirements are minimal. i added a few gl_glows to my version of the engine, that's about it for qc. i tried realm and it looks good in quake, but it chokes on skin heights. i fixed those in the models, and the engine hangs. keep working on it. looking forward to another engine to use. right now it's only darkplaces and aguirre quake.

[revelator]

ah good to know

shouldnt be a problem once i get full nehahra support running "planned anyway".

ill have a look at the glow code but i suspect it to require some rewriting in realm cause the glows in realm arent qc controlled hmm, well might as well start adding qc scaling in as well.

and glad it works on the intel boards now

[hondobondo]

had to think about what i did. gl_glows aren't actually controlled in qc. i was thinking about EF_RED and EF_BLUE. i only added some models which have glow effects: TE_beam, some models for the freedom bomb, and the flame2 model. but i run it in standard aguirre glquake all the time without the glows. anyway. hope this helps. i can post a debug output of the glquake warnings if you like, but i'm sure you can do the same. it's mostly skin heights, model vertices, excessive commands in models, and excessive model skin size. i might just post it anyway to get some input