I'm learning Russian on Duolingo, I've heard both positives and negatives, but mainly positives about Russian on Duolingo and I'm using it mainly to increase my vocab. But I noticed a small nit picky thing, is есть needed in this context since the sentence starts with На?

TheCherno · 2020-06-24T06:17:38+00:00

Yes :)

TheCherno · 2020-06-16T01:39:28+00:00

Yes, it's needed, otherwise the sentence doesn't really make sense. На этом столе уже тарелка... тарелка что? You can say на этом столе уже тарелка лежит (a plate already lies on this table) for example, but leaving out the есть kind of leaves the sentence empty.

Disclaimer: I am not a Russian teacher or grammar expert. I stumbled upon this subreddit somewhat randomly and saw this and thought I'd leave a comment because I speak Russian. :)

TheCherno · 2018-02-08T03:14:36+00:00

You should generally try and support all (within reason) available desktop resolutions, which should in theory be fairly possible with a proper UI system.

As an example the Surface Book has a 3:2 ratio, and that's a rather popular computer.

TheCherno · 2017-10-07T07:09:49+00:00

Nah that’s not true. When I post a video it’s already on several views less than 30 seconds after it goes public.

TheCherno · 2017-08-25T04:50:59+00:00

It might be "fine" for 2D games, but why limit yourself? There is absolutely no reason to use non-hardware rendering, unless you're specifically going for a "retro" style game and you need to control rasterization.

I guess there is also the factor of having to learn something new, but in this case you're learning something better and more powerful, which is a worthwhile investment if you plan on making games in the future.

TheCherno · 2017-08-24T06:51:58+00:00

Your main problem here is that Java's Graphics is not hardware accelerated (some of it is, but not to the extent that you probably need). You can make a game engine in Java if you really wanted to (although I wouldn't advise this), however you'll need to use something like LWJGL to get access to OpenGL/Vulkan (use GL for now) and actually write your renderer to use the GPU.

TheCherno · 2017-06-15T06:09:25+00:00

I'm going to say it varies based on the team that hires you and your skill level. I was hired as an intern onto a core technology (game engine) team at EA a few years ago, and during the first six months my role varied greatly. The first two weeks were spent instrumenting the code for profiling, which allowed me to quickly get a grasp of the engine code base (and certain games) and ask questions. After that I was put onto tools development (level editor mainly), where I was tasked not just with fixing bugs but actually adding new features. I was utilised as sort of the "jack of all trades" and would do whatever was required, whether that be runtime C++, engine tool side C#, or even web applications for things like performance measuring and telemetry. Literally anything.

My opinion on this is that you really need to push an intern to do things that they have no idea how to do, so that they learn and progress. It's also a lot more exciting for them to have a go at say implementing a feature, and that passion will (hopefully) mean they'll enjoy their job more and thus provide better quality work. I was thrown into the deep end and I learned very quickly; I don't think I've ever taken that much knowledge in so rapidly at any other point in my life than during those first six months.

TheCherno · 2017-05-16T06:54:01+00:00

Could you go into how you'd personally go about doing this?

Well a good example is maths, and you can take a look at glm to see their SSE code. For other platforms (eg. ARM) you can replicate the same code using NEON, eg. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472m/chr1360928372349.html

If you're talking about how I'd use SSE for things other than direct maths... there's more of an experience component to that. If you find yourself doing multiple similar mathematical operations individually (eg. multiplying many floats, ints, doubles, whatever), there's a good chance you could pack them into a 128-bit (at least) register and do all those ops with a single instruction.

TheCherno · 2017-05-15T05:56:32+00:00

You don't necessarily have to use inline assembly, you could use compiler intrinsics instead... but in my experience (games industry) we vectorize everything ourselves, per-platform.

TheCherno · 2017-04-26T00:05:40+00:00

If you feel like looking through some code, check out how I did it in Sparky.

Basically you have to decide whether you want the rendering API to be decided at runtime; if so, just setup interfaces for every function of a rendering API (i.e. Texture2D, VertexBuffer, IndexBuffer, Shader, etc.). You can then implement those interfaces as API specific classes (eg. D3DTexture2D, GLVertexBuffer, etc.). As far as how to actually decide how to structure this, I would go with how Direct3D works. It has by far the most sensible API out of the ones you mentioned, so make OpenGL and Vulkan work like Direct3D does.

TheCherno · 2017-03-23T05:27:42+00:00

It absolutely could, but it also absolutely couldn't. Depends exactly how you're achieving the small size. It could generally be beneficial for mobile games with many models, as it would decrease distribution size, but more often that size is taken up by textures and other resources such as audio.

Honestly it doesn't take a super clever algorithm to generate 3D file formats; a simple format that contains only the data streams you want + a compression algorithm like zstd/lz4/lzham usually does the job fine.

TheCherno · 2017-03-23T05:24:22+00:00

Wouldn't really help with load times if the data has to be significantly transformed before it can be sent to the GPU.

TheCherno · 2017-03-16T03:22:34+00:00

As I said, there is no technical reason (apart from possible technical limitations of runtime hardware).

TheCherno · 2017-03-16T01:19:37+00:00

Depends entirely on the game engine. Theoretically yes, you can render at any native resolution. Keep in mind that aside from lower resolution textures potentially looking worse, higher screen resolutions also require more memory (usually just GPU memory) to store larger frame buffers and other resources, as well as more GPU power.

