Disable Fog (C++ Help)

[Dark_Duke]

I figured out a solution :-)

I was able to find an appropriate solution for models/view-model being illuminated by gun flashes correctly and fixed them at their source, but that fix didn't apply to flickering lights. Flickering lights, even with dynamic lights being "disabled", would still affect models.

Solution:

/*
==================
R_AnimateLight
==================
*/

void R_AnimateLight (void)
[COLOR="Red"]{if (r_dynamic.value){ // <---- MOTHA FUCKIN GOLDEN CHILD[/COLOR]

	int			i,j,k;

	i = (int)(cl.time*10);
	for (j=0 ; j<MAX_LIGHTSTYLES ; j++)
	{
		if (!cl_lightstyle[j].length)
		{
			d_lightstylevalue[j] = 256;
			continue;
		}
		k = i % cl_lightstyle[j].length;
		k = cl_lightstyle[j].map[k] - 'a';
		k = k*22;
		d_lightstylevalue[j] = k;
	}
        }
}

[R00k]

I was going to suggest that function. But wasnt sure if you wanted those lights enabled or not as some maps with it off are totally dark where the lights should be. A few years back Muller was using an ATI card and suffered bad FPS near animated lights on E4M3. I told him to just disable the r_dynamic lights but he wanted at least to SEE the area lit. I added a if (r_dynamic.value == 2) return; at the top of that function so it WOULD present the light but never again animate it. It just became a static light.

[Dark_Duke]

I was going to suggest that function. But wasnt sure if you wanted those lights enabled or not as some maps with it off are totally dark where the lights should be. A few years back Muller was using an ATI card and suffered bad FPS near animated lights on E4M3. I told him to just disable the r_dynamic lights but he wanted at least to SEE the area lit. I added a if (r_dynamic.value == 2) return; at the top of that function so it WOULD present the light but never again animate it. It just became a static light.

All good, at least I had to figure it out myself (with some good direction from Baker)!

Good point though regarding lights that are off by default. Is that line really all you needed? That's pretty damn clever

[R00k]

this will turn on dynamic lights but wont animate them. for your use u dont want any dlights as it craps out the engine. why? im not sure but its just a hack to disable the lights. im not sure how the psp works in that regard
if it is the animated lights that crash the engine then give it a shot

[Dark_Duke]

this will turn on dynamic lights but wont animate them. for your use u dont want any dlights as it craps out the engine. why? im not sure but its just a hack to disable the lights. im not sure how the psp works in that regard
if it is the animated lights that crash the engine then give it a shot

I'll give it a try! Its only under certain conditions that the dlights crash the engine. Deathmatch mode specifically on certain maps.

[Dark_Duke]

New question. I'm really stumped on this one.

What I am attempting: a universal config.cfg that operates outside of id1 and mod folders. Or a single, universal config.cfg that is in id1 that all mods load.

I gave the code below a try, though I realized far too late that it is just feeding code "exec mso:/PSP/GAME/INSOMNIA/config.cfg" etc into command line buffer, and the command line doesn't give a shit about paths.

I am now stumped and am not sure how to proceed quite yet. Any sources I should look at or recommendations?

Code in question:

void Cmd_Exec_f (void)
{
	char	*f;
	char path[256];
	int		mark;

	if (Cmd_Argc () != 2)
	{
		Con_Printf ("exec <filename> : execute a script file\n");
		return;
	}

	mark = Hunk_LowMark ();
	snprintf(path, sizeof(path), "%s/%s", host_parms.basedir, Cmd_Argv(1));
	f = (char *)COM_LoadHunkFile (path);
	if (!f)
	{
		Con_Printf ("couldn't exec %s\n",path);
		return;
	}
	Con_Printf ("execing %s\n",Cmd_Argv(1));
	
	Cbuf_InsertText (f);
	Hunk_FreeToLowMark (mark);
}

[Baker]

I'll give it a try! Its only under certain conditions that the dlights crash the engine. Deathmatch mode specifically on certain maps.

You don't know that. Making assumptions is walking down the road of pain in programming.

"dlights crash the engine" if map is loaded is a "when" --- It is not a "why".

You don't know if it is memory, textures, a limit somewhere in the code for the PSP, or some bad code or an invalid pointer.

