Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Feb 2013
Offline Last Active Mar 13 2015 01:53 AM

#5199590 Thoughts on Rust?

Posted by on 22 December 2014 - 04:13 PM

My background: for the little I delved in game programming with C++, I was absolutely scared of the language. Previously, I was programming in C#/Java, and C++ with its manual memory management was so scary I switched completely to "modern" C++11 and used shared_ptr absolutely everywhere. Then my enthusiasm got drowned by "serious" work in PHP "language". And Javascript. I am a huge fan of finding problems on developer machine, and not runtime. And scripting languages are in absolutely the farthest distance from that ideal.


Year and a half later, I found Rust. It is like a breath of fresh air. It has the right idea. It is not that it is "killer" of some particular language. It simply stands out because it leaves less problems for runtime than any language I used before.


I am not saying that "Rust" is special. No, the idea of "ownership" and "borrowing" is special. Even if by some unfortunate event Rust dies, other languages are going to pick up this idea.


How else to explain it? Well, you know, how we find elements in map quickly? We keep it sorted. How do we quickly calculate statistics for the large amount of data? Well, we aggregate it as the data comes in. How do we avoid collecting garbage in language to ensure memory safety? Well, we define strict rules so we can know when all data is deleted at compile time. duh.


Yeah, I know, it sounds like Rust turned me into a fan smile.png

#5057187 Where to go to start to learn Python?

Posted by on 27 April 2013 - 03:19 AM

I am always worried that I will find a source that is just plain horrible


Don't rely on single source :)

Also when you understand basic language constructs, you can delve into something bigger. For example, I learned python while writing Civ4 script.

#5054988 Gravity's affect on velocity implemented with speed and direction.

Posted by on 19 April 2013 - 01:25 PM

My article may help to get started with vectors.

#5053126 c++ delegates, evil method?

Posted by on 14 April 2013 - 06:26 AM

If you have VS2012 and can install latest CTP, it adds support to variadic templates (from C++11). You can then do stuff like this:


#include <functional>
#include <iostream>
#include <list>

