0
109 Mar 24, 2012 at 18:34

I know that you are suppose to sort your triangles by transparency order so that they are displayed properly in the z-buffer, I did that and it works, but kind of. Some shows throught walls, some are colored, but most are fine. Is there a specific way to do this? I feel like I’m not doing everything, but only part. Thanks.

#### 38 Replies

0
151 Mar 24, 2012 at 21:48

You need to sort the transparent tris by transformed z coordinate, is that what you are doing?

0
109 Mar 24, 2012 at 21:55

No, I just sort them by transpency only! What is “ transformed z coordinate” ? :wub: ?
Thanks for helping :)

0
109 Mar 25, 2012 at 03:26

ok, I tried to sort by distance to camera, but it didn’t work as good as if I sort by transparency!?

0
151 Mar 25, 2012 at 09:37

Stick a video on youtube and we’ll have a look

Basically you draw the entire scene without any transparent polygons.
Then depth sort the transparent polygons
Then draw them, farthest away from the camera first.

0
101 Mar 25, 2012 at 11:06

What do you mean with “by transparency”? The opacity of each triangle? That makes no sense at all.

Transparent triangles needs to be drawn back-to-front. That can be more complicated than is sounds like. You need to sort by distance to the camera, but what distance? The center point? Still, that can give you wrong results In some cases.

Also, there can be circular overlap, where a triangle must be split in order to sort them. Have a look at BSP trees for more details. It is a technique that is mostly obsolete by now, but it explains the problems very well.

I think the most popular approach is to make the sorting work in most cases and restrict the art to not cause any of the known problems.

0
179 Mar 25, 2012 at 11:25

A picture is worth a thousand words, so.. :)

In the above screenshot, the rendered image was done in two passes. The first pass you render only opaque geometry, ideally from front to back to maximize fillrate efficiency. In this case, the sphere is rendered first, then the blue rectangle, and finally the ground. In the second pass, you render transparent objects from back to front. This is also known as the painters algorithm because that’s how a painter draws. In this case, the red rectangle draws first, then the green rectangle, and finally the yellow rectangle.

Try to avoid scenarios like this. If you must have cross sections, divide the mesh up into smaller pieces. Instead of having 3 rectangles, split them up into 6 and perform the same algorithm as I listed above.

0
109 Mar 25, 2012 at 12:57

Thank you TheNut, It couldn’t be any clearer, and it works :D

But it seems that I have to re-sort every time I move the camera, is that correct? Because I use glNewList(TriList, GL_COMPILE); only once and then glCallList(TriList); on every frame. So do I have to give up the glNewList and re-sort on each frame if the camera has moved? Wouldn’t this be real slow?

0
179 Mar 25, 2012 at 21:39

Yes, you need to resort your list every frame. It’s not that expensive though. 100,000 items sorts in about 10 milliseconds on my PC. You’re not going to have anywhere near that many items, so you’re well in the safe zone.

You should avoid programming with display lists as that API is deprecated. GL 2.X and newer states you should be using vertex buffer objects. If you must stick with the 1.X standard, then at least use vertex arrays as they’re more robust than display lists. Then you can selectively decide which geometry you want to render and which you do not, as well as adjust the order in which your geometry is rendered.

0
109 Mar 26, 2012 at 00:06

It works almost perfect thank you :) but the reason it’s “almost perfect” is because I sort the tri using the centroid of it, but when they are displayed in an angle, I sometime see some weird results, but not often.

I didn’t know about the display lists! thanks for letting me know.

I wonder why OpenGL is not capable if doing transparency itself. Do you know why? It would seems so simple for a microchip doing all kinds of complex stuff!!! Why give us the burden to make complex algo that can’t be perfect, and waste time on sorting when we could be computing something else that’s more important for the game or whatever it is!

0
101 Mar 26, 2012 at 08:31

It’s not OpenGL that isn’t capable of processing transparency, it’s hardware itself. The reason is that for true transparency you need multiple Z values in Z-buffer. You can simulate that with different techniques (alpha to coverage, monte-carlo, etc…), but it’s not easy.

