ZDoom

Already [added]

[quote="ibm5155"]
Maybe on the case like loading a map with 1000000 unknown textures, the messages could be generated just on a string file, and when someone open the console it would just convert all that strings to spriteblock. But maybe, this is how things work, so idk...
[/quote]

That's indeed how things work. But all that text needs to be handled before it's written into the console buffer. And that takes time. The old console code started to choke after less than 1000 messages, at least the current one is fast enough so that a larger number of startup errors doesn't mean minutes of waiting - and then missing most of the errors because they were already flushed out of the buffer.

[quote="Gez"][quote="ibm5155"]Text rendering is freaking slow, idk how is it made but if it's not this way, I would sugest doing a sprite rendering instead of text.
I did a SDL console, and the text rendering method was so slow that it would be useless to make a console game, so I did a test with a spriteblock, and I rendered each letteras a image, and boom, I got 1000fps :D...[/quote]

Real fonts are extremely complex. They're not just a collection of graphics for each glyph, they are pretty much programs in their own right. Read the articles on [url=https://en.wikipedia.org/wiki/Graphite_(SIL)]Graphite[/url] and [url=https://en.wikipedia.org/wiki/OpenType]OpenType[/url] to get an idea of how much stuff happens under the hood when you render a font properly.

Most of that is overkill for the typical Doom mod, where you don't really need to handle ligatures and nobody will really mind if hyphen, minus sign, em dash and en dash are all the same symbol. Obviously when rendering a letter consists in copying a graphic it's a lot faster than when it consists of running a program that will scan the context of the letter to see how it should be rendered exactly.[/quote]
Indeed, I already saw how complex a real font is, and that's why I just used the good and old sprite block, since my software was to emulate a terminal, it worked quite well.

I can only think some things about the pointed issues.

Indeed, scalling for a high resolution monitor may look bad with a short sprite block (but it's doom, pixels are cool :p)
-Solution:hm, use a low res sprite block for low resolution and a high resolution sprite block for a high resolution display

Gzdoom is already using sprite texts? if yes then idk what could cause the lag.

Maybe on the case like loading a map with 1000000 unknown textures, the messages could be generated just on a string file, and when someone open the console it would just convert all that strings to spriteblock. But maybe, this is how things work, so idk...

Hmm, does G/Zdoom render the game part where the console window is or does it only render what you see? ex:first the game render all the scnene, then the console is rendered upon that scene, or G/Zdoom only render the scene where it will be viewed, saving some time.
spoiler example
[spoiler=I may take more time to explain it better, I'm sleepy now :S]* = console area
. = rendered game area
=====
=****=
=....= gzdoom would only render this tiny area and not the full window, so the console area wouldn't overwrite the top screen
=====[/spoiler]

I agree, text rendering is non-trivial. When viewing the console (especially right after loading doom), one has to deal with the possibility of showing text involving the operating system (ie file paths) and that implies Unicode support where special characters may be important.

[quote="ibm5155"]Text rendering is freaking slow, idk how is it made but if it's not this way, I would sugest doing a sprite rendering instead of text.
I did a SDL console, and the text rendering method was so slow that it would be useless to make a console game, so I did a test with a spriteblock, and I rendered each letteras a image, and boom, I got 1000fps :D...[/quote]

Real fonts are extremely complex. They're not just a collection of graphics for each glyph, they are pretty much programs in their own right. Read the articles on [url=https://en.wikipedia.org/wiki/Graphite_(SIL)]Graphite[/url] and [url=https://en.wikipedia.org/wiki/OpenType]OpenType[/url] to get an idea of how much stuff happens under the hood when you render a font properly.

Most of that is overkill for the typical Doom mod, where you don't really need to handle ligatures and nobody will really mind if hyphen, minus sign, em dash and en dash are all the same symbol. Obviously when rendering a letter consists in copying a graphic it's a lot faster than when it consists of running a program that will scan the context of the letter to see how it should be rendered exactly.

By the way, I recently needed a larger console font in GZ[b]3[/b]Doom, so I hacked in a way to make the console text respect CON_SCALETEXT=1.

https://github.com/cmbruns/gz3doom/commit/1f09c616659c570f03a58761599c76e7b35f20d4

Yeah, if this happens it'd have to be exact multiples or else risk looking really ugly. (personally, I'd wind up using a nice 2x scale.)

Sprite text (bitmap) sucks for scalability and high def displays.

Guess what ZDoom's fonts are...

Text rendering is freaking slow, idk how is it made but if it's not this way, I would sugest doing a sprite rendering instead of text.
I did a SDL console, and the text rendering method was so slow that it would be useless to make a console game, so I did a test with a spriteblock, and I rendered each letteras a image, and boom, I got 1000fps :D...
The only problem I would think is coloring the font, hmmm, if all the chars on zdoom console couldn't change their colors, so all chars would have the smae color, would this increase the performance?

Nothing about the scaling - but I replaced the console buffer with a significantly faster version. It still slows somewhat down with excessive message spam but significantly less than before.

Did this end up happening? I don't see any options for it anywhere. Trying to do lots of console stuff on my HiDPI laptop and it's pretty rough.

Yes, indeed. It's really the shitty console buffer that causes the slowdown, nothing else! The code is truly of the 'What were they thinking?' kind.

Not for much longer, though, I'm almost done with a replacement that formats text only when necessary. And it can retain all its history. On modern systems the memory it uses is hardly relevant.

[quote="Graf Zahl"]I can't say. What I know is that the text buffer management is horrendously inefficient and can cause serious performance issues if a map is spamming messages.[/quote]
Is THAT what causes that? Wow. I've noticed a tremendously long load time on maps with missing textures (which get reported in the console). Never guessed it would be the console itself causing the slowdown.

I can't say. What I know is that the text buffer management is horrendously inefficient and can cause serious performance issues if a map is spamming messages.