Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 05 May 2007
Offline Last Active Jul 21 2015 12:42 PM

Posts I've Made

In Topic: Why don't game engines run in kernel mode?

09 June 2015 - 01:34 AM

It might be a weird idea in 2015 but I'd be curious if it would be helpful for consoles to have DOS-like operating systems. In DOS you were provided all the basic OS services and drivers you need for a typical application of that era, but you also had the possibility to bypass the OS completely and talk directly to the hardware if you really wanted to, and your program ran in kernel mode and ruled over the system. Since the hardware is always the same there would be only one I/O interface to code against per console. (So it wouldn't be like the actual DOS from the early 90s where you had to code for all possible drivers.)


I don't think console manufacturers would go in that direction with modern consoles though, for several reasons.

  1. Next-gen graphics API like Vulkan and DirectX12 are already doing a great job at removing as much overhead as possible from the driver by moving a lot of responsibilities to the application, and they do so in a safe way that doesn't expose dangerous kernel-mode instructions. It would take away the overhead of the syscall (context switching, reading interrupt vector, etc), but that's about it.
  2. It would limit the manufacturer's ability to improve their console's performance by providing better drivers if some studios are bypassing their drivers.
  3. It would be dangerous for the manufacturer's precious DRM. A buffer overflow happens quickly, and it's quite useful when it's running in kernel mode. wink.png  Find one game with a buffer overflow and then you can probably rootkit the OS with a DRM bypass and then it's game over.
  4. Since games and saves are all on the harddrive a fault in the code of one game could affect more than that game itself. For example, if a game breaks the file system, it would break a lot more than itself. That's a big risk that neither the developer nor the console manufacturer might want to take. Besides, only the brave would play Bethesda games. tongue.png
  5. Privileged code is inherently more difficult to debug. Even your debug printout and code dump functions can get corrupted if something goes wrong.

So yeah, console games are probably going to stay in user mode for now, and run huge OSes. But as a PC gamer this is a good thing because I don't want developers to get too comfortable with kernel-mode tricks, otherwise I'll get less games to play. smile.png

In Topic: Using named POSIX mutexes?

06 April 2015 - 04:39 PM

I'm not sure if pthread defines system-wide named mutexes, but the POSIX standard defines named semaphores, and a mutex is just a special kind of semaphore (that only takes values 1 and 0 and that is initialized to 1) so that should be good enough if not as handy.


Look at the sem_open function for how to use it. You might also want to read that SO question: http://stackoverflow.com/questions/16400820/c-how-to-use-posix-semaphores-on-forked-processes

In Topic: From scratch vs Unity

28 March 2015 - 08:15 PM

Those are a few reasons why I made my game from scratch instead of using Unity.

  1. Unity is way overkill for my project, which is a 2D RPG. If I wanted a premade engine, RPG Maker would be a much better buy than Unity for my needs. (Not that I'd use it because the graphics engine sucks and it's not cross-platform, but I'd sooner use that than Unity or Unreal.)
  2. I have a lot of code already written, including a very good (for my game's needs) editor program, to the point where moving to Unity would be *more* work than actually completing the game.
  3. I like owning the source code of my entire project. When I encounter a bug I don't want to wait for the Unity devs to fix it and even less to code a workaround myself.
  4. This one goes with 3 but just by principle, I don't want to tie my game to someone else's engine if it's not absolutely necessary for the project's success.
  5. I'm a systems and chip programmer and I love low-level programming. I have more fun writing my game from scratch and hand-optimize it than using someone else's work.
  6. The bare pro version is a $1,500 package that you pay upfront. I personally find the Unreal 4 payment model more advantageous, but for that I guess YMMV.
  7. For a "indie-friendly" engine, they buy a lot of stuff that look way overkill for indies such as their Mecanim animation system, yet they took an eternity to get a proper UI system which every game needs.

Now, I'm not an unrealistic daydreamer; I know that if my project was more complex and involved 3D and advanced rendering techniques I would have to seek a premade engine (although it would probably be UE4 instead of Unity) I just can't think of any point for me to switch to a premade engine this far into the project.

In Topic: how to comunicate with diffrent exe files?

18 March 2015 - 09:03 PM

Is there a reason you can't just open sockets at and transfer data that way? It's not as efficient as shared memory but it's much easier to work with, there are cross-platform libraries for sockets, and for I assume that the kernel is optimized enough to not go down all the way to the IP stack before noticing that the packets are for itself.


Shared memory is more efficient but it puts the burden of creating a communication protocol and synchronizing memory reads and writes on your shoulders. So I hope you really need the performance gain if you go that way. It's also less flexible since you can't put the server on a remote machine.

In Topic: Java book

15 February 2015 - 09:50 PM

Did you use Google? The second link I found looked very much like what you want: http://www.amazon.ca/Beginning-Java-SE-Game-Programming/dp/1435458087. The book is from the same editor, and looking at the cover art it's even from the same collection as the book in C++.


I didn't read it but it seems to be exactly the same as the other book but in Java, although it uses Java 6 and we're now at Java 8 so I don't know how recent it is.


Although, to be honest, while you totally can use Java to write a game, it's not a programming language that is typically used for that (it's more the kind of language that you will find running Web services, custom-made internal business apps, and now Android apps) so I don't think you will find the same quality of game development resources in Java as you do with C++, which is the de-facto programming language for writing game engines, or with C# which is the programming language used by the Unity engine and by the (although dead) XNA framework.