• Create Account

# Kaptein

Member Since 03 Feb 2008
Online Last Active Today, 03:34 AM

### #5139332Are some people not cut out for programming?

Posted by on Yesterday, 05:12 PM

I correct students in C++ class. I'd say 5% will never be a programmer, 50% shouldn't become a programmer (lack of interest), 45% will do well, and the last 5% have got that extra edge. As far as the extra edge goes, it won't matter. What matters is where your interests lie, and whether you can focus. If you find yourself constantly watching YouTube or Twitch, or playing games, you will never be the best at anything.

Considering you are working on parsing C++, which is draconic in difficulty, I'm assuming you want to be the very best. Unplug internet, buy a book, create code. Rinse - repeat. If not, just create the parser that works for you and try to keep your motivation up and try not to lose your passion for programming. Both are needed more than anything else. Being the best simply means you have to make sacrifices that doesn't necessarily translate into anything worthwhile. I personally just take it easy and do whatever I feel like - it just happens to mostly be programming.

### #5134806collision detection

Posted by on 26 February 2014 - 11:51 AM

An easy way to simplify "complicated" collision is to create a function that only returns true if the internal coordinates passed to it are inside a function.

An example:

We've already discovered that the player was indeed touching the tiles T1, T2 and T3 since the player unfortunately has an area.

So, to simplify things we take the players extremities and calculate which tiles they are inside, and from there we calculate the fractions of the players position inside those tiles.

Fractions are 0.0 to 1.0 only, and that makes math really easy.

If the players left foot is 0.8 fractions inside a tile, our tileHitbox() function can use simple math to determine if that specific point is solid, or not.

```bool tileHitbox(int tileID, float fx, float fy)
{
// depending on the tile, the math functions are abit different
switch (tileID)
{
case T_AIR:
return false; // air is never solid

case T_SLOPE_UP_RIGHT:
// the solid area only exists where fx < fy, a slope that goes up to the right (assuming +y is up)
return (fx < fy);
case T_SLOPE_UP_LEFT:
// the solid area only exists where (1-fx) < fy, a slope that goes up to the left
return ((1.f - fx) < fy);
default:
// in the default case, we just assume the entire tile is solid, for no particular reason
return true;
}
}
```

So, doing it this way adds some complications to your physics department. But we can solve that, using divide and conquer:

You'll notice that if your player has a high speed downwards, you can hit tiles too early due to gravity, which makes him stop a little bit too far up -- preventing him from "landing" pixel-perfect against the tiles.

To fix that, we let there be a function gravity() which takes a parameter telling us just how much the player needs to go downwards at this particular time:

bool gravity(float x, float y, float rate_down);

Each time gravity fails to move (x, y) down by (rate_down), you should call gravity() again, but halve rate_down. You can stop trying after a given number of tries. 4 tries could be more than enough, since all that matters is that no one notices the difference.

Example:

```float rate_total = rate_down;
int tries = 4;
while (tries-- && rate_total > 0)
{
if (gravity(px, py, rate_down)
{
// success, move point downwards
py -= rate_down;
// measuring how far we moved the point down prevents us from continuing
// after we had in fact moved down all the way
rate_total -= rate_down
}
// we always halve the speed here, just in case the loop continues
rate_down /= 2;
}```

The example above is just written off the top of my head. I hope it's not entirely wrong.

Another thing you can do is to calculate the size of a pixel, and just move 1 pixel at a time continually until the gravity rate is travelled. That would probably me much simpler code.

If your rate_down is too big, you risk skipping tiles entirely. So make sure rate_down is not too big, and instead call gravity() more times with a lower number to make up.

Solving these problems with the force (not just gravity) movement rate will give you access to defining tile hitboxes with simple math. It is very cheap and simple programming to test against tiles this way, but not particularly efficient. What it does though, is make your life easy. And that counts more than anything to me.

EDIT: This is going to get slightly more complicated now, since you probably want to "automatically" walk up and down slopes, or on the top of a circle tile should you want to create one.

So, how do you automatically walk up a slope? Well, you can just define different rules for moving the player right/left, jumping and falling down.

For jumping you need to check if his head hit something hard.

For falling, you need to check his feet.

And for right/left you need to check his knees, or something even higher up, because that allows you to to move "into" a slope. Your unstuck mechanism should make sure your player stays on top of the terrain at all times, simply by always moving him up until he is no longer stuck.

