Bottomless Mine v.1.0-beta

By jlnr (dev) Date 2010-11-10 00:56 Edited 2010-11-10 00:58

What do you want to happen with that resolution in fullscreen? You can either center the game using translate(){} and clip_to, or you can scale it up using scale(){}.

The problem with the ruby-opengl script is that noone really knows how to get it to work and the solution changes every few weeks.

Looks like an interesting game though. Maybe not casual enough for what I am used to lately (I first thought of Spelunky when I heard the name) :)

By RavensKrag Date 2010-11-10 04:24

Any idea what's causing the slowdown? From what I've seen using Gosu, this seems to happen when making a lot instances of of Gosu::Image. If this is your problem, perhaps you could refine the code somehow? This sometimes happens to me when I use TexPlay. Can't really say anything more specific without looking at the code though ^_^;

By lol_o2 Date 2010-11-10 14:48

Who forfended you to look into code? But rewriting it won't change anything. Or TexPlay is too slow for such actions or I can't use it.
And to this resolution: when running fullscreen applications, it changes the system resolution. Window just doesn't fit the whole screen and clipping can't change it. But it's only a few pixels.

By jlnr (dev) Date 2010-11-10 16:01 Edited 2010-11-10 16:03

But you can use a standard resolution (800x600) and then do the scale, or the translation.

Future Gosu versions will do the scale automatically. (Linux already does.)

By banister Date 2010-11-10 16:37

The new caching options makes it so you won't suffer this slowdown when using TexPlay.

Gosu::Image.new(window, file, :caching => false)

or for global affect:

TexPlay.set_options :caching => false

Use this on images you dont' intend to manipulate and you won't suffer the downtime TexPlay takes to cache the image

By lol_o2 Date 2010-11-10 17:40

But I'm manipulating these images. Uncaching is good to speed up loading time, my code each frame makes new image and draws a few circles. Possibly with OpenGL I could make it much faster.
And if future Gosu versions will make the scale automatically, I will wait for it :)

By RavensKrag Date 2010-11-11 08:56

Hmm... are the circles the same size each frame but in different places? Then you could just draw them as separate Gosu::Image instances instead of compositing them into one image. However, I assume you would have already though of that. If the circles are of different sizes, you could scale the Gosu::Image used to hold the circle to the correct size when calling #draw. I am currently using this latter method to draw simple shadows in my game.

By RavensKrag Date 2010-11-11 08:59 Edited 2010-11-11 09:05

I was merely saying that I didn't have time to look into your code at that moment. But I didn't think you were distributing source for some reason. I apologize for my incorrect assumption. I knew you were using ruby, but thought you were using the rubinius implementation to compile the code, thus eliminating the need to distribute source. This seems to be fairly popular decision, and thus my assumption.

However, I have actually downloaded the code now, so I suppose I'll take a look.

By RavensKrag Date 2010-11-11 09:12

Oh... actually, the game seems to generate a segfault in TexPlay on my machine. Here's a link to the error message. I put it up on pastebin as it's a bit long. http://pastebin.com/WLFZq2LB

By lol_o2 Date 2010-11-11 09:53

You say that Rubinius can "hide" the code? Maybe I'll use it, because I wanted to show the code only in 1st demo.
To these circles: my code is making a black screen (darkness) and then makes on it transparent circles (lights). I don't think it's possible with Gosu.
And I don't know what is your error. I'm using Windows.

BTW As I wrote at the beginning, I'll need some help with this project . So, is there any graphician on this forum? Because I need good animations for player etc., I'm not so good in such things.

By RavensKrag Date 2010-11-11 09:59

Ah yes, so I think my solution will work for you as well. Here's my algorithm.

Make a circle of a moderate size in TexPlay. ("moderate" depends on the size of your other sprites)
Compute the scale needed to generate the shadow needed (or in your case, light)
Draw the circle using Gosu::Image#draw and passing the appropriate scale factors for x and y.

This way, you only need to create one circle. However, I think there might be a problem if you scale the image too much, as the edges might get too choppy. Haven't gotten to dealing with that problem yet. Just thought of this solution the other day myself, and haven't had time to extensively test it, but from what I've seen it should be considerably faster, and perhaps use less memory.

By banister Date 2010-11-12 13:03

can you tell me:

