Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 7 developers from Canada and 18 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 27 Aug 2002
Offline Last Active Today, 10:56 AM

#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.

#5198289 When you realize how dumb a bug is...

Posted by Krohm on 15 December 2014 - 05:20 AM

Reference data does not match data from new code.

Checked again, again, again and again.

Did I forgot an offset?


Reference data comes from a different project. It's basically a for(...) <do stuff> and I'm interested in a certain loop iteration.

In a certain loop iteration. Not in two different loops iterations. Changed iteration to debug to same value. Realized there was no problem to fix. Called it an intense day.

#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.

#5188092 Loading multiple 3D models in the VBO

Posted by Krohm on 20 October 2014 - 01:42 AM

How is loading multiple 3D models in the VBO?
I'm afraid your English is prone to misunderstanding. I assume you're asking about usefulness and performance.


Putting multiple models in the same VBO is debatably useful. If the models feature a different vertex layout, then it will become a debugging hell as debug tools typically consider each VBO as containing a single type of vertices.


Years ago, I used to slap everything in a single VBO. That usage originated from an old OpenGL extension ("NV_VAR") which were fairly slow to switch.

Modern VBOs are much, much faster. When I switched from "all in the same VBO" to the new approach, I observed no performance difference.


As such, optimize your life and time to finish: do whatever comes easier to you, explore the problem, learn and... maybe you won't need to fix anything and there's no punishment for coming back and iterate your code to meet new requirements.