The drawback here is that your movement upwards a slope will not be at the rate of the slope, but rather at the rate of moving directly right/left. It may be noticeable, and if you don't want it to be like that you could do some combination stations with moving right/left that penalizes the player if he is indeed moving upwards.

To do that, you need to check if the player can move right/left at his feet level first, and if he can't but he still can move if we measure at his knees, then penalize the movement rate a little to make up for the impending upwards movement.

So, how do you unstuck someone? Well the cheapest way is:

```void unstuck(SomeGuy& guy)
{
while (terrain.test(guy.footLeft()) || terrain.test(guy.footRight())) guy.move(0.0, 0.1); // move slightly upwards until no longer stuck
}
```

Or something in that fashion.

### #5130488Voxels Theory

Posted by on 11 February 2014 - 02:50 AM

MarlboroKing, if your chunks are in power of two size you can make mod easier:

So, assuming we have a class Chunk with static const int SIZE_XZ and SIZE_Y:

```// for x and z axis
inline int fastmod_xz(int x)
{
return (x & (Chunk::SIZE_XZ-1));
}
// for that axis that points toward the sky and all that
inline int fastmod_y(int y)
{
return (y & (Chunk::SIZE_Y-1));
}

// These functions can also be static functions in Chunk, because they may be used alot
// Now let's make a wrapping function to determine both the chunk itself and the internal coordinates:

// assuming the coordinates we get in are local to our current grid
// (if they aren't we can still just mod() them to get local coordinates)
Chunk* Chunk::wrap(int& bx, int& by, int& bz)
{
int fx = bx >> 4; // replace 4,3,4 with whatever bitshifts you need
int fy = by >> 3;
int fz = bz >> 4;

// if the position is out of our local grid, we just return null ptr
if (fx < 0 || fx >= Chunks.getXZ() ||
fz < 0 || fz >= Chunks.getXZ() || // note: the total number of chunks with the current settings
fy < 0 || fy >= Chunks.CHUNKS_Y)  // and we are assuming a fixed number of chunks stacked in height
return nullptr;
// directly modifying the coordinates we got in
bx &= Chunk::SIZE_XZ - 1;
by &= Chunk::SIZE_Y  - 1;
bz &= Chunk::SIZE_XZ - 1;
// and returning the chunk as well
return Chunks.getChunkAt(fx, fy, fz);
}

```

### #5130256Scripting languages

Posted by on 10 February 2014 - 05:16 AM

I have an engine under construction, and while I've entertained tcc (because of direct memory compilation & linking, __and__ its C!), it's just not acceptable.. after all you could create a bitcoin miner instead of managing eg. UI elements

So, which alternatives are there out there that you prefer?

I was thinking about JavaScript, because I really liked it when I was forced to do webdev.

I haven't used lua or angelscript much, anything in particular I should know?

The most important thing I suppose is that I explicitly define my own API, and that it has some core functionality to begin with, eg. abs() sin() etc.

It wouldn't be damning if it didn't.

Also multiplat!

Primarily working on linux

### #5129771Starting a new game dev career. A 2D game, where should I begin?

Posted by on 08 February 2014 - 12:03 AM

From github:

https://github.com/LaurentGomila/SFML/wiki/FAQ#wiki-grl-whatis

Good multiplatform support, "object-oriented" SDL, sounds good to me.

You seriously need to take the time and go through g++, makefiles and the advanced OOP topics. You cannot seriously make games if you are going to struggle with the language too.

Of course, you could do all of this with smaller SFML projects. Two birds one stone etc.

### #5124896Switching GLSL shaders for a object?

Posted by on 19 January 2014 - 02:47 PM

Can i use just those two shaders when they are rendered?

Yes.

Say the position is defined as in vec3 in_vertex;

The normals are defined as in vec3 in_normal;

#version 130

uniform mat4 matproj;

uniform mat4 matview;

in vec3 in_vertex;     // these in statements is what makes this a unique shader that works for a specific mesh format

in vec3 in_normal;    // what this means is that the mesh format provides (x, y, z)  (nx, ny, nz) and (r, g, b, a)

in vec4 in_color;

out vec4 out_color;

void main(void)

{

gl_Position = matproj * matview * vec4(in_vertex, 1.0);  // a valid vertex shader MUST set gl_Position (that's the only requirement)

out_color = in_color;

}

