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 29 Jul 2001
Online Last Active Today, 12:30 AM

#5190666 64-bit ARM CPU?

Posted by Promit on 01 November 2014 - 08:41 PM




Note that writing in assembly does not necessarily produce the fastest possible code, even in math libraries. The compiler can beat you even if you copy its code thanks to global optimization. More importantly than writing, I maintain that being able to read and debug assembly code remains an enormously valuable skill for any systems level programmer.

#5190510 Why don't you use GCC on windows?

Posted by Promit on 31 October 2014 - 10:48 PM

Historically, GCC generated pretty shoddy binary code compared to VC anyway. The build chain on Windows was a mess too, requiring either the MinGW port which tended to be out of date, or aaaauuuuuggggh Cygwin. Lastly, most devs want to use VS just because it's the best of the IDEs, and VC++ is automatically supported while other compilers require messy configuration. I don't know if that is all still true, but those are the classic reasons.


Nowadays, the emergence of clang as a serious toolchain powerhouse has served to starkly show how dated both GCC and VC are. Frankly clang makes a mockery of the other compilers in practically every metric, whether it's build times, code quality, language features, whatever. A wide array of developers are familiar with it thanks to Apple platform development. I'm very curious to see what happens when clang finally becomes usable on Windows. 


All that said, it's pretty straightforward to write C++03 code, even with dashes of 11, that runs smoothly across the major compilers. My choice of compiler doesn't affect the code development at all.

#5189434 [Fixed]Image parsing : Read all file or x bytes at a time ?

Posted by Promit on 27 October 2014 - 10:27 AM

I prefer to memory map the file and skip the memory allocation part entirely. TGA of course requires some decompression code, so you will have to allocate a destination array. If your slowdown is in debug builds only, then you may be running up against the debug time sanity checks in std::vector.

#5189314 Mac or PC - Really, this is a programming question.

Posted by Promit on 26 October 2014 - 07:44 PM

Hardware: both.

Desktop environment: Win/VS, Mac/XCode or Xamarin, Linux/CodeBlocks

I use VMs regularly, dual boot Linux in a few specific cases (off USB 3 portable drives) but not as a general use thing.


Our core tech runs across all of these platforms, although iOS is the only public platform release right now.

#5188794 What Is Your Game Design Technique?

Posted by Promit on 23 October 2014 - 01:16 PM

No documents. No documents


We have a solid general idea of what the core gameplay goal is. Early on, this can shift and adjust and tweak every week or two. And then every month or two as prototypes crystallize, it's all about playing them with a very harsh judgement, and deciding what is or isn't fun. It's completely iterative, and we never quite know where the game will wind up. But on paper designs do nothing for me.

#5188206 Making a NOT library dependant game engine : useful?

Posted by Promit on 20 October 2014 - 04:30 PM

No game engine has value until it's been used to create an actual game. Start with that, then distill the engine out.

#5187236 Why not use UE4?

Posted by Promit on 15 October 2014 - 03:12 PM

UE4 didn't exist when I created our current codebase, and there would have been huge risks to switching mid stream. Also, the kind of work we do requires a lot of customization to underlying systems (especially physics and animation) -- this made Unity a non starter for us. I'd have to carefully evaluate whether UE would lend itself to the same level of customizability. That falls under MJP's second point.

#5187047 How to Separate the Rendering Code from the Game Code

Posted by Promit on 14 October 2014 - 05:41 PM

You guys are all overcomplicating things drastically. I've found that the best solutions are also the simplest. The aforementioned interfaces are appealing to OO-addicts but ultimate serve very little in the way of actual practical purposes, and tend to create more strong couplings and implementation assumptions than you initially realize. (Mike Acton would call them "typical C++ bullshit".) Entity component systems have their uses, but ultimately if you don't understand how to solve this problem in the first place then ECS just adds another mess on top and serves to obscure the failure to tackle the actual problem.


