Disable Fog (C++ Help)

[MadGypsy]

As much as you like the PSP, the seeming lack of a ability to run code in an IDE in Debug mode to step through code, see variable values, set breakpoints etc. prevents it from being very useful for learning.

My next sentence is not attempting to disagree with you in any way it's just a true statement. I have never set a breakpoint in my entire life. I know what it is, how to use it, have that option for at least half the languages I know and agree it can be very helpful. I've simply never used them. The languages that I know which have that feature also generally tell you exactly where and what the problem is as soon as it fails. In the cases where they don't I usually just work blind with a good idea of where the problem is.

This happened last night while working with HaXe. I got the most generic error I have ever seen. Something like "failure at position 151"... lol that error is so stupid I wanted to cry when I saw it (figuratively). But even in it's generics it is telling me a lot. It's telling me the failure has nothing to do with the compiled code cause there is no line number or classname (ex "Main.hx:121 type mismatch - String expects Int"). So, if it's not the app code it must be something regarding external files. I looked at the 151st position of all my external files til I found the problem.

I guess you could say my "breakpoints" are built in. They're called error messages and half a brain to figure them out.

[Baker]

"failure at position 151"

Well, C doesn't have error messages, low level programming languages do not protect the user from themselves and have essentially no safeguards.

If Javascript is arthemetic, then C is calculus.

[Dark_Duke]

My next sentence is not attempting to disagree with you in any way it's just a true statement. I have never set a breakpoint in my entire life. I know what it is, how to use it, have that option for at least half the languages I know and agree it can be very helpful. I've simply never used them. The languages that I know which have that feature also generally tell you exactly where and what the problem is as soon as it fails. In the cases where they don't I usually just work blind with a good idea of where the problem is.

This happened last night while working with HaXe. I got the most generic error I have ever seen. Something like "failure at position 151"... lol that error is so stupid I wanted to cry when I saw it (figuratively). But even in it's generics it is telling me a lot. It's telling me the failure has nothing to do with the compiled code cause there is no line number or classname (ex "Main.hx:121 type mismatch - String expects Int"). So, if it's not the app code it must be something regarding external files. I looked at the 151st position of all my external files til I found the problem.

I guess you could say my "breakpoints" are built in. They're called error messages and half a brain to figure them out.

Oh man, what a seemingly useless error message, At least it gave you an indicator of where it might be! Solving it probably felt damn good

What exactly where the external files you were working with?

I'm completely new when it comes to coding, so hearing all these different perspectives is pretty helpful. Everybody has their own way of coding!

[Dark_Duke]

Well, C doesn't have error messages, low level programming languages do not protect the user from themselves and have essentially no safeguards.

If Javascript is arthemetic, then C is calculus.

Basically C

[MadGypsy]

What exactly where the external files you were working with?

A long time ago I had an idea to make a "browser" powered by JSON instead of HTML. Browser is in quotes because it's implementation would be more like .hta (hyper text application). My external files are JSON files. There are 2 different uses - one JSON use is to describe elements (buttons,check boxes, etc). The second use is to describe the display list.

My current side project (FrontEnd) provides a VERY easy way to create semi-generic apps. It already blows the hta method out of the water entirely. Elements are already built-in to completion with the user only needing to provide the custom data. For instance:

"button":
{
"label":"go",
"cmd":["netstat","-n"]
}

if I used that snippet in the display list I would end up with a button perfectly sized to the label ("go") and complete with all mouse events themed to the overall shell (which is also completely custom) and upon pressing it it would run netstat. Netstat is just an example, you could just as easily do something like this:

"button":
{
"label":"run",
"cmd":["wscript","myCustomScript.vbs -someSwitch"]
}

or this

"button":
{
"label":"go",
"url":"http://quakeone.com"  //opens your default browser and navigates
}

or this

"button":
{
"label":"close",
"script":"Window::closeWin"  //utilizes a built-in script
}

With that said, whereas there are a whole lot of things programmed into the FrontEnd app, it's very simple to use external scripts to write your own functionality. One way that this smokes hta is right here in the example. HTA files fail with wscript vbs scripts and utilize cscript instead (which is semi crippled in comparison). My app has no such limitations.

C has no error messages

probably one of the reasons I never really bothered to learn it. HaXe ports to cpp/cs and error reporting is very verbose when compiling to either.

edit: the error reporting continues after compile through execution throwing runtime errors for the cpp/cs executable.

[Baker]

probably one of the reasons I never really bothered to learn it. HaXe ports to c++ & c# and error reporting is very verbose when compiling to either.

There are almost no reasons for someone to learn C.

But C is thin veneer over assembly language, and you can even directly write assembly language in C code.

C# is a high level language like Visual Basic that just happens to use some syntax similar to C and C++, but so does Javascript and no one would mistake Javascript as being a low-level language like C.

C++ keeps 99% of C syntax, but what goes on underneath is not the same as C. C is not object oriented and at all times provides essentially direct and unprotected memory access and requires one to do all of their memory allocations and deallocations. C++ also has mechanisms friendly to writing error handling.

But if you want as raw and as fast and as controlled programming as possible, C is that language. You can write operating systems in C or other programming languages in C or device drivers or networking libraries or a million other low-level things.

[MadGypsy]

