On Sunday, 22 July 2018 at 17:12:31 UTC, Ecstatic Coder wrote:

> 2/ Nuklear (https://github.com/vurtun/nuklear)

Reading the documentation for Nuklear, I found this: https://rawgit.com/vurtun/nuklear/master/doc/nuklear.html#drawing

> To draw all draw commands accumulated over a frame you need your own render backend able to draw a number of 2D primitives. This includes at least filled and stroked rectangles, circles, text, lines, triangles and scissors

That's basically what the Autumn of Code proposal would like to have built in D: A rasterizer with fundamental drawing primitives.  So, it seems Nuklear is a library intended to be built on top of the proposed rasterizer.

Mike

On Monday, 23 July 2018 at 08:08:03 UTC, Mike Franklin wrote:
> So, IMO, if you need to link in a library or object file that was not compiled from D code, then you're cheating.  This is also one of the reasons why I suggested re-implementing software building blocks such as `memcpy`, `memset`, `malloc`, `free`, etc. in D as another potential project for the Autumn of Code.
>
> So, to keep this software rasterizer project within scope, I suggest creating naive implementations of those functions in D for now to stay true to spirit of the project (no dependencies, everything in D), and "make the point".  You can those software building blocks in their own module, and let the user of the software rasterizer library link it their own implementation if they wish to deviate from the spirit of the proposal.


That's actually what I am doing now. Currently I wrote a short script to ensure the symbols in the main project within a subset (https://github.com/htfy96/rasterizer-d-embed/blob/master/check-no-und-symbols.sh). I also plan to create some basic dependency-free building blocks like memcpy/memset/memcmp (already implemented in https://github.com/htfy96/d-rlib) and malloc/free (maybe reusing some building blocks from std.experimental.allocator?) in separate projects. Regarding floating point operations, I plan to use dmd.builtins/ldc.builtins instead of linking with libm.

Above this well-defined set of primitives, the core rasterizer will be built, so that  users can plug in their own implementations or use the default implementation when libc/libm is linked.

On Monday, 23 July 2018 at 09:09:40 UTC, Mike Franklin wrote:
> On Sunday, 22 July 2018 at 17:12:31 UTC, Ecstatic Coder wrote:
>
>> 2/ Nuklear (https://github.com/vurtun/nuklear)
>
> Reading the documentation for Nuklear, I found this: https://rawgit.com/vurtun/nuklear/master/doc/nuklear.html#drawing
>
>> To draw all draw commands accumulated over a frame you need your own render backend able to draw a number of 2D primitives. This includes at least filled and stroked rectangles, circles, text, lines, triangles and scissors
>
> That's basically what the Autumn of Code proposal would like to have built in D: A rasterizer with fundamental drawing primitives.  So, it seems Nuklear is a library intended to be built on top of the proposed rasterizer.
>
> Mike

+1

Then I agree that Antigrain is probably the best reference code for the antialiased renderer, as its code is small, very complete (ttf/gsv/raster fonts, top quality antialiasing, etc) and reasonably fast.

IMO the better-C standard library runtime should be provided to the developer in charge of developing that rasterizer.

On Monday, 23 July 2018 at 08:08:03 UTC, Mike Franklin wrote:
> On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote:
>
>> Moreover, The term "dependency-free" in the project description often confuses me, because as a hardware-agnostic library the project does have to depend on external implementations like "sin"/"memset" or even "thread_start", and I'm not sure which kind of dependency is proper for this project: Should we assume a multi-threading model? Should this library rely on "malloc"/"free"? Correct me if my understanding is wrong since I had few experience on embedded programming.
>
> There is more to this project than just getting a software rasterizer in D.  Part of the goal is to demonstrate D as a formidable alternative to C in micrcontroller firmware programming.  D will never achieve that notoriety if it's always depending on C, the C runtime, the C standard library, or some library implemented in C.
>
> So, IMO, if you need to link in a library or object file that was not compiled from D code, then you're cheating.  This is also one of the reasons why I suggested re-implementing software building blocks such as `memcpy`, `memset`, `malloc`, `free`, etc. in D as another potential project for the Autumn of Code.
>
> So, to keep this software rasterizer project within scope, I suggest creating naive implementations of those functions in D for now to stay true to spirit of the project (no dependencies, everything in D), and "make the point".  You can those software building blocks in their own module, and let the user of the software rasterizer library link it their own implementation if they wish to deviate from the spirit of the proposal.
>
> Mike

I agree

But this BetterC minimalistic standard library (allocations, arrays, strings, slices, maps) is something which can be reused by many similar hardware-level projects.

This is a project on its own, and as I said, I think it should better be provided to the candidate so he can use his development time on developing the rasterizer, and, if there is enough time, a minimalistic nuklear-like gui system over it to demonstrate its performance and usefulness.

On Monday, 23 July 2018 at 09:52:54 UTC, Zheng (Vic) Luo wrote:

> Regarding floating point operations, I plan to use dmd.builtins/ldc.builtins instead of linking with libm.

That reminds me.  Something else to consider is that some of these microcontrollers don't have FPUs.  Graphics libraries designed for microcontrollers often use fixed-point math as a lowest common denominator.  I think, given the features of D, fixed-point or floating point could be selected at compile-time.

But, I don't wish to expand the scope of the project.  An all-floating point library would be fine, IMO, and fixed-poing math could be added to the library in a future iteration.

Mike

On Monday, 23 July 2018 at 10:24:14 UTC, Ecstatic Coder wrote:

> But this BetterC minimalistic standard library (allocations, arrays, strings, slices, maps) is something which can be reused by many similar hardware-level projects.
>
> This is a project on its own, and as I said, I think it should better be provided to the candidate so he can use his development time on developing the rasterizer, and, if there is enough time, a minimalistic nuklear-like gui system over it to demonstrate its performance and usefulness.

Indeed, having to port the druntime to new hardware is definitely not in scope.  I can't anticipate what features of the language the developer will employ, but as long as they stay within the -betterC subset of the language, I think it will be portable to something like that used in https://github.com/JinShil/stm32f42_discovery_demo

Even if it isn't portable, if it compiles and runs in -betterC on a PC, it will still be an excellent foundation to build on, and I'd still call it a success.

Mike

On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote:
> Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code!
>
> We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details.
>
> Spread the word!
>
> https://dlang.org/blog/symmetry-autumn-of-code/

Another issue of this program is that me, as an incoming graduate in the U.S., are prohibited to "work" in my first school year. (that law doesn't affect GSoC since summer is considered as the second school year). I'm not sure whether contributing to open-source projects is considered as "work" here. There are some legal issues related. I'm looking forward to some clarifications like (https://developers.google.com/open-source/gsoc/faq#is_gsoc_considered_an_internship_a_job_or_any_form_of_employment) stating that this program is an "employment" or not.

On Monday, 23 July 2018 at 10:33:28 UTC, Mike Franklin wrote:
> On Monday, 23 July 2018 at 09:52:54 UTC, Zheng (Vic) Luo wrote:
>
>> Regarding floating point operations, I plan to use dmd.builtins/ldc.builtins instead of linking with libm.
>
> That reminds me.  Something else to consider is that some of these microcontrollers don't have FPUs.  Graphics libraries designed for microcontrollers often use fixed-point math as a lowest common denominator.  I think, given the features of D, fixed-point or floating point could be selected at compile-time.
>
> But, I don't wish to expand the scope of the project.  An all-floating point library would be fine, IMO, and fixed-poing math could be added to the library in a future iteration.
>
> Mike

Having already implemented a video game engine using exclusively fixed point math for a nintendo handheld, I can tell you that the rasterizer code will have to be implemented with that in mind. Using several precisions (16.16/20.12/40.24 formats) and 64 bits products, avoid divisions, etc.

A very different beast IMHO, even with fixed point structs overloading the different math operators...

On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote:
>
> Spread the word!
>
> https://dlang.org/blog/symmetry-autumn-of-code/

Thanks to everyone for the project ideas, but I put the list on the Wiki for a reason. I'm always pressed for time, so if you have an idea for a project suggestion, it would help me tremendously if you can just summarize it on the Wiki rather than here.

Thanks!

On Monday, 23 July 2018 at 13:02:33 UTC, Zheng (Vic) Luo wrote:

>
> Another issue of this program is that me, as an incoming graduate in the U.S., are prohibited to "work" in my first school year. (that law doesn't affect GSoC since summer is considered as the second school year). I'm not sure whether contributing to open-source projects is considered as "work" here. There are some legal issues related. I'm looking forward to some clarifications like (https://developers.google.com/open-source/gsoc/faq#is_gsoc_considered_an_internship_a_job_or_any_form_of_employment) stating that this program is an "employment" or not.

I can't definitively answer whether not the U.S. government would consider it work, but I can tell you that neither Symmetry nor the D Language Foundation consider it employment; they view it just as Google does. I'll add that to the FAQ.