Disable Fog (C++ Help)

[Dark_Duke]

Running into some issues with the ProQuake(Kurok) port engine for PSP. Specifically on the map "A Thousand Years Into The Past" by czg from Rubicon2.

The first two maps of Rubicon2 are fine, but when you spawn in A Thousand Years into The Past, you are greeted to a black screen (until you adjust the fog start and end settings because the map seems to blow out any of the ones you had set previously)

The fog code (Proquake 4.71/Kurok Engine for PSP) appears to be a rehash of the Fitzquake implementation, though the numbers seem a bit skewed from the original engine. Right now I'm trying to determine the best way to add an option to disable fog entirely. Linked here is the source code.

Any ideas? I'm thinking about adding a "COM_CheckParm" for "-disablefog" and a menu item inside my prompt menu that launches before Quake starts (this is on PSP, its a debug screen that allows you to set specific startup paramaters) and some if(!COM_CheckParm("-disablefog")) or something to that extent around the bits of fog paramater code... but that would be the lazy way. What would be the best way to setup a cvar to enable/disable fog based on this code?

EDIT: Perhaps I should repurpose the fog_density code from the FitzQuake engine? Does anybody have any idea why it may have been left out?

[Baker]

Map fog settings are supposed to completely reset each time a new map loads --- at least for a modern true single player engine like FitzQuake or Quakespasm or DarkPlaces -- and the original PSP Quake was not based off a modern engine but original Quake.

I don't think the PSP ever read the values the same way as FitzQuake.

Standard Quake maps have no fog, wasn't even a feature of Quake. Only custom maps have fog and they expect the FitzQuake standard.

Since most modern custom maps would crash a PSP engine because of memory and since modern custom maps are the only ones with fog settings, you might as well consider fog on the PSP as "untested" as far as it applies to modern custom maps.

If you want to fix that on the PSP, you'll have to make sure that the reading of the fog keys and the fog commands are the same as FitzQuake 0.80 or 0.85, that the reseting of the fog keys are the same FitzQuake and that the usage is the same as FitzQuake.

So you'll have to prepare yourself for a lot of boring and tedious work or use a text comparison tool like WinMerge.

No matter what you do, it will just be getting your hands very dirty and doing a lot of tedious work to fix it.

You might just decide to not read the fog values from maps.

[Dark_Duke]

Map fog settings are supposed to completely reset each time a new map loads --- at least for a modern true single player engine like FitzQuake or Quakespasm or DarkPlaces -- and the original PSP Quake was not based off a modern engine but original Quake.

Oh well that explains a bit.

I don't think the PSP ever read the values the same way as FitzQuake.

Yeah, you're right. It has a totally different numbering scale which is what is causing a lot of the issues.

If you want to fix that on the PSP, you'll have to make sure that the reading of the fog keys and the fog commands are the same as FitzQuake 0.80 or 0.85, that the reseting of the fog keys are the same FitzQuake and that the usage is the same as FitzQuake.

I'll definitely give this a try and just go line by line, comparing the values.

You might just decide to not read the fog values from maps.

More than likely, this is what I'll ultimately probably end up doing. I think fog may be a bit out of reach for the PSP to handle, would be far easier to just remove it entirely. There would likely be a performance boost as well, in terms of custom maps. Thanks for the information Baker! It is greatly appreciated.

On a similar note, are dynamic lights being handled by a gl based code structure or closer to the original engine? I've found remmanents of both, though I'm not quite sure. Would you foresee any major issues returning back to the original Quake dynamic lights code?

[Baker]

Would you foresee any major issues returning back to the original Quake dynamic lights code?

If you are asking me then you don't understand what the code does.

Making changes you don't understand is never safe.

Options:
1) Learn what the code does
2) Don't make the change
3) Make the change after backing up your current source code (I hope you are doing this often) and seeing whether or not it works or compiles or explodes.

My goal was always to learn what the code does. That being said, I don't think you have a prayer of learning how dynamic lights work on a PSP, you would have to learn that compiling and working with, say, FitzQuake on Windows and then later apply that knowledge to the PSP.

