Gosu Forums - Gosu News

Gosu 0.7.41 released

2011-12-17T04:33:59Z

Another tiny polishing update that is uploading right now.

• All: Fixed several subtle bugs in the transform stack
• All: Fixed flush() when inside transforms/clipping
• Linux: Fixed another PNG loading bug (thanks again, Jamer!)

If you have run into either of these three bugs, I hope this update fixes them. Just in time for Ludum Dare too!

Gosu 0.7.40 released

2011-12-13T18:28:50Z

I am also flushing between states - it's nice to have reusable states that don't Z-collide with the game. But I was lucky enough to only scroll in one of the states. :)

Yes, it is already fixed, I just need to package a release again. (Soon, Ludum Dare is impending after all!)

Gosu 0.7.40 released

2011-12-13T10:50:21Z

So it's supposed to work past .41 then? Strange, as it works in .38, just not in .40.

Ah well, I'll shuffle the code around a bit for the time being, although it results in a bit of a performance hit. My code is by no means optimized though, so I'm sure I could stand to eek out some efficiency elsewhere. I look forward to .41, it sounds like that's gonna be good one.

For those interested, here's what I'm doing. It's intended to draw gamestates in different "layers," such that each state has it's own z-index ordering.

@window.translate *@camera.offset do
  @stack[ACTIVE].each do |gamestate|
    if gamestate.visible?
      gamestate.draw @camera.zoom
      @window.flush
    end
  end
end

Gosu 0.7.40 released

2011-12-13T10:02:51Z