You could very well just have examples of the straw that broke the camel's back in one particular scenario.

Without "why", you have nothing.

Trying to solve a "when" without a "why" is like trying to dig a tunnel with spoon. You'll never finish because you'll get frustrated first.

Wanting something is NOT enough. You have to earn it. With programming, the path to earning something is understanding something. You may or may not be able to learn enough about the engine in a time efficient manner using the sticks and stones the PSP provides as development tools because you can't set breakpoints or examine variable values or set watch conditions.

Programming is a mix a of impatience ("I want it now!") and patience ("Before I can get what I want, I have to do my homework to understand X").

If you are level 2 and want to cast a level 5 spell, you better hit the books.

Or ... accept that certain things don't work, live with it for now and focus on what you can control ... living with certain limitations for the time being because you know you can't solve them yet.

The first thing I tried with the Quake engine on Windows:

I liked ProQuake 3.50 and wanted to add video mode change. FitzQuake 0.80 had video mode change and I wanted to add video mode change to ProQuake 3.50 --- the code bases were similar, but not the same. The video code was very different and the engines had some major differences in places. I desperately wanted this.

It took about 6 months before I was able to successfully implement it, and I had notes about the specific steps I needed to do. I didn't try to brute force it, I tried it about 3 times over a couple of weeks and when ultimately the differences were too much and the engines not similar enough, I shelved it and worked on things I could do. Then later in the year, I reformulated with my increased knowledge and tried a few more times. Failed a couple more times, but was able to identify the problems and "missing links" and then finally I had a mostly successful one and then polished it up.

Asking questions is fine, but when you are asking too many questions you aren't spending enough time understanding the code and "doing homework". This stuff is hard, you've made a lot of progress and have done well --- but there aren't any shortcuts.

Your first resource has to be your understanding of the code. And growing that.

/One opinion. Probably wrong.

[Baker]

What I am attempting: a universal config.cfg that operates outside of id1 and mod folders. Or a single, universal config.cfg that is in id1 that all mods load.

Someone working on the engine has to know how the Quake file system works inside the engine and there's no shortcut to that, you need to familarize yourself with the code. It's probably part in quakedef.h and common.c.

This is a mystery only because you are trying to do it on a PSP and not using a real IDE. The following will let you compile easily on Windows.

If you want to find a keyword in the entire code base, just press CTRL+SHIFT+F and type in, say, "id1" and it will find it or after compile right click on something and click "go to definition" or whatever.

This: FitzQuake 0.85 that compiles with no alterations (Download source). You open the .sln in Visual Studio, click compile and run and it does.

Is essentially FitzQuake 0.85 except it compiles out of the box using MS Visual Studio 2008 C++ (Download .iso | SP1 Patch Download)

It will not compile without alteration with any version of Visual Studio other than 2008

Add: In Visual Studio, you can tweak code press F5 (run) and then click "X" to close Quake in windowed mode. And you can do it in a split second. And you could do it 15 to 20 times before you could do it on a PSP even once --- with all the insane messing around you have to do to load it on the PSP and then start it -- you could waste a whole hour on the PSP with next to nothing to show for it.

So fiddle with stuff like this on Windows, then once you have what works then --- copy and paste the lines to the PSP source code. At least for understanding the file system and things that are "basic Quake" functions.

Liking the PSP doesn't mean you use the PSP as rope to hang yourself with.

Make your life easy and prototype code on Windows and copy/paste to the PSP source code after you have it working.

/Again, just one opinion. Probably wrong

[Dark_Duke]

If you want to find a keyword in the entire code base, just press CTRL+SHIFT+F and type in, say, "id1" and it will find it or after compile right click on something and click "go to definition" or whatever.

Add: In Visual Studio, you can tweak code press F5 (run) and then click "X" to close Quake in windowed mode. And you can do it in a split second. And you could do it 15 to 20 times before you could do it on a PSP even once --- with all the insane messing around you have to do to load it on the PSP and then start it -- you could waste a whole hour on the PSP with next to nothing to show for it.

So fiddle with stuff like this on Windows, then once you have what works then --- copy and paste the lines to the PSP source code. At least for understanding the file system and things that are "basic Quake" functions.