A basic shader which transforms a vertex, and passes a color attribute to the fragment shader. Notice how we don't use in_normal, yet I still defined it.

You can make a copy of this shader, and as long as the attributes (in's) are the same, and the shader is valid, you can use it for ANY mesh that has this structure defined.

If the model also provided uvs, then I could not use them, simply because I didn't define them in the shader. It doesn't matter if the model provides 30 attributes, what matters is which of them I use in the shader, and which attributes have been enabled before rendering.

I imagine the answer to your question is yes. Their formats should be similar. What those formats look like is defined by your attrib statements when forming the VAO. The shader doesn't care if the model uses SHORT or FLOAT for (x, y, z) as long as the bindings are correct, and the number of elements are the same.

The binding is towards the string "in_vertex" and the number of elements is 3 as in "vec3" --> in vec3 in_vertex;

Whether or not the model stores (x, y, z) as float or short is not important, because you define that with attrib array pointer, which is tied to an index value.

To a shader these statements are the same:

glVertexAttribPointer(0, 3, GL_SHORT,            GL_FALSE, sizeof(vertex_t), (void*) offsetof(vertex_t, x )); // vertex
glEnableVertexAttribArray(0);
Is the same as:

glVertexAttribPointer(0, 3, GL_FLOAT            GL_FALSE, sizeof(vertex_t), (void*) offsetof(vertex_t, x )); // vertex
glEnableVertexAttribArray(0);

The difference is how the data is treated, but you just defined that. You are making a promise to OpenGL that the data you provided are of a specific type, and should be treated so and so. The shader must know there is an index 0, and that index is typically the position of the vertex (x,y,z) which in my example above would be "in_vertex."

Other than that, you just provide what indexes you want. Enabling and disabling them.

### #5124785Switching GLSL shaders for a object?

Posted by on 19 January 2014 - 12:58 AM

Each model is essentially a mesh which you just render using any command your library gives you. In opengl it's done with the glDraw* commands.

These commands are not tied to any shader you have selected, except you need to have the same mesh structure. (Or the shaders needs to be do with less)

An example:

x, y, z,   nx, ny, nz,    u, v, w

A format with position normals and uvs.

If the mesh provides those things, the VAO has those as attribs set up properly, and finally, the shader needs only those 3 things (or less), then that's really all there is to it.

Another example, same format as before:

A format with position normals and uvs. Except this time the shader only uses the position (x, y, z). This works nicely, because while you HAVE positions, normals and uvs, you can still choose to use less. You may still need to define the attribs in your shader, just not use them.

What this means is that as long as the shader is set up to read your format properly, the shader program can run, and it can do whatever you want it to.

As an example, just copy the shader you are currently using, rename it to copy.glsl, and render using that instead. It will shade the model in exactly the same way as the other shader, except one thing, they ARE different shaders (internally, as well as in name). Now you just need to change the second shader to do something else..

### #5124335OpenGL for 2D

Posted by on 17 January 2014 - 03:30 AM

it's up to you

there aren't that many matrix representations to choose from.

regular ortho from (-x to x, -y to y)

NDC (which means you don't need to specify projection) and goes from (-1 to 1, -1 to 1)

pixel-based ortho (0 to x, 0 to y) where Y goes downwards positively

and various modes of perspective with varying FOV, typically used with 3D, because it looks 3D

what you use it entirely up to you, but it's common to use orthographic projections with 2D

keep in mind you still have a Z axis, just there's no way for you or the player to perceive it, unless you use math-magic

SDL is just easier overall. It provides you with all the multimedia aspects you need, including window, input, sound and other things.

If you use OpenGL barebones, you will need to implement many concepts on your own, such as sprites

You'll also need to provide music & sound (typically as streams & samples)

this is nothing too complicated with todays libraries, and if you already have a good grasp of whatever language you are using, you will be ok

your challenges lie in learning OpenGL (which is inadequately documented, and I know OpenGL well), and implementing concepts for your game

If you are using glm:: you already have much of the barebones OpenGL bits covered. Create orthographic projection with whatever coordinate system you desire

The easiest version probably being mapping pixels 1:1

Implement sprites, create a train (sprites following sprites), and have it follow a path

if you can do that, you can create a game no probs

### #5122989Please check this for me. :)

Posted by on 11 January 2014 - 11:36 PM

-- First, you mention "C++."  What you are programming in there is the beginner "hybrid mix."

So, put everything in a class "just because?" I see people who liberally create c++11 inline templated headers as full fledged implementations. It's not how I program, and I don't judge them either. They certainly know what they're doing, but it's an uncomfortable read for me. I came from many years of programming C. If anything, it has taught me to be practical about my programming. I programmed faster when I didn't use classes, but I also produced more code. I soon after programmed mostly pure C++. Now, I just do whatever I need to do, simply out of acknowledging I should really only produce the code I absolutely need (right now). Whatever floats your boat, right?

I don't think the guy who posted the questions is currently learning classes, though.

It's easier to learn functions by seeing the simplest examples where they are useful, and many here have already provided some.

### #5119112Is using an existing library, actually cheating?

Posted by on 24 December 2013 - 05:18 PM

"Oh, and I have some form of OCD-related perfectionism."

Me too, but I don't think that matters. I'm perfectly OK in using libraries.It's do or die, really. If you try to create everything yourself you're not going to be making any games.

I have been programming for many years now, and it's just recently that I'm trying to create most of the things I need myself, by learning advanced algebra at the same time.

I'm not making anything, and I know it all too well. It's part of my process, but at least I have made many games and many huge projects before. I always relied on everything I could find.

I'm strongly convinced that the best kind of code is the one you know has been proven and is well tested, and that's it. Creating games is a huge amount of work beyond just programming.

Let's look at the things you may need to do for, say, a zelda game:

1) Layered map format AND map editor, the latter being a major source of frustration the first time around - perhaps an external proven editor will work out

2) A ton of art assets in specific formats, because without them you don't have a (visually pleasing) game