That is a very complicated part of the Quake engine.

[Dark_Duke]

If you are asking me then you don't understand what the code does.

Making changes you don't understand is never safe.

Options:
1) Learn what the code does
2) Don't make the change
3) Make the change after backing up your current source code (I hope you are doing this often) and seeing whether or not it works or compiles or explodes.

My goal was always to learn what the code does. That being said, I don't think you have a prayer of learning how dynamic lights work on a PSP, you would have to learn that compiling and working with, say, FitzQuake on Windows and then later apply that knowledge to the PSP.

That is a very complicated part of the Quake engine.

I totally have zero understanding of the dynamic lighting code. I've gotten thus far... definitely won't be stopping now! I do indeed have all revisions of my source code backed up. I'm actually on Revision 3 at this point. With every major change, I have a "development" clone version of code that I can compile and tinker with to my hearts desire. In the process usually having like 10 failed compiles before even succeeding.

Learning for me is generally modifying parameters/googling to understand what the code is doing. Also comparing any revisions to the original Quake source. Though trying to understand the dynamic lighting code has been a struggle to say the least. Generally I just modify and try to compile, if it fails I go back and try to find the mistakes I made. If it succeeds, I go in and see if it does what I thought it might do. In NotePad++ I often compare the various iterations of Quake on PSP, between ProQuake 4.71, Kurok 0.4 and Jurak Styks Quake v1.1 to see what has changed.

What I may try and do, is re-implement the dynamic lighting code from the original Jurak Styk Quake port. I was just hoping you might have insight on why it was changed from that original Jurak Styk port, more like a history of why it was changed and perhaps for what reasons? Be it optimization, bugs, or just trying a different method.

[Baker]

I've never once even looked at the original PSP Quake source code.

That being said, I would guess it did not have colored light support and Kurok added colored light support, fog support and skybox support.

But since I have never so much as looked at the original PSP Quake, it's all speculation on my part.

[Dark_Duke]

That being said, I would guess it did not have colored light support and Kurok added colored light support, fog support and skybox support.

Ooooo good info! I didn't know the original Quake engine didn't have skybox support and fog support until you mentioned it in this thread, took that for granted I guess with the latest engines. Anyways, I will feebly attempt to revert the dynamic light code back to something closer to the original Quake. The Kurok engine crashes when dynamic lighting is enabled on some of the DM maps on the PSP.

Thanks for the information man! Tedious work is my middle name. I've been finding myself staying up late pretty often just looking through the source code trying to discover differences and determining how they work. Call me a masochist

[Baker]

The Kurok engine crashes when dynamic lighting is enabled on some of the DM maps on the PSP.

Then find r_dynamic in the source code

And change the if statement to ....

if (r_dynamic.value && cl.gametype != GAME_DEATHMATCH)

And then deathmatch will never use dynamic lights. cl.gametype is either GAME_DEATHMATCH (multiplayer scoreboard) or GAME_COOP (single player scoreboard).

No one wants dynamic lights in deathmatch anyway. People that know what they are doing during off dynamic lights for deathmatch right after they turn off the red flash you get when you get hurt.

[Dark_Duke]

Then find r_dynamic in the source code

And change the if statement to ....

if (r_dynamic.value && cl.gametype != GAME_DEATHMATCH)

And then deathmatch will never use dynamic lights. cl.gametype is either GAME_DEATHMATCH (multiplayer scoreboard) or GAME_COOP (single player scoreboard).

No one wants dynamic lights in deathmatch anyway. People that know what they are doing during off dynamic lights for deathmatch right after they turn off the red flash you get when you get hurt.

YOU SIR, ARE A GENIUS.

I will do just that!

[MadGypsy]

I've been finding myself staying up late pretty often just looking through the source code trying to discover differences and determining how they work.

That's how you do it. That's pretty much my M.O. for almost every language I know. With the exception that I also study the docs if there are any.

[Dark_Duke]

That's how you do it. That's pretty much my M.O. for almost every language I know. With the exception that I also study the docs if there are any.

