BkSmith - Mark's Quest v0.4

By Spooner Date 2012-10-09 22:11

Seemed a decent engine. Important thing is to scale the screen so I can see it ;)

Use Gosu#enable_undocumented_retrofication to stop it from blurring, run at 640x480 (or 800x600) res and scale it down with:

class Game < Chingu::Window
  def draw
    scale 0.5 do
       super
    end
  end
end

By kuehkookies Date 2012-10-10 04:31 Edited 2012-10-10 07:01

Thanks for the advice :)
Well, I did all of those on older computer so I shrunk the resolution of the window (once was 544x416 pixels) to keep frame rate above 45.

By the way, is there a way to scale the whole window (from 384x228 to twice of it or 640x480) without messing all of objects inside of it?
I scaled all of objects into twice of its size (by using factor attribute), ended up every objects that should be 'landed' on terrains falling down and messing sword-swinging animation as well.

Frankly I considered to remake all of the image resources into twice of their size to brings back the game into 544x416 pixels or 640x480 pixels dimension, which will take extra effort for me. However, if anyone know how to scale the window as I demanded above, let me know. :)

Regards,

EDIT: Based on some game samples, I figured the self.factor gives the exact thing I needed. Now I'm remaking sample levels to fits the scaled objects. Thanks anyway :D

By Spooner Date 2012-10-10 13:49

Never use Gosu's factor attribute unless on a single object - it isn't consistent and it is very slow. Instead, scale the whole window, as I originally suggested, which keeps your coordinates completely consistent and is about twice as fast as individually scaling every sprite!

By kuehkookies Date 2012-10-10 18:02

I scaled the window as you suggested, and it runs fast now thanks to your tips. :)
Nice one! :D

However, I got a problem about viewport.
The viewport runs as if the window isn't scaled, which makes the background scrolls when the player reach the edge of screen, not when the player is at the center of the screen. I tried to trick the viewport by overriding the center_around method but it didn't resulting a good one; the scrolling became weirder! :p
I'll commit fresh codes if someone asks for it BTW.

Any suggestion about the viewport?

By Spooner Date 2012-10-10 21:15

Ah, I never use the Chingu Viewport, instead preferring to manage scrolling myself. It isn't that complicated code really.

But yes, the Viewport assumes that the window isn't scaled. You could override Window#width and #height to return the scaled window size, rather than the actual window size (that is 320 wide rather than 640 wide). Alternatively you could tweak center_around as you say:


def center_around(object)
      self.x = object.x * @factor_x - 320 / 2
      self.y = object.y * @factor_y - 240 / 2
end

Here, factor_x/y would be 1 since you aren't scaling the individual sprites, but the whole window.

By kuehkookies Date 2012-10-11 11:49

Thanks, now the viewport works as it should be. :D
Now I'll concern the game's performance, since I'll use lots of objects in a room. Also I'll do some resources, too.

Hope this one will finish sooner :)

By captainclams Date 2012-10-14 02:41

