ic0de

I have considered Lua because of it's use as a scripting language but i want to write games without the weird pointers and malloc/free syntax of c++ and the weird indentation and lack of ; in python. Which seems to lead to Java or C#, but i don't want to do either because one is tied to microsoft and the other isn't known for speed.

 

C++ doesn't require you to use malloc/free at all. That's all just inherited from C. In C++ you can use new/delete.

 

Example:

 

int* p = new int [37];

delete [] p;

 

here's a tutorial on how to use them.

 

http://www.cplusplus.com/doc/tutorial/dynamic/

 

I suggest you stick with C++. It gives the programmer the most freedom and there is a vast amount of support and libraries for it.

That said, write games, not engines is required reading. A "3D engine" should probably never be your ultimate goal, and it certainly shouldn't be your first goal.

This article seems to have become a bit of a thought terminating cleche around here. I don't think people shouldn't make engines but they should obviously be developed concurrently with a game. I don't think this article should be used to smack people in the face who want to write an engine and I don't think it should be put on any kind of game development pedestal.

http://notepad-plus-plus.org/

I use Notepad++ it's meant for coding but it's not an IDE and works great for what you're talking about too.

I have an artist (which hopefully wont bail)

Ah yes one of my biggest problems.

 

When I get bored I write DOS games. They may seem like a horrible waste of time being so out of date and all that. However when you write one of them you learn a lot about the hardware you're using and there great fun. You don't have to worry about your code getting to complex because a really complicated program wont run on most dos machines. They are usually quick and almost every line is important and you learn a ton about optimization. So next time you feel like this I would get started on one of those and like me you will wish modern programming was like this.

Case in point - MineCraft (java)

 

Minecraft isn't exactly "fast", In Minecraft I get 30-40 fps in most other games I get 60-75, In my game Engine I get 110-130 fps its written in C/C++ and looks a lot better than Minecraft. It all depends how fast you want to go. To write really really fast games you don't necessarily need C++ but you do need a compiled (or assembled) language. That said Minecraft is still fast enough to play and be amazingly fun (it used to have terrible performance back in alpha/beta) and alot of games written in other languages are fast enough. So unless you want your game to run really really fast you could use java or python or something.

Rather than outputing to an intermediate file, why not add the messages to a std::vector?
Then just display the last 10 lines or so or delete the first one until the length is less than 10 messages.

Also, rather than using Windows GUI components to display the messages, perhaps just make the messages draw to the screen as basic bitmap fonts or something. Have a basic boolean to toggle when you press the '`' key to specify if to draw the console or not every game loop.

 

In my engine I do something similar to this, I have a console class which stores its most recent lines internally in an std::vector and also writes that information to a file. When I use my console::outf() function the line is written to a log and added to an std::vector and the console is then drawn from the std::vector. As for drawing my console it is simply another GUI element.

Well I doubt a game like comanche uses 2d marching. to obtain pitch yaw and roll you must pass 3D rays through a view camera matrix. the original rays always point towards Z and then the view camera matrix represents the helicopter orientation and position as well if it is 4x4.

 

I wouldn't be suprised if comanche did use 2d rays. I've achieved amazing results with it, I only need to cast as many rays as there are columns of pixels. I'm not gonna change the algorithm completely just so that I can roll the camera. If absolutely necessary I'll just rotate the final image. Anyway here's a screenshot of my raycaster (using a map from comanche) just to show how viable the approach is:

 

anyways does anyone know how to do this in a 2.5D raycaster like wolfenstein?

OpenCL is certainly an option, but why not just use graphics shaders? OpenCL most likely won't give you access to hardware filtering, whereas a graphics shader will. OpenCL is more general purpose and can run on any kind of parallel hardware (multiple cores on a CPU, or CUDA cores on an nvidia card for example), but since you're working with a graphics algorithm anyway, you might as well use something like GLSL or HLSL.

