FitzQuake Mark V - Easy to compile and ...

Discuss programming topics for the various GPL'd game engine sources.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: FitzQuake Mark V - Easy to compile and ...

Post by Baker »

revelator wrote:Btw baker, how would i go about loading an image via texmgr with no data width heigth and only the texture name ?
im toying with adding tenebraes particel lexer and decals to quakespasm.
In order to add a texture in the FitzQuake texture manager, you use the TexMgr_LoadImage function.

You have to be very clear ...

1) who owns the texture? Does the map own it (cleared with map change)? Does a model own it? (cleared when models are flushed?) FitzQuake-derived engines can gamedir change, this means flushing all the models.
2) the manner of which it can be reloaded (reload from file? reload from memory?)
3) The type of file (rgba vs Quake palette).
4) Texture processing attributes. Is it an alpha texture? Does it picmip? Is it gl_nearest (like HUD elements that never go linear filtering)?

Code: Select all

	gl.gltexture = TexMgr_LoadImage (NULL /*owner*/, path /*this is the name to display when listing the textures*/, dat->width, dat->height, SRC_INDEXED /*means quake palette*/, dat->data, path /* this is the reload path, NULL for load from memory*/,
									  sizeof(int)*2, TEXPREF_ALPHA | TEXPREF_PAD | TEXPREF_NOPICMIP); //johnfitz -- TexMgr
Another way to phrase it, it is more involved but it yields many benefits in being able to reload textures or clear specific type of types.

It is very structured.

Note: Spike added decals to Quakespasm in Quakespasm Spiked.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

Ah i might have a look at spikes version then :) thanks for the explanation.
I do have a few things i want to try and push onto this engine like the tenebrae particle system, and mh's allmost lossless bumpmapping.
I do have a feeling it would look nice in the end hehe. The particle lexer is pretty nice but not many people have experience working with flex scripts which is a bit sad as it works quite nice and the code is pretty close to the old particle code.
Productivity is a state of mind.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: FitzQuake Mark V - Easy to compile and ...

Post by Baker »

revelator wrote:mh's allmost lossless bumpmapping
Now you've made me curious. :biggrin: Do you have the source code of one of MH's old engines with this feature?

/I'm operating on the idea that might have on QuakeSrc.org at some point, but dead because it is no longer available.

Also: Quakespasm Spiked has FTE's particle's system. Just providing information.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

Yup ;)
I can upload it somewhere ?

One thing to note, mh's version does not use Per pixel lighting "so no shadowmaps etc." instead it relies on some rather fancy trickery,
the end result is not as spectacular as FTE with rtlights but the effect is rather nice on the eyes regardless. And its way way waaaaaaay faster hehe.

Also i think i got how to use texmgr now, something like this ?

Code: Select all

                case TOK_MAP:
                    int	 fwidth, fheight;
                    byte *data = Image_LoadImage(SC_ParseString(), &fwidth, &fheight);
                    if( data )
                    {
                        effect->texture = TexMgr_LoadImage(NULL, "particle", &fwidth, &fheight, SRC_RGBA, data, SC_ParseString(), (src_offset_t)data, TEXPREF_NOPICMIP|TEXPREF_LINEAR|TEXPREF_ALPHA);
                    }
                    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
                    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
                    break;
Productivity is a state of mind.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: FitzQuake Mark V - Easy to compile and ...

Post by Baker »

revelator wrote:Yup ;)
I can upload it somewhere ?

One thing to note, mh's version does not use Per pixel lighting "so no shadowmaps etc." instead it relies on some rather fancy trickery,
the end result is not as spectacular as FTE with rtlights but the effect is rather nice on the eyes regardless. And its way way waaaaaaay faster hehe.
http://www.filedropper.com/ is one place to upload files for free and I don't think it requires registration.

I'd like to see it because I'm interested in trickery. MH usually comes up with some insane ideas.

And since QuakeSrc.org around the time I started engine coding, I never really got to see some of the engine ideas from that period, and that was a crazily inventive time period! :!:
Code snippet you posted
It looks right to me.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: FitzQuake Mark V - Easy to compile and ...

Post by mh »

