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 Aug 2009
Offline Last Active Jun 11 2015 05:45 PM

Topics I've Started

spare time project IP

05 August 2014 - 07:05 AM

not sure if that fits into this sub-forum, yet I haven't found a better place to ask.


A lot of employment contracts state that all IP (that implies source code, art assets etc.) created during the time of employment belongs to the company, thus even your spare time efforts. Some contracts state that you have to ask for permission to be allowed to even just start working on something in spare time. (means: no weekend game jams etc.).


I wonder, how is the legal state of this in various countries? I know there are some limitations to it in California, some countries even render those parts of contracts invalid, yet it's hard to google for it (or I just use wrong term?). Someone like Notch created his Minecraft as spare time project and it seems his employer never claimed rights for it. that makes me all wonder what's the state of spare time project IP in US states and European countries.


I'd be fully fine with just links to read the specific laws.

Entertaining loading "screen"

21 August 2010 - 10:33 AM

I hope this is the right place to ask. I'm not one of those creative guys, so I really rely on your help ;)

I'd like to ask you for ideas for something entertaining to watch and maybe even interact while loading up a game or level. Primary for consoles. It shouldn't be "massive", as the loading should not slow down due to it, but it can use simple drawing, images (tho, not too much as it would be silly to have a loading for the loading screen :D ).

Some games already do this, like the hologram that Killzone 2, that can be slightly move with your sixaxis. I'd like to offer something eye candy, maybe something related to the level that is loaded. maybe some completely unrelated but cool to watch effects (but they shouldn't be annoying to those that just want the loading to be done).

I guess you get a picture of my idea.

if you have questions or any random idea or suggest, don't hesitate to post it.

Thanks in advance.


is Z linear?

03 March 2010 - 08:06 PM

from my oldschool days I know, when writing a rasterizer, I could interpolate x and y linearly in screenspace, but z was hyperbolic, so I had to interpolate 1/z and calculate the reciprocal per pixel. Now, working on a homogenous rasterizer, interpolating with 1/z wasn't working properly and I seeked some paper that would explain what I miss and it looks to me like z is interpolated linearly. http://escience.anu.edu.au/lecture/cg/Texture/perspectiveCorrection.en.html http://www-graphics.stanford.edu/courses/cs248-07/lectures/2007.11.06%20CS248-13%20Z-buffer/2007.11.06%20CS248-13%20Z-buffer.ppt (page 18) it sounds logical
When projecting a homogenous vector we divide by the homogenous coordinate: (xw/w, yw/w, zw/w, w/w, u/w, v/w, 1/w, R/w, G/w, B/w, A/w)
so you end up with (x, y, z, 1, u/w, v/w, 1/w, R/w, G/w, B/w, A/w) BUT on the other side, I KNOW the ZBuffer on hardware is not linear. what do I miss?

Triangle Scan Conversion using 2D Homogeneous Coordinates - z interpolation issue

12 January 2010 - 10:37 PM

my question is regarding this paper: http://www.cs.unc.edu/~olano/papers/2dh-tri/ how to interpolate z properly? The solution I came up is simple. using the edge functions you get the baricentric coordinates, I use that to interpolate W and Z linearly, as I did not yet divide, that's methematically correct. I then divide Z by W for every pixel, everything is fine. for interpolation of random vertex attributes that do not need to be divided by W, I multiply them by the inverse matrix, like stated by that paper. I also get the 1.f/W value by multiplying [1 1 1] by the inverse matrix. interpolating that and dividing per pixel every interpolator by (1.f/W). that works fine. BUT this leads to two divides, one by 1.f/W and one by W. I could of course divide every vertex-z by W and multiply by the inverse matrix, then I would just need to divide per pixel by 1.f/W, but in this case clipping would be needed. so, what's the correct way to do it to avoid two divisions per pixel? Thx ProfL