template<typename ... Args>
struct event {
	std::list<std::function<void (Args...)>> handlers;
	void listenIn(const std::function<void (Args...)> & handler) {
	void call(const Args ... args) {
		for (auto handler : handlers) {
			handler(args ...);

class other {
	void handler1(const std::string & name) { std::cout << "Hello " << name.c_str() << "!" << std::endl; }

int main(int argc, char* argv[])
	auto a = new other();

	// this event will work with handlers having one string parameter
	event<std::string> e;

	// listen in any compatible class method
		&other::handler1, // class member
		a, std::placeholders::_1 // bind first param to object pointer, leave others for the event


	delete a;

	return 0;


Basically you get type safety with no downsides, if you can ignore crap in the bind method. You can also add a lambda function as a listener:


// listen in inline lambda function
e.listenIn([] (std::string & name) { 
	std::cout << name.c_str() << " is mine." << std::endl; 



Several parameters example:


class other {
	void handler1(const std::string & name) { std::cout << "Hello " << name.c_str() << "!" << std::endl; }
	void handler2(int number, int basket) { 
		std::cout << "There are " << number << " apples in the basket " << basket << std::endl; 

int main(int argc, char* argv[])
	auto a = new other();

	// this event will work with int, int
	event<int, int> e2;

		&other::handler2, // class
		a, std::placeholders::_1, std::placeholders::_2 // bind first param to object pointer, leave others for the event

	e2.call(8, 2);

	delete a;

	return 0;


Note that adding listener in lambda function is actually safer and easier, because all the hell will break loose if the event is called after the "a" is deleted (on access to any class member).

#5052808 Academia

Posted by on 13 April 2013 - 09:10 AM

Academia. Full of brilliant people. However, more often than not, when it comes to programming, they produce the hardest code to read EVER.
Why do you need to name your class fields as c, cc, d, e? What the hell are you trying to obfuscate? And no, that wall of well-aligned comments is not a solution. And please, stop teaching students variables by naming them a, b, c, d. Please. Just. Stop. Later they become professors who can not produce a readable code.
You probably think that your code looks good because it nicely fits in a box. I know that you were making pixel shaders before I was even born, but you are wrong.
Another example:
/** A two dimensional array holding particle positions. For the
 * derived container_poly class, this also holds particle
 * radii. */
double **p;
Why don't you just name it "positions"? What are you trying to save? Certainly not a compiled binary size, because the name does not matter there. Are you producing that extremely complicated code inside this class SO FAST that you can not type a full name of "positions" variable every time it is needed? No wonder you end up with your method contents looking like this:
int l,dijk=di+nx*(dj+oy*dk),dijkl,dijkr,ima=step_div(dk-ez,nz);
int qj=dj+step_int(-ima*byz*ysp),qjdiv=step_div(qj-ey,ny);
int qi=di+step_int((-ima*bxz-qjdiv*bxy)*xsp),qidiv=step_div(qi,nx);
int fi=qi-qidiv*nx,fj=qj-qjdiv*ny,fijk=fi+nx*(fj+oy*(dk-ima*nz)),fijk2;
double disy=ima*byz+qjdiv*by,switchy=(dj-ey)*boxy-ima*byz-qjdiv*by;
double disx=ima*bxz+qjdiv*bxy+qidiv*bx,switchx=di*boxx-ima*bxz-qjdiv*bxy-qidiv*bx;
double switchx2,disxl,disxr,disx2,disxr2;

so you have created qj, qi, and more badly named
crap at the top of your function... again.
Oh sure it is more compact. And that is NOT a good thing. Of COURSE I can figure out what it all means eventually, I am not THAT stupid. But it is not the point.
What if you have another friggin' class where "p" means "pizza"? Why do you have to remember to mentally switch from "oh, I am working with particle class so "p" means "positions"" to "oh this is pizza delivery class so "p" means "pizza"".
But yeah, I understand that you won't encounter "pizza" anywhere, because you have never worked with a huge code base where you simply can not remember everything.
P.S. This little rant was not intended as a good critique. It just sometimes gets to me smile.png

#5052754 Advice Needed

Posted by on 13 April 2013 - 05:22 AM

Yes, Java is a good language to learn programming, as any other general-purpose language :). Anything else is a religious debate.

#5052745 I want to make a 2D game engine! Where do I start?

Posted by on 13 April 2013 - 05:01 AM

Your engine is only good for what you test it for.


The big part of writing a reusable and good code is being able to test it in a real-world scenario. In case of a game engine, I would discuss that it is near impossible to write a good game engine without writing a game. Even then, this makes this engine only tested for this specific type of game [1].


Why it is so? Because a use-case is the main factor that drives any software. A good game code works for game-related use case, and not for an idea of a game-engine. If we test your engine by executing some demo of 3D terrain and a skybox, then our engine is good for making a demo for 3D terrain and a skybox. If we try to build a game on top of that, we will most likely find that our engine needs to change. Because our use-case have changed.


Do we really need an "engine"?


Why do we even want to write game engines?


I think we do not like the idea of our code being used for one game only. Why rewrite, when we can reuse the same thing again and again? Let's separate our engine-specific and game-specific code and make engine reusable this way.


Well, the problem is that games are quite different. And we like different games. Even in 2D side scrollers, we want to make new wildly insane mechanics different for every game and maybe even the level. The bad things start happening when the game-specific stuff starts to creep into our engine. Now, instead of being optimized for a single game, our engine needs to be optimized for both use cases. And sometimes it is not feasible, and we may end up using separate engine versions for separate games. We should have just made different games without wasting time for one engine.


The "good" code.


Let's just accept the real world, and embrace it. In the real world, no one ever creates perfect code (except me, but that is a joke [2]). Things break in the real world. Sometimes we need to rewrite big portions of the code. And we learn, often the hard way, that writing a good code requires a knowledge of what a bad code is/was. 


And sometimes a good enough code for one game may be a bad code for another. And vice-versa.


It depends on what it is used for.


Group code by the Use Case.


The big thing driving a good software design nowadays is called decoupling and separation of concerns [3].

The Big Idea is to create the tools, not frameworks or engines. A tool is self-sufficient. It should not know about anything else but itself, and require the minimum of third-party components.


Inject a bit of pragmatism here. It is OK to copy-paste a helper function from our "engine" into the tool to make it more self-sufficient. Even better, optimize this helper function to work better for our tool. Our tool can have its own "vector" type, or use plain arrays best suited for its job, instead of using engine's "vector" type. It may not be DRY [4], but it might be OK.


A game is a test for the tools, as well as the reason the tools exist. It should remain that way.

The question of deciding what "tools" to write should be dictated by the requirements of the game, not a vague idea of what possible games there might be.


How to write a tool?


Let's write a game, and let the tools be the solutions to the problems we encounter while writing a game.


For example, write an input handling the way it is best suited for our game, and make it more and more tool-like and decoupled as we complete it. This way we can keep an eye on suitability for the game and the performance of our tool.

In the end we can move this "tool" into a separate library. We may use a software like CMake [5] to avoid thinking too much about compilation and linking. We may even write a small demo application that uses nothing but this tool


We can write a small demo applications to demonstrate that our solutions work properly without the dependencies of the full game. 

This is good for several reasons:

  • If we ever want to evaluate our tool/solution for inclusion into another game, it is easy to see if they are suitable, because a use case is clearly demonstrated in a small amount of code that is required for a demo.
  • This motivates to avoid adding dependencies to our libraries, because we will need to add dependencies to our demo applications.
  • We see more immediate results while developing a game, because we have the working demo applications sooner than the finished game.
  • In case something breaks or needs improving, we can use the demo as testing grounds instead of launching now-big game with all the other clutter.

And even if we do not succeed to completely move our tool into a separate library, our code is still better and more decoupled, because it is more "tool-like".


[1] Write Games, Not Engines, scientificninja's blog.

[2] “Nobody actually creates perfect code the first time around, except me. But there's only one of me.” [Tech Talk: Linus Torvalds on git, Google, 15 August 2007].

[3] Managing DecouplingBy Niklas Frykholm, GameDev

[4] DRY - Don't Repeat Yourself

[5] Cross Platform Test Driven Development Environment Using CMakeBy AllEightUp, GameDev


(should I expand this into a full article? there is much more to say on this subject)

#5052402 What exactly is considered a system?

Posted by on 12 April 2013 - 05:02 AM

To iterate previous responses, there may be systems on different levels:




You may have a crafting system. You can craft a tool using a defined amount of wood and steel. Players can learn this system and expect it to work the same way.

No such system would mean no defined way tools appear. They may be raining from the sky one second, the other second they will degrade into worms.


Game engine


For example, you may have a material system. You can have a documentation which describes how to load textures, apply materials - how to generally use this system.

No such system would mean that there is no defined way to do material management, and every use case may be completely different.


Project management


You can have a bug-tracking system which sets a way in which bugs are reported, checked and resolved.

No such system would mean fixing bugs as they come. Joe and Jones may be fixing the same bug at the same time, no one cares.

#5051460 tictactoe

Posted by on 09 April 2013 - 05:14 AM

It is a compiled exe file :)

#5051213 Not sure what it is that I'm doing wrong with templates in this case

Posted by on 08 April 2013 - 09:15 AM

The approach I use is this (seems like "Method 3"):

// template_file.h

#pragma once


#include <template_file.inline.h>
And definitions:
// template_file.inline.h

#pragma once
#include <template_file.h>

"inline" file is used like a usual .cpp file. This speeds up compilation a lot.
Sadly, I don't remember where I first found this approach.
Edit: you can replace "pragma once" with "#ifndef .., #define ..". Same thing.


Ok, so you have two header files?

Having a hard time visualizing your approach. The way I understand it is this:
- template-file.hpp: this is where you have the class declaration (and the sub-methods)
- template-file.inline.hpp: this is a just a place-holder file to make it easier for the compiler to swallow
- template-file.cpp: this is where the implementation of the template class is located

Am I right or am I way off?


No, implementation is in template-file.inline.hpp, because there is no .cpp file. Template files are inlined anyways per-use. Or, should I say, compiler chooses how and where to compile multiple binaries resulting from used variations of the template parameters.


You would include template-file.hpp in other files to use template.

#5048291 SDL - waste of time?

Posted by on 30 March 2013 - 07:19 AM

Um, I believe one of the most common use cases of SDL is for window creation and input management while leaving graphics to OpenGL.

#5047914 Which is easier to program C# or Java?

Posted by on 29 March 2013 - 01:54 AM

C# had an advantage of learning from Java's mistakes, as well as having a chief architect who previously worked on a Delphi language. C# has much more syntax sugar added in later versions, which shortens many statements. .NET runtime also seems to have an architectural advantage of being the runtime for any language compilable to IL instructions, while Java runtime is made just for Java.


All in all it comes down to getting used to it. Also the big part of ease of use is knowing your way around the libraries you need.

#5046784 Is it bad to use an IDE when you're just starting out with programming in...

Posted by on 26 March 2013 - 01:01 AM

Compile your first few classes without IDE just to learn what is going on "under the hood". Then move on to IDE.

#5045738 Java or learn c++

Posted by on 22 March 2013 - 03:31 PM

A lot of concepts of making a game are the same across all languages. So I imagine if you are a beginner all that really matters is your skills going up :).


Right now I am prototyping some things in C++ and I find that it really is not quite as rapid as in Java or C#. So it has its disadvantages.

#5044153 Directions!

Posted by on 18 March 2013 - 02:27 AM

What stuff do you not understand?

What basic concepts do you already know?

What do you mean by "serious programming"?

What is your long term goal?


You can always write tic-tac-toe with both OpenGL and DirectX and compare them. Just an idea.