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 15 Jun 2006
Offline Last Active Apr 10 2015 06:18 AM

#4845842 Create objects only once

Posted by Katie on 07 August 2011 - 11:40 AM

Material* mat = manager->getMaterial("MyMaterial");
if(mat == NULL) {
   // This is the first time someone wants to use this material. So create it

Don't do that.

You're putting in a branch point you don't need. I presume the second call to "getMaterial" should be "createMaterial". Also, you're not checking the error states of anything.

You're putting loads in unpredictable places. You now have several possible disk accesses (which are slow) plus shader compiles inside your rendering cycle. It means the first time a given material appears in view you're going to get chunky frame times.

Just go and load up all the stuff you need before you start. Presumably you are loading up the models anyway which name the material types, so just stick them in a list, then create them all. Then you can go through all the models setting the material pointer. Then you can start rendering, and now you know that all the bits are in place, so you don't need to worry about getting nulls back from your getMaterial call.

Don't put ANYTHING you don't need in your render loops -- anything you can do upfront, do it upfront.

#4845557 Sprite blitting

Posted by Katie on 06 August 2011 - 03:43 PM

OK, I had a look at the code and it's not really something I can "just post" because it uses a lot of my own utility classes.

I can talk you through the main points though.

Probably the easiest way to do this is to evolve your way gently towards it.

So the thing is to put all your images into one texture -- a texture atlas.

Draw your sprites using immediate calls for now setting up each x,y,z and texture coords. You should have a working, but slow engine.

Put a shader in -- the vertex can just pass things through, the pixel shader is a simple texture read.

Pass in uniforms for the sprite X,Y,W,H and rotation. (next step is to turn it into something faster). Also you'll need columns and rows for the images in the atlas and also a uniform to say which image to use. Now your shader can compute the screen X,Y coords and texture coords. You use the supplied coords to tell whether to add width/height values to the coords. Just draw a square at (0,0),(1,0),(1,1),(0,1) in immediate mode after setting up the uniforms for each sprite.

This is still slow but getting there.

Now turn the immediate mode square into a VBO, draw the four verticies out of it each time.

So the next part is supplying the sprite data in a texture buffer...

(to be continued...)

#4843816 Can anyone point me to Mac specific OpenGL 3.2 tutorials?

Posted by Katie on 02 August 2011 - 05:03 PM

There are no big single guides for this stuff. You'll have to go to multiple places.

The superbible should have the mac start-up code which gets you to the point of having a GL context ready to render into.

From there, the GL stuff is common on all platforms.

You'll just need to do things like keyboard/mouse handling, but that's a relatively thin layer -- my X11/unix version is 1000 lines of code including some big lookup tables for the keys. The mac docs will have this in them -- although my copy of the superbible has enough stuff to run with.

As for being all 3.2ey... create VBOs, stuff data into them, create shaders, run shaders. That's pretty much it really. People keep making it out to be a bigger thing than it is.

#4842052 Ray tracing fur/hair

Posted by Katie on 29 July 2011 - 03:31 AM

You don't have to split the hair into segments; you could solve spline against plane intersections directly.

That solution should also give you the coordinates of the intersection, which gives you a depth value... and that will let you do ordering of the contributions.

#4841014 Ray tracing fur/hair

Posted by Katie on 27 July 2011 - 03:01 AM

You're effectively trying to intersect two mathematical lines of zero width which is hard.

(The hairs approximate perfect lines from sufficient distance)

Testing the view ray against the hair is difficult, because you think you need to think of a way of bulking up the hairs so that there's a way of doing the intersection.

Apply some of Katie's rules of software engineering;

1. Ask what it is you actually want.
2. Invert the brute force solution and see if looks easier from there.

What you actually want is not knowing whether the ray intersects the hair or not. What you actually want to know is "how many hairs contribute what colour to this pixel".

Turn the problem around. Your pixel projects back from the camera, effectively occupying a long truncated pyramid shape. Your fur/hair lives in a volume. First off, if those gross volumes don't intersect, the answer is none.

Once you've established that the ray is passing through the volume that the hair might possibly lie in, you can do an intersection between the volume that represents the projection of the output pixel through that volume and equations describing the hairs. The hairs will typically be described as delimited curves which are reasonably easy mathematical objects to handle.

If you can establish that the hair intersects that volume, you can add some of the hair colour to the pixel. (The pixel is unlikely to be fully occupied by any given hair).

The complexity of this then the # of hairs, coupled with the complexity of solving the equations describing the hair. It's relatively easy to make the hair drift, wobble, wave etc, since you then just add more terms to the hair expression.

The gotcha is that you really want the hair/fur to be translucent at the edges, so you'll need to establish earlier intersections first before doing the hair intersections.

#4840421 Few questions about the legal part of a game company

Posted by Katie on 26 July 2011 - 02:44 AM

How much work have you already done?

Do you have the basic infrastructure completed and running? If not, you don't need a lawyer yet.

Go and write the game. You don't need a lawyer until a lot later in the process.

And a bit of advice on lawyers -- the longer you can keep them out of your life, the happier you will be.

#4840414 Question about imperial units

Posted by Katie on 26 July 2011 - 02:32 AM

It gets more complicated than just metric or imperial. There are also things like "metric feet".

A metric foot is 300mm long. It's ~5mm short of an actual foot. Wood, annoyingly, in the UK comes in metric feet lengths. Yes, that's right. You can't buy an 8 foot spar. You can buy a 2400mm spar. The problem arises when you actually need 8 feet of wood because 2400mm is nearly, but not quite 8 foot.


The reason there are different conversion factors is that the units all arose for different things. A foot is about a foot length. A yard is about an arm length. An inch is the last part of a thumb. That sort of thing. A furlong is the distance a couple of oxen can pull a plough in one go before they have to rest. A chain is the width of a bit of land of an acre in area and a furlong long. An acre is the area you can plough with one plough team in a day -- and hence varied depending on what you consider to be "a day", "can" and "team" and hence on things like what the soil there is like.

All of these were then sort of standardised over several centuries, but the measurements needed to be close to what they'd always been, so they ended up with "funny" conversion factors between the units.

If you're doing engineering in imperial (my Dad used to) then yes, you get used to doing conversions and using things like the "poundal" and the "thou". I grew up in the metric era, but I grew up in a household which measured things in imperial. In a discussion in the office a little while ago, I described something as "about 10 thou" and one of the guys here said to the other (younger) team members "See!!! I told you it wasn't a made up unit..."

#4839897 gpu based particle system

Posted by Katie on 25 July 2011 - 02:18 AM

"Of course, this trick only works if their spawn-rate is 1:1 with their lifetime"

It's perfectly reasonable to include some downtime as a ratio inside the particle data. You just draw a degenerate quad/tri if the particle is currently not running. By tweaking the origin times/respawn ratio times you can then generate effects like a fire which flares up and dies down.

#4836082 Microsoft's No-Bid Contracts

Posted by Katie on 16 July 2011 - 12:37 PM

"Where the hell does government get the right to tell me I'm no longer allowed to use DDT to kill the insects in my garden."

DDT's an interesting one. There's a body of opinion that banning it has killed more people (from malaria) than using it would have done. That is; although it's dangerous, it's better than the mosquitos having a good time.

#4836064 why is C++ not commonly used in low level code?

Posted by Katie on 16 July 2011 - 12:00 PM

It has a tendency to be a little less predictable in things like memory allocations, object sizes and what it's copying where.

People who are working (say) inside the Linux kernel need that little bit extra control over exactly what's happening.

#4833482 Data Oriented Design: How to disable elements

Posted by Katie on 10 July 2011 - 04:09 PM

"they just PROCESS ALLWAYS ANYTHING in their DDO culling."

That sentence makes no sense.

#4833465 Game design document formats

Posted by Katie on 10 July 2011 - 03:19 PM

There isn't a magic format.

Hell, most places don't even bother writing things down properly. I think outsiders overestimate how organised software companies are.

Generally; don't write design documents. You don't need them. You need them to communicate a vision to 100 people. If you're writing a game on your own or with two or three other people, it's paperwork you just don't need.

#4830254 Help! How to build the basic skills for game design.

Posted by Katie on 02 July 2011 - 02:09 AM

If it's game design you're interested in... then design games.

Don't design computer games, they take a lot of faff. Go design board games. Raid copies of monopoly and other board games for parts and dice. Draw up your own boards on big bits of cardboard. You can make decks of cards by buying small packs of index cards. There are also other game pieces available from companies like http://www.rolcogames.com http://www.p4g.co.uk/ http://www.dice.co.uk/ and http://www.gameparts.net/ (at least a couple of these places will sell in really small quantities and some of them do "prototyping" kits containing sample selections of components).

Writing rules is easy... playtesting them and fixing them so they work not so easy -- but this is the important part.

The skills you pick up here about designing fun and fair games transfer to computer games.

#4829926 delete this thread please

Posted by Katie on 01 July 2011 - 03:32 AM

"1) Would a commercial enginge available for Indies (up to 5000$) allow this level of costumization"

No. You're going to have scalability issues. Why? Because most extant MMOs (and hence their engines) are based around rather static world geometry. Minecraft keeps the geometry local and generates by psuedorandom techniques when required, saving the areas as it does so.

In order that you can have a landscape like that but which can be altered by any of the players, you'll need to store the whole landscape (in the way Minecraft does) but also to send deltas in that landscape to all players who can see the change (and you'll need to determine who can see each change). In addition you not only have to tell players connected now about changed geometry, you'll need to tell all the players who will reconnect later about changes.