* What version of Gosu you're running (also see if upgrading Gosu fixes the segfault)
* What operating system you are running
* What exact version of Ruby you are running
* If the segfault happened immediately or only after some time

thanks

:)

By RavensKrag Date 2010-11-12 19:35

I'm using the latest version of Gosu, on Ubuntu 10.04, 64-bit. My ruby version is ruby 1.9.1p378 (2010-01-10 revision 26273) [x86_64-linux], as stated by ruby -v. The segfault happens immediately upon starting this particular application.

I am writing a game of my own using TexPlay, and it does not have this problem. Normally when TexPlay crashes for me, I get some sort of useful error about how I made the image too big or something. Though, occasionally TexPlay just eats through my memory and crashes my computer without any useful error. But that's a topic for another thread ^_^;

By banister Date 2010-11-12 21:17

ok, get the new 0.3.1 gem and tell me if it still crashes :)

By RavensKrag Date 2010-11-12 22:45

Nope, no change whatsoever.

Also, note to lol_o2, your code is quite obfuscated, from what I've looked at o_O; Particularly specjal.rb. It looks more like C than Ruby. I like one-liners as much as the next guy, but I really think you should space out some of that stuff. I have a feeling some of that stuff is to deal with collision detection, but man... I can't make heads or tails of it. Wouldn't it be better to get some abstraction in there? Idk, that's just my opinion. I'm using Chipmunk just so I don't have to deal with collision detection ^_^;

By banister Date 2010-11-13 08:25

Can you give me a C backtrace from gdb?

By RavensKrag Date 2010-11-13 16:19

I believe there is a C backtrace included in the segfault message I posted earlier. Will that not do?

Just to be certain the error is the same, here is the latest error message. http://pastebin.com/udsz8hwb

By banister Date 2010-11-13 17:55 Edited 2010-11-13 18:13

The line from texplay.rb that's supposedly causing the crash is this:

obj = original_new(*args, &block) # this just calls Gosu::Image.new()

The C backtrace also shows the function responsible for the segfault is in gosu.so. Based on this I suspect the problem is in Gosu, not TexPlay.

However if you could get a full backtrace from gdb it may contain more information that the ruby backtrace does not have. Do this:

gdb ruby
r bottomless_mine.rb
(wait for crash)
bt
(and gist the result :)

Thanks!

By RavensKrag Date 2010-11-13 21:40

Ok, here's your gist with the backtrace info.
https://gist.github.com/675673

By banister Date 2010-11-13 21:51

Thanks. Yeah it looks like it's a Gosu issue.

By Spooner Date 2010-11-14 21:25

I also had it segfault on Sound#initialize.

I used to have a similar problem with Chingu, since Gosu segfaults on Linux when a file-name isn't correct, but Windows raised an error (and remember, Linux is case-dependent so more likely to have bad path names if you are porting from a case-independent OS).

By RavensKrag Date 2010-11-15 07:11

I had a hunch that this error had something to do with filenames, so that makes sense to me. The hunch comes from file names/paths screwing up my code as well.

By lol_o2 Date 2010-12-06 20:32

Did anyone managed how to make this OpenGL working? I will need it soon.

By lol_o2 Date 2010-12-10 15:37

I posted the newest OpenGL error (with this "not found") on main Ruby forum. Maybe they know how to fix it. The real problem is, that this solution poster previously is not working for Ruby 1.9.2. So I installed Ruby 1.9.1 and it's now working.
This time I made mirrors. I needed this OpenGL for running DevIL. I changed the screenshot method to able setting width.
This line: $screen.screenshot(width=[81920-$game.scx,768].min).to_gosu($screen).draw(81920-$game.scx+width,576,0,-1,-1) makes screenshot each frame, changes to Gosu image and draws in specified place. Effect is awesome: http://img406.imageshack.us/img406/7530/mirror.png But I'm writting this because of some problem (I'm putting aside awful lags). I just started using DevIL/OpenGL, maybe I'm doing something wrong, or it's this library's issue. It's showed on the screenshot above: the mirror is drawn on the top. No matter how Z I type, it covers everything. And I don't know what's wrong.
And another problem I probably had with TexPlay in my previous project. I used it to make lights, but drew some time, it was making the game crash. I figured why (this time with DevIL): these screenshots in each frame are using more and more memory (RAM). After some time, game just stops and crashes. I don't know so much TexPlay or DevIL to realise why is it happening.

