Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Jun 2010
Offline Last Active Today, 02:43 PM

Posts I've Made

In Topic: Fast Approximation to memcpy()

12 October 2016 - 05:59 AM

template<typename Type, size_t Num>
constexpr Type[Num] memcpy(Type[Num] src)
    return src;

Thats the modern C++11 variant. Better syntax (why pass in dest when we have return-values), and zero runtime overhead. And I'm not even sure if that even compiles and/or works, as an added bonus ;)

In Topic: Best way to be a game developer?

08 October 2016 - 09:25 AM

Or do you? Are my opinions of needing to go to college for game development wrong? Am I capable of learning game design on my own effectively?


So first you mention "C++ for dummies", and now you are asking about game design. That has nothing to do with each other, so you have to be a little more clear what you want. Do you want to learn game design? Do you want to learn game programming? Level design? Art design?


From a coding perspective, you can learn the basics of game programming without a college, specially thanks to site like the one you are writing on :)

See for example the "Are you a self-thaught grafics programmer"-thread. If you invest a lot of spare time into learning game programming, you certainly can do it on your own. Learn the basics, get yourself a project that interests you and provides a good middle-ground between challange and payoff, and you are good to go.

Depending on the college, but a proper education can give you a deeper understanding of some of the topics, as you are fed with topics you would normally maybe not touch (algorithms, design pattern, ...), but its not that you cannot possibly learn how to programm without an education, that is bs.


On part of game design specifically, I found most of the game design related courses in my "college" interesting, but not strictly helpful/mandatory. You get lots of good input maybe for your own ideas, some tips on balancing/creating new ideas, but there is no such thing as a game design cookbook that shows you what to do step by step. Game design is a very creative and dynamic process, so outside of new ideas that you could also get by looking at example of successfull, innovative games yourself, there is little that an game design education can teach you AFAIK.


Next question is indie vs studio game development. ...

Ok, so now you seem to assume an aweful lot. I don't know if thats just your writing style? But whenever you write "we", "you", etc... I strongly tend to disagree, or atleast say to myself "why, thats surely not the case for everybody".


The main reason we become game developers is to make that idea in your head a reality.

Actually the reasons might vary. Some people might take more joy from supplying fantastic art to an idea that they themselves find tolerable, or solve challenge coding-problems to make the next "no mans sky" run smoothly. So what you probably want to say is that your main reason to become a game developer is to make your own dreams come true?

You're not making a game you want to make, you're making a game someone else wants to make. Now a couple of years ago that wasn't that big of a deal because new ideas were coming out and graphics kept getting better, but that's not the case so much anymore.


Why does that contradict itself? Just because someone else wants to make the game, doesn't mean I don't also want to make it. As soon as you are in a team, unless you are the very creative lead or came up with an idea strictly in a team-based process, you are going to work on an idea that somebody else came up with period. Now you can enjoy the idea yourself, but there is no difference between an indie-company or an AAA-studio here. Its probably easier to give your own influence towards the idea in a small studio, granted, if that is what you are looking for.

Still the bottom line is: Somebody is going to work with another persons idea, no matter what. We learned that hard way in the 4 team-based projects we had at college so far.


Imagine hearing about the next big game your studio is going to be working on and absolutely hating it. Like making the 18th cod hate.

Just an additional side-note, but: I'd much rather work on the 18th CoD then on some "lets make something that has to stricly be 100% innovative"-type of indie game idea that usually ends up as an Unity2D-made "pretentiously clever word-play in the title of the game, as the main game concept"-game. No hate towards indie-games, but just to show you that everyones preference is different.


Which is better? Working studio without control of what you're doing with stable pay or working indie with potential for heart crushing failure?

So for me I totally prefer studio, and thats where I'm going to gear my career towards. Fortunately (?) for me it offers the best on all ends as far as I can see now.


Should I prioritize game development on mobile platform for lower risk or aim high for higher capability, but much more risk?


I would say, that this question itself is based upon an observation that I cannot comply to. You say "mobile platform" = less risk, and list flappy bird as an example. That is simply not true. Sure for the guy there was little risk, because he was doing it as a free time job, but also his chances for success were equally limited. The mobile-market is currently flooded with cheap-ass games where half of it is just clones of other games like flappy birds. So your chance of becoming successfull is very slim (I'd argue that flappy-bird becoming successfull is more of a miracle than anything else).


So what should you do? If you just want to make projects in your free time it really only depends on what you want to achieve in the end. Or, to hand the question back to you, would you want to work on the 34th flappy-bird clone for a 0,1% shot at success if you really hated doing it? :)


Oh, and since it fits both those questions as well as the part about hating to work on a game you don't like: Ironically, most (some?) indie-gamedevs actually have to work on projects they don't necessarily want to. You see, if you are making a living off of games, you don't have that much of a choice in what you do. You have to make money somehow. You can try pretty much everything as a first project to see if it works, but if it doesn't, whats left to do? I know of many instances, some even personally, where people just have to resort to doing state-sanctioned education games, or stupid stuff like "bus simulator 2016" instead of the game ideas they actually want to pursue.


