Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Aug 2002
Offline Last Active Yesterday, 01:12 PM

#5014649 Resources on heightmaps?

Posted by Krohm on 27 December 2012 - 03:14 AM

This has been discussed several times. I'll do a quick recap of heightmaps and terrain algorithms.

Terrain algorithms: dead. Just brute force. Caveat: perhaps using pixel-based tracing might make sense.


Heightmaps: they are 2D array of values.

Format to use: everything lossless will fit. I like PNG 16-bit grayscale. A raw dump might be more appropriate in some cases. Multichannel recomposition (value = red + (green << 8) + (blue << 16)) is hard to work with but at least it won't get garbled if some processing program does not support it. Floating-point based formats are to be taken with extra super special care.

How to convert them: they are a bunch of triangles! In the past, several methods have been proposed. In the end, they're not really required unless going for AAA quality, and even in this case, you'll find out many games triangolate trivially.

OpenGL implementation: there are plenty.


You're better with a specific question.

#5014644 Meshes and the rendering api

Posted by Krohm on 27 December 2012 - 02:51 AM

I think you should first seperate the idea of geometry, buffers, and the game objects themselves.


It's worth noticing that while meshes, are purely graphical objects (in the world of pretty demo land) in the real world, they are not.

At a minimum, they might feature a simplified collision hull.

Therefore, I think it's a good idea to actually model the mesh independently from the rendering. Such as having a MeshCreationParams and a Mesh structure, with the former being effectively the model and dealing with persistent representation.

From what I've read a good solution is to send it all in batch jobs to a dedicated rendering class that encapsulates the graphics api, which sounds good but how to structure the vertex data without touching the graphics api is abit unclear to me.

Of course those statements don't make sense by themselves, they take from granted we have some middle API to help us with those "batch jobs".

Personally I suggest you to not think about it too much. Use an explorative approach to better understand your needs and then rewrite.

Nobody, unless highly skilled, can figure out something useful. There are way too many variables to consider, especially when dealing with various hardware configurations. Don't be afraid of throwing away prototypes.

#5009750 A system of Magic/Spell Creation

Posted by Krohm on 12 December 2012 - 02:24 AM

Yet another spell system thread. There have been plenty and most I recall share the same, basic problem: they are too high level to produce any consistent/predictable behavior.
FYI, "spell systems" are already there and are industry standard to a certain degree. They're called scripting languages and they are used to script weapons or spells.
Let not fool ourselves, spells are programs and what we're really doing here is to research a visual scripting language which
  • Is intuitive to user, both in term of use and products
  • Plugs well with the game
  • Allows extensive inspection of internal structures to understand and balance effects.
Let me elaborate on the "high level" problem. Consider the Control rune. It conveys a lot of functionality. Your goal is to have spells which have more "depth" than a slider, but this system really isn't. A control spell will always be a control spell.

From an implementation standpoint, Heal and Drain health are the same thing, except they add a different amount of data. Design top-down is good but to make this work, we have to think it at all levels way down.

Unclear results. What is the product of necromancy, wall, multiple? I have difficulty understanding what configurations are valid. There are no such things as "examples". There must be clear rules.

#5007341 IMGUI

Posted by Krohm on 05 December 2012 - 03:07 AM

c) I don't think you can identify controls throughout a frame. All widgets are independent of eachother. I'm having trouble coming up with reasons why you need to identify a control with IMGUI.

Because you might need to associate a specific state with it. If the state is part of the model, that's no trouble (except the code needs to cater with this possibility). If the state is part of some external setting (such as skinning) the code has no way to deal with this. When scripting enters the picture the need for robust state association becomes a priority (as mis-guessing a control state association might violate some invariant).

Personally, after IMGUI, I looked at cocoa bindings and I found them quite more promising. Unfortunately, the amount of machinery required to make them work is scary.

#5005257 Blender and Directx10 c++

Posted by Krohm on 29 November 2012 - 04:52 AM

I strongly suggest to use Blender export using internal custom properties. Collect those properties and dump them to json.
Then export the geometry as collada and load it up using AssImp. This way, you still get some benefits of collada and full support of your features. Yeah, theorically, Collada alone could do that but looks like AssImp doesn't (sure blender don't export them anyway) so we have to work around that.
The idea of producing my own format for data exchange ... mh, I'd rather not do that.

#5005252 IMGUI

