The code to write TGA is pretty simple, that might be why. Or maybe it was compatible with other software they used at id at the time. 

Simple and fast. PNG with compression will take longer. It will freeze game for a second.
Of course I'm just speculating. 

I prefer to start with uncompressed images. It's easy enough to convert quickly with any number of apps. I use something similar to this: https://www.imageconverterplus.com/features/right-click-menu/

@metlslime id was most likely was using Truevision video accelerators in their Windows machines back then. TGA was originally from Truevision. 

 

Software Quake used PCX. Because that was an 8-bit renderer it was also just a simple matter of "dump the pixels".

According to Carmack's .plan file ID were using Intergraph accelerators on NT as their graphics workstation platform of choice at the time GLQuake was written.

PNG format didn't even exist when Quake was released. First release of PNG was October 1996.

TGA offers simplicity and speed, although nowadays with disk IO being the primary bottleneck for many operations a compressed format may well be the faster option, at least until SSDs go cheaper than spinning plates of rust. 

I prefer to start with uncompressed images. It's easy enough to convert quickly with any number of apps. PNG has lossless compression. It's like ZIPping TGA, but in one operation. It is easier to preview and maintain. 

Got it. Obviously PNG would be the most handy format at the moment especially for immediate sharing. I take the previewing aspect for granted as I have the aforementioned shell viewer/converter and Photoshop. 

JPG is not really "needed" for web use, it just the most common. Many times it gets used when PNG would be the better choice.

Read about how those compression algorithms work and when they're appropriate to use. 

Quake screenshots are not a good case for png, but are OK for jpg. 

Quake with texture filtering off is a bad case for JPEG, though. JPEG is also a bad choice if you want to make brightness adjustments afterwards, especially extreme changes (something I often do when I get screenshots of lighting bugs.)

Ideally JPG, PNG, TGA would be available. I think MarkV can do those and has a cvar to pick the format. 

aye, jpeg sucks. you can reduce the compression to get something close to png, but doing so just increases the filesize too. if you've got high res textures (which frankly just look like noise in the first place) etc then jpeg can't make it any worse, but otherwise imho png is a better choice than jpeg at least for a default setting.

(windows) bmp might work if you want something more equivalent to tga, its basically just a different header but much better supported (at least on windows and except by quake engines). it can also be paletted, and doesn't need extra libraries.

but png is best if you're going to shove it on a website (and why take screenshots if not to share them). 

The problem with BMP is that each row must be a multiple of 4 bytes, so for odd resolutions like 1366x768 or if you want 24-bit data you can't just fwrite the output from a glReadPixels. 

Open the source code for JoeQuake. There are 3-5 headers. 1 cvar. Link libpng and libjpeg. Call the appropriate function to write a png or jpeg. 30 minutes tops. 

Well okay, TGA isn't particularly small, either... 

doesn't matter what the engine writes out, you should convert to jpeg before uploading it. 

http://www.quaketastic.com/files/screen_shots/xlarves_dream_3.png 

doesn't matter what the engine writes out, you should convert to jpeg before uploading it.

Depends.

If I wanted to highlight something like a conchars font with different filtering and scaling options I'd leave as PNG. 

JPG was created for photographs. If an image is not a photograph then JPG is probably not the best format. In particular, JPG is a poor choice for images with large areas of the same continuous color, such as many web page graphics.

JPG is not intended for images which will require additional editing, but for an in-game snapshot is probably fine. The option for a higher quality image would be good to have, but I would not consider it a necessity for a game. 

Hi!

While playtesting a map I'm working on, I got a stack overflow bug: First, I pick up the quad damage, enter the door to the left and then aim somewhere between the Enforcer and the radioactive container in front of him. I could fairly reliably get the following stack overflow:

CALL4 1705(T_RadiusDamage)T_RadiusDamage()
misc.qc : barrel_explode
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
weapons.qc : ApplyMultiDamage
weapons.qc : AddMultiDamage
weapons.qc : TraceAttack
weapons.qc : FireBullets
weapons.qc : W_FireShotgun
weapons.qc : W_Attack
weapons.qc : W_WeaponFrame
client.qc : PlayerPostThink
<NO FUNCTION>
stack overflow
Host_Error: Program error

The map can be downloaded below:

https://www.dropbox.com/s/i43hcljprz3c45f/bugmap.zip?dl=0 

I've reliably reproduced this too.

Increasing MAX_STACK_DEPTH in pr_exec.c to 64 is sufficient to resolve; a lower value may also do but I didn't bother testing.

It's caused by a large amount of exploding boxes in close proximity setting each other off. 

I remember running into this issue myself once many years ago. I was under the impression it's simply a common Quake bug/limitation, but I can't seem to reproduce it in Winquake/GLquake using Esrael's map. Does it occur everywhere or is it actually something introduced in and carried over from the Fitz code? 

It's a hangover from the original ID code.

You need to be very specific about this because it's the chain of effects that sets off the stack overflow. Hence you need the Quad and you need to be in the very specific situation where there are 6 or so exploding boxes in close enough proximity.

You shoot near one box, the Quadded shotgun explodes it, it triggers the next box to explode, which triggers the next box, and so on.

Each explosion is 4 function calls: barrel_explode for the explosion, T_RadiusDamage from he explosion, T_Damage to the next box, then Killed which kills the next box and in turn sets off another barrel_explode.

Removing one of the boxes should be sufficient to prevent it ever happening.

I also have engine code somewhere that effectively gives you an infinite stack (at least until you run out of memory) which would also more robustly fix this and other similar issues. 

findradius is just all kinds of evil. its possible for exploboxes to be skipped entirely too, depending on how .chain gets clobbered by the different explosions.
Frankly, calling T_RadiusDamage inside Killed/.th_die should be considered a bug, fixable by delaying it to a think function. This also fixes the above crash, too. 

While playtesting a map I'm working on, I got a stack overflow bug ...
This is a bug in QC that happens on anything with a call to a radius explosion function within a death event.

This is why tarbaby.qc (line 172) delays the explosion to the next frame. So that you cannot get a chain effect and stack overflow.

The misc.qc - barrel_explode function is broken. It should delay the radius explosion one frame and it would be fine. I fixed this in AD QC if anyone wants an example of this.