3) A vast amount of interactive and _related_ gameplay mechanics

* Such as hooking into a floating "brick" which you can move away from you by, say, boomeranging it

* Lifting throwing and pushing the same thing

* Common enemies that can be scattered throughout the world

* Scripted (unique) boss battles

* Player states: Idle, jumping, running, jumping and running, flying, falling, swimming, diving, drowning, damaged + any other state (typically just blinking sprite), received item, holding sword, sword spin, attack, use item, frozen, electricuted, .... and the list goes on

4) Resource management that simplifies scripting, so that the level designer can design levels effectively (eg. being able to place NPCs WYSIWYG)

5) Realtime palette, so you can reuse assets, if you want

6) Weather and time of day effects, because its 2013 ;)

7) Binding it all together for redistribution among testers, designers

8) Version control for the codebase, levels and scripts

9) Game design that utilizes the present and future power of the game engine

Many of these points are not necessary, of course. But it could be something you have planned for.

The game will never be as good as you originally set out to do, but you may be surprised that it has improved in other areas.

So, I think focus needs to be on what doesn't already exist, which is essentially what is unique to the game you want to create.

If i had the choice between programming a level and drag-and-dropping it, assuming the programming happens in a text-editor, I would choose the drag&drop approach.

Being able to instantly see everything even in a very limited editor can be very healthy for morale. You can weigh the pros and cons, I suppose.

Try to implement Lua scripting, and create some NPC classes that all behave in unique ways, then do the same for items. That's all you need to get your foot in the door. The rest is just lots of work, and lots of rewritten code. You're never going to create your first game all the way from start to finish without having to do some serious thinking and scrapping both ideas, concepts and code.

How you solve all the problems is entirely up to you, and I think it helps you as a coder not to cheat and have everything in the gameplay laid out before you. Ideally you should get to a point where you take any concept and implement that in some way into a game. That concept almost never survives the design and implementation process, simply because things don't always fit in perfectly as it starts out as an unknown and you can't prepare for everything. Eventually you'll get a better sense of what works and what doesn't.

The bottom line is really simple: Ensure you and your teams motivation stays high by using whatever is proven and works. From there you can do whatever you want, because you can't blame the underlying structure. The rest is up to all of you to just start coding, and no amount of planning survives contact with reality.

EDIT: As the man above says, SDL is simple, but it's enough for a 2D game, if you keep things within reason. You mention having many years experience with programming, so I think you can just go ahead and make a small framework that renders sprites and sorts them by (an imaginary) Z-value. Create a camera class that follows the player around. Create Tile class and add some functions you can override with derived classes. If you are into that kind of thing.

