Jump to content

  • Log In with Google      Sign In   
  • Create Account

MaxDZ8

Member Since 27 Aug 2002
Online Last Active Today, 04:13 AM

#5098418 Maps or level editors

Posted by MaxDZ8 on 03 October 2013 - 12:20 AM

how would they add multiple levels or maps?
They don't really add "the maps" to the game. Rather, they give the game the ability to load a map at time. They then have somewhere a small script telling which level is first, and each level has annotations of other levels to follow. So in the C++ code itself probably does not even know about the levels. The scripts might know about the first or for some simple games, they could be whole level lists.

Would they have to input everything manually?
In the C++ code you mean?

This is referred as hardcoding and it's well known to be a source of problems. It is only adequate for extremely small datasets. achild above suggests "pacman" to be simple enough to go with manual input and I sort of agree for a single level.


Would they have to build their own level/map editor? Could they take a preexisting level/map editor and adapt their game to recognize what another level editor puts out?

The opinions here are more varied. There has been a time in the past when having your editor was necessary. Right now it's more like an option. People pointing out simple games having editors on their own don't get the point. Those talking about UnrealEd forget Unreal Tech is a large share of the whole game development industry.

Personally I think dedicated editors are done - there are a lot of advantages in allowing an artist to use the editor of his choice and just import the work.




#5097750 Rendering only what the camera see

Posted by MaxDZ8 on 30 September 2013 - 12:50 AM

To elaborate on Tom KQT, here's another example.

Say you have a particle system generating 1000 particles. Do you cull each particle? Not at all! You cull the particle system itself.

A particle system with 1M particles? We might try to split it in spatial chunks.

Granularity is key. Personally I've found that even on rock bottom hardware vertex transform is so fast that I can draw 2x more vertices at 10% more cost (at worse). So I made all my batches (and thus their culling box) twice as big. The performance was about the same. I then made my batches even bigger and found out there was an improvement in performance. Right now the batches are about 10x the original size and they still give better perf than the original. Why? Probably because D3D9 batch dispatching is really that slow.




#5097743 hardware instancing?

Posted by MaxDZ8 on 30 September 2013 - 12:29 AM

I'd suggest to just merge all cubes of the same type in the same batch. Even with extreme interaction rates (say 5 per second) you should have no problem in updating the buffers correctly if you did your octree right.

What mhagain states is completely correct, but there's no need to do that on the complete dataset each frame - just draw all the "surface", potentially visible cubes.




#5097741 Well Structured Code

Posted by MaxDZ8 on 30 September 2013 - 12:26 AM

As I'm learning JavaScript myself, I cannot avoid noting how JS documentation is really dependent on data types being there.

This separation between data types as something that just exists in our mind to understand against data types as something understood by the language is JS main problem in my opinion. Code readability, as well documentation is seriously hampered.

So sadly, in the long run, I consider static, traditional languages to be far superior.




#5097740 Help with browser game

Posted by MaxDZ8 on 30 September 2013 - 12:21 AM

I googled it up and found various images, I'm not sure what it is really as I'm not going to sign up to try it but I'd say it's a browser-based game like ogame or something.

For a start, learn HTML, CSS, JavaScript. See you in a few months.

You will very likely need to learn PHP for server side programming as well.




#5097046 How to draw the heightmap properly?

Posted by MaxDZ8 on 26 September 2013 - 12:16 PM

My suggestion is to not worry about it. Implement pure geomipmapping (which I consider easier than geoclipmaps) with 1 drawcall per batch. Then eventually iterate. Doing superchunks is surely not trivial.

It doesn't need to split buffer objects on the fly. It's just a matter of playing with index values smartly and modifying drawcall data.

But again, I suggest to start simple and scratch your head after you are sure you got a problem with draw call count. I am serious about that.




#5096967 How to draw the heightmap properly?

Posted by MaxDZ8 on 26 September 2013 - 07:28 AM


Thanks! So first I have chunks like 1x1, 2x2, 4x4,.... every chunk containing 4 smaller ones. and then in every frame I decide which chunks should be drawn. But then if every chunk means a separate drawcall then thats a lot. Im not sure I understood it right though.
It seems I somehow didn't convey the message.

You must use a "hierarchical" approach. The whole point is: as chunks move away from the observer, they require less detail --> less triangles. Also, nearby chunks will likely have similar (if not equal) LOD level.

So let's say we have a 64x64 vertices chunk (4k, it's still a bit conservative). Next LOD level will have 32x32 vertices. You still resolve their LOD levels separately{1} and find out your terrain is like:

+---+---+---+---+

| 2 | 1 | 1 | 1 |

+---+---+---+---+

| 1 | 2 | 1 | 1 |

+---+---+---+---+

| 2 | 1 | 0 | 0 |

+---+---+---+---+

| 1 | 1 | 0 | 0 |

+---+---+---+---+

See the four chunks at top right. In this case, instead of drawing four LOD1 chunk you might draw a single LOD1 "super chunk".

Similarly, you might be able to draw the two LOD1 chunks at bottom left by splitting in half a LOD1 superchunk (by just limiting draw call primitive count).

So what I'm trying to show is that you specifically don't need to do one call per chunk.

 

This is of course if you're using geomipmapping. Clipmapping doesn't work that way but I personally don't like it much for small terrains.

And how do I handle the "lines" between chunks of different sizes? .....if one has 2x the resolution than the other.
This is a well known problem. You must resolve possible combinations in advance and fill the gaps. Those "filling" triangles are often referred as "skirts".

Clipmapped terrains have an advantage here as the skirts are basically static.