Posted by Krohm on 29 November 2012 - 04:33 AM

To my own surprise, it has been more than two years since I asked something about designing a GUI.
My efforts on IMGUI resulted in a total loss. At the end, I ran out of time and I had to go back to the legacy GUI system.
It appears to me that IMGUI hasn't delivered. Many people would object that IMGUI is just GUI as it has always have been on consoles. That might be the case but a generic system is a different thing from a specific system.
I am very worried about the fact unity is still noted as example two years later. I would expect something more.

My main concern is that IMGUI proponents appear to be selling on

  • IMGUI is easier
  • IMGUI is implicit
  • IMGUI can do everything RMGUI can

It appears to me that those, taken alone, are true statements. But I'm not really sold they are true at the same time.
Take for example "can do everything RMGUI can". No, it cannot. Examples in the thread I've linked. It can do so only if IDs are generated and this is non-trivial. Once you generate IDs, say goodbye to the "implicit" part of the discussion.
And, to be honest, after trying to implement it, even for a barebone system, I'm unsure it's really "easier".
Sure it's not going to plug with the usual workflow without some effort.

Personally, when I first read CEGUI documentation, there was so much emphasis on Lua at the time I had the impression in was a very important requirement. It isn't the case, and I'm now looking at a complete CEGUI integration. So everything about that is now irrelevant to me.

#5004425 Directx9 don't know how to add samplers to pixel shaders

Posted by Krohm on 27 November 2012 - 01:19 AM

I've heard that you need to add a texture to the pixel shader as the back buffer...

No, it does not work like that. PS output is always to backbuffer. It's not a texture. It's a buffer. Set it using SetRenderTarget. If the used resource is a texture, it will be filled for you, no need to copy.

#5003407 How a team for 2D JRPG should be formed

Posted by Krohm on 23 November 2012 - 01:50 AM

Hello HipK, are you doing this in parallel with your college or education? I think this is very good intention but seeing the replies from other OPs, I think you'd be better to state this clearly. If that's the case, I'm afraid I can share some experience.

I've already been into a game project (not jrpg) but it gone after 3 weeks because 2 concept artists,1 modeller and the former (modeller) were basically always inactive.One of them even reaplyed me to a mail after an half year when the project was totally abandoned...

I've been there and I can tell you this is very likely to be the case in... 4 cases out of 5 (because I've given up at the fifth).
What I found is that the persons who didn't give up were the ones I trusted since start. Rather than interviewing them, I've talked to them for weeks. You can explicitly ask them something but mostly you run the checks yourself. Question such as
  • Do this (wo)man show consistent attitude and hobbies? This is an indication of how much they are really interested in those activities.
  • Are they party addicts? There's no problem in having fun. But if the fun must go on starting Thursday night, you can bet productivity is not going to be all that great.
  • How often they explicitly show support/opposition to someone else idea? This is an indication of their teamwork quality. Under NO circumstance take someone who argues on bike shed discussions. They must be able to focus on the goal.
  • Now that FB is around: look at their profile. You'll find out for example that... I'd rather not talk about that.