0
101 Mar 26, 2012 at 09:51

@Alienizer

I wonder why OpenGL is not capable if doing transparency itself. Do you know why? It would seems so simple for a microchip doing all kinds of complex stuff!!! Why give us the burden to make complex algo that can’t be perfect, and waste time on sorting when we could be computing something else that’s more important for the game or whatever it is!

Hardware manufacturers went down that path once before, with the fixed function pipeline. You had a fixed set of features the hardware could handle, and that was it. If you wanted anything more innovative, you had to do it in software.

It was soon very clear that this was not going to work. Instead pixel/vertex shaders became the norm. Then multiple rendeer targets, instantiation and hardware tessellation, etc. Graphics hardware is now moving in the direction of becoming a completely generic CPU, optimized for extremely parallell tasks, such as graphics, but also physics, password cracking and all kinds of number crunching.

This means we are not limited to what the hardware manufacturer had in mind, but can invent new techniques. The only drawback is, you have to do more yourself…

0
151 Mar 26, 2012 at 10:20

Yes, OpenglES is a prime example of this.

ES1.0 functioned much the same as opengl, you had the same matrix stack etc. The only real difference was that you couldn’t do glBegin(…)/glEnd(), you had to use buffers

ES 2.0 all that went out the window and you now just have shaders. You have to do all your own matrices etc, but you do have hardware shaders.

Pain in the proverbial for the first project, after that really nice.

0
109 Mar 26, 2012 at 12:56

hmm, yeah, I see what you all mean!

But really, they couldn’t do something as simple as transparency???

If we can do it in software by simply sorting our object by z-dist, why can’t the GPU do it instead? and even better than by object, do it by pixel, so it’s flawless all the time!

They can make microchip, send rovers to Mars, but yet, they can’t do transparency :lol:

0
101 Mar 26, 2012 at 13:13

@Alienizer

But really, they couldn’t do something as simple as transparency???

Transparency is not simple. You think it’s simple because you’re not accounting for all the corner cases.

If we can do it in software by simply sorting our object by z-dist, why can’t the GPU do it instead?

You can’t “simply sort objects by z-dist”. A polygon that is closer to the camera than another polygon for one pixel, may be farther away for another (see the case of intersecting polygons given by TheNut a few posts back). The only thing you can do that always works is sort per pixel. Nowadays you can do that on the GPU, but compared to a simple (but possibly wrong) per poly sort it’s quite expensive.

Also, for the GPU’s to be able to sort polies, they first needs to know all the polygons. Which is completely contrary to how they work - they simply execute all draw commands in the order you give them. Another thing is that the GPU doesn’t think about translucency as you do. The GPU just blends the pixels with those already in the backbuffer, given some factors for both values. You think of translucencies in terms of src_alpha and one_minus_src_alpha, but that’s just one of the available permutations. You could also do simple additive blending, which is order independent. Or perhaps you simply want to blend in a rectangle, regardless of its z-value.

0
109 Mar 26, 2012 at 14:46

I worte a simple 3D engine once. And that’s what I was doing, draw all pixels from back to front in an off-screen buffer, and transparency was handled perfectly. Very simple to do, that’s why OpenGL should do it, or at least, have that option.

I think that the GPU is still very primitve. They add things to it, but in the end, it makes the programmer’s life more difficult. Why can’t we simply send all our poly to the GPU, textures, normals, UVs and all, and simply rotate our cam, have a callback for collision, things like that, even some GPU RayIntersection stuff. Everyone could write some peofesional games without spending a lifetime trying to understand how to make a rotating cube. It’s now so complex that it makes no more sense. By the time I understand all of OpenGL and able to write somethng worth while, it’ll be in a few years when they’ll have more for me to learn, so I spend my time learning what it does and never do anything with what I learn, because it’s already deprecated! Or maybe I’m just too dumb.

0
101 Mar 26, 2012 at 14:50

@.oisyn

Transparency is not simple. You think it’s simple because you’re not accounting for all the corner cases.