There's another method having the term "contiguous" that does not need explicit skirting. A beginner told me that it perceived it as a definite advantage. It is basically a vertex-interpolated geomipmapping. By a signal analisys standpoint it is a bit too liberal in my opinion.

 

{1}: or not, if you want to be super efficient, but I don't suggest to do so.




#5096076 Would this be a good idea? (Episodic release)

Posted by MaxDZ8 on 23 September 2013 - 01:10 AM

This is going to sound harsh.

 

I'd say it's too expensive. Take a look at Desura, Humble Bundle or Indie Royale, a lot of games are shipping below 5USD and I got my games for 1-2 USD, including 5 episodes of a Sam and Max franchise.


that decent pc game has hundreds of devs and thousands of dollars of budget.I'm the only programmer with little to no budget
Irrelevant by consumer point of view.


buy one hour at 7$,the next part will be longer at the same price
Nonsense.


#5096070 Game Logic: Creating a Scripting Language

Posted by MaxDZ8 on 23 September 2013 - 12:32 AM

I also have my own scripting language.

My raccomandation is: give up.

Differently from others, I had extra requirements which made pre-existing scripting languages difficult to use (if possible at all). It's currently core for my game and yes, I trust it well enough.

It appears to me however this thread is considering the goal with a technical mindset only. Besides the technical, I don't see discussion about the why OP shall embark on this project. It seems OP is considering the language in a vacuum and that's not what's going to give good results.




#5095104 This beauty...

Posted by MaxDZ8 on 19 September 2013 - 12:44 AM

Amateur. I've once dealt with code written... I think in Korea. The variables were numbered up to... like 74, in a convenient 800 LOC function.




#5095098 Animation with obj mesh per keyframe in DX11

Posted by MaxDZ8 on 19 September 2013 - 12:34 AM


how can I interpolate
In line of concept, you cannot, because OBJ does not guarentee the order of vertices is coherent across different files. So you have those values somewhere but you don't know where. Consider moving to a more modern format.


#5094441 Level Generation

Posted by MaxDZ8 on 16 September 2013 - 07:37 AM


As to not get to far off track from my original question, why is the data oriented design better then the
first code example. I'm not questioning it's actual purpose or efficiency. I have just heard the name "data oriented design" before 
and would like to know what that is. You don't have to give me a full blown explanation tailored to me. I take links
It's more or less like equations, where we write x + 7 instead of two numbers. This does not come easily as we have to write stuff that adapts to every (meaningful!) configuration for us, thinking in advice what we need. Of course if I tell you what amounts to x + 7 you cannot give me an answer and similarly in code we cannot get a solution... but we have to write code which somehow outputs the correct solution for us every time. We do that by exploiting properties the data is guaranteed to have and to define those properties we need to define the problem.

 

So for example in a tiled world we might be interested in knowing, for each cell in the world (not each tile):

  1. how it look?
  2. is it passable?
  3. if passable, sound of footsteps
  4. if passable, deals damage?

So we might want for example to make a specific cell passable even though it typically isn't, because that's a classic for hiding secret goodies: going through a nonsolid wall. In general we have to decide which property is part of the world cell and which is part of the tile itself.

Instead of defining properties in code we define them in the data itself.

Let's assume for easy explanation we load each tile graphics from a file. Then the actual tile graphics data is not really relevant: we just have to load it up completely, pack it in a texture and draw a quad measuring - say - 2x2 world units.

 

But now I'd stop there and let you figure out what you need to pack in your world.




#5092627 Particle Collision

Posted by MaxDZ8 on 09 September 2013 - 12:22 AM


How would you go about determine if a particle collided with something? We finally got GPU particles working but for rain we want it to create a new particle on collision with the ground. How might one go about doing this?
The first "new gen" stuff I recall is Lutz Latta's "Building a Million Particle System". Also called "UberFlow". The performance was nothing short of incredible, considering it run on midrange Shader Model 3. It apparently ran on Shader Model 2 as well but I'm not sure.

I cannot find the original resource, but this presentation from AMD seems to include it.

Note that this system can make particles collide and react to height fields.

 

Another presentation from GDC2007 covers particle effects from a game in the Command & Conquer franchise. You might notice some similarities with Uberflow but it provides a major update and several artistic reasoning when it comes to why instead of how.

 

Main problem is essentially finding a way so particles can collide with arbitrary geometry without killing their perf. So far the only sure thing is that you cannot just push the whole collision geometry data to a PS. Will you go for the "subset" approach? Or maybe you'll prefer voxelization? I'm torn myself.




#5091740 Venting via Twitter

Posted by MaxDZ8 on 05 September 2013 - 02:06 AM


How do you all deal with the day-to-day minutiae of corporate life?
I vent on social networks as well. Most of the time, nobody understands. And that's fine for me.


#5091733 no gpu onboard ?

Posted by MaxDZ8 on 05 September 2013 - 01:49 AM


for example external gpu are
5x, 10x (?) faster?
Goes like this:

Intel - it or miss. Often not properly documented in leaflets. HD4000 (some ivy bridge chips) is minimum considered decent. Haswell chips have a "Crystalwell" option, 128MiB of L4 cache. This is the fastest integrated option and the most expensive, marketed as "Iris pro" if memory serves.

Intel graphics is not really an option for gamers. HD4000 is the turning point as it's more or less as powerful as a card worth 50 bucks. Crystalwell is a real game-changer, I'd say it's as fast as a 80 bucks stand-alone card.

AMD graphics is better (with Crystalwell being the exception). Worth, at best 65-70 bucks.

In the end, they all get trashed by cards worth 100.






PARTNERS