### #5118188Shaders (GLSL) in one file? Is it practical?

Posted by on 19 December 2013 - 12:48 PM

It's very convenient. For example:

#define FRAGMENT_PROGRAM

#define VERTEX_PROGRAM

#version 330

#ifdef VERTEX_PROGRAM

layout(location = 0) in vec4 in_vertex;

...

#endif

#ifdef FRAGMENT_PROGRAM

...

#endif

That makes loading the file relatively simple, since you just run it through a function that spits out both vertex and fragment:

One string without the first define, and the second without the other. The rest of the files contents are still present in both files, but the shader compiler will compile only the relevant parts. Take care though if you are compiling shaders during rendering. In that case you will want to pay special attention to the length of the shader code.

The benefit of doing this, is reducing the number of files you need to keep track of, and in the webserver case, the files you need to transfer

The contents in both are related in that the vertex program sends data to the fragment program. The transferred data you use in the fragment shader must come from matching out statements on the vertex program.

I used to separate the files previously, and it was OK. I just got to the point where I had alot of shaders, and it helped abit to reduce number of files.

You do lose the ability to combine common vertex programs with specialized shaders, such as the generic fullscreen quad vertex shader.

### #5118115OpenGL programming

Posted by on 19 December 2013 - 07:59 AM

OpenGL is a standard which can be implemented by just about anyone. Graphics drivers typically have OpenGL implementations installed with them. OpenGL specifies a C implementation, and the driver creators implement that by following the standard.

When you install Windows, it comes with a decades old OpenGL 1.1 dll. If you install graphics drivers from vendors who have modern implementations of OpenGL you can go all the way to OpenGL 4.2.

The most widely supported OpenGL version now is OpenGL 3.x. Some laptops with no GPU support OpenGL 2.x only. Please don't use it. Use 3.x.

As I said, OpenGL is a C-specification, and its a rasterizer. It doesn't require being hardware accelerated, but it sure helps.

To write your own OpenGL backend is very time consuming, but you'll learn alot. If you want to make games, don't do it. If you want to learn, go ahead. It can be frustrating, but very rewarding.

EDIT: I should probably add that a C-library works with C++. C++ can be thought of as an extension of C. C tends to have baggage from ye olde, but is very straightforward, while C++ has more functionality and stricter rules which could enable safer coding, and in some cases could end up with a class-hierarchy soup.

You will want to have classes in game programming, because projects tend to get big, fast. Abstracting away things which can go wrong into safe to use classes help alot. Just don't go overboard. If you find yourself overloading (float) in your vector class, you know you need counselling.

good luck!

### #5117212Implicit conversion errors

Posted by on 15 December 2013 - 07:24 PM

Nothing legal about that, im afraid

However, you can certainly use some of the constructors of vec4:

vec4 vector(float); --> (float, float, float, float)

In your case it would turn out like this:

outdepth = vec4(indepth);

Not sure why you would spend 4 channels saving the same value, though.

I'm seeing you are expecting the value (f, f, f, 1.0)... if HLSL really does this, then they are in the wrong. Bad design decision!

I guess you're just stuck with vec4(vec3(indepth), 1.0f);

Also, admit it: It's not much work.

### #5116872Need some opinions about how a finished game would look like

Posted by on 14 December 2013 - 09:32 AM

Although d3d8 isn't multiplatform, BASS is. If you wanted to, you could try creating multiplatform project next time.

Looking at dependencies, the .exe seems pretty static, which is good. You can share this game with just about anyone without them needing to install anything extra.

The game does all it set out to do. The win sound may be too loud in comparison to the ambience/music.

Overall, not bad. I think you should consider this project done. I know I would.

Good job

### #5116687Questions about mesh rendering performance

Posted by on 13 December 2013 - 08:51 AM

I believe they are still faster, but cannot firmly claim since I'm not using them for a long time.

They don't even exist after GL 3.x

I think most people are still relying on GL_ARB_compatibility.

While true, people who ask for help in these forums should not exit a discussion with the illusion that they are doing the right thing in the longer term.

Some features of OpenGL are too old to be considered safe to use. This includes display lists.

This doesn't mean no one should use them. It's just a reminder. Using 3.x features is always the right choice. It has major penetration right now, and will stay for a long time. Compatibility mode or not. (I personally use compatibility mode, not for any particular reason)

PARTNERS