ibm5155 wrote: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 ...
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 Graphite and OpenType 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.
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.
ibm5155 wrote: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 ...
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 Graphite and OpenType 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.
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 )
-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
=====
ibm5155 wrote:
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...
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.
...
)
