Giter VIP home page Giter VIP logo

ashton's Introduction

Welcome to Gosu!

Gosu is a 2D game development library for Ruby and C++.

The main website is www.libgosu.org. The source code, wiki, issue tracker and change log are all hosted on GitHub.

Gosu is released under the MIT license.

Getting Started

The best entry point into Gosu's documentation is the wiki home page. Try doing the tutorials there if you don't know how to get started, or look at existing projects in the Gosu Showcase.

Community

  • There is a lively Discord community.
  • If you want to discuss or announce something in a more permanent place than a chat room, we also have a message board.
  • Please file bugs and feature requests on GitHub.

ashton's People

Contributors

bil-bas avatar charlescui avatar jlnr avatar kyrylo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ashton's Issues

Error when importing gem

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.

Cache shader uniform values in Ashton

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

Undefined method 'z' for Window

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

Colorblind comparing in shaders

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

Original image:
image

Result:
result

Concluson: it replaces one of colors (bottom-right), but can't change the one in background.
My specs: Win 7 x64 GeForce GT540M

Use RbConfig::CONFIG['DLEXT'] instead of .so

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. :)

Alpha/Color issues with Gosu/Ashton

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.
screenshot_shader_off

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?)
screenshot_shader_on

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

Textures hardcoded to pixelate

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.

Shader uniform naming should be handled better

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!

Optimise fastcos/fastsin in particle engine.

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 %

Path issues with Ocra

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

Particle system segfaults

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!

Ashton::Texture#render interacts with other textures being rendered

I'm encountering some strange behavior when rendering textures.
Basically, when I render one texture, it interacts with any textures rendered previously.

Examples

Here's the most simple example of my problem:

Most simple example

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

Rendering onto another texture

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

Retroactive interaction?

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

Insanity with many textures

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... what?

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).

Installing is more complex than it needs to be

$ 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'

Texture size not getting set properly

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.

Dependency on outdated opengl in gemspec

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.

Issues installing gem

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?

Ashton post-processing does not respect Apple Retina displays

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:

image

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?

Error installing on OSX Mavericks

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?

Gem not working in 1.9.3 under Windows 7 64-bit

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.

Shader uniform value types should be handled better

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.

Shaders should support multitexturing

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).

Not working with opengl gem 0.9.0

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.

OpenGL not supported

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?

Unable to create a texture of size

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: in initialize_ ' 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: in initialize ' 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: in mask ' 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: in init ' 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: in each ' 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: in draw ' 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: in draw ' 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: in tick ' 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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.