Well Baker, this morning you have truly gone and blown my mind. I genuinely have been hanging myself with developing on the PSP. It takes far too long to test anything and gives you very little in information. Developing/testing first with an IDE on a similar engine, and if functional, re-implementing to the PSP will save me TREMENDOUS time.

Or ... accept that certain things don't work, live with it for now and focus on what you can control ... living with certain limitations for the time being because you know you can't solve them yet.

You know, this point very much so resonated with me. The full complexity between dynamic lights and fog are very much so beyond me and realistically not attainable for at least 6 months of working with the engine/developing/researching. Long road ahead of me For now, I've disabled the fog code and disabled dynamic lighting under certain circumstances, I will have to come back to those to solve them at their core once I have more experience/knowledge of the code base.

The first thing I tried with the Quake engine on Windows:

I liked ProQuake 3.50 and wanted to add video mode change. FitzQuake 0.80 had video mode change and I wanted to add video mode change to ProQuake 3.50 --- the code bases were similar, but not the same. The video code was very different and the engines had some major differences in places. I desperately wanted this.

It took about 6 months before I was able to successfully implement it, and I had notes about the specific steps I needed to do. I didn't try to brute force it, I tried it about 3 times over a couple of weeks and when ultimately the differences were too much and the engines not similar enough, I shelved it and worked on things I could do. Then later in the year, I reformulated with my increased knowledge and tried a few more times. Failed a couple more times, but was able to identify the problems and "missing links" and then finally I had a mostly successful one and then polished it up.

That must have felt extremely gratifying. It really can be a slow process, I'm starting to learn that there are parts of this engine that genuinely are far beyond my current understanding and likely won't be attainable for years to come. Though, for whatever reason, and likely the same reason why you kept at it, there is just something incredibly interesting and appealing about working with this engine. I don't really know why I find myself so attracted to it honestly. At least now I have the proper tools to work with it instead of bludgeoning the source code to death with my club

Asking questions is fine, but when you are asking too many questions you aren't spending enough time understanding the code and "doing homework". This stuff is hard, you've made a lot of progress and have done well --- but there aren't any shortcuts.

Your first resource has to be your understanding of the code. And growing that.

/One opinion. Probably wrong.

I seriously want to express how much your help has meant to me. You, R00k, the others are AMAZING. I greatly appreciate your patience with me

My parents used to tell me often that I ask FAR too many questions. One day my father got fed out and bought me "The Great Book of Questions and Answers". He told me to look there before I asked him

So I do apologize if I am at all testing your patience. This thread has been EXTREMELY helpful for me and you have pointed me now in the best direction, between using an IDE and giving me the tools I need to really start getting somewhere, I've already downloaded and installed the Visual Studio iso's you linked and am about to start coding away

[Baker]

I seriously want to express how much your help has meant to me. You, R00k, the others are AMAZING. I greatly appreciate your patience with me

My parents used to tell me often that I ask FAR too many questions.

I made lists of things I wanted to understand on paper.

Then I started doing text searches to find where things connected and made an outline for each of them and would describe how they worked on paper. Then maybe I performed experiments.

So I leveled up. It wasn't easy. It was often frustrating.

One time I wanted to understand the FitzQuake renderer, so I tore it apart and re-implemented in another engine, writing it myself and on some occasions making enhancements. This wasn't quick --- it might have been 2 months.



I also tore apart MDave's Kurok changes in his Windows engine and re implemented them in that engine. Yeah that Engine X project could play Kurok (but more oriented towards a modified Kurok I made). It wasn't the first time I tore apart MDave's Kurok Windows engine.



Anyway, yeah, you have to tear things apart and be passionate about stuff.

Just wanted to provide some context. There is hardwork behind everything.

But for me personally, I only became experienced by tearing things apart that I was interested in.

So --- I guess I am also pointing out, I was NOT doing my learning on a PSP --- it wasn't even remotely close to anything like that.

(I like I alluded to --- from the code I've read MDave was NOT doing his experimentation on a PSP either, he did test implementation on the Windows Kurok engine first and then would port it to his PSP engine, based on what his project files looked like)

And final thing: Above I said it "was frustrating". It was always hard, never easy. But as I kept battling the code until I understood it, things became easier.

/Yeah, yeah, a "TLDR" post --- "too long didn't read". I try to avoid writing mini-books --- it's bad form. Brevity is the soul of wit.