Hey, I would love to try this out, but when I try and run I get this error:

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in gem_original_require': ./lib/player.rb:428: syntax error, unexpected '.', expecting kEND (SyntaxError)
    .then  {@image = @animations[:shoot].next}
     ^
  from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in require'
  from main.rb:8
  from main.rb:8:in `each'
  from main.rb:8

I'm on Mac OS X. Screens look great though, looking forward to trying it out.

By jlnr (dev) Date 2012-10-14 06:07

I would guess that the game requires Ruby 1.9. You can either wrap it in the Gosu container .app if you are familiar with that, or you can install Ruby 1.9 with rvm.

By Spooner Date 2012-10-14 15:22

This isn't a 1.9 issue, but rather a lack of Bundler issue ;)

The game requires gem install chingu --pre (and no non-release candidate version installed) since it just does "require 'chingu'". The author needs to use a Bundler Gemfile to ensure that the end user is running the correct Chingu version.

However, if using the correct Chingu version, you'll find that that doesn't work in 1.8 (it uses 1.9 hash syntax) so you need 1.9 to play anyway!

By captainclams Date 2012-10-15 02:46

For some reason my rvm had defaulted back to using 1.8. However, after making sure I was using 1.9, and installing chingu --pre, I'm now getting this error:

/Users/paulmeskers/.rvm/gems/ruby-1.9.3-p194/gems/texplay-0.4.3/lib/texplay/texplay.bundle: [BUG] Segmentation fault
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin12.2.0]

Followed by a long stacktrace. My gem list is:

bundler (1.2.1)
chingu (0.9rc9, 0.9rc7, 0.8.1)
crack (0.3.1)
diff-lcs (1.1.3)
gosu (0.7.45 universal-darwin, 0.7.41 universal-darwin)
mime-types (1.19)
rake (0.9.2.2)
rest-client (1.6.7)
rspec (2.11.0)
rspec-core (2.11.1)
rspec-expectations (2.11.3)
rspec-mocks (2.11.3)
rubygems-bundler (1.1.0)
rvm (1.11.3.5)
texplay (0.4.3)

Cheers, and thanks for the help so far.

By Spooner Date 2012-10-15 03:13

Since the code just does a require "chingu", it will always pick 0.8.1 over 0.9rc*. You can get past it if it uses Bundler, but it doesn't, so you literally have to have the --pre version as the only one on the machine (well, in that Ruby installation) so it is the only one it can pick.

As to the texplay issue, I can't help you. Any number of things could be the cause of that... 0.4.3 should be solid in Ruby 1.9 - presume it doesn't give any clues about what it was doing in the stacktrace?

By captainclams Date 2012-10-22 01:40

Figured it out, my texplay was never installed correctly -- it had failed to install due to the most recent Mountain Lion update not defaulting the location of gcc4.2 to /usr/bin. This was the fix:
http://cczona.com/blog/2012/07/fix-for-make-usrbingcc-4-2-no-such-file-or-directory/

Cheers

By kuehkookies Date 2012-10-15 07:10

I've added Gemfile, as Spooner recommends to make end-user gets the right library.
Bundler makes me taking a look for a while, but it works well here :)

These are rather new for me. Sorry for inconvenience. :)

By Spooner Date 2012-10-15 14:24

Thanks for that, though you've not actually made it use Bundler properly.

You haven't specified the gem versions you need, e.g.
gem 'chingu', '~> 0.9rc9' # Use 0.9rc9 or higher

To ensure the program uses bundler to load only the bundled gems, at the top of main.rb: require 'bundler/setup'

You'll see, if you run it like that, that it will then generate a Gemfile.lock, which will contain details of the exact gems and versions that the user will be forced to use (based on your system). You should commit this file too for applications.

By kuehkookies Date 2012-10-15 15:02

Firstly, I'm sorry because this is my first time to use Bundler, so that's why I missed that point. :D
BTW I've committed the Gemfile and Gemfile.lock as well, also I've added the bundler require at the main.rb.

Thanks for the tips, and the help this far. :)

By Spooner Date 2012-10-15 15:34

That looks great, but I'd recommend using specific versions (the version you develop with) for all your gems. Not as important as the Chingu version though.

As a random suggestion, I'd recommend avoiding using all those globals in your code. Rather than $game_bleh, add an attribute to your Game window and access via $window.bleh (Chingu automatically sets $window to the gosu Window).

By jlnr (dev) Date 2012-10-16 06:46

To add another opinion, I prefer to just specify the names in the Gemfile without a version. If you ever run gem update and realize that everything is broken, then you either revert the Gemfile.lock or you take the time to make everything work with the latest gem versions. Or if you are in a hurry and only need to update one gem, you can use gem update gemname.

By Spooner Date 2012-10-16 14:24

Fine until you abandon it, one of your 20 used gems breaks (e.g. going up a major or minor version) and no-one can remember what version of what needs to be different (OK, a stretch, but just limiting Gosu to "~> 0.7.45" prevents a lot of completely unnecessary issues).

By jlnr (dev) Date 2012-10-16 15:35

But then, how do you find out when Gosu 0.8, or chipmunk 2.0 or any other major version comes out? I know that this is not bundler's responsibility, but I find it to be a nice place to check. :)

By Spooner Date 2012-10-16 19:38

I dunno, I prefer to make major upgrades very manually, since unless I really need them, I don't want to risk them breaking stuff. This is opposed to just updating for patches, which you still do if you specify a range of valid gem versions to update to. But still, you raise a valid point about it, since after all, you expect the end-user not to mess with the lock-file and in either case you have complete control over gem versions.

Enjoying the complete sidetrack, kuehkookies?

By kuehkookies Date 2012-10-17 01:01

Actually yes, even though I must make all of resources and completing the whole game. I noted the suggestions you posted and has been implemented in the system. :D
For now the game runs well, and I'll try linking some rooms to simulate a stage.

By Spooner Date 2012-10-17 01:14

Oh, another FPS hint is that setting the caption every frame is actually quite slow. I do it during development, but it is another thing that is dragging you down (only by a few FPS, but it is a measurable amount of slowdown). You don't see it in fullscreen anyway...