next »

[ferreiradaselva]

Ok, complete beginner programmer here. I've recently started dabbling with C/C++ and, for practice, I made several console apps that do different things (not all were successfully compiled into what I want though because those seem to entail more complex stuff).
And a day or so ago I decided to take it to the next level and give a try at Allegro; setting it up was a pain (apparently, installing the devpak into Dev-C++ and trying to include the library wasn't enough to recognize the included header file(s) as existent), but I did it thanks to instructions for MinGW Allegro 4.2 which I guess I'll have to work with rather than with Allegro 5. For a start I've been attempting to get a bitmap screen to work and, through referring to the manual and two tutorials that cover the Allegro I use (one of which is on these very forums) and some trial and error, I've managed to successfully compile a fully functional program that draws a bitmap over another one (complete with transparency) and runs until you hit the escape button. Now the only thing left is to figure out how to make the cursor not flicker without also having the side effect of the program crashing when I hit the escape button.
Hey, it may not be some huge feat, but for a person who only recently began programming, this is a big step forward towards more complex programming

This is absolutely a good a achievement! :D


I finally finished the implementation of 'rotate', 'look_at', and 'perspective' matrices in my engine YAY! Painful, but finally working. I looked a lot in the source of GLM and linmath to learn the math.

And better yet, I have a guud and simple game idea in mind!

[oahda]

Dev-C++? Wasn't that last updated like... fifteen years ago? o-o

[JWki]

Dev-C++? Wasn't that last updated like... fifteen years ago? o-o

It's not exactly what you'd call up to date yeah.

[ThemsAllTook]

Well-constructed software doesn't stop working from age alone.

[ProgramGamer]

That would be true if the infrastructure around that software (drivers, OS, DLLs, etc...) didn't change almost constantly.

[qMopey]

That would be true if the infrastructure around that software (drivers, OS, DLLs, etc...) didn't change almost constantly.

Which is why some of the best code doesn't have any, or at least minimal, dependencies!

[ferreiradaselva]

It's just an IDE. It's not like something critical. S/He could've been working with any simple editor.

[oahda]

I seemed to recall it had its own compiler too, but I guess not?

[JWki]

I seemed to recall it had its own compiler too, but I guess not?

I thought the same yeah. I think it does really.

[ferreiradaselva]

It uses MinGW-gcc.

[JWki]

It uses MinGW-gcc.

Oh does it

[ThemsAllTook]

I got a new Mac recently, and naturally, it came with the latest OS X (or macOS or whatever the heck they've decided to call it today). Changing major OS version used to be a particularly arduous process for my development tools, because they relied on a bunch of stuff that Apple kept repeatedly breaking. I had made a concerted effort a while back to futureproof my build chain so that this wouldn't be as much of a problem anymore, and I got to see the fruits of my labor today - I updated everything and built it with the latest Xcode, and apart from having to fix a couple of new errors that clang (correctly) detected, everything went very smoothly.

I had taken pretty much an entire year off from game programming, so coming back to see my tools still just as sharp as I left them was particularly nice. Time to make some cool new stuff!

[JWki]

I got a new Mac recently, and naturally, it came with the latest OS X (or macOS or whatever the heck they've decided to call it today). Changing major OS version used to be a particularly arduous process for my development tools, because they relied on a bunch of stuff that Apple kept repeatedly breaking. I had made a concerted effort a while back to futureproof my build chain so that this wouldn't be as much of a problem anymore, and I got to see the fruits of my labor today - I updated everything and built it with the latest Xcode, and apart from having to fix a couple of new errors that clang (correctly) detected, everything went very smoothly.

I had taken pretty much an entire year off from game programming, so coming back to see my tools still just as sharp as I left them was particularly nice. Time to make some cool new stuff!

Must feel good to be back at it!

[oahda]

Got a "new" (used) one too recently and tried Homebrew again for the first time in years and was happy to see how much it had grown since last time; got most of my libs from there and my projects up and running on the new computer in no time.

[ferreiradaselva]

Uh... I think I got semaphores working on the first try.

I was using a set of booleans to manage the synchronization of the threaded main loop (render on the main thread, update on the second), and was working just fine. The problem is that I had to use a 'while' loop to check one of the booleans to wait the an update to finish... and it would use 20-30% of CPU. Not good. Semaphores solved the problem.

Magic.

[JWki]

Uh... I think I got semaphores working on the first try.

I was using a set of booleans to manage the synchronization of the threaded main loop (render on the main thread, update on the second), and was working just fine. The problem is that I had to use a 'while' loop to check one of the booleans to wait the an update to finish... and it would use 20-30% of CPU. Not good. Semaphores solved the problem.

Magic.

Wait until you get to use fences.

[qMopey]

Uh... I think I got semaphores working on the first try.

I was using a set of booleans to manage the synchronization of the threaded main loop (render on the main thread, update on the second), and was working just fine. The problem is that I had to use a 'while' loop to check one of the booleans to wait the an update to finish... and it would use 20-30% of CPU. Not good. Semaphores solved the problem.

Magic.

Does your semaphore contain a loop internally? Are you using a real atomic instead of a lock? Did you read some of the "little book on semaphores"? To me I'd say there's a 99% chance you have a bug. I worked in a studio that had semaphore bugs for a long time, as they are tricky to get right. I doubt you got yours right first chance.

Edit: Unfortunately my grumpy posts leaked into the happy topic.  

[oahda]

Got my little SDK up on a repository, cloned it onto the Linux machine, fixed up bash scripts to compile the command line tools, used the command line tools to compile the engine library, and used the tools to generate, build and run a default project linking against the library—just had to fiddle a bit to get everything working. Will add in the SSH compile soon so that I can compile for Linux on that machine from the Mac. e:

[ferreiradaselva]

Does your semaphore contain a loop internally? Are you using a real atomic instead of a lock? Did you read some of the "little book on semaphores"? To me I'd say there's a 99% chance you have a bug. I worked in a studio that had semaphore bugs for a long time, as they are tricky to get right. I doubt you got yours right first chance.

Edit: Unfortunately my grumpy posts leaked into the happy topic. 

My semaphore implementations were basically some loops with bool checking. It worked, but too much of a hassle and CPU usage. I don't know exactly how libuv semaphores work (but I know it's a wrap around the POSIX standard on Unix and whatever on Windows). It looks like it's also a loop internally (http://man7.org/linux/man-pages/man3/sem_wait.3.html), but I have no idea how it works without consuming too much CPU like mine did.

Edit: btw, I heard of that book before, but I never read it. I'm gonna check it out. Thanks for the suggestion.

Wait until you get to use fences.

I still don't know if I will try to solve the problem of shared memory in the game engine or leave that for whoever decides to use, but *so far*, the interaction between the update loop and render loop doesn't lead to any NULL reference problem, because everything is pre-allocated and uses an ID (when the ID is 0, then it's an unused object/asset). The max that happens is the render loop to draw an object that was already destroyed during the frame that the object was just destroyed.


I want to release this as a gamedev framework/template, just like GameDevTemplates, Punity and SFML, but with better assets management, scenes implementation and both 2D and 3D rendering (all already implemented).

It's very rare to see a C framework that have built-in a good scenes/assets manager. The only thing that I left without implementing was the 'gameobject', because I would like to give the freedom to anyone to implement them as they like.

Got my little SDK up on a repository, cloned it onto the Linux machine, fixed up bash scripts to compile the command line tools, used the command line tools to compile the engine library, and used the tools to generate, build and run a default project linking against the library—just had to fiddle a bit to get everything working. Will add in the SSH compile soon so that I can compile for Linux on that machine from the Mac. e:

Very nice!  What is the build automation tool? CMake?

[oahda]

Got my little SDK up on a repository, cloned it onto the Linux machine, fixed up bash scripts to compile the command line tools, used the command line tools to compile the engine library, and used the tools to generate, build and run a default project linking against the library—just had to fiddle a bit to get everything working. Will add in the SSH compile soon so that I can compile for Linux on that machine from the Mac. e:

Very nice!  What is the build automation tool? CMake?

Premake for everything except Android which uses CMake because it was hell getting even that to work to begin with and I'm not doing it all over again with Premake.