The problem with GLSL/HLSL is that they are deeply integrated into the OpenGL/D3D pipeline. A shader operates on a single pixel but my algorithm draws columns at a time. Ideally I would be using a shader that instead of outputting a one pixel can write pixels wherever it chooses. In short if I were to use shaders to get the same effect I would need exponentially more rays. This is a 2d raycaster like wolfenstein 3d or doom and almost exactly like comanche its not a good fit for the shading pipeline.

Hi, I have a doubt about optimization. 
Until now I dont care about load more than one time a image. So, for example, if I had two classes that need the same image I load two times instead of load one and share two pointers to the image. 
But now I need to increase the speed of my games, so I have a cuestion: What is the relation between memory and fps? I can get more Fps wasting less memory, or it is only usefull when I have a limited memory space like in a mobile phone?
 
Thanks in advance for the help! 

Often it works in the reverse, you can drastically increase you fps sometimes when you increase you memory usage. For example it is faster to store vertex normals in memory rather then generating them each frame. One way to optimize is to find a process that is repeated continuously and store the result so you only have to do it once. Or sometimes a data structure will have extra data in it that will increase memory usage but it may be faster to traverse therefore increasing fps. In the example you gave the performance should be almost identical except at load time in which case loading one image is obviously faster.

Or apparently learn the poorly documented Assimp API?

Really? poorly documented? I found their documentation very useful. All you have to do is load the data using a single call to assimp and then you have a fairly transparent structure that holds all your data. Like so:

Assimp::Importer importer;
const aiScene* scene = importer.ReadFile("file.obj", flags);

Then you can grab vertex positions from that same structure like so:

xpos = scene->mMeshes[0]->mVertices[i].x;
ypos = scene->mMeshes[0]->mVertices[i].y;
zpos = scene->mMeshes[0]->mVertices[i].z;

Correct me if I'm wrong, but isn't it hundreds of times faster to do raytracing operations through the GPU? I haven't gone that low level yet with graphics stuff, but from other stuff I've seen that utilizes GPU, it seems like it'd be the optimal choice.

This is true however even GPU raytraycing is too slow for realtime. I have seen raytracers that can run on the gpu fast enough for games but to get it to run this fast its nerfed to a point where you can easily get better looking graphics using conventional rendering.

Just to be clear, the texture_location, normal_texture_location and height_texture_loc are the locations of 'sampler2D' uniforms, right?

thats it exactly

Thanks. So when I do that, how do I access each individual texture from a GLSL fragment shader?

you will have two uniform sampler2Ds in your fragment program and you will access each with the stander texture2D function the only difference is that you will have two uniforms instead of one. You will send textures to your shader like so:

//Sample code used for normal mapping
glActiveTexture(GL_TEXTURE0);
glUniform1i(texture_location, 0);
glBindTexture(GL_TEXTURE_2D, dTex);


glActiveTexture(GL_TEXTURE1);
glUniform1i(normal_texture_location, 1);
glBindTexture(GL_TEXTURE_2D, dNorm);

glActiveTexture(GL_TEXTURE2);
glUniform1i(height_texture_loc, 2);
glBindTexture(GL_TEXTURE_2D, dHeight);

and use them like so

//simple multiplicative blending example
varying vec2 texCoord;

uniform sampler2D texture1;
uniform sampler2D texture2;
uniform sampler2D texture3;

void main()
{
vec4 sample1 = texture2D(texture1, texCoord);
vec4 sample2 = texture2D(texture2, texCoord);
vec4 sample3 = texture2D(texture3, texCoord);

gl_FragColor = sample1 * sample2 * sample3;
}

Why are you using GL_POLYGON? you seem to be using just quads replacing GL_POLYGON with GL_QUADS should be faster. Also get rid of those extra glbegin/glend's in between each face.

I use SDL I can write into the audio buffer and generate tones. Probably not worth to move your game into SDL unless your game is already using SDL for other stuff.