gosu / ashton Goto Github PK
View Code? Open in Web Editor NEWSpecial graphical effects and other extensions for the Ruby/Gosu game library (⚠️ unmaintained)
License: MIT License
Special graphical effects and other extensions for the Ruby/Gosu game library (⚠️ unmaintained)
License: MIT License
I made a shader that checks if pixel has a given color and if yes, it replaces it with another one (so basically a color replacement). The issue is that it doesn't work for all colors. OpenGL ignores some colors as if it couldn't see them. Example one is RGB: 0/91/32 (and even ones with similar values).
Below the example shader and program. Link to example: https://www.dropbox.com/s/sjkw70bjsdzpde4/colorblind.zip?dl=0
Shader code:
uniform sampler2D in_Texture;
varying vec2 var_TexCoord;
void main()
{
vec4 color = texture2D(in_Texture, var_TexCoord);
vec4 test1 = vec4(0.0/255.0, 91.0/255.0, 32.0/255.0, 1); //the bugged color
vec4 test2 = vec4(44.0/255.0, 210.0/255.0, 190.0/255.0, 1); //random working color
if (color == test1) {
gl_FragColor = vec4(1,1,1,1); //change to white if green
return;
}
else if (color == test2) {
gl_FragColor = vec4(0,0,0,1); //change to black if cyan
return;
}
else
gl_FragColor = color;
}
Program code:
require 'gosu'
require 'ashton'
include Gosu
class GameWindow < Gosu::Window
def initialize
super(640, 480, false)
self.caption = "Test Game"
@image = Image.new(self,'image.png')
shader = Ashton::Shader.new(fragment: "shader.frag") #initialize shader
new=Ashton::Texture.new(@image.width,@image.height) #make a texture for processing
shader.enable
new.render{@image.draw(0,@image.height,0,1,-1)} #draw image on texture using shader
shader.disable
@image=new.to_image #replace old image with new one
end
def draw
@image.draw(32,32,0) #draw the resulting image
#cyan (44,210,190) is replaced with black
#green (0,91,32) is replaced with wh... oh ,wait. It's not replaced :(
end
end
GameWindow.new.show
Concluson: it replaces one of colors (bottom-right), but can't change the one in background.
My specs: Win 7 x64 GeForce GT540M
Works fine on win32, of course.
Error is: ld: duplicate symbol _rb_cColor in color.o and ashton.o for architecture x86_64
reported by amimeyet_
Regardless of whether Gosu::enable_undocumented_retrofication
has been run, Ashton::Texture
is always drawn pixelated, not smoothly.
Solution is to allow for :pixelated => boolean option on creation, otherwise use the default based on whether enable_undocumented_retrofication has ever been run.
I added the workaround to $gosu_blocks on all examples, but unless it uses Window#gl, $gosu_blocks is never created by Gosu. Just need to remove the "workaround" on examples that don't use shaders!
I'm encountering some strange behavior when rendering textures.
Basically, when I render one texture, it interacts with any textures rendered previously.
Here's the most simple example of my problem:
The following code consistently renders a black screen for me, despite secondary_buffer
never being draw. If you alter the order of the primary_buffer
and secondary_buffer
renders in #update
, then it draws the 250x250 red square at (0,0) as expected.
require 'gosu'
require 'ashton'
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
That remains the same if I try to render onto another texture, and then render that. (This isn't terribly surprising to me, but I know essentially nothing about OpenGL, so I'm not sure that it shouldn't be surprising...)
require 'gosu'
require 'ashton'
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
The craziest thing is that it actually seems like it is effecting things retroactively. Even if I render primary_buffer
and then immediately draw it to @screen,
a subsequent render to secondary_buffer
, which is never drawn, messes that up.
In the following example, I have made secondary_buffer
not render for 1 second at the beginning to show this effect more clearly.
require 'gosu'
require 'ashton'
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
I honestly thought this was a pretty simple interaction, and so I decided to make an example with a bunch of textures to show it. But to my surprise, it worked as expected (well, the colors were slightly dimmer than expected, but we can't have everything, can we?). So I removed some, and my head exploded, because apparently it's all rather more complicated than I thought.
require 'gosu'
require 'ashton'
class TestGame < Gosu::Window
def initialize
super(600, 600, false)
@a = Ashton::WindowBuffer.new
@b = Ashton::WindowBuffer.new
@c = Ashton::WindowBuffer.new
@d = Ashton::WindowBuffer.new
@e = Ashton::WindowBuffer.new
@f = Ashton::WindowBuffer.new
@g = Ashton::WindowBuffer.new
@h = Ashton::WindowBuffer.new
@i = Ashton::WindowBuffer.new
@renders = [
proc { @a.render { pixel.draw 0, 0, 0, 200, 200, 0xaaff0000 } }, # RED at ( 0, 0)
proc { @b.render { pixel.draw 200, 0, 0, 200, 200, 0xaa00ff00 } }, # GREEN at (200, 0)
proc { @c.render { pixel.draw 400, 0, 0, 200, 200, 0xaa0000ff } }, # BLUE at (400, 0)
proc { @d.render { pixel.draw 0, 200, 0, 200, 200, 0xaaffff00 } }, # YELLOW at ( 0, 200)
proc { @e.render { pixel.draw 200, 200, 0, 200, 200, 0xaaffffff } }, # WHITE at (200, 200)
proc { @f.render { pixel.draw 400, 200, 0, 200, 200, 0xaaff00ff } }, # PURPLE at (400, 200)
proc { @g.render { pixel.draw 0, 400, 0, 200, 200, 0xaa00ffff } }, # CYAN at ( 0, 400)
# proc { @h.render { pixel.draw 200, 400, 0, 200, 200, 0xaa333333 } }, # DARKGRAY at (200, 400)
# proc { @i.render { pixel.draw 400, 400, 0, 200, 200, 0xaa999999 } }, # LIGHTGRAY at (400, 400)
]
@draws = [
proc { @a.draw 0, 0, 0 },
proc { @b.draw 0, 0, 0 },
proc { @c.draw 0, 0, 0 },
proc { @d.draw 0, 0, 0 },
proc { @e.draw 0, 0, 0 },
proc { @f.draw 0, 0, 0 },
proc { @g.draw 0, 0, 0 },
# proc { @h.draw 0, 0, 0 },
# proc { @i.draw 0, 0, 0 },
]
end
def update
@renders.map &:call
end
def draw
@draws.map &:call
end
end
TestGame.new.show
But the real icing on the cake is when you uncomment @h
and @i
above and change update to @renders.shuffle.map &:call
(spoiler alert: you probably shouldn't do this if you are prone to seizures).
It's worth noting that shuffling the draws does not seem to affect anything.
So, am I just doing something wrong? Or is my computer broken? Or is this a big bug?
For reference, I'm running on Windows 8.1 with Ruby 1.9.3 and the latest versions of Ashton (from Git) and Gosu (0.8.3).
Segfault after about 10 seconds in the particle system demo. Only seems to arise in OSX/Linux (Was originally developed in Windows which didn't seem to care!).
reported by jlnr - thanks!
I'm having some issues compiling the native extensions on mavericks - am I missing a dependency?
Fetching gem metadata from https://rubygems.org/...
Resolving dependencies...
Using gosu 0.8.6
Using opengl 0.9.1
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby extconf.rb
creating extconf.h
creating Makefile
make "DESTDIR="
compiling ashton.c
In file included from ashton.c:8:
In file included from ./ashton.h:15:
In file included from ./common.h:7:
./GLee.h:760:20: error: typedef redefinition with different types ('ptrdiff_t' (aka 'int') vs 'intptr_t' (aka 'long'))
typedef ptrdiff_t GLintptrARB;
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:55:18: note: previous definition is here
typedef intptr_t GLintptrARB;
^
In file included from ashton.c:8:
In file included from ./ashton.h:15:
In file included from ./common.h:7:
./GLee.h:761:20: error: typedef redefinition with different types ('ptrdiff_t' (aka 'int') vs 'intptr_t' (aka 'long'))
typedef ptrdiff_t GLsizeiptrARB;
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:56:18: note: previous definition is here
typedef intptr_t GLsizeiptrARB;
^
2 errors generated.
make: *** [ashton.o] Error 1
Im running with ruby version:
ruby -v
ruby 2.0.0p481 (2014-05-08 revision 45883) [universal.x86_64-darwin]
I believe this is the default now?
As title says. For reproducing, try running texture_render_example in fullscreen. It glitches out. Happens in Ashton 0.1.4
shader.frog = 1.0
fails if in_Frog is a integer type
shader.fish = 1
fails if in_Fish is a float type
Should try again if pushing ints works with floats (or vica versa). Also should cache the type after pushing a value, so there aren't more errors.
I've uploaded a basic example to github
https://github.com/bigtunacan/nature
The gist of it though is I have created an Ashton::Texture with width/height matching my Gosu::Window. When I draw directly to the Gosu::Window things will draw correctly, but if I draw to the Ashton::Texture images will be cut off in though they should be within the bounds of the texture.
In the example I have linked to if you run it you will see an image that is cut off as described.
I have something that looks like this
def initialize
self.texture = Ashton::Texture.new 640, 480
end
then in my update
def update
self.texture.render do
self.img.draw(150, 0, 0)
end
end
The image is 89 px wide, but it will be cut off even though the texture width is set to 640.
reported by amimeyet_
Trying to use texture unit 1 to perform shader-based stencilling, finds that the texcoords don't vary and the texture is always black. Not sure what the issue is, but I thought it worthwhile simplifying this for users with an api like:
Shader#multitexture(1, texture, :mask)
which will do something like:
shader[:mask] = 1
@textures[1..-1].each_with_index do |image, i|
glActiveTexture [GL_TEXTURE0, GL_TEXTURE1, GL_TEXTURE2, GL_TEXTURE3][i]
glBindTexture GL_TEXTURE_2D, @textures[1].id
end
glActiveTexture GL_TEXTURE0
Perhaps also use a default vertex shader based on how many texture units are required (or just have 2 in the default one is probably reasonable, since requiring more than that is unlikely).
Ashton fails to load because dynamic libraries have a .bundle
extension on OS X (actually that is not generally correct, but that is what Ruby uses):
begin
RUBY_VERSION =~ /(\d+.\d+)/
require "ashton/#{$1}/ashton.so"
rescue LoadError
require "ashton/ashton.so"
end
RbConfig::CONFIG['DLEXT']
give you the file extension. Sorry for not sending a pull request, I just realised I could do this while typing this issue. :)
At the moment, a uniform can be accessed as "in_VarName" or :var_name (used, in Shader#initialize, for example). Alternatively one can call (dynamic) methods to set them, such as shader.var_name = 5
Definitely shouldn't be treating strings and symbols differently, because that will confuse people who think they are the same thing :D
Either should enforce a naming convention or allow anyone to use whatever, but the latter would mean you'd be doing shader.in_VarName if you wanted to be consistent with a common GLSL standard. Meh, all messy!
reported by lol_o2
It was this standard 'no such file to load: ashton' bug. You just compile game with Ocra and this happens when you want to run it. I fixed it somehow by copying these lines from gosu.rb to ashton.rb:
require 'rbconfig'
if defined? RUBY_PLATFORM and
%w(-win32 win32- mswin mingw32).any? { |s| RUBY_PLATFORM.include? s } then
ENV['PATH'] = "#{File.dirname(__FILE__)};#{ENV['PATH']}"
end
Right now Ashton has a dependency on Gosu ~> 0.7.45, but I think it would work just fine with the just-released Gosu 0.8.0. I would suggest ~> 0.7, since I don't plan on breaking backward compatibility before 1.0. (Not even then, actually :) )
Originally reported on the Gosu board: http://www.libgosu.org/cgi-bin/mwf/topic_show.pl?pid=7953#pid7953
There isn't a way to read uniform values, at least not in older versions of glsl, so it would be nice to cache them. E.g. so you can do shader.frog += 1
Mostly doesn't work :(
Hi,
Trying to install the gem and getting the following error:
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.
/opt/boxen/rbenv/versions/2.0.0-p353/bin/ruby extconf.rb
creating extconf.h
creating Makefile
make "DESTDIR="
compiling ashton.c
In file included from ashton.c:8:
In file included from ./ashton.h:15:
In file included from ./common.h:7:
./GLee.h:765:14: error: typedef redefinition with different types ('int' vs 'void *')
typedef int GLhandleARB;
^
/System/Library/Frameworks/OpenGL.framework/Headers/gltypes.h:65:15: note: previous definition is here
typedef void *GLhandleARB;
^
1 error generated.
make: *** [ashton.o] Error 1
Any ideas?
Hello,
Trying to build a shader and started getting this error:
ashton/lib/ashton/mixins/version_checking.rb:9:in `check_opengl_version': OpenGL 2.0 required to utilise Ashton::Shader (Ashton::NotSupportedError)
from /Users/jairosa/projects/joseairosa/ashton/lib/ashton/shader.rb:40:in `initialize'
I'm, running on a mac machine and got OpenGL installed.
Any ideas?
Using Ruby 1.9.3 (RubyInstaller) with "DevKit" for native gem compilation.
gem install ashton
seems to work, but the resulting ashton.so prompts Ruby to say:
"%1 is not a valid Win32 application"
(And I had to edit ashton.rb to get that far; the rescue clause of the version check is broken). When I look at ashton.so in a hex editor, it looks like an ELF instead of a Windows DLL.
Hello.
I wanted to use Ashton with this OpenGL wrapper so I changed the code in order to make it work. And well, it works pretty well if I fix this error: <ASHTON_PATH>/lib/ashton/shader.rb:109:in `enable': undefined method `z' for #<TestWindow:0x305d168 @__swigtype__="_p_Gosu__Window"> (NoMethodError)
.
So, I just tried adding some lines to the Window class:
def z(&block) ; yield ; end
And it worked! Well... only for some things. I can post_process(){ ... }
but I can't add a shader to a specific image and the post processed blocks are ignoring z depth.
I looked for some def z ; ... ; end
in the code but found nothing ; so what can I do ? What's that method and how can I rewrite it ?
Thank you for your attention.
Best regards,
TzA
Suggested by ker:
modulo is bad, rather use two while loops, one for <0 to += 360 and one for >360 to -= 360
especially modf is bad
convert to integer, the do the loops in integer
saves you both modf and %
Running the ashton examples on my 2012 MacBook Pro Retina, the gosu window is created at four times the size (given 640 x 480, OS X gives gosu a 1280 x 960 viewport), however the Ashton post-processing still draws in the original 640 x 480 window. Below is a screenshot of the bloom example exhibiting this issue:
Is it possible to instruct Ashton to do post-processing over a larger area, or possibly detect the presence of a retina display and adjust accordingly?
I want to do per-pixel lighting of sprites using a normal map, but I don't know how to get both diffuse and normal maps into the fragment shader at once using Ashton.
Is this already possible by e.g. assigning a Gosu::Image or Ashton::Texture to the shader as a uniform?
If you look at ashton.gemspec, you can see this line:
s.add_dependency 'opengl', '~> 0.9.0'
It add dependency on old opengl gem version, which is no longer supported in Ruby 2.0.X (the newest one is 0.10.0). The dependency is artificial, because the new version works just fine. My hacked version of Ashton has this line removed, so I can use it with newest Ruby version.
$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin12.1.0]
$ gem -v
1.8.24
$ gem install ashton
ERROR: Could not find a valid gem 'ashton' (>= 0) in any repository
ERROR: Possible alternatives: gaston
$ gem install ashton --version 0.0.1alpha
Fetching: opengl-0.8.0.pre1.gem (100%)
Building native extensions. This could take a while...
Gems should always start with at least minor version (0.1.0) in order to avoid having to manually type in the version to install it.
Apparently, Ruby doesn't realize that 0.0.1 is actually greater than 0.0.0 O_o
EDIT: Ignore the above.. I'm dense.
Also, gosu
should be a runtime dependency for the gem. Add the following line to your ashton.gemspec
:
spec.add_dependency 'gosu', '~> 0.7'
Also getting the following: cannot load such file -- ashton/ashton.so
/Users/ryguy/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- ashton/ashton.so (LoadError)
from /Users/ryguy/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from /Users/ryguy/Code/Ruby/Games/ashton/lib/ashton.rb:8:in `rescue in <top (required)>'
from /Users/ryguy/Code/Ruby/Games/ashton/lib/ashton.rb:4:in `<top (required)>'
from /Users/ryguy/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from /Users/ryguy/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
I'm having some issues with getting Gosu and Ashton to render clean images.
Without Ashton I've found out that drawing a Gosu::Image on any non-whole position or up/down scaling makes some dark edges appear. It's not noticeable on a blurry picture.
With Ashton a shader that does nothing on the pyramides it messes up the colors and alpha channel. (gl_FragColor = texture2D(in_Texture, var_TexCoord); I'm not opengl savvy, am I doing something wrong?)
I've made a test case project here: https://github.com/Aerotune/ashton_alpha_issue
I'm using Gosu 0.7.50, Ashton 0.1.3 and I'm running Mac OS 10.7.5
Some player reported an error in one of my games. Whenever he starts a level, he gets this exception:
Unable to create a texture of size 768x672
'
C: / Users / Ulis / Desktop / Adventure Island Ruby / Adventure_Island / data / scripts / ashton / texture.rb: 73: ininitialize_ ' C: / Users / Ulis / Desktop / Adventure Island Ruby / Adventure_Island / data / scripts / ashton / texture.rb: 73: in
initialize '
C: / Users / Ulis / Desktop / Adventure Island Ruby / Adventure_Island / data / scripts / ashton / window_buffer.rb: 5: ininitialize ' C: / Users / Ulis / Desktop / Adventure Island Ruby / Adventure_Island / data / scripts / map.rb: 48: in
new '
C: / Users / Ulis / Desktop / Adventure Island Ruby / Adventure_Island / data / scripts / map.rb: 48: inmask ' C: / Users / Ulis / Desktop / Adventure Island Ruby / Adventure_Island / data / scripts / map.rb: 42: in
modify_mask '
C: / Users / Ulis / Desktop / Adventure Island Ruby / Adventure_Island / data / scripts / map.rb: 217: ininit ' C: / Users / Ulis / Desktop / Adventure Island Ruby / Adventure_Island / data / scripts / map.rb: 26: in
block in draw '
C: / Users / Ulis / Desktop / Adventure Island Ruby / Adventure_Island / data / scripts / map.rb: 26: ineach ' C: / Users / Ulis / Desktop / Adventure Island Ruby / Adventure_Island / data / scripts / map.rb: 26: in
draw '
C: / Users / Ulis / Desktop / Adventure Island Ruby / Adventure_Island / data / scripts / game.rb: 113: indraw ' C: /Users/Ulis/AppData/Local/Temp/ocrB9AE.tmp/src/Adventure_Island.rb: 85: in
draw '
C: / Users / Ulis / Desktop / Adventure Island Ruby / Adventure_Island / data / scripts / console.rb: 71: indraw ' C: /Users/Ulis/AppData/Local/Temp/ocrB9AE.tmp/lib/ruby/gems/2.2.0/gems/gosu-0.11.2-x86-mingw32/lib/gosu/patches.rb: 152: in
tick '
C: /Users/Ulis/AppData/Local/Temp/ocrB9AE.tmp/lib/ruby/gems/2.2.0/gems/gosu-0.11.2-x86-mingw32/lib/gosu/patches.rb: 152: intick ' C: /Users/Ulis/AppData/Local/Temp/ocrB9AE.tmp/src/Adventure_Island.rb: 118: in
(ignore the fact that Ashton is embedded in game, it's some old release)
The game at this line creates a WindowBuffer. I've seen someone has this error years ago and I believe it's related to old graphic card, but I'm reporting in case it can be fixed somehow.
You can see the game here: https://youtu.be/6uvSeOi4HOA (download in description)
I'm having some trouble with using the gem.
I run gem install ashton
and it installs ashton-0.1.4
fine.
However, when I try to require "ashton"
in my Ruby code, I get this error:
C:/ruby193/lib/ruby/gems/1.9.1/gems/ashton-0.1.4/lib/ashton.rb:8:in `require_rel
ative': cannot load such file -- C:/ruby193/lib/ruby/gems/1.9.1/gems/ashton-0.1.
4/lib/ashton/ashton.so (LoadError)
from C:/ruby193/lib/ruby/gems/1.9.1/gems/ashton-0.1.4/lib/ashton.rb:8:in
`rescue in <top (required)>'
from C:/ruby193/lib/ruby/gems/1.9.1/gems/ashton-0.1.4/lib/ashton.rb:4:in
`<top (required)>'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:60:i
n `require'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:60:i
n `rescue in require'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:35:i
n `require'
from C:/Users/Jacob/Documents/GitHub/pew-pew/main.rb:6:in `<main>'
When I opened up the gems directory, I found the ashton.so
file in the /lib/1.9
directory. When I copied it into /lib
, I got a new error:
C:/ruby193/lib/ruby/gems/1.9.1/gems/ashton-0.1.4/lib/ashton.rb:8:in `require_rel
ative': 193: %1 is not a valid Win32 application. - C:/ruby193/lib/ruby/gems/1
.9.1/gems/ashton-0.1.4/lib/ashton/ashton.so (LoadError)
from C:/ruby193/lib/ruby/gems/1.9.1/gems/ashton-0.1.4/lib/ashton.rb:8:in
`rescue in <top (required)>'
from C:/ruby193/lib/ruby/gems/1.9.1/gems/ashton-0.1.4/lib/ashton.rb:4:in
`<top (required)>'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:60:i
n `require'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:60:i
n `rescue in require'
from C:/ruby193/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:35:i
n `require'
from C:/Users/Jacob/Documents/GitHub/pew-pew/main.rb:6:in `<main>'
I'm running Ruby 1.9.3 on Windows 8.1.
As of version 0.9.0, the maintainers of the opengl extension have split GLU and GLUT into separate gems. As a consequence, the Ashton examples give "uninitialized constant" errors.
I installed said gems, and tried adding 'require 'glu'" and 'require 'glut'" to the top of ashton.rb, but it didn't help.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.