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!


Member Since 27 Aug 2002
Offline Last Active Today, 01:02 PM

#5213091 Component-based architecture - entity and component storage

Posted by Krohm on Today, 09:06 AM

No idea what exactly is going on there but what you have done isn't a component thing to me.

Just because you can put arbitrary "component" object handles inside an array, which allows you to build "entities" does not mean you are component based.

The above is not component based either, it's switching behaviors exactly like a monolithic entity would do. I'll agree that has some very slight flexibility added.


No idea what a "physics" component is supposed to be either. I assume it is a rigid body representation.


Here is ECS, condensed to the its core.


There are no entities. There are only the components.

See Fig-2.gif



The message "between the lines" and showcased in the above diagram is: the execution/update of components is independent from other types and can be - in theory - completely asynchronous. I dare everyone in writing a fully async, fully ECS-only system but that's for another time.


So, what does that mean? It means basically the opposite of this:

One idea that came to mind was having a vector of pointers for each type of component and passing the corresponding vector to the corresponding system.

You should really have the components exist in the systems only and link to them on need rather than keep them floating around and putting them back in on need. Seriously, where do you think rigid bodies are going to go each frame? In the physics library. Where do you think the models will go if not in the rendering subsystem? No point really in taking them out: you take out reference / pointers to them and leave them live in their own land using a base class or a proxy of some sort. Internally the subsystem accesses everything it needs while externally you don't.

#5211676 Problems with partial OpenCL kernel dispatch

Posted by Krohm on 19 February 2015 - 08:00 AM

Wait, you can specify read_only on globals? It was my understanding it was for image objects only.

Parameter 7 to clEnqueueNDRangeKernel is currently (int)ArraySize(waitOn). Leaving aside it is a cl_uint, the pointed events must complete and I have no idea what is going on with them.


Considering png typically goes with integers I would also check out the way you mangle the resulting data.


Ultimately, some drivers have watchdogs and will kill dispatches if they take too much time to run. Considering the inner loop seems to be doing nothing (the value is trashed right away) I think that's fairly indicative. Am I missing some side effect?

#5211671 terrain editor resolution based on height

Posted by Krohm on 19 February 2015 - 07:39 AM

i want to have the ability to adjust the resolution on the area where the terrain are raised/lowered,

Interesting idea in theory. In practice this would require a perfectly regular structure such as the point grid to become irregular. I guess you could do some sort of quadtree to provide more resolution. I remember a paper about quadtree-accelerated parallax occlusion mapping which could be adapted to your uses. It's not very complicated but I have doubts it's really worth it. Last time I checked the Unreal developer network it looked like not even Unreal (3) had support for that so I have doubts about its usefulness.


how do i handle or store the height data? right now the height data are just stored in a 2x2 array and each array is equivalent to one vertex in terrain grid

That's fairly peculiar. Why are you doing that? I would just use a 16-bit grayscale map. Or perhaps RGBA32 for super extra precision but I don't see much of a point in thinking at this as a bidimensional sample of sort. Please elaborate, I'm curious.


I'm pretty sure what you're looking for can be done using quadtree-s.

#5210219 Moving capsule and ball intersection?

Posted by Krohm on 12 February 2015 - 02:39 AM

Considering your last reply, I'd strongly suggest use of a proper physics library.

#5208872 Next-Gen OpenGL To Be Shown Off Next Month

Posted by Krohm on 05 February 2015 - 07:44 AM

I'm not sure this is good news. Considering ARB Khronos large history of success with GL I cannot avoid thinking they'll do something incredibly dumb (such as the nonsensical fences added recently) for the good of marketing.

#5207395 Is there a way to draw super precise lines?

Posted by Krohm on 29 January 2015 - 04:49 AM