By jlnr (dev) Date 2010-12-10 19:28

Opening a gl{} block renders everything that has been drawn before to the screen, so you manually have to place it where it should be in the Z order. I hope this doesn't make your code too ugly. It wouldn't be too hard to have gl(z) do...end, it's just that nobody ever needed it before. Until now? ;)

By banister Date 2010-12-10 22:11

DevIL requires that you manually free images using the #free method in order to release memory.

By banister Date 2010-12-10 22:20

DevIL may also have been rendered superfluous given the new (undocumented) functionality in TexPlay. If you ask Spooner very nicely he may explain how to use render_to_texture() and Window#to_blob and friends :)

By Spooner Date 2010-12-10 23:55 Edited 2010-12-11 00:01

Yes, well, I agree that it might be better to render to a texture in this case. Here is a general idea of how you'd go about that:

def draw
# Draw into a buffer image, rather than directly onto the screen. THIS HAS TO OCCUR BEFORE you do regular drawing to the screen.
# the image can't be larger than 1022x1022
@buffer ||= TexPlay.create_image(...) # size of actual game area (not including mirrored bit).

@buffer.clear # Make sure there is nothing in the buffer.

$screen.render_to_texture(@buffer) do
# Draw everything into the @buffer image as you would normally do to the screen.
# What you'd normally put directly in #draw
   @background.draw(...)
   @sprites.each {|s| s.draw(...) }
   @font.draw(...)
end

@buffer.draw(...) # draw the image one way on the screen.
@buffer.draw(...) # draw the image the other way on the screen.
end

Anyway, that is just a framework to get you started (it ONLY requires texplay). I have NO idea about the amount of lag this will cause, but it might well be a lot less than the opengl/devil route and since you always reuse a single image as the buffer, you never need to worry about running out of memory.

By lol_o2 Date 2010-12-11 09:09

Maybe it's a good idea, but it's .to_texture, without render, and it requires 7 parameters, not 1. But I don't know how parameters. I typed anything and it made black screen... Maybe there's a way to make it good, but FPS was ~2x smalled than with my previous method. So maybe I'll try to make it with OpenGL if it's possible.

By Spooner Date 2010-12-11 12:03

I am afraid that it _is_ #render_to_image and it takes one parameter (and one hashed parameter). Not sure what you've found there...

Example of use: example_window_render_to_image.rb

EDIT: Banisterfiend tells me that #to_texture is the C function that #render_to_image wraps. Don't use it directly! Also, you might be using an older version of TexPlay. Make sure you have updated it AND cleaned all the old versions out.

By banister Date 2010-12-12 01:42

Alternately, couldn't he just Gosu::Image.load_tiles($screen) the window...since Window implements to_blob?
Do you remember the API for Window#to_blob? i forget... :P

By lol_o2 Date 2010-12-28 19:23

I was working with the code last 2 days and at last I made good mirrors using only OpenGL. Previously FPS was falling below 10 with two mirrors at once, now I have 40-50 FPS. I only need Gosu to make able Z-ordering for GL drawing. These mirrors won't be better without it.
More problem I have with lights. Only simple and useful thing I found is color mask. Or I used it wrong, or ruby-opengl has this feature incorrect. The code looks like this:

glEnable(GL_BLEND)
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
glColorMask(true, true, true, false)
glColor(1, 1, 1, 1)
glRect(0,0,384,288)
glColorMask(false, false, false, true)
glColor(1, 1, 1, 0.5)
glRect(0,0,384,288)

It's only a test code. But it should draw translucent rectangle. However it makes it opaque. Does anybody know something about it?

And as I wrote before, I described ruby-opengl gem problem on Ruby forum, however I don't understand the answer :/ (Topic)

By jlnr (dev) Date 2010-12-29 07:17

> I only need Gosu to make able Z-ordering for GL drawing

I just moved this issue way up on my list since I got asked about it on IRC too.

By jlnr (dev) Date 2011-01-08 23:34

> I only need Gosu to make able Z-ordering for GL drawing

Implemented in 0.7.26 and worked in my test. I moved a glClear() through the Z space to hide lower Z levels. Very interesting, hope it works for you. :)

