OSDev.org

Brendan wrote:Hi,
You need to add a "change log" to your website. This forum is for announcements, and it is not intended to be used for your personal "revision control system commit history".


Cheers,

Brendan

But it's interesting (unlike changelogs or one post threads plainly saying Something v0.1.2.3.4 is out). And much more organized and readable than hundreds of topics differing in only version numbers, very fast going to forum oblivion. Active projects would be at the top and most recent posts in them would mirror the current project state.

I don't have a pass for anti aliasing. I have a list of grey scale bitmaps (one for each letter, darker means more transparent, and whiter is the font colour) and I scale them like images to the size of the font. That gives smooth edges with no performance hit.

Oh, and thanks for taking a look at my OS1

Brendan: they are on the website too, in the ,,history'' menu

obiwac: i dont wanted to mess with the fonts untrivially so much (especially since my system is also has unicode/utf8 bitmaps) so my aliasing was (is) done by 2x*2x rendering size of the overall frame buffer, and backscaling when putting it to the screen. but its basically unnecessary in the future, since the resolutions on the monitors are very good nowdays, the pixels are small, its no need to alias any more. so i decided to wipe out the aliasing algos.

Dawn operating system block diagram

Just out of curiosity, how much of that did you (or your team) write from scratch, and how much of that is a library that you are using?

i wrote everything from 0, including the C compiler

Well, then I'm officially impressed.

SpyderTL wrote:Well, then I'm officially impressed.

*shakes hands*

obiwac wrote:I don't have a pass for anti aliasing. I have a list of grey scale bitmaps (one for each letter, darker means more transparent, and whiter is the font colour) and I scale them like images to the size of the font. That gives smooth edges with no performance hit.

Oh, and thanks for taking a look at my OS1

I'm guessing you mean Signed Distance Field text? http://www.valvesoftware.com/publicatio ... cation.pdf

hgoel wrote:

obiwac wrote:I don't have a pass for anti aliasing. I have a list of grey scale bitmaps (one for each letter, darker means more transparent, and whiter is the font colour) and I scale them like images to the size of the font. That gives smooth edges with no performance hit.

Oh, and thanks for taking a look at my OS1

I'm guessing you mean Signed Distance Field text? http://www.valvesoftware.com/publicatio ... cation.pdf

Not exactly, what I meant, but I have tried that technique in the past, and I do think it works quite well. But I like to keep things simple and smooth, so I scraped the idea. Now I just downscale big bitmaps. Interesting read, none the less!

obiwac wrote:

hgoel wrote:I'm guessing you mean Signed Distance Field text? http://www.valvesoftware.com/publicatio ... cation.pdf

Interesting read, none the less!

Yeah, no kidding. I may actually try giving this a shot. This seems a lot simpler than vector based true-type fonts.

Has anyone used this approach for fonts before?

SpyderTL wrote:

obiwac wrote:

hgoel wrote:I'm guessing you mean Signed Distance Field text? http://www.valvesoftware.com/publicatio ... cation.pdf

Interesting read, none the less!

Yeah, no kidding. I may actually try giving this a shot. This seems a lot simpler than vector based true-type fonts.

Has anyone used this approach for fonts before?

Yes, there's a video that goes over the implementation (in Java with OpenGL) quite well. https://www.youtube.com/watch?v=d8cfgcJR9Tk

2017, may 2. - C and user interface bugfixes
Fixed rename function, and added rmdir to C runtime.
If a window creeps below taskbar, putting it down and bringing it up will result in proper location.
Bad absolute mouse location data is truncated.
Better fit of icons in file browser.
Fixed a bug in unicode decoder.
Fixed a file system integrity issue.

prices changed (crypto value skyrocketed)
download links updated


file system IO file creation speed test:
i created a directory structure consiting a few 10k of directory, and a total 100k files in the directory structure from size of 4k to 40k., and removed 40k of them randomly, total data size is below 1 gbyte of 10k directory and 60k file (710 mbyte approx + chunks).

the process took approx 2 hours.

this means typically 600-1000 file per minute = creating 10-20 file per second with content. the emulation environment can go with 300 kbyte/sec on my computer, the real file creation number should be around 40-60 file / second.

is this good? does anybody have comparable datas from his system?

matt11235 wrote:Yes, there's a video that goes over the implementation (in Java with OpenGL) quite well. https://www.youtube.com/watch?v=d8cfgcJR9Tk

That is a good video, and the font to texture tool they used would be extremely helpful. I also found several other good videos on the subject, but they all seemed to focus on games and on using pixel shaders, which makes sense.

But I was just curious whether anyone had used this same approach for non-game, non-pixel shader based fonts. Could you use this same approach in your window GUI system, instead of bitmap or true-type fonts? Would the performance be better or worse compared with true-type fonts? Obviously, with hardware shader support, this approach would be faster, but what about FPU or MMX or SIMD extensions?

I'm probably going to give it a try in any case, because the code to render text based on distance seems trivial, and the code to render true-type fonts would probably take years to me to perfect. But I was just curious if anyone had already done it and could give me an idea what to expect, performance-wise.

SpyderTL: if you start to write gui, you has to innovate rapidly, inventing daily 20-30 things like that in the video from 0, it not worths studying every random rendering invention of others, since you will have to come up with your own aniway.
it does not matter what strategy do you follow, if you have freely resizeable textured elements in a multiwindowing system consuming tens of tousands of ID-s, your only focus will be saving the speed, becouse it will fall down like a meteor, you will basically continously have to shovel back the **** into the cow with more and more extreme solutions to keep the things smooth.

of course you can do the GUI by just copying elements with for cycles to the screen with a few clock cycle per pixel like early OS-es do, but then you loose the ability to have 0-1 fraction number range to descripbe the graphics things, and you fall back to the textures given bitmap size to copy directly only, which makes everything obsolote and pain in the @$$ to deal with, especially since the screen size can be anything.

(or, as i alreday suggested: you can use dawn os as a gui in a subleq emulator)