Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Nov 2010
Offline Last Active Apr 21 2016 03:24 PM

#5284936 point inside convex quad, using only integers?

Posted by on 03 April 2016 - 05:41 PM

So here's what I managed to do, I get the sign of the determinant for each edge and make sure all the edges have the same sign if they do then the point is in the quad. Seems to work ok so far.

bool pointInBox(quad q, point p)
	point* v = q.vertices;
	bool d0 = ((int32_t)(v[1].x - v[0].x) * (int32_t)(p.y - v[0].y)) > ((int32_t)(v[1].y - v[0].y) * (int32_t)(p.x - v[0].x));
	bool d1 = ((int32_t)(v[2].x - v[1].x) * (int32_t)(p.y - v[1].y)) > ((int32_t)(v[2].y - v[1].y) * (int32_t)(p.x - v[1].x));
	bool d2 = ((int32_t)(v[3].x - v[2].x) * (int32_t)(p.y - v[2].y)) > ((int32_t)(v[3].y - v[2].y) * (int32_t)(p.x - v[2].x));
	bool d3 = ((int32_t)(v[0].x - v[3].x) * (int32_t)(p.y - v[3].y)) > ((int32_t)(v[0].y - v[3].y) * (int32_t)(p.x - v[3].x));

	return d0 == d1 &&  d1 == d2 && d2 == d3;

#5194305 Problem with perspective in opengl

Posted by on 23 November 2014 - 01:44 PM

This doesn't look like a perspective problem, it looks like you're culling the wrong faces. Have you set glCullFace(GL_BACK)? If not that may fix your problem. You may also need to set glFrontFace(GL_CCW).

#5180800 Optimization philosophy and what to do when performance doesn't cut it?

Posted by on 16 September 2014 - 01:59 PM

So I often have a dilemma when coding where I have to make things run faster but the project isn't finished. As programmers we are often told to code first and then optimize later, this is related to the famous saying "premature optimization is the root of all evil". However adhering by this philosophy is not necessarily always practical, this would require a costly review of a huge codebase, a much more economical approach would be to optimize "as you go" or basically making things as efficient as possible before moving on. I always have trouble figuring out which method is the most practical, when I'm faced with the fact that my project while not finished it simply does not meet performance requirements for the given hardware. What approach should I take to speeding it up?

#5076916 Rendering a GUI efficiently

Posted by on 11 July 2013 - 11:12 AM

Gwen apparently supports caching (take a look at the ICacheToTexture interface in the base renderer). Unfortunately I haven't tried to implement it yet so I can't say anything about its usefulness.


Hmm thats very interesting. Depending on how it works that may be ideal. Unfortunately none of the samples seem to use it.

#5076670 Sending single float to shader

Posted by on 10 July 2013 - 12:24 PM

Just a tip, if you call glGetUniformLocation every time you update your variable you run the risk of stalling your pipeline which heavily degrades performance.


It's better to get the location once after linking your shader and then storing that location to be used everytime you update or use a static variable to cache that data like so:

void updateTimeOfDay()
	static bool haveLoc;
	static GLuint loc;

		loc = glGetUniformLocation(shaderOne.getShaderIndex(), "TimeOfDay");
		haveLoc = true;

	glUniform1f(loc, timeOfDay);

#5076503 Forcing early Z, which extension to use?

Posted by on 09 July 2013 - 09:25 PM


Does not load like image_load_store has anything to do with early depth test. So no, you should use the conservative depth.


Yeah I know that the purpose of the extension is not specifically for early z tests but it can be used to enable them as I read here:




What I was hoping was that cards that didn't support GL_ARB_conservative_depth might support GL_ARB_shader_image_load_store to be used as a fallback or vice versa.

#5075086 Yet another Deferred Shading / Anti-aliasing discussion...

Posted by on 03 July 2013 - 01:28 PM

I use FXAA but I don't use whats built in with the graphics driver. What you can do for better results is download the FXAA 3.9 shader (used to be on Timothy Lottes blog but I can't find it anymore), it has some conditional compilation setup in it which you can use to tweak the settings. This method is far better then using the graphics driver because you can apply it at a more optimal spot in your rendering pipeline (preventing some unwanted blur). Amazingly the same shader works for both hlsl and glsl and it will work on Intel and AMD gpus as well as consoles. It is important to note that you must have some method to generate luminosity before running the fxaa shader (this is pretty trivial).

#5046387 What do i do now?i

Posted by on 24 March 2013 - 07:13 PM

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.




int* p = new int [37];

delete [] p;


here's a tutorial on how to use them.




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.

#5025572 How long would it take to...

Posted by on 25 January 2013 - 04:30 PM

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.

#5025087 Basic text editor?

Posted by on 24 January 2013 - 07:09 AM


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

#5022397 Losing interest in game development...

Posted by on 16 January 2013 - 07:17 PM

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.

#5020851 Is it such possible to create fast games without using C/C++ ?

Posted by on 12 January 2013 - 03:27 PM

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.

#5020827 In-Game Console

Posted by on 12 January 2013 - 02:17 PM

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.

#5018063 "roll" in a raycaster

Posted by on 05 January 2013 - 10:41 PM

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?

#5014999 Is OpenCL what I need?

Posted by on 28 December 2012 - 12:25 AM

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.