It's just applying an emboss effect to the raw texture data, nothing spectacular. Something I did back in 2001 or 2002 and am now slightly embarrassed about having my name attached to. Looks quite crap. I wouldn't bother.

Regarding texture loading, OpenGL allows you to specify a texture with width, height, format but a NULL data parameter. The texture will be created with no data (i.e. it's black) and it can then be populated by glTexSubImage or glCopyTexSubImage calls.

Code: Select all

glTexImage2D (GL_TEXTURE_2D, 0, GL_RGBA, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
FitzQuake doesn't allow this.

Instead you must always supply a data parameter, so for certain texture types (the render-to-framebuffer warp images) FitzQuake passes hunk_base as a dummy data parameter. I adopted this when building the underwater warp code, but very quickly discovered that you must be very careful to not specify a TEXPREF_ flag that modifies the data in-place, otherwise you'll scribble all over previous hunk allocations.

A useful modification would be to allow the TexMgr code to accept NULL data instead.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

its bit newer than that :) it was something we brainstormed back when my avatar name was reckless, it was shortly before you started work on directq and scrapped it. It uses a different take on standard normal mapping making it insanely fast, i cant remember if i was the one who got the idea but you wrote the code for it ;)
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

https://sourceforge.net/projects/cbadva ... les/Tools/ grab the realm.zpaq file.

mhquake with pk3 support and arb water shaders.

Somewhere along the line i broke something so it crashes atleast on amd gfx cards, if you spot the bug let me know it has been driving me crazy since msvc seems to be unable to read the expression where it crashes.
Productivity is a state of mind.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: FitzQuake Mark V - Easy to compile and ...

Post by Baker »

revelator wrote:https://sourceforge.net/projects/cbadva ... les/Tools/ grab the realm.zpaq file.
Nothing on Windows 7 can open that file, I tried every zpaq utility and none of them work on my computer. :confused:
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

peazip maybe ? i used that to create it and i can open it.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

packed it as a normal zip file, same link. Hope that works better else i start to worry :shock:
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

Found a rather old version of realm on one of my harddrives that does not crash, but its ungodly slow on my R9 390 amd card strangely enough it runs ligthing fast on my old nvidia 560 gtx grrrr. Started moving over stuff from the newer version slowly so i can catch the code that makes it crash in the later version.

The version i uploaded uses shaders for water / slime / lava and / heathaze surfs, and initially i suspected the shader code to cause the crash but i just reimplemented it and it runs (well not fine since its slower than tenebrae on a geforce 1).

the debugger also seems to think that the bug is in the surface drawing code, render list seems to have a bad pointer somewhere but i had no luck finding it yet.
Productivity is a state of mind.
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: FitzQuake Mark V - Easy to compile and ...

Post by revelator »

Found the culprit !!!! damn this was a bitch to hunt down GL_EXT_compiled_vertex_array do NOT use on newer cards it will slow them to a crawl,
on older cards it actually speeds them up Oo but it will totally fuck you over if enabled on newer gfx cards, we talk single frames here.

After removing the above it runs like a charm. It also caused some rather weird texture glitches when enabled, mostly on liquids.
Productivity is a state of mind.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: FitzQuake Mark V - Easy to compile and ...

Post by Spike »

tbh, GL_EXT_compiled_vertex_array is too poorly defined to be used by anything but quake3. everyone else should use VBOs.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: FitzQuake Mark V - Easy to compile and ...

Post by mh »

I believe that compiled vertex arrays existed purely as an optimization for software T&L cards doing multipass rendering.

The idea is that by locking the arrays you tell your driver that you're not going to be modifying them until you unlock; at that point the driver can run vertex transforms, optimize them (whatever that means), and transfer them to GPU memory (if it determines there is an advantage to doing so, which would be very implementation-dependent behaviour). From there you can run your multiple passes, and the key thing is that no matter how many passes you run, the vertex arrays are only transformed and otherwise processed once.

The CVA spec also contains a statement that "If the vertex array data is locked while the DrawElements commands are executed, then OpenGL may be able to transform each of these shared vertexes just once" - however, this is behaviour that you don't actually need CVA for any more. In fact it's just the post-transform vertex cache, which happens automatically anyway.

That's a danger in relying on 1998 specs and other documents when it comes to OpenGL.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Post Reply