It's not impossible, but it's a difficult problem to solve well. Which brings me onto the next part...

" If nothing of the above works for me then I would have to build it, with something like Boost as you suggested, nfries88. How long would that take me, providing I can work lets say the average 40 hours a week in the project. 1 year? 5 years? 10 years? (I can't spend more time than that"

If you are at the stage of referring to Boost as "something like Boost" then you have a number of things ahead of you.

You need to;

1. Get good at C++.
2. Get good at games development.
3. Write this game.

There's a reason why, when I go shopping for good C++ developers, I'm looking for people who've been using it for several years. It takes of the order of 10000 hours to get good at something. There are about 2000 working hours in the year, so 5 years is the point at which people could be good. 5 years does not MAKE a good C++ developer[2] but the chances of someone with a year of it being good are so small it's not worth worrying about. It's not that I wouldn't hire them, but I would be aware that if I hire them I'd be expecting to have a lot of conversations about segfaults.[1]

Games dev is a related but different set of skills. It's about understanding how to handle game loops, to defer doing things, to cache things, to handle inputs in the right way, to look at a set of problems and understand how to solve them not just in performant ways but within the envelopes of games. To understand things like "good enough is good enough", "faking it is cheaper than doing it" and "neither you nor the player needs this". These are skills which also need honing. They're less technical than the development -- they're about psychology, project scope management, product ownership and control. But they still need to be learned and practiced.

I'm telling you all this because "1 year is a fair estimate for a basic Minecraft-like MMO. Certainly less than 5 years" is almost certainly untrue. It's not a malicious lie; it's an untruth born of optimism. But it's still unlikely to be true. And you'll be disappointed. Minecraft's a tricky problem to solve -- and to be clear here, Notch is NOT a beginner. It's not his first released game nor is it his first released bit of software. And it's taken him a year. And an MMO version of it is a step further on.

Why DOES everyone want to write an MMO as their first game? What happened to implementing things like Qix or Pong or Breakout so that you get the hang of the basic principles before leaping straight into client-server software that is complex by anyone's standards?

[1] Yes, I know everyone here is an EXPERT in C++, and that you all got that way in just a couple of weeks and that you're all exceptional in this. So don't even bother telling me.

[2] This is a common commercial error in hiring processes.

#4828328 OpenGL text

Posted by Katie on 27 June 2011 - 11:05 AM

You can't. You'll need another library to create textures containing your text. Eg pango/cairo.