So what you should do when you want to make a living off of the game ideas you want to make? I hope I've made it clear that your assumption about the mobile market was errorneous, so what else can I add? I'd argue that if you have an idea you want to put into live, do whatever has to be done to make it happen, regardless of if it is going to be successfull. If you do not want to end up broke, you should take care of what happens if it fails though - so eigther you have enough savings to back you off, separate safe projects to make up for it, or maybe just a completely different full-time job, and make your game in your spare time only, if all else fails.





Thats as far as I can tell, I'm sure there are a lot of different perspectives to be gotten from different people. It seems to me though that you already have a clear vision of what you want to achieve, so I'm not sure there is much to be said to your questions other than different people giving their own opinions (which may or may not be of value to you).

Hope this still helps.

In Topic: How big is your project?

06 October 2016 - 09:02 AM

The stats for my engine (in C++):


- Hobby project

- 4 years in developement

- 113k lines of code (not counting newlines)

- 1335 source files

- => ~80 LoC per file


- Some additional ~100k lines for tools (editor), genre-specific code (top-down 2d plugins, ...), and so on.


Its comfortable to work with that way, some files tend to become larger, some single ones around 1k LoC, but I usually try to split up classes/files if they become this huge. I find it far easier to work with small files, you have a better overview of everything and find things you are looking for much quicker. Goto Definition/Declaration makes jumping around files virtually free.


As for refactoring, I find it vitally important to have a look at old code, even if it still works in the current version. Unless its something you write one time and then never again, you learn just so much from looking at old code and how to improve it.

For example, I have written 3 different visual "scripting" languages so far. While details vary, some core-concepts stay the same. The first implementation was horrible, since I had no idea what I'm doing. Slightly reworking it from here and there gave me a good idea of some larger-scale changes I would make if I were to write it again. So when I wrote the second one, I applied those ideas, and it turned out much better. Then I ended up reapplying those changes to the first visual language, essentially still finding room for improvements in the process, which in turn lead to more improvements on the second language. Now by the time I've written the third one, I knew exaclty how it should look, and now thi swon't require any refactoring in the near future, as far as I can see. If I'd just said "screw refactoring", I would probably have three horrible implementations of a visual scripting language, while now I have 3 decent ones that are way easier to work with, where the third one took no extra effort whatsoever.

So bottom line, refactoring can be really good if you write similar code over and over again and want to learn how to improve it.

In Topic: Some HDR, tonemapping and bloom questions

26 August 2016 - 09:45 AM

HDR simply means using a larger-than-backbuffer texture format, such as R16G16B16A16 while doing lighting (like adding up light contributions, which could be greater than the [0, 1] range) and later in the pipeline, tonemapping/bloom post-processing effects?


Tonemapping is about calculating the average luminance (essentially light intensity?) and to smooth it out over the final image?


Actually as I've been told, HDR just means the first step of storing/calculating lights in a larger space. Tonemapping is just a process to get this information in a format that can be displayed on regular displays. If we ever had a full HDR monitor, no tonemapping would be needed anymore.


If so, where does Bloom fit into all this? Is tonemapping and bloom the same thing? Does it make sense to use only either or only both together? (Tonemap vs Bloom vs Tonemap+Bloom)


Bloom is just a light-bleeding effect that is naturally caused by the restrictions of a lense. In CG, we use a dedicated bloom pass to simulate this behaviour. So you can have tonemapping without bloom, but bloom works way better with HDR (now instead of having a bloom-threshold of 0.9, you can have a value of 9000.0 which will only bloom really bright light sources ie).


When calculating the average luminance, is it wise to do it in a compute shader or just mipmap the whole image and read the 1x1 level?


Regarding the different methods of calculating the average luminance, I would personally do it manually eigther via a compute-shader, or repeated fullscreen downsample-passes. I have found that the automatic methods fail to produce accurate results, which might be depending on the hardware, yet it happened on all of my PCs. The problem I've been facing with auto-downsampling was that it wouldn't take the average of the neigbouring pixels on downsampling correctly, kind of seemed like he was using a point-filter. The effect was, that a single dark area in a specific portion of the scren would cause the avg luminance to drop drastically. I haven't checked this in a while but back then, using manual downsampling actually fixed it.


Does tonemapping and bloom require special 3d assets to function properly? I am using assimp for example and am stuck with its restrictions when it comes to asset parsing. Best thing would be if it could just adapt to whatever scene is rendered.


No, not at all. Models don't need to change based on the rendering model anyways, and textures can also stay the same (since ie. the color texture of a model actually represents the amout of light being absorbed, which stays the same with HDR or without it).

In Topic: Is it pathetic to never get actually helpful answers here?

14 August 2016 - 04:01 AM

Since we are on the topic:


A one-line question is less likely to give you a meaningful answer, than a medium-length question with an explanation of at least some context to this question.


For example, unlike Alberth, I wouldn't feel like to search through all your previous topics to see what had happened. So with that in mind, I wouldn't be able to answer even this question. If you gave a short example, it would be easier to see what had happend. Like: "For example, that last time I asked about this, I just got people telling me to do that which was not part of my question".


I just had a brief look at your previous questions and, it seems most of them are kind of short like this. So maybe one thing that can be a reason, and that you can approve on is, trying to give more information towards your question. Nobody likes to read wall of texts but at least show some background, show us what you actually expect, then you might get answers more to what you actually expect :)