Also, it needs to work together with the rest of your rendering. This is easily getting VERY complex.

• Oh! You wanted your cascading shadowmapping to cast filtered semi-shadows? And you have refraction on that water surface? Well, at least you don’t use deferred rendering… Oh you do?

Just because it is simple in YOUR case, it isn’t simple in general. So why would they waste development time and silicon on features everyone will have to reimplement themselves anyway?

0
109 Mar 26, 2012 at 15:13

What I’m saying is, we use video playback, games, renderers, and that’s about it. So a video card should do just that. Cuda lets you do renderes, in real time if you have the hardware. But Cuda is not a chip, it’s software.

We should have a video chip to only do renders, games, and playback videos. That’s it. CPU for running our OS and GUI, and another card, with 32768 RISC cores (of very limited instructions) to let us do the number crunching stuff. That would be a real super computer and not hard on the programmers. The more features, the more complicated, the more questions, the more bugs, the more problems, the more time wasted. Lets see, Windows 3.1 use to run as fast on a 286/66mhz as it does today with Windows7 on a 3GHZ. They should re-design the standard rather than trying to modify it. OpenGL is very old, and is now very big, too big.

0
179 Mar 26, 2012 at 15:36

Try not to look at OpenGL as a final solution. It’s a tool no more different than a paint brush is to a painter. It’s not the brush that paints the picture, it’s the painter who commands the brush. What you’re looking for is a high level engine built on top of OpenGL. Unreal, Crytek, Unity, etc. These are examples of software that hide or abstract such low level mechanics. Ever wondered why Unreal Engine is so commonly printed on game boxes? It’s for the very reason that programmers do not want to reinvent the wheel.

I also wouldn’t say life is made more difficult because of the state of things. Rather, I would say that there is simply more things to do. Although I think you’re starting a debate about rasterization vs ray tracing. Ray tracing is a more straight forward rendering technique, but it has some disadvantages. The most noticeable being that the two most popular rendering APIs (GL & DX) are using rasterization. Take a look at this article.

0
109 Mar 26, 2012 at 15:57

i agree with you 100% but I think the technology is not going the right way. Maybe I’m wrong about it, but it seems they simply patch old tech to make it new tech and we are left with all kinds of things that we have to know, like oh, can’t do this because it’s not working with this and that, or it’s deprecated, so use this instead, but only if the card can do it, but if it’s ATI do this instead, and if Nvidia, do it that way etc etc etc. It gets very confusing.

I’m still trying to make an OpenGL context on a window to use anti-aliasing 4x 2x !?, and I’m still reading all that stuff, it’s been 2 weeks I’m on it, and I still get a black window :angry:
Sure I can copy codes from free stuff, but that doesn’t mean I’ll understand what it does. Maybe I need to go to an OpenGL school? if there is such thing!

0
117 Mar 27, 2012 at 11:06

Actually the only simple solution to this is the “real” solution through path tracing :P. In real physics there is nothing like transparency, shadow maps, etc. - there are just photons that can be reflected, refracted or absorbed - thats all :)

The technology is IMO going the right way, as GPUs begin to be general computing processors (note that half of my renderer now is written in OpenCL and in C++ on CPU) - so yes, the tech is going the right way - generall computing processors are good, of course that means that in future whole OpenGL, D3D and possibly (hopefully) others (even those using ray tracing) will be written in C/C++ on GPUs (like OpenCL is for example).

0
109 Mar 27, 2012 at 12:45

A jock of all trades is a master of none. So I think this rule should also apply to the GPU. Imagine a microchip that is designed to only do progressive photon mapping in real time? Imagine using a 3D design software that works with such an IC? Editing your materials and moving/creating objects in fully rendered mode? That would be so cool.

Anyway, back to that transparency problem. How do you trully do transparency on the GPU? On that is 100% correct, even when zooming, rotating and panning?

0
117 Mar 27, 2012 at 17:30

Depth peeling
There is a solution to do full transparency through depth peeling (you actually render scene N times, where N equals number of “transparent layers”, each time discarding pixels with depth lesser and equal than the actual value in depth buffer in previous layer).