I honestly don't know how anyone could think "hardware" lines to be usable. Even assuming they get drawn "where expected" they still don't render "as expected" (they don't interact with zooming properly).


A relatively old NVidia article on filtered lines.


I also want to quote for emphasis:

If you want thicker/softer lines, the foolproof solution is to render a quad that bounds every pixel-center that could possibly need shading, and then in the pixel shader, derive an opacity/alpha value from that pixel's distance to the mathematical line.
I'd go that route myself... even though I've often been confronted with endpoint rendering, mitering and other issues in the past. It would probably be possible to do all this in a set of shaders nowadays and it would sure provide enough quality for 99% of uses in games.

#5207385 Standard structure of a large scale game

Posted by Krohm on 29 January 2015 - 04:10 AM

Try considering games such as Quake 1. You will see they were considerably more homogeneous in mechanics.


Special cases in code are... I wouldn't say they are canon, but they happen and sometimes they save the day. I recall of someone admitting they shipped a game with code such as:

if(levelIndex == 5) {
    entity[12].position.y += 1.0f; // because it doesn't get placed correctly for some reason and we really need to ship!

Of course it is bad practice.


What changed from old games to new games? They become more data-oriented and, as they grown more complicated they embraced scripting.


While my "full scale" game has been in long-term cryo-stasis for a while, I still think its design was really well tought-out. It had no gamestates at all. Everything went through something similar to components and the engine knew nothing about the relationships between those components. Those were provided by gameplay-specific code by scripting.



Now, I'm not suggesting you go scripting right away. It involves complicated things. Data oriented design could still get you far.


Example: we have a FPS with hit-spacebar to action mechanic.

We enumerate the "actions" required. Doors open. Buttons get pushed. Pinballs gets played.

When loading up the data, we find an entity using action[2]. We create a PinballAction object and attach it to the entity.

PinballAction will be very complicated (push current keybinding, set new keys, set new camera parameters, activate the complicated pinball simulation with the newly bound keys... ).

That still requires a switch to instance the correct class, but that switch is no more in the "live" parts but rather in the loading paths (which are hopefully simpler).


If you go scripting, you save that switch as well. Of course, if your actions are simple going scripting will likely be not worth it.

#5204464 Multiple Lights on game map with forward rendering

Posted by Krohm on 15 January 2015 - 07:22 AM

NB: all the game I've seen showed like ~32 number of lights. But I'm not sure if it's "hardcoded" to their engine. (I can't imagine looping thru 32 light properties in the shader just to compute 1 pixel's color)
Well, I did that as an experiment years ago on a GeForce 6600 GT, 128bit GDDR3. It did work (with quite fine parallax occlusion mapping) albeit not smooth enough to be used in production.


I would expect modern mobile to match that performance level at least on some silicon but since a lot of devices have hi-dpi screens I cannot really promise anything.


If you are sure you always have a high light count, consider deferred.


TL;DR: it is possible and sometimes viable to iterate them. Whatever it is in your case it's another matter. 




If only I could store light properties in a texture and read em back in the fragment shader, that'd be great.

Wouldn't this be the same as a lightmap (or more like deferred shading)?


Absolutely not. Deferred is (sort of) splatting your lights on the (not quite) "finished" scene.

What he plans to do here is to use texture as an array (as a side note, this is what I did years ago).

It is doable... but be careful with instruction counts. Your shader might get killed after a while. This will be probably both hardware and driver-dependent. Proceed with caution!

#5204463 Did I do this vertical parallax scrolling correctly?

Posted by Krohm on 15 January 2015 - 07:04 AM

The second image makes me think the nearest layer of rocks must be really close to the camera. If that's the idea, then it's success!

#5201955 a better fix your timestep?

Posted by Krohm on 05 January 2015 - 09:04 AM

I keep asking myself: is this really necessary?

A physics library will fix its time step by itself. Another problem solved.

#5199519 Tile Map Editor - Individual Tile editing

Posted by Krohm on 22 December 2014 - 08:21 AM

The tiles look unique in this screen, yes.

Try to compare across various screens. I think the brown/white bricklike decoration is perhaps the easiest repetition to spot.


In a tile-based game I prototyped about 1 year ago, I had "tile decorations" on top of tiles. They were basically mini-tiles themselves. Each cell had a tile and a list of decorations to be applied.

#5198933 Serializing individual entities

Posted by Krohm on 18 December 2014 - 07:42 AM

Yes, you've talked about prefabs previously. What I really mean "between the lines" is that just doing new SpecialEntity() in some way might likely end up being just as fast as the whole de-serialization thing. Of course in this case we're no more talking about a generic de-serialization but a more specific kind of spawning. You can see this has plenty of advantages for your mental sanity.

#5198280 Serializing individual entities

Posted by Krohm on 15 December 2014 - 04:50 AM

That's an interesting problem I faced some time ago.


Mind that system was fairly involved. It was built around flexibility so pretty much everything could have arbitrary scripts attached. My plan was to re-use the garbage collector machinery to isolate and entity data set and serialize it (I know I can serialize full heaps and restore correctly).


However, when it comes to partial serializations, there were so many other difficulties I couldn't solve such as handling shared data. In general I wasn't sure of validity of this operation so the thing never made it.


Can you describe your use-case in gameplay terms and how it relates to the system envisioned here? Are there any special properties you can exploit to cut corners?

#5196191 C++: Easiest way to implement an in-game Time/Date system?...

Posted by Krohm on 04 December 2014 - 02:07 AM

...  maybe a real-life second is an in-game minute or some such, and time acceleration allows it to progress faster...
Is it just me or posts here are assuming the in-game time  will increase at a more or less constant rate?


If you plan to run the simulation for a lot of time with "time scale" changes, I suggest against using a single reference point in time. In the past I've had some nasty things with accumulation errors and I cannot be completely sure the new frameworks solved them. Keep around a list of "time speed" changes and reset your time reference to last time multiplier change.

#5190857 Tower Defense game - How to manage towers ?

Posted by Krohm on 03 November 2014 - 01:02 AM

Two replies on implementation but ... hey, looks like nothing on the game design yet (I see game design as tag)!


Be warned: those numbers are very hard to tune. 


In a tower defense game "with a twist" I was working on about 10 months ago I had a similar design: there were 4(+1) towers, each with three "incremental" upgrades and a final "specialization" upgrade.


Everything you do must have a specific role. While some overlap between roles might be beneficial, it should be an exception.


Inherited classes are to be used only for logic. Whatever can be made by simple data should be simple data. Cost, range, ROF and dmg does not justify use of derived classes. Logic by contrast does: consider the difference between a "point damage" tower and a "area damage" tower.


In the latter case you should prefer enemy clusters to easy choices. In the former, you might want to optimize to... finish off enemies? Most games seem to just distribute the damage by selecting the nearest.


Try to make an "horizontal" prototype before getting to the upgrades. I found out the amount of playtesting required to tune the exact values is fairly involved.


As a side note, I'm thinking about:

  • Cutting the number of levels to 1/3
  • Removing the whole upgrading system completely
  • Simplifying the buffing system

In practice, I want to make a simpler iteration first. It is a viable product anyway.