Do you use flush() somewhere? Up to the upcoming .41, flush() can only be used outside of clipping and transformations :(

Gosu 0.7.40 released

2011-12-13T04:37:51Z

Ok, finally got around to it. Here's the error.

ruby: ../GosuImpl/Graphics/DrawOpQueue.hpp:128: void Gosu::DrawOpQueue::popTransform(): Assertion individualTransforms.size() > 1' failed.
Aborted `

Ludum Dare #22 next weekend December 16th-19th

2011-12-11T23:22:36Z

Theme voting started already. Anyone in?

http://www.ludumdare.com/compo/ld-22-theme-voting-round-1-of-5/

Gosu 0.7.39 released

2011-12-02T18:46:08Z

That would be great ! But take the time needed, your work is still awesome

Gosu 0.7.39 released

2011-12-02T18:31:48Z

Oh...yeah well, that is impossible sadly :) It may work with a future render_to_texture function.

Gosu 0.7.39 released

2011-12-02T18:24:19Z

I was referring to Window#record ;)

Gosu 0.7.39 released

2011-12-01T20:51:41Z

translate does actually work with custom GL now. Just be sure to use gl(z) { code } instead of the old gl { code }.

Macros are also implemented using gl(z), and they respect transforms correctly.

Gosu 0.7.39 released

2011-12-01T20:27:42Z

Too bad it currently doesn't take Custom OpenGL Code :(
I hope it'll be possible in a coming version ;)

Gosu 0.7.39 released

2011-11-29T15:34:04Z

Also note that this only works in 0.7.40, so we are definitely in the wrong thread now. ;)

Gosu 0.7.39 released

2011-11-29T15:05:06Z

Yeah, I figured translate() was the solution there. Thanks a lot.

Gosu 0.7.39 released

2011-11-29T13:52:42Z

I got the impression that the only effect that the recorded size had was to affect how #draw_rot managed rotation and center_x/center_y. Other than that, the size is not relevant (And I tell Gosu that all my recordings are 1x1 because I don't need to rotate or center them and everything is fine :D).

Gosu 0.7.39 released

2011-11-29T10:17:45Z

That's what it used to do, and you didn't even have to pass width/height then. But the resulting values were hard to rely on so I made it manual. (e.g. what if you want to record a map, but this one block happens to an empty first row/column)

It always starts from (0, 0). You should draw what you want to draw all between (0, 0) and (width, height), but you can easily use translate() to do so.

Gosu 0.7.39 released

2011-11-29T05:18:45Z

So, how does this work exactly? There's a height and a width, but no x and y? What if I record images being draw at 2000,2000 or something like that? Is it somehow intelligent enough to cut out the 2000x2000 block of dead space?

Suddenly interested in this technique for the game I'm working on, but I have a larger bottleneck I need to get through first.

Gosu 0.7.39 released

2011-11-28T18:20:01Z

This is an amazing feature ! I was starting to use render to texture, but it seems that native Gosu will now do the trick ! Thanks again !

Gosu 0.7.40 released

2011-11-25T19:03:53Z

Yeah, that would be awesome. :D Linux, right? I haven't exactly tested it a lot in my VM before releasing.

Gosu 0.7.40 released

2011-11-25T15:37:05Z

Just updated to 0.7.40.

Not totally sure what's wrong, but it's broken for me. Sorry to be helpful and unhelpful at the same time, but I got a deadline to meet. Well, more of a personal milestone, but still. I'll try to post more detailed information later.

Gosu 0.7.39 released

2011-11-22T18:15:27Z

I'm not sure. Never implemented it, just used ;)

Gosu 0.7.39 released

2011-11-22T14:47:40Z

Isn't that the same as render-to-texture? I have no clue (yet) ;)

Anyway, I'll be focusing on the interface for a while now. Contributions on GitHub are welcome if there is a use case for them. (Unused code breaks within months, in my experience)

Gosu 0.7.39 released

2011-11-22T14:36:11Z

For this purpose, maybe enabling a backbuffer would be even more useful.
Do you plan to enable it sometime?

Gosu 0.7.39 released

2011-11-22T11:33:58Z

I really want to add render-to-texture too, but I think it would be even more misleading to make it related to macro recording - I think it should be a separate function. Some advantage of record-to-macro that couldn't be had with a proper texture:

• recording macros is super fast, independent of graphics drivers, unlike textures
• macros can be much smaller than textures in memory. If you want to e.g. record a large tile map, each tile is 144 bytes in the macro because it only references the existing tile Image. On a texture, you could only represent 6x6px in that space.
• macros scale up and rotate nicely like vector graphics do, textures become pixelated and blurry.

Maybe "like vector graphics" is really the right way to imagine them? idk :)

For my use cases (tile maps, skeletal animation) this makes them much better than textures. But now that they're there, the next cool feature will indeed be render-to-texture. Maybe that'd make the whole GLSL post-processing thing nicer too?

Gosu 0.7.39 released

2011-11-22T03:44:16Z

As I said, I'm not denying it's awesome, but if we can see it move onto actually being mutable as an image, that would be the real big step I think for Gosu. (One of the key features that really stands out both performance-wise AND graphics-wise)

Gosu 0.7.39 released

2011-11-22T02:50:13Z

Although it acts like an Image in Gosu, all that happens in record is that it stores a series of GL commands you are calling and can replicate exactly that at a later date (why jlnr calls it a "macro"). This is a small speed improvement in C++ but a massive, massive one in Ruby (since then you just have "many" operations in pure C++, not "many" Image#draws calling those same operations in Ruby). Brilliant for drawing large backgrounds from tiles, for example, which don't often change and need to be re-recorded.

Gosu 0.7.39 released

2011-11-22T00:35:19Z

I still feel like this whole record() business is misleading and very very strict in terms of what it can and cannot do.
I know this is a really useful feature, but I feel like this could be a stand-out feature for Gosu if we could (*ahem* you could...) figure out how to make the recorded data mutable like a texture.

Gosu 0.7.39 released

2011-11-21T21:57:50Z

well, I'll do my research with GL then :)

Gosu 0.7.39 released

2011-11-21T20:55:56Z

No, you can use raw GL for that though. You just have to call Graphics::flush() and then use any of the GL functions for copying the screen to memory (or was it textures? - not Gosu specific anyway).

Gosu 0.7.39 released

2011-11-21T20:32:11Z

so right now you can't "take screenshots" using this, can you?

Gosu 0.7.39 released

2011-11-21T20:24:59Z

Right, because recording is not the same as rendering to a texture. toBitmap() will throw an exception telling you that Macros cannot be converted into Bitmaps.

Rendering to textures has not been implemented yet. But if it was, you wouldn't need record anyway. :) There would be an equivalent pair of beginRenderingToTexture/endRenderingToTexture.

Gosu 0.7.39 released

2011-11-21T20:23:51Z

Thanks.

So this should work, right? (but it doesn't :P)


graphics().beginRecording();

// do some drawing ops.

auto_ptr ptr =  graphics().endRecording(1280,720);
Gosu::saveImageFile(ptr->toBitmap(), resourcePrefix() + L"screenshot.png");

Gosu 0.7.39 released

2011-11-21T19:54:24Z

Sorry, I was confused. They are both members of Gosu::Graphics and documented there:

http://www.libgosu.org/cpp/class_gosu_1_1_graphics.html

Gosu 0.7.39 released

2011-11-21T19:44:21Z

uhm, I'm sorry, but as it's not documented I didn't know how to use it.
Anyways, I can't see it as usable...

Gosu 0.7.39 released

2011-11-21T19:34:49Z

In C++, it is beginRecording() to start recording, then Gosu::Image(endRecording(width, height)) to construct an image from the result of the recording process. Both are member functions of Gosu::Graphics. (corrected)

Gosu 0.7.39 released

2011-11-21T19:01:28Z

As erisdiscord said, is record working?
I'm on C++ and 0.7.40 and still getting error C2039: 'record' : is not a member of MyWindow (class MyWindow : public Gosu::Window)

Gosu 0.7.40 released

2011-11-20T21:20:38Z

I guess it depends on whether rotate and scale are mutating methods or not. Since they won't mutate the underlying Image at least, I would've expected them to always be non-mutating. I think your middle code bit should be manipulated_image.translate!(1, 0). So for efficiency's sake, one could make it clear as img.rotate(6).scale!(2).draw(...), meh. :/

Gosu 0.7.40 released

2011-11-20T17:29:27Z

Not really. The standard way to manage chains like that is only to calculate when required by something like a draw (treat it something like a ruby iterator?).

Gosu 0.7.40 released

2011-11-20T17:26:11Z

Since I cannot stop you Ruby guys from keeping a reference to the "manipulated" image, that's the only way it'd make sense. But it'd also mean a new allocated object for every step in the chain. :( I will benchmark all the possibilities once I get there.

Gosu 0.7.40 released

2011-11-20T16:22:43Z

Oh, sorry, I thought we were getting img.draw x, y, z, scale: 2, rotate: 45, mode: :add in 0.8. I think I remember you mentioning you liked the idea of method chains though :(

The issue I have with img.rotate(6).scale(2).draw(x, y, z) is the probably performance issue of lots of ruby method calls every time I draw something (maybe not that important; sometimes it is hard to judge real CPU impact). However, if I can do manipulated_image = img.rotate(6).scale(2).translate(x, y) and then manipulated_image.translate(1, 0) and then manipulated_image.draw() at a later date, then I feel I am really winning :)

Gosu 0.7.40 released

2011-11-20T16:16:42Z

The hashes are only coming for constructors in 0.8, not Image#draw and friends. I haven't had time to do benchmarks yet either, but it seems we could have a modular drawing thing at the same performance cost. (img.rotate(6).scale(2).draw(x, y, z), which I scheduled for 0.9 :P)

Gosu 0.7.40 released

2011-11-20T13:22:23Z

In 0.8 the arguments would be hashes, so the "missing parameter" argument is a terribly short-lived one :).

Gosu 0.7.40 released

2011-11-20T10:02:57Z

Spooner brought this up too, but I am not convinced yet. With a shared base class, the interfaces of Image and Macro would be the same, except Macro wouldn't have #to_blob and #insert (the new interface for things like Texplay). #gl_tex_info could be there, but return nil as large Images already do. Or maybe BigImage could be a third class, but then calling Image.new to create it would be weird.

Or I could actually implement #to_blob and #update for Macro. (#to_blob would require render-to-texture to be there, #update is easy.) That would probably take the same amount of time and keep the class count down.

The annoying thing is that all the differences lie in the arguments to the methods, so it would actually be more correct if Macro had an interface that is similar but technically unrelated to Image, with the color and mode arguments missing because they won't ever work accurately. Usually they're at the end of the argument list...except for #draw_as_quad. So that wouldn't be super clean either.

Weird, weird, weird. :)

Gosu 0.7.40 released

2011-11-20T09:16:45Z

Perhaps it's time to refactor slightly: new base class (Drawable) that is inherited by Image and Macro. That way there's no worrying whether an image is actually an image, right? C:

At least once all the draw methods work for recorded macros.

Gosu 0.7.40 released

2011-11-19T22:27:27Z

Hotfix release:

• All: Fixed interaction between recording and transforms
• Linux: screenWidth/screenHeight also returns the size of the primary screen only (thanks again, JayThirtySeven)
• Linux/Ruby: Fixed linking error

The only things record cannot handle now are lines, triangles, clipping and custom GL, and the resulting image cannot generally be drawn with draw_rot or draw_as_quad/getData().draw(...).

Gosu 0.7.39 released

2011-11-19T11:13:54Z

It is a bit like rendering to a texture, but not really. It just groups a lot of drawing operations together. This is why you cannot draw_rot the resulting image yet, or tint it with colors (but this will be fixed). You can also not use Texplay on it.

Also, unlike rendering to a texture, it does not restrict you to drawing in the region between (0, 0) and (width, height). You need to use clipping for that.

Gosu 0.7.39 released

2011-11-19T05:34:05Z

Goodness. Record is working? I'm gonna have to dig out some of my old code one of these days and try it out. :D

Gosu 0.7.39 released

2011-11-19T04:18:16Z

Ooooh! That record thing sounds pretty nifty. So it's basically like getting a region from the screen and then being able to draw it?

Gosu 0.7.39 released

2011-11-19T00:57:18Z

Oh, and a note. If you call record within any transform, the outer transform will be applied to what is in the block. This makes sense in its own way, but will change, so don't rely on it :)

Gosu 0.7.39 released

2011-11-19T00:33:44Z

I'm using a fair bit of recording in Smash and Grab and it makes a massive difference to frame-rate (only about 3000 draws in 4 recordings though). Without it, I'd have to render everything to multiple images and mess around with a lot of code to manage that instead, because it would be unusable otherwise. Thanks for finally fixing it up properly - saved a lot of code over what I had to use for the undocumented version though it is likely to break other games that use it because it now works properly :D

Gosu 0.7.39 released

2011-11-19T00:15:10Z

This is a bit more of an experimental release, I have cleaned up the backend a lot, which conveniently made the long-undocumented record function work.

Let me know if performance has suffered in any way. If anything, Gosu should be faster now, but it doesn't feel faster in CptnRuby for me. (Might be my system.)

• All: Added Window#record(width, height).
• All: Removed an overcautious assert() from OGG file reading
• All: Fixed OGG files' destructor stopping unrelated songs
• Linux: Fullscreen only covers one screen now (thanks JayThirtySeven!)
• Ruby: Switched from rdoc to YARD

Note to GL hackers: Custom GL code now inherits Gosu's MODEL_VIEW matrix (applied transforms) as well as current clipping rect. If your code does not want this, you have to unset it manually. Also, if the current clipping area is empty while you call enqueueGL, the GL block is not run. I am open to debate this, it's a weird case. :)

record is a super-powerful, awesome feature, and there are countless ways to use and abuse it. In two sentences, you can just do @map_image = record(@map.width_in_pixels, @map.height_in_pixels) { @map.draw } once and then draw @map_image every frame. @map_image will behave like a single Image, but contain a vertex array of all your map tiles. One method call - @map_image.draw - will draw your whole map. This is a good optimization in C++ and a HUGE one in Ruby. Putting 120,000 calls to Image#draw inside a macro, I could still draw it at 60 Hz, and that would be one gigantic map. Try that with nested Ruby loops!

I wish it wasn't so hard to explain, I really need to adjust the CptnRuby script. :)