This solution is good and do order independent transparency without any problem, but! Imagine the second posted screen by TheNut - you’d need to render the scene 4 times into 4 different buffers (thats overkill) - so this solution is practically useless for games (as it needs huge amount of fillrate and memory).

So I don’t think this one will help.

Hacky way (note, needs ninja for the word “hacky” here :ph34r: )
In my current game in-development there is quite a bit need for specific transparency solution - so I tried several solutions and wasn’t happy with any (couldn’t do the cool stuff with any). Note that I’m extensively using deferred shading in it. I could use ray-tracer, but it has other stuff to do (it actually does just reflections and VPN spawning - raytracing that is quite heavy itself, doing refractions = transparency would made it a lot slower) … I’m also running out of ideas, but what prooved really useful was doing just a single depth-peel pass with half the resolution (to save fillrate, still looks good, even for glass) -> It is still very heavy, but I think that with a little fine-tuning I’ll be able to put it to good use. Of course, this limits everything (two glasses, one before second, will look wrong) -> but it has more advantages:
1.) GI and ray-traced stuff is visible in and on transparent objects
2.) Doesn’t need to do any (re)sorting, you render all time front-to-back
3.) It is more effective than it seems to be
4.) When more quality needed (or Radeon 7990 :D present), one can add depth-peel layer(s)

So it really depends on what you actually need! Just summarize what u need for your project and try to come up with solution.

0
109 Mar 27, 2012 at 19:30

I see what you mean, quite involved just to do transparency.

I do not have a specific need, but for example, if I was adding to my game a glass maze, with hundreds of walls of different hights and colors and png-tranparency materials? Then what? that would be just about impossible to make such game in OpenGL? and have to use real-time raytracer or something?

0
168 Mar 27, 2012 at 20:56

It’s easy for programmers to say “why can’t they just make a microchip to do XYZ”, but hardware designers also operate under constraints and trade-offs. They are trying to do the best they can with the design and manufacturing technology available. There are many things they would like to do but it’s just not practical / feasible with current tech.

Programmers have a similar relationship to hardware designers as artists have to programmers. :) One has to play within the sandbox built by the other, and sometimes they get frustrated that the sandbox is too small, or the sand is too rough and not sticky enough or something, and they think “imagine what I could do if only had better sand / a lot more sand! Why should I have to compromise my creativity with the arbitrary limitations of this sandbox?” And then it’s easy to be angry at the sandbox builder. But the limitations aren’t arbitrary - the one who built the sandbox isn’t lazy or trying to gyp you; she’d love to give you a bigger sandbox or better sand, but she can’t do that without compromising something else, as she has to work within her own practical limitations.

So, the artist may be frustrated that the programmer can’t give him more polygons, more textures, etc. but the programmer knows her code must run in real-time, within a certain memory limit etc. And she may be frustrated that the hardware designer can’t give her more memory, faster shaders, etc. but the HW guy knows his chip must run without taking too much power or getting too hot, must behave consistently, must not cost too much to manufacture, can’t break the speed of light, etc. And the HW guy might be frustrated that the scientists can’t design a smaller / faster / more reliable / less power-hungry transistor, that the fabs can’t manufacture ICs more quickly / cheaply, and so on and so forth…

Enough rant. :) Back on the subject(s) - it’s worth noting that special-purpose raytracing hardware has been (and is still being) tried. They’ve made progress, but so far it does not work well enough to bring to market. There has also been a lot of research on software ray tracing on the GPU, and there’s been good progress there as well. The key problem with parallel raytracing is lack of coherence in memory access when rays diverge, so the “secret sauce” in all these things is finding a way to efficiently regroup rays to regain coherence at certain stages in the process.

And as for transparency - there are many ways to handle it with more or less degree of correctness, such as per-object sorting, depth peeling (already mentioned), A-buffer (linked list of surfaces per pixel, sorted and composited - can be done with compute shaders on GPUs today), adaptive transparency (computes a approximate depth-to-opacity mapping for each pixel), and inferred lighting. All these approaches have trade-offs - the main one being that the more accurate methods are very slow - probably too slow for a real game application unless you have a very simple world - and the more approximate methods are faster. So, pick your poison based on what best fits your use-case!

