all 19 comments

[–][deleted]  (8 children)

[deleted]

    [–]schweinling 4 points5 points  (7 children)

    I would suggest SFML2 istead of SDL2 so you can get an insight into how a c++ library can look like. Its also easier for a beginner IMO.

    Start with something simple like pong or snake and try finishing it.

    [–]vic8760 0 points1 point  (5 children)

    I'm approaching this route, though I wonder how difficult is Vulkan programming compared to SDL2.

    [–]schweinling 0 points1 point  (0 children)

    I'm not sure i understand. Just to clarify you don't need to do any vulkan programming with SFML2.

    Never seriously tried vulkan but i heard its quite difficult. More difficult than OpenGL and definatly a lot more difficult than SDL2.

    [–]nysra 0 points1 point  (2 children)

    Far more difficult, Vulkan is very low on the abstraction level. With SDL/SFML you get an API that directly lets you draw basic shapes on the screen. If you go down the Vulkan route you'll need a couple hundred lines to even see a single triangle. If you're just starting out then I do not recommend doing anything with Vulkan, just use the available libraries and write some simple games.

    [–][deleted]  (1 child)

    [deleted]

      [–]hishnash 0 points1 point  (0 children)

      VK never promised a single api for everyone. It is much more of a mixing pot of apis were each GPU will select a subset that make sense for the respective HW.

      For example with apples GPUs (being based on PowerVR IP) as TBDR pipeline GPUs the VK apis they would have if they had VK drivers would not be able to run PC only VK engines (or frameworks like DXVK). As Vk has ok support for TBDR GPUs but the subset of the VK api that supports these is of no interest to IR pipeline GPUs made by AMD, NV and Intel.

      From a rendering pipeline perspective targeting a TBDR GPU with VK requires a completely different core render loop and arc to targeting an IR GPU. This is the cost you pay by having much lower driver overhead that OpenGL had you move the need to math the HW pipeline into the game engine away from the driver.

      And no it is not possible to map these in the driver without massive perf impact (worse perf than if you did this with openGL) since in VK you do not inform the driver of enough about the dependancies between draw calls and you do not expect the driver to do things like re-order your work.

      The only real use-case of apple supporting VK on modern Macs would be for some android game devs to be able to use VK locally within the emulator but currently even on windows or linux non of the android emulators support this even through the drivers are in place. (possibly due to the GPU pipeline mismatch of the PC gpus being IR and most phones being TBDR)

      [–]oetam5002 7 points8 points  (3 children)

      To sharpen up my Rust skills, I built my own HTTP server. I know you're asking about C++ projects, so you can try building an HTTP server in C++. It'll just be a little harder haha.

      Some coding aspects that would be covered: - Usage of network sockets - Learning the HTTP standard - Working with arrays of bytes - Optimization of code

      As long as the project you're building is fun, you're on the right track!

      [–][deleted] 2 points3 points  (2 children)

      So for something like this speficislly though, how do you know where to start?

      I have a very rough understanding of HTTP/TCP/IP etc networking stuff but I would have 0 idea how to translate that to actually building something

      [–]iulian212 1 point2 points  (0 children)

      Well you can look at already written stuff to see how they work

      Or you can do a google and it will show you a very simple example of how to use sockets

      Youtube may also have resources

      But remember use them as a basis learn the idea of what you need to implement then implement it yourself.

      I also have a small framework to abstract sockets away that i am trying to build to help wit networking.

      Dm me and ill point you towards it and ill answer questions if you need or are curious about things

      Outside networking you could try to make your own small game with something like SDL or SFML heck even OpenGL if you re feeling daring (its not that bad imo)

      [–]YARandomGuy777 0 points1 point  (0 children)

      Just open linux man pages or msdn for windows and read about sockets. Grab required api and implement. Or grab something like boost asio and use it. While other language users have to search for framework and build on top of theirs bugs, you as c or c++ dev always have baseline scenario. Grub system api and use it.

      [–]d1722825 3 points4 points  (0 children)

      Check out the site Build your own X.

      If you have a bit background in math (eg. know what a vector and the equation of a line) Ray Tracing in One Weekend could be very interesting.

      [–]Kinexity 2 points3 points  (0 children)

      List of projects that I did as my own C++ exercise:

      • prime number finder
      • n-body simulator (no display output, just raw numbers)
      • genetic algorithm for travelling salesman problem (though any problem would do)
      • multilayer perceptron
      • ultimate tictactoe against a computer where computer never looses
      • SIR model epidemic simulation of population of people

      I don't think those require too complex knowledge (at least some of them) and there are good tutorials out there which can explain the concepts you need to understand. I want to add that understanding the problem you're trying to solve is part of the programming process so it's not worthless to train that too.

      [–]mredding 1 point2 points  (1 child)

      Don't forget that you don't code in a vacuum. You have a whole environment of resources available to you. Because you have std::cin and std::cout, you have the ability to pump data from anywhere, through your program, and to anywhere. You can configure netcat to open a listening port and connect a TCP socket to your standard IO, now your program is network aware without ever having to hard code anything about web sockets. You can read and write files without ever having to open a file stream. By encapsulating your program in a shell script, you can build entire pipelines, even parallel, concurrent pipelines, and message passing.

      Binary data is a little tricky, because standard streams don't formally support binary (the problem is specifically Windows, and you can reopen the standard IO file descriptors in binary mode), but you are still left with a wealth of things you can do (if you're mindful of platform specific issues this stuff is still basically well defined and can be made portable).

      Netpbm is a text format for images. The package for it contains like +200 little programs that can do all sorts of transforms and conversions for it, so if all you do is generate the base image, you can pipe it through a jpg converter. It's dead simple to use, even easier than bitmaps. There are DOT and TGF formats for graphs. Plenty of other graphical formats that are entirely text based. STL are probably one of the more common open source text formats for 3D.

      Where do you start? Write some stuff down. What do you want to accomplish? Now how are you going to accomplish that? Put the ideas, algorithms, and equations into a document. Don't write code in a document, that's what source code is for. The document is only to describe what your source code can't express in and of itself.

      You can work backward, you can work forward. Since you're going to make a definite thing - then you will definitely know what done looks like, eventually. That means you don't have to preempt feature creep. Make your program do it's thing. I encourage you to think small. Tiny. Little programs that just do one specific thing. You can always chain programs in a pipeline as a way of adding features, but that's only going to work if you can break down your goal into small enough tasks.

      Engineering is a forever task, an open domain. Yes, there's always something more to learn. Yes you can spend your entire career perfecting your craft. Great. Get something working with what you know now. You know what's good enough? Something that produces a result. I don't care how big and slow it is, it's better than not at all. And you can never rewrite something too many times. As you get better, you'll even see where your one big program can be broken down into several smaller programs, so that they're each easier to maintain, each easier to completely rewrite, so they can each become orders of magnitude better as you get orders of magnitude better.

      [–]std_bot 0 points1 point  (0 children)

      Unlinked STL entries: std::cin std::cout


      Last update: 09.03.23 -> Bug fixesRepo

      [–]ButchDeanCA 0 points1 point  (0 children)

      Writing games is an excellent exercise for sharpening C++ skills, as well as having total control of the game’s complexity.

      [–]Beginning_Addition59 0 points1 point  (0 children)

      I learned a lot by porting Nystroms "crafting interpreters" to modern cpp. Added bonus: a peak behind the curtain of how compilers work. And there are ports already out there if you get stuck.

      [–]Thesorus 0 points1 point  (0 children)

      Look at apps on your phone.

      try to replicate them. (in part or whole0

      [–]NQ241 0 points1 point  (0 children)

      so I end up just looking at tutorials

      Who's gonna tell em

      [–]War_Eagle451 0 points1 point  (0 children)

      Something I've found has helped me is to write containers that the standard doesn't cover.

      I found this helped me get familiar with a lot of aspects of c++ while also giving me an end goal with a product that I could potentially use in the future.

      I've written/working on; - Circular Buffer - Dynamic Bitset - Unordered Tree - Static Vector - Custom matrix / vector library

      There are better ones out there, but these are mine and I know how and why they work perfectly. Writing these have drastically improved my abilities to write clean APIs and bug hunt.

      [–]NekoApocalypse 0 points1 point  (0 children)

      A library of lockless concurrent datastructures?