Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Juliean

Member Since 29 Jun 2010
Online Last Active Today, 07:43 AM

Posts I've Made

In Topic: Is it worth to use index buffers?

Yesterday, 05:01 PM


See https://www.khronos.org/opengles/sdk/docs/man/xhtml/glDrawArrays.xml for example. It says the index type needs to be unsigned byte or unsigned short - it doesn't look like the indices parameter is optional. And actually the documentation for draw elements that you linked states the number of indices to draw, not vertices..

 

Uh, did you post the wrong link or did you mix something up? What you mean is glDrawElements, which, yes, needs indices. glDrawArrays like you (and MJP) have posted is the non-indexed rendering variant. If you look at the documentation you will see that dlDrawArrays doesn't have the "index type" parameter you describe, its in glDrawElements ;)


In Topic: Is it worth to use index buffers?

Yesterday, 08:29 AM


Is there any performance advantage in using index buffers?

 

Yes, in some cases.

 

The first important thing to remember in most common cases is: Memory consumption reduction = performance improvement. This is due to the increasing gap between memory and processor speed, with processors getting faster at a rate much higher than memory (certainly true for CPUs and GPUs are likely not different).

 

Even outside from that, if you can eliminate "duplicate" shared vertices with an index buffer, the post-transform cache is more likely to being able to reuse the same vertices, which means that you can save many vertex shader executions/vertex processing. This goes along with common optimization techniques to make use of the post-transform cache, you might want to look into that.

 

There are exceptions, of course, you will not just have net gain by using index buffer. A 3D cube with lighting won't gain anything from an indexbuffer, since though the corner vertices share the same position they have different normals per side. But I belive that for general models, index buffers are almost always the right choice (you might want to use 16 bit indices if possible to save even more memory/performance).


In Topic: Resolution scaling and World / Screen Coords

27 July 2015 - 08:19 AM


What is the best / proper way to consider the bigger (or smaller) resolution? How should I be doing this?

 

If you are OK with a blurry scaled image, you can just set the backbuffer resolution of your application to 640x480, which will fit it to the screen automatically (you don't show your usesers any resolution settings when the logical resolution is fixed anyways). Alternatively, you can always just render your scene to an offscreen texture, and copy it to the backbuffer in a final pass. The main advantage of having the backbuffer in the logical resolution of your game is that screenshots & screen recordings will already have the correct size.

 

I'd also give the option of eigther a windowed mode where your window size is equal to the logical resolution of the game, and alternatively also a mode for fullscreen where you render the game in real resolution in the center of the screen with nothing around it.


In Topic: Design pattern for linking UI events to editor code?

27 July 2015 - 06:55 AM


But then wouldn't you end up with a large amount of command classes?

 

Depends. Generally yes, but you are not going to avoid that alltogether. Its way better to have a lot of classes then a giant if statements because 1) the classes are independant of each other and thus 2) all the classes can be organized and managed better. You still have to realize that if you have different parameters that you want to couple to your UI, you will at least have to write SOME code for letting your application know that this parameter exists and what to do with it.

 

But if you want to reduce the amount of code for parameters, here is what you can do. Instead of writing a different class for each parameter, you use a template class (for the type) and store a function pointer:

template<typename Type, typename Object>
class ParameterCommand : public ICommand
{
	using FunctionPointer = void ()(Type);
public:
	ParameterCommand(Type value, Object& targetObject, FunctionPointer targetFunction),
		pTargetObject(&targetObject), targetFunction(targetFunction)
	{
	}
	
private:
	
	Type value;
	TargetObject* pTargetObject;

	FunctionPointer targetFunction;
	
}

And then you can just do:

ParameterCommand<float, Brush> radiusCommand(5.0, brush, &Brush::SetRadius);

This is just an example and might not even perfectly fit your use-case, but you get the idea. Command pattern, unlike your nested if-list, allows you to use all the class/template magic of C++ to reduce the amount of things you have to write. But you have to write some code for each parameter... wait, you are using C++, right? There might be even easier tools in other languages based on reflection, but command pattern is still a viable top-level solution which allows you to solve the specific subsets of your problem the way that your language makes it the easiest.

 

On an unrelated note, was the brush-example an artifical example or do you really plan on making those undoable too? I'd advice against it, I hate nothing more than wanting to undo a series of changes I made, and having the application undo all my brush/tool changes in the mix. Might be personal opinion but not many applications even do that which I've seen.


In Topic: Design pattern for linking UI events to editor code?

27 July 2015 - 05:54 AM

Command pattern might be what you are looking for, it separates all actions into different classes and supports undo-commands (though you still have to implement the undo-operation yourself, unless you store the whole games state and copy/store that for every undo command...).


PARTNERS