Can't you simply write those things in a high level language and utilize native extensions written in C for the things that you want as low level as possible?

I'm pretty sure that the days of torturing yourself with highly powerful but incredibly unfriendly languages are basically over. I mean, even flash can utilize native extensions written in just about any "native" language. The entire bullet physics library for flash is nothing but the c(whatever) version used as a native extension. That's how flash quake (original, not my thing) was done too.

[Baker]

Can't you simply write those things in a high level language and utilize native extensions written in C for the things that you want as low level as possible?

I'm pretty sure that the days of torturing yourself with highly powerful but incredibly unfriendly languages are basically over.

Well, this type of discussion isn't for me to say and unfairly asks me to explain the validity of your point of view. I'm just one guy and my thoughts are only useful to the extent they are or are not something correlates to the bigger picture.

You'd be better off asking that at StackOverflow and see what the responses are.

[Dark_Duke]

Hey Baker,

Where should I look in regards to dynamic lighting not affecting weapon models/enemies?

Though dynamic lighting is disabled, the gun and enemy appear to be affected by dynamic lighting and flash a whitening texture over them when shooting. Another example, where on a map there would normally be a blinking light (but dynamic lighting is disabled), all the world textures are static as should be, but the gun/enemies will still blink as if being illuminated.

If you had any direction you could point me, it would be extremely helpful! I'm searching and searching and cannot find it.

[Baker]

The PSP did everything differently than other engines, so I don't remember.

Find ViewModel or Draw_ViewModel or R_DrawViewModel in the source and you may be able to find it (I hope the PSP source code had the name similar --- not a 100% chance). But that just draws the gun. You might want to look for "lighting", maybe "vertex lighting" but it would be one word, but not necessarily jammed together it might have an underscore between it or even be in the file name.

And maybe looking for the word r_fullbright and looking for code associated with that may show you a way to disable it.

Happy hunting

[Dark_Duke]

The PSP did everything differently than other engines, so I don't remember.

Find ViewModel or Draw_ViewModel or R_DrawViewModel in the source and you may be able to find it (I hope the PSP source code had the name similar --- not a 100% chance). But that just draws the gun. You might want to look for "lighting", maybe "vertex lighting" but it would be one word, but not necessarily jammed together it might have an underscore between it or even be in the file name.

And maybe looking for the word r_fullbright and looking for code associated with that may show you a way to disable it.

Happy hunting

HO HO HO HO HOOOOOOOOO! I found it! Thank you very much!!! And down the rabbit hole I went.

Turns out, the function R_DrawViewModel is pretty much entirely empty, with the EXCEPTION OF

 	currententity = &cl.viewent;	

 	R_DrawAliasModel (currententity);

Looked into R_DrawAliasModel, and it has a bunch of lighting if statements, being if(r_model_brightness.value), or if (force_fullbright) and has stretch of code FORCING dynamic light! I'll add in some code for if(r_dynamic.value) and if(!r_dynamic.value) as well as some fixlight/forcelight settings in those if statements

Thanks for the help!

[Dark_Duke]

UPDATE TO LAST POST: Okay. I got it doing what I thought I wanted to it to do... shit. What I really want to do is disable flickering lights from affecting models. LOL. I just basically turned my gun model and enemy models into fullbrights... I still want them to be affected by the map, but just not by flickering lights? Is that even possible?

I think I found what I am looking for... for checking whether if dynamic lights are detected. Is this it?

     if (fa->dlightframe == r_framecount	// dynamic this frame
     || fa->cached_dlight)			// dynamic previously

[Baker]

You found a whole bunch of cvars, right? r_model_brightness and such. Roll back your changes and play with each of the settings and find what each of them do and how they effect things.

Yeah, I wasn't saying make things full bright. I was saying that where you found that, you would find the code that controls lighting with different circumstances.

You should find what each of the cvars do. You have found the right code files, now you have learn what the different options are so that you can determine what changes you need to make.

Maybe set to: if (0 && /* <--- add that */ fa->dlightframe == r_framecount

And run it and see what happens.

/I'm hoping you know "0 && anything" is always false

[Dark_Duke]

Maybe set to: if (0 && /* <--- add that */ fa->dlightframe == r_framecount

Oh cool and weird! That didn't do what I thought it did. Adding the 0 && seems to have broken dynamic lighting for when shots are fired... not explicitly that, but that was one of the results. Dynamic, flickering lights still affect viewmodel regardless

I do understand the results of the various cvars now as well! I'm just not entirely sure how to accomplish an if check for flashing dynamic lights. Essentially, I want to disable (the invisible) flickering lights from having an affect on models/viewmodel but want the envirormental dynamic lights to affect the viewmodel/enemy models. I'll have to do some more probing and dig into the r_dynamic.value cvar

[Baker]

Dynamic, flickering lights still affect viewmodel regardless

Yeah, you'll have to dig then. There were some unusual things in the engine, some of which were never too much of a priority to investigate because there were always more pressing problems.

I remember the model lighting not being the same, I think it was based off an old obsolete tutorial at the long-dead QuakeSrc.org site.

Often the first tutorial for anything is unpolished because they guy writing is excited about. Then maybe after road testing, someone else uses it gets made better and gets refined, but that never finds its way back to the original tutorial

/One guess ... probably right, but maybe not