Banner advertising on our site currently available from just $5!
KatieMember Since 15 Jun 2006
Offline Last Active Mar 03 2015 05:27 AM
- Group Members
- Active Posts 849
- Profile Views 7,074
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Posted by Katie on 06 August 2011 - 03:43 PM
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...)
Posted by Katie on 02 August 2011 - 05:03 PM
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.
Posted by Katie on 29 July 2011 - 03:31 AM
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.
Posted by Katie on 27 July 2011 - 03:01 AM
(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.
Posted by Katie on 26 July 2011 - 02:44 AM
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.
Posted by Katie on 26 July 2011 - 02:32 AM
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..."
Posted by Katie on 25 July 2011 - 02:18 AM
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.
Posted by Katie on 16 July 2011 - 12:37 PM
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.
Posted by Katie on 16 July 2011 - 12:00 PM
People who are working (say) inside the Linux kernel need that little bit extra control over exactly what's happening.
Posted by Katie on 10 July 2011 - 04:09 PM
That sentence makes no sense.
Posted by Katie on 10 July 2011 - 03:19 PM
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.
Posted by Katie on 02 July 2011 - 02:09 AM
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.
Posted by Katie on 01 July 2011 - 03:32 AM
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 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.
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?
 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.
 This is a common commercial error in hiring processes.
Posted by Katie on 27 June 2011 - 11:05 AM
Posted by Katie on 23 June 2011 - 09:58 AM
Were I to have a go I might be tempted to start with Linux as a base (because the software is much more open). There are extensions to X11 which allow you to inject keypresses/mouse moves into the system from other userspace applications.
Libusb now allows you to write USB device drivers in userspace. As long as the device produces USB and you can find what the protocol looks like, it shouldn't be too complicated to run it. Read some bytes, parse them, emit events, go round in a loop -- you could possibly even do a lot of this in a scripting language rather than needing C. You'd then be able to tweak the translations to fit the situation.
Once you've got X11 events happening, there's a whole bunch of games available -- nintendo emulators, spectrum emulators and a lot of free linux native games; including some fairly well made clones of PC games (eg; OpenTTD or Widelands). Plus there are a bunch of other tools to do things like emulate keyboard input using only mouse movement, so it would mean general computing applications would become accessible.
And all of this can be done without any huge investment so you can afford to try things without sinking money into it while you're learning the techniques.
It'd be a bit lashed-together to start with, but it's an entirely approachable project.
 Eg; http://www.inference.phy.cam.ac.uk/dasher/ which is a neat tool for writing text using only a mouse.