0
109 Mar 27, 2012 at 22:08

That’s just my point Reddbeta. It’s like cars, they know how to do it so it last 100 years, but they don’t, because of money, they want return business. Same for hardware, I’ve learn that while working for a firm in Florida back in the 90s. They already had designed for much better hardware, but they only give one bit every year, so the users keep buying. Just like cpu cores, Intel already made a 80+ cores prototype, but we’re only going to see the 2, 4, 8, 16 ,32, 64,128 cores in 1, 2, 3, 4, 5, ,6 ,7 years, or more.

Everything the big guys do is not because they don’t know how, or don’t have the mean to do it, it’s about the money, making sure that our technolody today is dinosaur in a year and have to buy the letest, year after year. That’s what I’m angry about.

Say, I build a 1x1 sandbox for you this year, next year, I’ll make you a 1x2, then the year after a 2x2, so I keep getting money from you. But if I were to make you the best that can be built, a 50x50, you would not buy again for another 10 years, until I I have the technology to make a 100x100.

http://www.physorg.c…cores-chip.html

and we’re not going to see this technology anytime soon are we?

Money is the root of all evil :ph34r:

0
168 Mar 27, 2012 at 22:27

Imagine if they did bring a 1,000-core processor to market. How much would they have to charge for it to break even on the cost of manufacturing? And recoup the startup costs of creating the manufacturing process? How many people would buy it then? The higher the price, the fewer the customers, so there very well might not be any price that would make that a viable market proposition.

Sure, they may have already designed a processor that isn’t going to hit the market for 5 years, or 10 years, but I think it’s a mistake to assume they’re cynically holding it back to drag out our dependence on them, or something. More likely, they’re holding it back because it wouldn’t be profitable to bring it to market now. They have to make at least as much money as they’re spending, so the company can continue to operate and not go bankrupt, etc. If you think that’s evil, then that’s your right, but I think that’s a very naive viewpoint. What are they supposed to do - sell it at a loss, rack up massive debt and then go out of business in a couple years?

(And FYI, from the article it sounds like on that 1,000-core processor, the cores are just special-purpose video decoding units or something, not general-purpose CPUs. Bit of a different thing. There are GPUs on the market today with over 1,000 ALUs on them, which is a closer comparison.)

0
117 Mar 28, 2012 at 00:49

Reedbeta has a point! Of course, if one tries enough hard, he can achieve real time ray tracing (as a writer of Ray Tracing series here on DevMaster.net knows :) - he inspired lots of people to write real time ray tracer :P).

Also I’d like to note that it everything is for money in the first, second and last place. Of course here comes a good thing - as long as there is another company doing the same thing, there is progress (simple sample, fictional):
1.) I release CPU for $400 with 100GFlops 2.) I design better CPU with 1000GFlops, I’m going to release 10 years from now 3.) I profit for 3 months 4.) My “very beloved” friend comes, releasing CPU for$400, but with 200 GFlops
5.) I don’t profit in 3 months -> so I release a new CPU (based on owned and designed one) that has 300 GFlops
6.) And goes on…
7.) And on…

n.) I release CPU designed in step 2 actually 1.5 year from beginning
n+1.) Have to design even better CPU now

As you can see, concurrency makes progress - e.g. as long as there will be another company, the stuff will develop with huge speed, when the concurrency doesn’t exist, it’s bad, very bad (be honest - how much improvement have we seen in Windows since version 95 … don’t count the prettier icons, security (as this one just needed improvement due to “exterior effects” = spreding the internet) and even more interrupting messages? … of course one can use Linux like me :ph34r: (btw. does ninja smiley look really that good to everyone like to me?))

Same applies for everything! Be it game development, api development, hardware, cars industry, phone industry, … or even toilet industry.

0
109 Mar 28, 2012 at 02:13

