Vector graphics

Re: Vector graphics

Postby Lyberta » 04 May 2019, 22:14

fluffrabbit {l Wrote}:Everything is already there. GUIs, web browsing, audio, mouse and keyboard input, but these are fundamentally different operating systems


Not really, all OS have files that are sequences of bytes. Pretty much all OSes have directories. Almost all networking is TCP or UDP over IP. Almost all audio is PCM. Almost all graphics are square pixels on rectangular monitor. Windows, macOS, Linux, Redox, ReactOS, whatever, they all share a lot. A LOT.

fluffrabbit {l Wrote}:so the intermediate layer is effectively a platform, and the larger that platform grows the harder it becomes to use on new and/or resource-constrained systems


New systems usually are compatible with some old stuff. Do you see audio stop being PCM? Do you see graphics not using pixels? It stays the same for decades. Only small internal details change.

fluffrabbit {l Wrote}:If I managed a compiler suite, I would say no graphics, no audio, no networking, none of that operating system BS because this is a low-level programming language with high-level syntax


And nobody would use that because we are not in 1960s anymore. Even UEFI - the lowest level before the OS - now has ultra HD graphics.

Even text requires a shitload of RAM. I've downloaded Unicode character database and it consumes 33.5 MiB in text form. I guess I can manage to optimize it to use something like 10 MiB of RAM at runtime but maybe not less. And that's just plain text. That's just to print some characters to the terminal. Oh wait, in order to print I would need a powerful graphical subsystem, that's way over 10 MiB...
⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧
User avatar
Lyberta
 
Posts: 605
Joined: 19 Jun 2013, 10:45

Re: Vector graphics

Postby fluffrabbit » 05 May 2019, 02:07

It's not the low-level hardware and design differences that separate operating systems, it's the APIs they come with. C++ sits on top of operating system APIs, making more code, which real programmers don't need. It would be nice to have C++ code that runs at a lower level than all that, such that a kernel and all the hardware drivers could be written in it. My gut tells me that running these proposed APIs on top of UEFI is a pipe dream, and that comes from 1990s reasoning, not 1960s.
fluffrabbit
 
Posts: 551
Joined: 11 Apr 2019, 11:17

Re: Vector graphics

Postby Lyberta » 05 May 2019, 11:02

fluffrabbit {l Wrote}:C++ sits on top of operating system APIs, making more code, which real programmers don't need.


I'm extremely glad I don't have to call OS APIs most of the time. They are extremely horrible. All of them. I love that C++ safeguards me from OS. OS is bad. C++ good.

fluffrabbit {l Wrote}:It would be nice to have C++ code that runs at a lower level than all that, such that a kernel and all the hardware drivers could be written in it. My gut tells me that running these proposed APIs on top of UEFI is a pipe dream


I think it's just a matter of someone porting stdlib to that environment. I'm definitely interested in writing some UEFI code.
⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧
User avatar
Lyberta
 
Posts: 605
Joined: 19 Jun 2013, 10:45

Re: Vector graphics

Postby fluffrabbit » 05 May 2019, 13:08

Lyberta {l Wrote}:
fluffrabbit {l Wrote}:C++ sits on top of operating system APIs, making more code, which real programmers don't need.


I'm extremely glad I don't have to call OS APIs most of the time. They are extremely horrible. All of them. I love that C++ safeguards me from OS. OS is bad. C++ good.

While that's probably true, I have always found the Windows API to be mysterious and magical. Windows C++ development is its own animal distinct from POSIX. The larger the C++ standard gets, the more Windows programmers shy away from MinGW and use MSVC instead, which I think is a shame. Back in the day, I was hesitant to use MinGW at all because it was bigger than 5 MB while the Tiny C Compiler was nice and compact (and libtcc for C scripting is a thing now too, yay). Now I just say screw Windows.

Lyberta {l Wrote}:
fluffrabbit {l Wrote}:It would be nice to have C++ code that runs at a lower level than all that, such that a kernel and all the hardware drivers could be written in it. My gut tells me that running these proposed APIs on top of UEFI is a pipe dream


I think it's just a matter of someone porting stdlib to that environment. I'm definitely interested in writing some UEFI code.

Yes, that's the problem: getting the C++ runtime libraries on the target system. What about MS-DOS, Amiga, and the Sega Dreamcast? You can run C code on all of them, but I don't know about these proposed super-high-level APIs. On the other hand, if these super-high-level APIs become part of the C++ standard and run on top of or can even replace UEFI, you can replace operating systems! That would be awesome.
fluffrabbit
 
Posts: 551
Joined: 11 Apr 2019, 11:17

Re: Vector graphics

Postby Lyberta » 05 May 2019, 23:13

Well, there is IncludeOS where you just type

{l Code}: {l Select All Code}
#include <os>


And your program becomes an operating system. Just almost no drivers.
⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧
User avatar
Lyberta
 
Posts: 605
Joined: 19 Jun 2013, 10:45

Re: Vector graphics

Postby fluffrabbit » 06 May 2019, 09:03

IncludeOS... "in the cloud". What about embedded systems? What about graphing calculators?
fluffrabbit
 
Posts: 551
Joined: 11 Apr 2019, 11:17

Re: Vector graphics

Postby Lyberta » 06 May 2019, 11:47

Send patches :P
⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧⚧
User avatar
Lyberta
 
Posts: 605
Joined: 19 Jun 2013, 10:45

Re: Vector graphics

Postby fluffrabbit » 06 May 2019, 13:24

If it isn't doing anything unreasonably high-level I just might. Of course one should expect nothing of their programming languages, but that's more of a C way of thinking...
fluffrabbit
 
Posts: 551
Joined: 11 Apr 2019, 11:17

Re: Vector graphics

Postby fluffrabbit » 06 May 2019, 16:03

Just found this. Once you've exported the sequence of SVG frames from Blender at a lower framerate (in the 10-30 range) you can load the frames in the game engine at 2x or 4x their specified size for scaling and interpolate between the frames using 2 texture inputs and the GLSL mix function if you have multiple texture inputs working (you will have to call something like glUniform1i( glGetUniformLocation( "uniform_name" ), texture_slot ) for each texture slot the shader has).
fluffrabbit
 
Posts: 551
Joined: 11 Apr 2019, 11:17

Who is online

Users browsing this forum: No registered users and 1 guest