TurboScreen 001

Hi guys

I finally put online my humble project TurboScreen. A C++ library. Not tested but it's working (i think). You can make a screen (it's a window. I call it a screen) and put some color pixels in it. Put some documentation online and activated a forum. Just take a look at main example in docs section of site. Doesn't do much but is a start. For seeing source code just download it from site.

Library is working in my windows 10. :)

project site: http://www.turboscreen.org
I didn't test your library but I see high motivation on your side...

I suggest you continue your journey trough open source by contributing and learning existing patterns, because in doing so a person of your profile can achieve many awesome future goals.

to become a developer for developers is a great and awesome step forward!
Last edited on
Hi malibor

Thanks for comment. Already working on TurboScreen 002 version.
Last edited on
If you want to be pro developer I suggest to start learning about library versioning, for example:
https://semver.org/
Last edited on
Hi Malibor

Thanks for link. I took a look at it. Maybe next version will follow this recommendations.
@forgottencoder - on you docs page, instalation should be installation
Yep. You should assume your reader knows how to use their environment. You don't need to explain that they should create a directory for their project and a source file for their code, or what the options for GCC mean. We know how to use our compilers. What we need to know is if there's any special considerations we should know about to integrate your library into our code. If there aren't any you can just say that. It looks like just adding the files to the build system is enough.
Last edited on
Hi seeplus

Thanks for pointing text bug. I will correct it.
Hi helios

Well i assume that an example with my own compiler would help. Better to have something than nothing. I will put a note in there later saying there are no special considerations to integrate library in code. Adding library sources files and gdi library is enough.
Custom library code should be as compiler agnostic as possible.

Better still is OS agnostic, but dealing with things like graphics and sound/music that isn't always possible without resorting to a 3rd party library.

Any custom library code should be tested in two (or more) compilers if at all possible. For example, MSVC++ and MinGW/GCC.

I routinely mash code snippets and test them in MSVC++ and Code::Blocks. On occasion code works for one and not the other. With a bit of rewrite that doesn't change the outcome now the code snippet works for both.
Hi Furry Guy

Thanks for your advice.
It depends upon your target audience. Personally, I hate github code that assumes you're using g++ or other linux compiler/environment.
@seeplus,
haha, so true, the first thing I do is create a project, add source files to it and set build flags the way I like...

On another side, what I like the most, in recent years majority of repos have a CMake build configuration which is awesome because build is familiar.
Topic archived. No new replies allowed.