Factorio was written in C++ with help of Allegro graphic library, it's custom game engine, models are made in Blender, rendered in a 45deg angle to match isometric view. Unity wouldn't handle a game with that scale - it has too many "useless" features for that type of games.
Rather then source code itself, look up the info in documentations when available.
In this case, look here: https://liballeg.org/a5docs/trunk/display.html#al_create_display, where it is described pretty nicely, the 2 parameters are width and height of the window you create.
Allegro is a 2D game engine. I'd suggest taking a look, get familiar so you can build your own engine.
In school we made 2D games using grids in Swing, but I'm sure you can find a toolkit library in C++ with support for a grid layout (or canvas), and mouse/keyboard event handling.
If you want to build a 3D engine, I'd suggest OpenGL game programming by Kevin Hawkins. The book is a bit outdated but it should serve you as a primer into building a 3D game engine.
Another resource for 3D game programming using OpenGL is http://www.videotutorialsrock.com/
Note that you can create 2D games using OpenGL but OpenGL is not a game engine.
This might be a sharp corner of Allegro poking through. Allegro mouse events contain an attached cursor position, while key events contain only a key code. Requiring a mouse button ensures the bound event contains a cursor position.
Look into SFML or Allegro, they are basic game development libraries for C++ and have a solid documentation full of examples. It won't teach you how to build a new Battlefield but it should be enough to make a simple platformer like Mario with some practice (and there are "real" games written in them too, eg. Factorio is built in Allegro).
Can you show what you did to fill the bitInfo struct? I'm asking because I have a feeling you are trying to write 24 bit color data to something that actually expects 32 bit color data.
If it isn't that, have a look at this page, in particular the section headed "Remarks":
>The bits in the array are packed together, but each scan line must be padded with zeros to end on a LONG data-type boundary.
That means that every line in your picture needs to be some multiple of sizeof(LONG) in length. If you don't do that, you'd expect behavior like you see in your picture, that every line after the first is shifted by a certain number of pixels.
edit: Actually, while I'm here, have a look at Allegro. From your screenshots I get the impression you're working on something at least game-adjacent. Low-level Windows graphics is complete garbage to work with for exactly the sort of reasons you're running into. Unless your specific aim is to get to know a rarely-used platform-specific API in frustratingly detailed ways, I recommend using some library to take care of the technical details so you can focus on getting interesting things done.
you didn't way which operating system you're using
depending on how much C you know getting a game library/framework setup with your compiler can be difficult
you have to set the include directories, the lib directories, the linker flags ... you have to have to download the right version or you might even be forced to make and compile the library yourself
I think SDL2 is a great library, but all the tutorials I know of use C++
lazyfoo has the best sdl tutorials http://lazyfoo.net/tutorials/SDL/
he starts off with C, but moves onto C++ later
maybe you'll learn enough from the C portions so that you can make a small game
but I'm going to recommend Allegro https://liballeg.org/
here is a VERY basic tutorial in C for Allegro
http://www.gamefromscratch.com/page/Allegro-Tutorial-Series.aspx
you are not going to be able to make anything fancy in a month
you might be able to make an advanced pong or asteroids, but I think that's all
> Back in the day assets were easier to create.
But the barrier to entry was higher. Back in the day you needed a lot of hardware to even get bootstrapped. There was nothing like Unity.
IIRC Allegro was one of the only options for most developers outside of making their own. It was available but there certainly was no GUI. Funny thing about this graphic engine, it's still relevant. Factorio was built on it. https://liballeg.org/readme.html
Since someone else already recommended SDL, I will add Allegro. Like SDL it is a cross-platform framework that takes care of the low level details of game programming.
Qt is C++, but it is easy to use and very well documented with lots of sample code and tutorials. I have only done the tutorials in Gtk, but it is also pretty easy to get started with.
You might be able to use non-canonical mode. If this is for a real-time game and you don't want to use a game framework like Allegro or libSDL, you will most likely need to use interrupts or polling.
A stable and reliable alternative to SDL is Allegro (both 5.2 and 4.4) https://liballeg.org/index.html. It essentially is a game engine, but it's very minimal and you can draw shapes very quickly, with mouse and keyboard event detection.
I used to use SDL and Allegro (wow, throwback). Libraries like these give you access to various resource you need to develop games or interactive media. They act as a simple rendering and drawing engine, but also give you access to sound, keyboard, mouse and other system events. They are based on and hide various system dependent interfaces for drawing (OpenGl, DirectX or direct frame buffer), sound and input.
Depends!
If by GUIs you mean "desktop programs", text editors etc - give a try to Qt or wxWidgets. First is a full fledged multiplatform framework for C++ (it's big but has a lot of examples and is far more than just GUIs - it has libraries for working with internet, handling image formats, multimedia and so on). wxWidgets on the other hand is just a GUI library.
Now, when it comes to games specifically you have 3 options. Allegro, SDL or Unreal Engine. First two are fine for 2D games (eg. Factorio was made in Allegro), Unreal Engine is if you want to build something larger (it's also industry standard for game development).
You should also be able to choose ALSA or OSS in allegro5rc – see here for an example of the config format: https://liballeg.org/a5docs/trunk/system.html#al_get_system_config But yes, the game links to <code>libpulse.so</code>, so it's required in that sense.
I've been getting this error with everything that builds against Allegro 4 since glibc was updated to 2.28 in the Arch repo about a week ago. According to the Allegro docs, these functions were all renamed to prevent conflicts with some implementations of libc, but aliases were put in to enable backward compatibility, and they're enabled by default and need to be manually disabled. That seems to be the issue here -- these function names are conflicting with math functions in the current version of glibc.
You can try either modifying the Aseprite source to define ALLEGRO_NO_FIX_ALIASES and disable the conflicting function declarations (hopefully they're not being called by those names anywhere in Aseprite -- they are in AGS), or temporarily roll back to an earlier version of glibc -- I did the latter to build AGS, but I also had to roll back a bunch of other libraries that had all been updated to work with glibc 2.28.