Let's take a simple 2D RTS. What data is needed by just the renderer to compose the main scene?

struct Tile
    struct Texture* tileTexture;
    Vector2D position; //in whatever coordinates you want

struct GameUnit
    struct Sprite* sprite;
    int animationFrame;
    Vector2D position;
    float rotation;
    //add properties like color tint, alpha, etc as needed

That is the only communication that you need between the renderer and the game. The game's render function doesn't call any low level rendering functions; it assembles arrays of these structures. The renderer's job is to accept these structures and put them on screen. That's it. You may wish to elaborate on classes like Sprite and Texture, or leave them as opaque and configure them through some kind of overarching Graphics object. But this is, as written, very simple to express in pure C and it's not necessary to add more complexity even for modern shader based 3D games.


Notice a key difference in how I'm thinking about the problem and how you're thinking about the problem: the game code does not contain the information necessary to render the scene. That creates coupling between components. Instead, the game code builds the information necessary to render the scene, and passes it on. The change in perspective may seem slight, but it's fundamental to how modern graphics systems are designed. If you do this right, then the renderer can completely recreate a frame from its input data with no outside interference, including releasing the entirety of the game objects' memory -- or never creating them in the first place. And now with some judicious save/load code, you can capture, replay, and debug graphics frames in a tool that has NO game code in it.

#5186762 Do you use UML or other diagrams when working without a team?

Posted by Promit on 13 October 2014 - 03:10 PM

I feel that code structure diagrams are unnecessary, period.

#5186595 Should i to compile using static library or shared library?

Posted by Promit on 12 October 2014 - 08:14 PM

Shared libraries introduce potential for mistakes, due to rules about memory management and library versioning. Converting static libraries to shared can lead to huge headaches. My preference is to set things up entirely as static unless I have a specific reason to want a shared library. I rarely do.

#5186198 Are mobile games revenues real?

Posted by Promit on 10 October 2014 - 10:58 AM

Actually I've been curious why more indies don't share more concrete info about their revenues/sales. Is there some reason to not do so?

#5186085 safely researching PC games

Posted by Promit on 09 October 2014 - 06:00 PM

Also, Windows 8 does have an actual app store, though I don't know how much is actually on there.

#5185902 BitmapFont - looking for atlas-packing-function

Posted by Promit on 08 October 2014 - 09:28 PM

This is essentially state of the art, and written by a fellow GameDev member to boot.
There's probably ready made code out there... I believe Freetype-GL has an implementation.

#5185649 If you ever used a vector in c++ could you show...

Posted by Promit on 07 October 2014 - 06:28 PM

I guess this explains why performance might take a hit using vectors. Hopefully my game won't suffer accessing a list of a few hundred at a time.

There's no bigger performance hit in a game than crashing. And my experience in the field has been that aggressive use of vectors (rather than raw memory) helps catch a lot of crash bugs early.

#5185648 How to prepare myself to get a job in a AAA game company?

Posted by Promit on 07 October 2014 - 06:25 PM

Some misc thoughts on the matter:

* Know C++ really, really well. Not just the usage of the language, but a lot of the design internals of the language, how code generation behaves, etc. We can go back and forth all day about the value of other languages in development, but ultimately it's the C++ experts who get the jobs first. 

* Have ONE demo that is GOOD and polished. I've had mixed results on whether studios actually want to see the demo, or see just the code, or ignore it entirely. But simply having it matters, and the more you can show the better. Alternately, have a demo that demonstrates some very sophisticated technical work that you did. This is useful if you're applying for a specialist job (graphics, physics, etc), not so much for a generalist game programmer job.

* Have a broad base of knowledge. Multiple graphics APIs, multiple languages, multiple engines, multiple everything.

* Be willing to work hard. Candidly, game development is not a 40 hour a week job and there's a lot of people willing to put the hours in out there. Some companies might pay lip service to "work life balance" but we all know it's not true.