Seems like the best way to learn, by example! Out of curiosity, are there any books that discuss the Quake engine in particular?

I've read briefly through https://www.bluesnews.com/abrash/ which has been pretty interesting. Would be cool if there were more resources like this if you knew of any!

[Baker]

There is a (semi-dead) forum: InsideQC Forums • View forum - Engine Programming
Tutorials: InsideQC Forums • View forum - Programming Tutorials
The occasion conversation at Func: Func_Msgboard: Quakespasm Engine Func_Msgboard: Quake Custom Engines

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.

You'd learn 10 times as fast using a Windows engine with an IDE like Visual Studio. MDave not only did a PSP version of Kurok, but a Windows engine for Kurok, so even when he was working on the PSP version, he basically had everything mostly tested in advance in Windows. And I already had worked with the Quake engine 2.5 years before I did anything with the PSP.

I'm not trying to discourage you from enjoying coding on the PSP. I'm just pointing out that the limited and low quality tools at your disposal for the PSP sort of means it is easier if you already know what to do and might be next to impossible as a learning tool if you don't already know what to do.

[Dark_Duke]

There is a (semi-dead) forum: InsideQC Forums • View forum - Engine Programming
Tutorials: InsideQC Forums • View forum - Programming Tutorials
The occasion conversation at Func: Func_Msgboard: Quakespasm Engine Func_Msgboard: Quake Custom Engines

WOW! These are amazing and EXTREMELY helpful!

You'd learn 10 times as fast using a Windows engine with an IDE like Visual Studio. MDave not only did a PSP version of Kurok, but a Windows engine for Kurok, so even when he was working on the PSP version, he basically had everything mostly tested in advance in Windows. And I already had worked with the Quake engine 2.5 years before I did anything with the PSP.

You are completely right on that, learning via a PSP port is probably one of the absolutely worst ways to learn programming/the Quake engine.

I'm not trying to discourage you from enjoying coding on the PSP. I'm just pointing out that the limited and low quality tools at your disposal for the PSP sort of means it is easier if you already know what to do and might be next to impossible as a learning tool if you don't already know what to do.

You haven't discouraged me at all! I'll start delving more into the PC side of things and try and gain a better understanding of things overall. In fact, I may take the Kurok engine and develop of a few modifications for the PC first! And then apply that knowledge towards the PSP. The PSP offers virtually nil in the debugging/development realm. Though it's sort of endearing, and extremely challenging. Like trying to run with no legs? Basically, playing Dark Souls one handed

[Baker]

You haven't discouraged me at all! I'll start delving more into the PC side of things and try and gain a better understanding of things overall. In fact, I may take the Kurok engine and develop of a few modifications for the PC first! And then apply that knowledge towards the PSP. The PSP offers virtually nil in the debugging/development realm. Though it's sort of endearing, and extremely challenging. Like trying to run with no legs? Basically, playing Dark Souls one handed

Good I know I often enjoyed the results of something for the PSP more than I did the PC. I just hated working with sticks and stones.

You have to have something you like to cause you to enjoy coding.

[Dark_Duke]

Good I know I often enjoyed the results of something for the PSP more than I did the PC. I just hated working with sticks and stones.

You have to have something you like to cause you to enjoy coding.

Speaking of which, I just went ahead and disabled the fog code entirely! With my sticks and stones Took three re-compiles over the course of 45 minutes . First try didn't even finish compiling, I had left in too many old references. Second attempt it compiled, boot up the game, menu and demo plays out okay, on mapload screen is black? Went back, though I had disabled all the fog code and removed video_hardware_fog.cpp, I had left two instances of "sceGuEnable(GU_FOG);" and "sceGuDisable(GU_FOG)" in play! Third time was a charm, feels good

Now I can play Rubicon2! Also, your suggestion regarding dynamic lighting also worked perfectly! Though, I have noticed that when dynamic lighting is disabled, the gun and enemy models will continue to illuminate as if dynamically lighted. This has always been an issue with this engine to my knowledge, going to try and track that one down next!