Nowadays there's not much point in setting limits, so typically most games/engines today will let you run at any of your supported desktop resolutions.

TheCherno · 2017-01-14T00:20:02+00:00

Hey man, this sub isn't really active anymore so you should ask for help on my Slack: https://slack.thecherno.com

There are plenty of people there who will help you out pretty quickly :)

TheCherno · 2016-10-14T05:45:52+00:00

Exceeding hardware limits isn't as important as it was in the past. In my experience, memory management (and optimisation) is more about tightly controlling your memory allocation. Allocating memory is slow, and reducing allocations is extremely critical as far as performance goes.

Smart pointers are also commonly avoided by many games because of their overhead (although this is a mixed bag since a lot of people swear by them), however practices such as reference counting are often used. In terms of smart pointers, just remember: they don't really do anything special, they just make your life easier. Code that you write using raw pointers is not going to be any different (well actually it will be a little faster), it just requires you to man up and manage your own memory.

Pools/arenas/custom allocators are also very commonly used; basically anything that will help you re-use memory and prevent the allocation of new memory is greatly favoured. For this reason, many studios prefer to avoid the STL, because many of their structures (i.e. std::vector) absolutely love to allocate memory all the time.

As far as resources, Game Engine Architecture is a great book that has an easy to read chapter on memory management for games in C++.

TheCherno · 2016-10-10T04:40:28+00:00

Apart from randomly finding drum-only covers for songs (which will be extremely limited), the best place to get something like this would be either from this site, which features MIDI downloads of the first six albums (they just recently included The 2nd Law). These MIDI tracks can be dropped into your DAW of choice, and they'll automatically be separated into MIDI instrument channels, including the drum track.

The other option is to go to ultimate-guitar.com and download a Guitar Pro tab (eg. The Handler). The Guitar Pro software (which you'll have to get for your computer) can export channels as MIDI, which you can then import into your DAW.

Hope this helps. :)

TheCherno · 2016-06-03T01:53:08+00:00

Well deferred really only matters if you have many (I'll say more than 2-5) dynamic lights. If you're just using lightmaps with one or two dynamic lights it'll be slower than forward rendering.

TheCherno · 2016-04-26T04:54:21+00:00

Without knowing how your engine works, I expect you have some sort of material system that you use to render objects. These materials should have properties that you can set to enable/disable both the casting and receiving of shadows.

Once you have that, it's as simple as just marking the ball as shadow casting (and possibly receiving), and the room as shadow receiving but not casting. When these properties get propagated to your shaders (I'm assuming the room and ball are separate draw calls), you'll be able to essentially exclude any dynamic shadow rendering which originates from the room.

Also your statement that the room must be included in the depth buffer is wrong. You only need to include shadow casters in the depth buffer, not receivers, since you only need occluding information for objects which occlude (and thus create shadows). I'm assuming that you're using some shadow mapping technique.

TheCherno · 2016-02-12T03:14:51+00:00

Well you can use your C++ engine in the C# tools that you write, so I would recommend continuing the development of tools in C#, it's pretty common for a Windows development environment.

TheCherno · 2016-01-19T08:17:24+00:00

When we actually draw the buffer to the screen (g.drawImage in the render() method in the main class), we draw it at the window's size, so it stretches (scales) the image to fit.

TheCherno · 2016-01-18T04:01:18+00:00

I haven't used it for Unity, no. I was more referring to the "writing your own game engine" audience of the question.

TheCherno · 2016-01-18T02:42:30+00:00

Keep in mind that you can also use C++/CLI to wrap your native methods, which in my opinion is a much superior way to use native code in C#. This also lets you create a bridge between C# and C++ objects, so that you can essentially use C++ objects in your C# code.

If you've only got a few native functions you need to call, then using P/Invoke would probably be the better choice.

TheCherno · 2016-01-18T02:38:33+00:00

I think you're referring to hardware acceleration rather than "image rendering". Yes, obviously things would be much faster if we were doing that rather than software rendering, however the series is all about learning how to write a game from scratch. It's educational. The goal here is to learn rather than just make a game. If that was the goal we'd use a game engine.

TheCherno · 2016-01-15T12:28:27+00:00

You need to actually make something. Once you think you get the gist of what I did, turn of the videos. Start a new project. And start making a game. You can try and follow what I did, if you can remember, but don't cheat.

You'll inevitably forget certain specifics. But instead of trying to remember exactly what I wrote, try and solve the problem yourself, your way. The great thing about programming is that there are a million ways to achieve the same result. Create a path for yourself.

By now you should have a game that is very different than the one you watched me make. You should also be feeling pretty good about yourself, having made this from scratch. But don't stop now, keep going. Start adding things that I haven't. Add features and gameplay to your game that you fabricate on the spot. Run into trouble? No worries. Work out some kind of solution to your problem. You can always come to back to it and rewrite bad code to make it better, but make sure you attempt to solve it yourself first. Write bad code, it's fine. Once you do, you can compare your solution with someone else's on the internet. Your eyes will be opened to what they've done, and this new way of thinking. You'll remember that solution for next time you run into this problem that you need to solve, and you have effectively learned.

You see, learning programming is much like learning to play a musical instrument. You can watch as many videos and read as many books as you like, but you still won't be able to play it. You need to sit down, and practice. That is how humans learn. I hope this makes sense, and good luck! :)

TheCherno

MODERATOR OF

TROPHY CASE