Anyway,(oh,i'm a programmer) i'm going to complete the engine (Map Editor,Scripted dialogue,GUI system,Script system,game entities and so on..)

That's an hell of work for a single dude. With at least another team mate, you'll end up in extreme pressure. I can tell you because I was there (except I had a programming team mate).
On the pro side, many years ago a member actually manged to do a JRPG. But you'll have to keep it simple. You really want a proof of your skills rather than a "commercial" product.

I really want to start and finish a project because i want something done in my portfolio.

Way to go! I wish you success! Remember: this is your target, not something commercial quality. In the end I had to give the middle finger to everyone and focus on something I can do myself.

#5002276 Best 3D physics engine for accurate collision handling on desktop/laptop comp...

Posted by Krohm on 19 November 2012 - 01:18 AM

  • Isn't this the same thing as 2)?
  • I'm not even sure how this would have to react or what specific behavior you're looking for but I believe PhysX/Havok/Bullet would all resolve those collisions with "accurate enough" precision. I'm inclined to think they would actually resolve the collision in the same timestep as internally the various libraries does not really see stuff colliding but rather satisfy a set of constraints such as "do not encroach any other object". Of course, this is highly casual phenomena in nature and if you're designing something around this specific behaviour, I strongly suggest to desist.
    Seriously, even flipping a coin in reality does not produce consistent behavior. And I bet reality is ran by a fairly good enough physics lib.
  • Bullet has a special conditional continuous collision detection. I'm surprised physX does not have it! Try looking harder.
  • Bullet is open source runs well on most configs I've tested and has an OpenCL solver in the works for anyone having a CL enabled card. Odds are you'll have to enable it manually but that does not look like a big problem.

Basically, I need SUPER reliable collisions.

Then give up interactive-oriented physics libraries.

Something that can't be accomplished with a simple ray casting approach that sends a ray from the last position of the object to the current position (as this object may be potentially large and colliding with small objects via rotation)

No library I looked at implemented this method. If you think anyone serious is doing that, odds are you might not even know what you're talking about.
Sorry if I sound rude but more specifically... what are you trying to accomplish? Providing some context is typically a good thing.

#5002269 Developing a game engine. Round 2.

Posted by Krohm on 19 November 2012 - 12:55 AM

  • Shoud I implement an actor hierarchy and give an object unique ID?
  • If yes, where should the id be assigned. In the level file? Or it should be generated on runtime(this is the case I used before) .
  • I use the ID's to synchronize between the separate threads(or just subsystems. Not all systems have own threads). However almost every system has a copy of the actor(Renderer is keeping a scene node representing the actor, Physics is keeping a rigid body for example).
  • What will happen if I try to implement a multiplayer open world game and I need to load the the object(actors) continuously over time?

  • In practice, I've found this is convenient but I guess there's no real "requirement" in the strictest sense. Keep in mind your internal systems shall probably not use this id, but rather interface to the structure directly.
  • You'll find out you'll need serialization ids and runtime ids.
  • So much for your statement about good practice. I'm afraid there's plenty of potential for error here. The easiest thing to point out is that putting your scene node directly in the renderer is probably not a good idea (separation of concerns, move this functionality to an external "driver" class). Using threads already? Uhm, I suggest to rethink your design.
  • There's no "if". Don't write an engine. Write a game. That said, your game will have requirements. Is this scenario a requirement or not? For personal experience I can tell you that overengineering will get you nowhere in 99% of the cases.

#5001162 Purpose of std::function

Posted by Krohm on 15 November 2012 - 03:15 AM

I think it's worth noticing std::function is correctly mapped even when capture lists are used with lambdas.
Function pointers cannot as far as I recall , and sure interfaces cannot.
So they're really the only "complete" way to deal with lambdas, a thing which I consider to be a bit ugly, but that's it.

#4997890 What is important in a game engine?

Posted by Krohm on 06 November 2012 - 12:20 AM

Just to let you know, I don't think your survey is well thought-out.

Built in editor
The game engine has a built in editor in which you can build levels visually.

Scale: from "trivial" to "crucial".
No idea what "trivial" is supposed to mean in this context (i take for granted it means "irrelevant").

But the really scary thing is that you name "internal editor" over and over.
There has been a time in which having your own editor was considered cool.
Those times are long gone in my opinion.
Personally, I now think providing dedicated level editors are a sign of bad planning.

#4996611 What Sorts of Algorithms and Data Structures are Useful to Game Programmers?

Posted by Krohm on 02 November 2012 - 11:51 AM

Thank you for pointing this out. I believe it is an important difference.
Not to be on the defensive but I still haven't had the chance to experience what you picture.

#4996451 Sending lots of data to the GPU?

Posted by Krohm on 02 November 2012 - 01:25 AM

I was thinking a way around this would be to create an image at run time where each pixel represents the XYZ and intensity of the light as RGBA and send that instead to the shader. That way I could theoretically have a thousand lights with no problems.

I had implemented this back in... 2006 I think, on an entry-level GeForce6.
Main problem with that kind of hardware is they cannot loop arbitrarily. They can loop 255 times at best, but even when fitting the HW resources, the shader might eventually time out and abort. Hopefully this is gone now. If memory serves, it was possible to process about... perhaps 50 lights per pass?
Performance was interactive, but far from viable.

Real problem (which holds even now) is float textures take quite a lot of bandwidth and float texture lookup is often slower than int lookup.

#4996449 Time to write rendering engine from scratch

Posted by Krohm on 02 November 2012 - 01:18 AM

I'd be extremely careful as the goal is not clearly defined. I use AssImp for the loading yet I'd find hard to take less than 5 working days. But perhaps my definition of "without fancy shaders" is different from yours.