The One Man MMO Project
I've known for a while that my graphics renderer wasn't gamma correct. Up until a couple years ago, this wasn't an issue, then somebody noticed that we've all been doing lighting calculations wrong for the last 20 years. You've probably heard of gamma. In effect it is a brightness adjustment. Without gamma correctness everything renders a little too dark.
Textures typically are in a color space called sRGB with a gamma of 2.2, lighting is done in linear space (gamma of 1.0) and the screen most likely has a gamma of 2.2. The idea with gamma correctness is to make sure that the input textures and colors are converted to linear space before they are processed with the lighting in the shader, and that the result is converted back to gamma 2.2 when it is sent to the display.
Thursday evening I discovered this excellent OpenGL tutorial which explains most of what is needed to implement this in OpenGL. There were some details missing, so I'll fill those in here.
Read 11233 more bytes... (0 comments)
The software particle system is running. Here's a screenshot of the oil fire effect I've been using to debug the particle system. It looks quite good when it is moving although there are still a few things I want to add to it. Particles at the bottom go from yellow to red to gray so if you cover the bottom quarter inch so you can't see the particles appearing (which will be done in the game,) it looks like a pretty convincing fire. It was fun finding reference video on the internet. Looked at a lot of oil well fires.
I can't believe how many adjustments are needed to make a particle effect. I would get one thing looking good, then something else would look bad. First there was popping when particles hit the end of life, so I added a fadeout. Then it didn't look very realistic with just one particle texture, so I added animation. Then there was visual popping as the particle textures transitioned between animation frames so I added fading between animation frames. Then I noticed that particle creation was sort of "clumpy" where there would be a lot of particles created and then a pause, which made the bottom of the fire look like fireworks, so I had to distribute that more evenly. And on and on.
Soft particles are working, I implemented a simple depth check linear fade, not the fancier function from the NVidia paper, but they don't come into play in this screenshot.
Shadows are working, however it looks odd when particles disappear since there's no alpha in shadow mapping so where a particle fades out, it simply pops out in the shadow. I should be able to mitigate that with higher numbers of smaller particles so the popping isn't as obvious.
I haven't done any lighting on the particles yet but I'm going to tackle the hardware accelerated version of this next.
Read more... (0 comments)
Today there was a bug. A bad one. I was trying to use a 4-byte RGBA color value as a vertex attribute to tint the particles in my new particle system. It worked if I set the value manually, I tried a bunch of different colors: red, green, blue, black, white. Those colors worked perfectly. The real color values were supposed to lerp from one keyframe to the next. That totally did not work. If I didn't set the color, the particles were magenta, or sometimes cyan. I checked the lerp calculation, that was good. I checked the conversion from 64-bit color to 32-bit, that had a bug so I fixed that. I looked at the vertex and pixel shaders. They were super-simple so nothing there to be messed up. I checked the color data in the game versus the data in the VBO on the video card with GDebugger and Windows Calculator. The data was identical. I was at a loss.
Read 2887 more bytes... (0 comments)
Really interesting talk on the graphics in Battlefield 3 by Johan Andersson, the Rendering Architect at DICE. Parts 2, 3, 4 have the most "meat". There are sections on lighting, post processing, terrain, particle effects and more. For those not entirely into rendering, he breaks down all the passes that go into a single frame in part 4 (there are a lot.)
Parts: 1 2 3 4 5
Read more... (1 comments)
To get things ready to add the new particle system, I've been adding support for additional fields in my vertices. Previously all my vertices were the same Position/Normal/UV format. I've also been removing the use of deprecated functionality when I have the opportunity.
As part of the vertex upgrade, I wanted to replace my existing calls to the deprecated glVertexPointer/glNormalPointer/glTexCoordPointer functions with the more up-to-date glVertexAttribPointer. While reading about glVertexAttribPointer, I discovered Vertex Array Objects (VAO's.) A VAO combines all the calls you would normally have to do to set up your vertices, VBO's and IBO's into one call. I read about VAO's in the OpenGL SuperBible, but there is some hand-wavey stuff in their code that worried me. Looking into it more, I discovered glGetAttribLocation.
Vertex attributes (position, normal, colors etc) are passed to the shader via an array of integers. You can specify the integers yourself which is what the OpenGL SuperBible does - YUK! Or you can just declare your vertex attributes in the shader code and use glGetAttribLocation to find out where the shader compiler put them for you. Much nicer.
Getting the rendering to actually work however, was a huge pain. I spent a lot of time staring at a black screen in GLDebugger. There is a lot of misinformation on VAO's and I couldn't find a single example of how to use glGetAttribLocation like I wanted. So to save anyone else the pain, here's how it goes.
Read 6865 more bytes... (0 comments)
I've been following the launch of Guild Wars 2 with some interest. I've played the original Guild Wars quite a bit, and have been seriously considering picking up Guild Wars 2. But not anymore. At least until they work the bugs out.
When I read the reddit thread where people could ask ArenaNet Customer Service the reason they got an account suspension, that was pretty funny - even though the language is pretty colourful.
But today ArenaNet went too far. An in-game vendor was offering one particularly good item for significantly below market value. Apparently a mistake on ArenaNet's part, (given that everything that vendor was selling cost exactly 21 Karma.) Some players bought this item from the in-game merchant. The result, from reddit.com:
We permanently banned 3,000 accounts of players who substantially exploited it, and applied 72-hours bans to another 1,000 accounts of players who mildly exploited it.
People bought items from an in-game vendor and got a permanent ban from their brand new $60 game for it? I'm sorry ArenaNet, that's just wrong. I don't care how many times they did it.
If it was going to mess up the economy, then roll it back, but you can't call buying something from a vendor an Exploit and punish people for it. Take some responsibility for your mistake.
I suspect someone at ArenaNet realized that they'd made a public relations gaffe banning all those players, because they have relented. They're still not taking any responsibility, but if banned players go through customer service and beg for their account back and then delete anything they got from the vendor, then ArenaNet will let them keep their account. You can read the announcement here.
Read more... (4 comments)
I've been integrating Variance Shadow Mapping shadows into my full game engine. As expected, that took longer than expected. I have the feeling that I'm going to be tweaking the shadows until the game comes out. There are a lot of adjustments. Shadows are not an exact science by any means.
My first question was "where do I put the sun?" I looked at a bunch of screenshots of other games. It turns out, most games put the sun in the same place - where the shadows are most visible. So behind and to one side of the shadowcasters.
Once the sun was to one side of the camera, I found an issue - looking at the shadow map in GDebugger, the entire visible portion of the scene was rendering at one end of the shadow map with "up" towards the center of the texture - wasting about 3/4 of my shadow map memory. There was however, a surpisingly simple solution!
Read 2052 more bytes... (1 comments)
I needed to have a way to take a color and change its brightness but to be sure that the color would remain true as I adjusted the brightness. I've used RGB a lot over the years so I was familiar with scaling the color components by a value, but I wasn't sure that technique would retain the color properly or that it would let me use the full brightness range available.
Researching the problem, I quickly found this Wikipedia article with a description of the HSL (Hue, Saturation and Lightness) representation of color and an algorithm for how to convert to and from RGB. The HSL color space looks like this:
You'll note that one of the axes is lightness -- just what I wanted. And it works like a charm.
Read 3605 more bytes... (0 comments)
One of the things I've always liked about computer programming is that if something works, you really don't need to know how it works. Libraries work like this, quite often code samples do as well. I've been working on getting soft shadows to work, and when I started, armed with a great code example of soft shadows using Variance Shadow Mapping I was totally optimistic I wouldn't need to really understand how shadow mapping works.
Well that's out the window. I understand.
Read 3063 more bytes... (1 comments)
Wow, been a while. I've been on vacation, playing with my daughter, going out with the wife. First time since my daughter was born that I can say I've seen 5 of the top 8 movies on Metacritic (or any of them actually.) Dark Knight was fun, Prometheus was fantastic, The Amazing Spiderman I saw in 2002 - it was called "Spider-Man".
There has been some small amount of progress on the game, but I tried to take my own advice this year.
Read 5536 more bytes... (0 comments)
Designing a Secure MMO Login System - 2014-08-30 12:19:14 (6 comments)
Its just a random number appended to the data you are hashing so that if you hash the same password for two different users, they don't have the same hash. That way it is harder for someone with a list of common passwords to hash and compare them ...
Designing a Secure MMO Login System - 2014-08-30 12:11:57 (6 comments)
hi, im new to all this ... what is "salt" ?
Thanks for the suggestion, I hadn't considered that. I'll try to figure a way to let players do that.
So I notice that the colour picker has no place to simply input an RGB colour. Will we be able to input an RGB colour manually in-game so that we can get the exact shade that we want?
Single-File Installer - 2014-07-23 17:48:47 (2 comments)
Found a solution to the MT warning message http://onemanmmo.com/?mt
Copyright (C)2009-2014 onemanmmo.com. All Rights Reserved