By lol_o2 Date 2011-01-09 18:01

Thanks for new function, it works perfectly. :D
But I still don't know what with other problems.

By lol_o2 Date 2011-03-13 10:41

Game updated

And again some note to OpenGL:
At last I found a good method to make the lights. But it's not working with Gosu :( I mean the stencil function. Is it going to be fixed? Because for now I made an ugly cheap effect for this.

By jlnr (dev) Date 2011-03-13 14:23

What can I fix? Is it that I don't allocate memory for the stencil buffer when I set up OpenGL?

BTW: You are developing on Windows and you have a pretty big game going on, right? Did you notice any crashes with the new audio library? There seems to be a bug that doesn't happen with only one or two test sounds. (That is what I am hunting down right now)

By lol_o2 Date 2011-03-13 17:55

The only problems with the new audio library are not working midis and unable to change playing speed for samples. I haven't got any crash with it.

By jlnr (dev) Date 2011-03-13 18:26

MIDI support is doable, but sample speed should already work. Does it not work at all or is the accepted value range just smaller?

By lol_o2 Date 2011-03-13 18:57

Checked it and this speed works, but max is only 2.

By jlnr (dev) Date 2011-03-14 05:27

That is what I read somewhere but never confirmed, does that make a practical difference? :)

By lol_o2 Date 2011-03-14 12:33 Edited 2011-03-14 13:53

Yes, my code is using greater values. But it's not a big problem, I can fix it.

EDIT:
Already fixed using few sounds with different speed. (but previously it sounded better)
And I forgot to tell about important issue with Gosu. The problem with mouse. It happens in editor. I'm using .button_down? to draw tiles, but sometimes when I press the button and game lags, the button stays pressed even when it isn't. For example when I had a save button and clicked it, editor stopped until the map was saved. But when it started again, the mouse button was working as pressed and the tiles was drawing, but the button wasn't pressed. To stop this lag it's needed to press it again.
I hope it's good explained :)

By lol_o2 Date 2011-03-24 14:07

Looks like I have some TexPlay issue. I posted this game on the other forum and players there are writing about problem with non solid walls. I also saw this once. To make solid map, game is making a mask image for each room and every tile is splicing to mask on the start. The problem seems to be that sometimes tiles are not splicing. I see it rarely, but to cause this, you need to splice newly created image (image.splice(Image.new)). However my current code is preloading every tileset, so now I don't know what's the problem.

By lol_o2 Date 2011-07-24 20:17

Game updated, go to top

And BTW, the music problem seems to be caused by changes with Audiere in Gosu 0.7.30. I downgraded to version 0.7.28 and works good.

By lol_o2 Date 2012-02-01 19:29

Well, after small break, the game is updated.
New version has some important changes.

By chase4926 Date 2012-02-02 21:42

Just so you know, ocra doesn't hide the source code at all.
It's just extracted to a temporary folder whenever the application is run.

By MCMayor Date 2012-02-03 06:14

Could you include a walkthrough so it's quicker to test? I've had no luck trying to beat it alone. I'm stuck at the bottom of a hole surrounded by 2 doors I don't know how to open and 3 enemies I don't know how to defeat. It's right and down from the start.

By lol_o2 Date 2012-02-03 09:18

Maybe I'll think about a walkthrough or make some things more visible. But at the start, there are 4 secret passages:
First above the lower left door (which is somewhat visible)
Second, some sections later, shoot the crate next to the ruby
Third is the floor with 2 spiders
And fourth, breakable wall above the wooden platform
Next few areas are rather obvious.

By lol_o2 Date 2012-07-15 19:55 Edited 2012-07-15 21:13

Game is finished :) (well, almost). Download at top of topic

This release has at last ending and full map and it's fully tested and has only 2 known bugs (or 1). I included source code, because it's pointless to hide it when using OCRA.
Now I'm waiting for Ashton to be released to get rid of slow and bugged TexPlay and improve performance. Since there's no .mod support in newest Gosu, game is compiled with last best working 0.7.28, which sadly, freezes game when using OpenGL methods (sometimes).
BTW, this may help with mikmod: http://opensource.creative.com/pipermail/openal/2008-November/011358.html

So have fun. Testing game took me 26 hours to complete and I died >700 times :/ Report any errors etc.