I do agree with that 100%, competition is a must for inovation, but, because of money, everything slows down. Take the food industry for example, the content shrink, but the box stays the same size, just way thinner. Fillers are added to the food and on and on. There are always new buyers, it’s not like everyone in the world will buy the 100GFP within 3 months and that’s it no more buyers for 3 years. Even if they do, these companies will be billionairs in 3 months, and will have plenty of money and time to make a 400GFP within a few years and be billionairs again.

I guess we are all right, depending on the view perspective :ph34r: (yeah I love that icon)

0
179 Mar 28, 2012 at 03:21

You’re only as fast as your slowest component and humans are sadly the slowest component. I’m sure AMD and Intel wouldn’t mind putting faster chips on the market every X days/weeks/months, but due to the way manufacturing works nothing would ever hit the market. Machines build machines and it takes time to get that up and running in remote places. Once they’re finally up and running, obviously it’s in the company’s best interest to work them to the grave. The longer they are in use, the more they pay themselves off and the prices of hardware drops. When new tech comes out, the cycle continues. If you could eliminate the bottlenecks of manufacturing, you would effectively escalate production dramatically while keeping prices down. Who knows, perhaps the evolution of 3D printing could solve these problems.

Sure it’s nice to have 1000 cores, but having 6 or 8 cores isn’t that bad. I have loads of fun with my hexacore and I have 4 other boxes to tap into with distributed computing + GPGPU. This is all research stuff, but it’s my fun and that’s what counts :P When it comes to games though, don’t think you need to deliver the cream of the crop. Entertainment is the #1 focus. Everything else is just bonus. I can flood you with a list of basic looking games, but they offer tremendous amounts of entertainment. Don’t try to go for ray-traced image quality on day 1 :)

0
109 Mar 28, 2012 at 03:31

Yeah I suppose so. I just want the ultimate even if it doesn’t exist yet, but I know it’s on the drawing board. It’s like a candy in the box and can’t have it just yet :(

Now, they should work on a StarTrek “replicator” so we can have those 1000 cores CPU yesterday for \$10 :lol:

0
101 Mar 28, 2012 at 08:08

The problem of the 1000 core CPU is not so much the cost of manufacturing or the market, but that we as programmers have no clue how to use it. So far we have pretty much assumed a single core, single thread programming model when designing software, because that’s the hardware we have had.

Massive concurrency and parallelism is the bleeding edge of research. The problem is that most algorithms, and perhaps how we have become used to thinking about programming in the last 50 years simply don’t fit the 1000 core architecture.

Already, when we run our code on merely 2 cores and a handful of threads, it is almost completely unavoidable to shoot ourselves in the feet, arms, heads and shoulders. Every time in a different order.

Actually keeping 1000 cores busy will be a very hard problem. Likely it will require new languages, or at least something else than the C, C++, C# we have now.

Purely functional languages could be useful, since they can evaluate parts of expressions independently on it’s own core. Immutable data structures could enable memory to be safely shared between cores. The problem is, these are features found in languages like Haskell, where excessive memory use and garbage collection makes high performance, tight constraints code close to impossible.

On the hardware side, there are already lots-of-cores processors available, like this one:

It’s designed to run FORTH on 40 cores, each one a complete computer with rom, ram, and io. Now, designing code for running on each code has to be done manually. I’m not sure if the cores can be reprogrammed dynamically, but I don’t think so.

0
151 Mar 28, 2012 at 08:18

Well it’s not all linear, we actually have lost a lot.

Back in about 1990-1995 we had real time raytracing, it ran on a transputer farm running Tao OS.

http://en.wikipedia.org/wiki/Tao_Group

But it never took off, the main product from all our work was a JVM that ran 147 times faster than Sun’s

Then we lost parallelism for a long time, before it started to come back in the form of GPU’s

The real problem was that you had to be GOOD, I mean REALLY GOOD to write fast code in Occam. GPU’s are much easier to code for as the parallel nature of them is kind of hidden from the programmer.

Now for the replicator to work, we need to understand the relationship between energy and mass. We know the high level relationship (Albert said E = mC\^2), but we don’t know the relationship at the quantum level.

So if you want to get your wishes, donate money to science and let them find the Higgs :D

@geon

That’s really interesting, I already have code that converts Forth into glsl, I wonder if I can go the other way …..

0
117 Mar 28, 2012 at 10:04

Sure it’s nice to have 1000 cores, but having 6 or 8 cores isn’t that bad.

Yes! There is also another problem with 1000 cores… there are other issues - limited memory and memory access (one can’t fit whole 3D scene in cache) - this can mess things up. Really accessing same block of memory from 4 cores is slow, imagine you’d be accessing it from 1000 cores (of course one can use duplicates of data in separated memory for each group of cores - smells like distributed computing).

Actually keeping 1000 cores busy will be a very hard problem. Likely it will require new languages, or at least something else than the C, C++, C# we have now.

Not necessarily with C/C++/C# - we just would need better way to work with them (a library, or extending the language could do the job).

Using haskell is cool. Coding useful stuff in it that actually isn’t that slow (just about 2 or 3 times than in C) makes one feels like boss :ph34r:. Not that I can write that good code in haskell.

0
101 Mar 28, 2012 at 12:49

@Vilem Otte

there are other issues - limited memory and memory access (one can’t fit whole 3D scene in cache) - this can mess things up. Really accessing same block of memory from 4 cores is slow, imagine you’d be accessing it from 1000 cores (of course one can use duplicates of data in separated memory for each group of cores - smells like distributed computing).

Perhaps memory “broadcast” where several cores read the bus at the same time? Sounds like it would cause horrible locking issues, though.
@Vilem Otte

Using haskell is cool. Coding useful stuff in it that actually isn’t that slow (just about 2 or 3 times than in C) makes one feels like boss :ph34r:. Not that I can write that good code in haskell.

Right! Haskell is pretty nice when you get in the right mindset for it. I wrote a simple Othello/Reversi min/max AI in it and it worked ok. About as fast as my C implementation I’d say. (I never benchmarked them, nor was the C version fast to begin with.)

It really requires you to rethink a lot of algoritm’s and data structures though. I couldn’t use mutable arrays like in C, so I came up with a representation of the board as a map of a tuple (the board coordinate) to an “enum” (don’t know the actual name for it in Haskell).

I remember reading a paper from Naughty Dog (or perhaps Epic?), discussing the features of the next generation of programming languages for games. The author suggested a mix of paradigms with purely functional features for the math, etc.

0
117 Mar 28, 2012 at 14:49

I actually considered doing game scripts in functional paradigm - it is really easy to implement and work with it, although I’m a bit feared what would any person that should work with this said about it.

For example simple definitions of enemies in C-like scripting as:

struct enemy_t
{
skinned_model enemy_mdl;
float life;
}
void enemy_t::onhit(float dmg)
{
life -= dmg
if(life < 0)
{
life = 0.0f
enemy_mdl.setanim(NULL);
enemy_mdl.setragdoll();
}
}


could be reduced to:

data Enemy = Enemy (Model mdl) (Float life)

Enemy_onHit (Enemy mdl life) dmg
| life - dmg < 0 = (Enemy (ragdoll mdl) 0)
| otherwise = (Enemy mdl (life - dmg))

0
101 Mar 28, 2012 at 15:14

@Vilem Otte

data Enemy = Enemy (Model mdl) (Float life)

Enemy_onHit (Enemy mdl life) dmg
| life - dmg < 0 = (Enemy (ragdoll mdl) 0)
| otherwise = (Enemy mdl (life - dmg))


Hmm. Haskell for game scripting… Why not?

I’m all for functional style programming, but I’d go for a more conventional scripting language. Perhaps Lua or Python. Even Javascript (V8 ?) would work, and it’s a pretty nice language that a lot of people already know.

0
117 Mar 28, 2012 at 23:37

There even is something called HINT - allows you to add haskell interpreter to your applications (considered cool :P). I hope I’ll find some time in next few weeks to try it out a little for game-like scripting.