Jump to content

  • Log In with Google      Sign In   
  • Create Account


Programming a "TV"


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 GothSeiDank   Members   -  Reputation: 156

Like
0Likes
Like

Posted 12 November 2013 - 06:38 AM

Sorry, I hope this is the right forum. 

 

Anyway, I would like to do something that looks like an old CRT-TV. 

 

I already got the scan-line and vignette shader (GLSL), now my problem is that I need to slightly "bend" the surface on the edges to the back to create this illusion of an old CRT-TV surface. I am using Game Maker Studio, so I have only 2D capabilities and limited 3d functionality, like drawing models and manipulating matrices. 

 

Can someone help me to get this started? smile.png

 

edit: A picture of what I mean in a game where I saw it. It is very subtle and I hope you can spot it in the screen well enough.

tHcVFUL.png


Edited by GothSeiDank, 12 November 2013 - 06:41 AM.

If you say "pls", because it is shorter than "please", I will say "no", because it is shorter than "yes"
http://nightlight2d.de/

Sponsor:

#2 tonemgub   Members   -  Reputation: 634

Like
1Likes
Like

Posted 12 November 2013 - 07:08 AM


I already got the scan-line and vignette shader (GLSL)

Where did you get it from?

 

Anyway, you can create the bent screen effect by using a bump map.



#3 GothSeiDank   Members   -  Reputation: 156

Like
0Likes
Like

Posted 12 November 2013 - 09:06 AM

How would such a bump map look like?

Also, Game Maker can't really utilize bump maps :S. 

Is there any other solution, except drawing a picture over the surface and faking it?


If you say "pls", because it is shorter than "please", I will say "no", because it is shorter than "yes"
http://nightlight2d.de/

#4 InvalidPointer   Members   -  Reputation: 1371

Like
2Likes
Like

Posted 12 November 2013 - 09:28 AM

I would generally not use the term 'bump map' to describe it as that's a reference to an entirely different, very specific technique that just so happens to use a similar-looking texture as an input.

 

In simpler terms, you're using a distortion shader that adds or subtracts a value to the texture coordinate (distinct from the value sampled from a texture at that texture coordinate, though the actual offset would be taken from a second texture) depending on the location onscreen. tonemgub's soltution is basically to paint a texture that contains offsets gradually pointing towards the middle of the screen, with decreasing magnitude as you move away from one of the corners. It would work, but is likely more computationally expensive than it could be.

 

Fortunately, folks have already worked out how to do most of this with math. If you're interested in a really detailed CRT monitor simulation, give this neat site/shader a gander.


Edited by InvalidPointer, 12 November 2013 - 09:30 AM.

clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.

#5 powly k   Members   -  Reputation: 632

Like
0Likes
Like

Posted 12 November 2013 - 09:29 AM

Bump mapping is a lighting effect and completely unrelated. You just want to add some offsets to where you read your texture from in the GLSL shader - where you have something like texture(textureUniform, uv); try uv*=strength; texture(textureUniform, vec2(uv.x*sqrt(1.0-uv.y*uv.y*.5),uv.y*sqrt(1.0-uv.x*uv.x*.5))/strength); or some other similar mapping from square to disc instead.


Edited by powly k, 12 November 2013 - 09:29 AM.


#6 tonemgub   Members   -  Reputation: 634

Like
0Likes
Like

Posted 12 November 2013 - 01:28 PM


distortion shader

Yup, that's exactly what I was thinking of too, but I tried to put it in simpler terms and it came out wrong. Sorry.

 


uv*=strength; texture(textureUniform, vec2(uv.x*sqrt(1.0-uv.y*uv.y*.5),uv.y*sqrt(1.0-uv.x*uv.x*.5))/strength);

But is it really faster to use real time calculations instead of a pre-rendered texture for the distortion offsets? I always thought it was the other way around - texture sampling should be faster than these calculations, at least. You're doing the calculations every frame, whereas for the texture - it is only filled with the distortion offsets once.



#7 LorenzoGatti   Crossbones+   -  Reputation: 2525

Like
1Likes
Like

Posted 13 November 2013 - 04:27 AM

But is it really faster to use real time calculations instead of a pre-rendered texture for the distortion offsets? I always thought it was the other way around - texture sampling should be faster than these calculations, at least. You're doing the calculations every frame, whereas for the texture - it is only filled with the distortion offsets once.

Don't guess, measure. Run benchmarks with both versions of the shader applied to a set of computationally heavy cases of your game (e.g. multisampling and unusual amounts of overdraw to stress fragment processing, lots of geometry to stress vertex processing, artificially inflated texture number and sizes, etc.)
Produci, consuma, crepa




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS