Last active
August 29, 2015 14:06
-
-
Save rintaun/d4c9f0edfd8e1e0b2756 to your computer and use it in GitHub Desktop.
Ashton texture rendering interacts strangely with... well, everything.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
require 'gosu' | |
require 'ashton' | |
=begin | |
This test is basic proof that rendering one texture interacts with rendering others. | |
This will render a black screen, despite `secondary_buffer` never being drawn. | |
If you alter the order of the `primary_buffer` and `secondary_buffer` renders in #update, | |
then you will see the 250x250 red square render at 0,0 as expected. | |
=end | |
class TestGame < Gosu::Window | |
def initialize | |
super(500, 500, false) | |
end | |
def update | |
primary_buffer.render do | |
pixel.draw 0, 0, 0, 250, 250, 0xaaff0000 # RED | |
end | |
secondary_buffer.render do | |
pixel.draw 250, 250, 0, 250, 250, 0xaa00ff00 # GREEN | |
end | |
end | |
def draw | |
primary_buffer.draw 0, 0, 0 | |
end | |
end | |
TestGame.new.show |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
require 'gosu' | |
require 'ashton' | |
=begin | |
All of that remains the same if we try to render onto another texture, and then render that. | |
(Which isn't terribly surprising to me, but I don't know anything about OpenGL, so I'm not sure | |
that it shouldn't be?) | |
=end | |
class TestGame < Gosu::Window | |
def initialize | |
super(500, 500, false) | |
@screen = Ashton::WindowBuffer.new | |
end | |
def update | |
primary_buffer.render do | |
pixel.draw 0, 0, 0, 250, 250, 0xaaff0000 # RED | |
end | |
secondary_buffer.render do | |
pixel.draw 250, 250, 0, 250, 250, 0xaa00ff00 # GREEN | |
end | |
@screen.render do | |
primary_buffer.draw 0, 0, 0 | |
end | |
end | |
def draw | |
@screen.draw 0, 0, 0 | |
end | |
end | |
TestGame.new.show |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
require 'gosu' | |
require 'ashton' | |
=begin | |
The crazy thing is that it actually seems like it's effecting things... retroactively? | |
Even if we render `primary_buffer`, then **immediately** draw it to @screen, | |
a subsequent render to `secondary_buffer`, which is never drawn, messes that up. | |
In this example I have made `secondary_buffer` not render for 1 second at the beginning | |
to show this effect more clearly. | |
=end | |
class TestGame < Gosu::Window | |
def initialize | |
super(500, 500, false) | |
@screen = Ashton::WindowBuffer.new | |
end | |
def update | |
primary_buffer.render do | |
pixel.draw 0, 0, 0, 250, 250, 0xaaff0000 # RED | |
end | |
@screen.render do | |
primary_buffer.draw 0, 0, 0 | |
end | |
if Gosu::milliseconds > 1000 | |
secondary_buffer.render do | |
pixel.draw 250, 250, 0, 250, 250, 0xaa00ff00 # GREEN | |
end | |
end | |
end | |
def draw | |
@screen.draw 0, 0, 0 | |
end | |
end | |
TestGame.new.show |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am aware that I am not clearing the textures before rendering to them; that just introduces even more craziness.
Also, this is just the case with two textures. It gets even more incomprehensible when a larger number of textures and sprites are thrown into the mix.