Jump to content

  • Log In with Google      Sign In   
  • Create Account

Kwizatz

Member Since 07 Apr 2000
Offline Last Active Yesterday, 10:02 PM

Posts I've Made

In Topic: Wedding Celebration!, with free 3d envionment pack for all and discount o...

21 May 2014 - 04:11 PM

Congratulations! and Thanks! biggrin.png


In Topic: Implementing an Entity Component System in C++

27 February 2014 - 04:03 PM

I am sort of late to this discussion but I am looking on how to implement the pattern myself,

 

Ok thanks for your answers.

 

I have another trouble:

  • My game has maps
  • Maps are made of cells
  • Cells have a position, an ID and a texture.

What should be the components, what should be the entities?

 

I'm pretty sure Map should be an entity, but then:

  • Cell can't be an entity (otherwise I can't use it in my Map entity)
  • Cell can't be a component since it uses other components (Position, ID and Texture).

 

And the same problem goes for a lot of things. Can one use component in other components or did I get it all wrong?

 

From what I've gathered I would say neither of those are entities, they all should be part of a map resource, referenced by a map component that is updated by a map system.

 

To elaborate, your map may be a XML document with cell or tile elements themselves with position (relative to the origin), id and texture (itself a reference to an image, shader and/or material) attributes.

You write some code to convert the XML into a runtime resource object, which is then referenced by a map component, the component is the "instantiation" of your resource, and it will then contain information specific for that instance of the resource, for example position if your map may coexist with multiple maps snapped together.

 

Later on, in your game loop you may have a map system which updates any variables in your map component, and a rendering system may render it later, or a collision system may query the component which itself would query the resource for collision information, etc.


In Topic: Best way to get 2D overlays or images on screen (for a GUI).

06 June 2013 - 07:05 AM

I see, immediate mode, there is no reason why my GUI won't work with that, but since is no longer on core profile, I decided to drop it. but you're right, the amount of vertex calls for a single quad are too few in comparison to a full mesh that immediate mode shouldn't have that much of an impact in this situation.

 

In fact you can render your whole gui as 3d mesh (consisting of multilayered quads in front of a orthogonal camera). This way you could utilize some interesting effects, e.g. dynamic lighting of the gui, where the cursor is the light source, or automatic highlighting/bloom outlines of selected elements, gui shadows etc. This is not for pure functional guis, but it is really nice to pimp your gui visuals smile.png

 

I hadn't though much about that, It is nice, and you gave me a reason to expose shaders to the user, its all pimping of the UI as you said though, what I meant was that you never see any shaders for the basic operations, for example doing the bulk of the drawing on the fragment shader rather than just effects, but I guess its not really practical, and the way to do it is still the same as it was before the dynamic shader pipeline.

 

Thanks for your help! :)


In Topic: Best way to get 2D overlays or images on screen (for a GUI).

05 June 2013 - 09:07 AM

immediate OGL calls? what exactly do you mean? did you mean as I said before render lines with GL_LINES, rects with GL_QUADS, on DrawArrays/DrawElements?

 

I did that once, but it was not consistent, depending on the card nvidia/ati/intel, a line would end a pixel short or a pixel too long, an outline rect would not exactly match a filled rect, etc, even with the 0.375f pixel offset trick, I wouldn't get pixel perfect matches and would have to compensate one way or another.

 

I am not seeing any issues right now with my approach either, I am not really looking for alternatives right now, but its kind of something you don't see talked about too much, I've seen all kinds of shaders for example, but not one specific to GUI rendering, so I was just wondering if there was some sort of defacto way to do it I didn't knew about.


In Topic: Best way to get 2D overlays or images on screen (for a GUI).

04 June 2013 - 07:04 PM

Well, I do support alpha blending, in fact I have a software implementation in the library to blend at the client buffer, I can't recall if this was one of the reasons to drop it.

 

I do think one of the main reasons for the drop is that with glDrawPixels I have to make the call each single frame, even if no widget changes are recorded, with a texture, if no changes are recorded, then no changes to the texture are required, no call to glTexSubImage and you can just render the overlay quad with the same texture as it was on the previous frame.


PARTNERS