Rewriting Planes and Sprites

● ARCHIVED · READ-ONLY
Started by Milena 9 posts View original ↗
  1. I've always write on making Planes and Sprites as like:

    def create_image(image_name) @image = Plane.new @image.bitmap = Cache.picture(image_name)endIs there another way to create planes, sprites and bitmaps? I saw the one on create_background on Scene_MenuBase, but are there ways to deal with it with Planes and Sprites too?
  2. The purpose of making "def create_background" is if the developer / scripter wants to alias / overwrite that method.

    I don't really understand the whole question of this topic.

    If you want to create Planes / Sprites just create it using [dot]new

    You don't need to separate it in other method if you want to make an exclusive script as long as it works and you could understand your own script.
  3. Hi there. I am going to rephrase my question, normally if I want to make a plane, I use Plane.new, if I want to make a sprite I would make it Sprite.new...

    are there other ways to make a plane or a sprite without using Sprite.new or Plane.new alone?

    Like this way?

    #-------------------------------------------------------------------------- # * Create Background #-------------------------------------------------------------------------- def create_background @background_sprite = Sprite.new @background_sprite.bitmap = SceneManager.background_bitmap @background_sprite.color.set(16, 16, 16, 128) endor this:

    Code:
      #--------------------------------------------------------------------------  # * Create Snapshot to Use as Background  #--------------------------------------------------------------------------  def self.snapshot_for_background    @background_bitmap.dispose if @background_bitmap    @background_bitmap = Graphics.snap_to_bitmap    @background_bitmap.blur  end
  4. Those are just grouping purpose

    When I'm lazy, I usually do this kind thing

    class Scene_Something < Scene_Base  def start    super    # -------------------------------    @spr1 = Sprite.new    @spr1.bitmap = Cache.something    @spr1.x = 100    @spr1.y = 100    # -------------------------------    @spr2 = Sprite.new    @spr2.bitmap = Cache.something    @spr2.x = 100    @spr2.y = 100  endendIt doesn't really matter as long as it works.

    In other case, I usually do something like this

    class Another_Sprite < Sprite  def initialize(vport, image_name)    super(vport)    self.bitmap = Cache.somewhere(image_name)  endendSo, by calling this one line

    Another_Sprite.new(@viewport, "imagename")You not only create a new sprite object. But also assign the bitmap

    Does that makes sense?
  5. @Milena: Object#new ( this is the notation for methods, reciever#method_name ) is how you allocate and setup a new object instance. There is not another way of creating an object short of writing a C extension to ruby and making another way yourself.

    You could, however, write a method for Sprite or Bitmap to call new in a specific way:

    class Bitmap def self.new_zoomed(name, zoom_x, zoom_y) cache = Bitmap.new(name) zoom_rect = Rect.new(0, 0, cache.width * zoom_x, cache.height * zoom_y) bmp = Bitmap.new(zoom_rect.width, zoom_rect.height) bmp.stretch_blt(zoom_rect, cache, cache.rect) cache.dispose return bmp endendHowever, notice that my custom method uses Bitmap#new. The pipeline works like so:objectClass#new -> ObjectInstance#initialize -> #current_calling_method

    When you call #new on a Ruby class, it allocates space in the computer's memory to hold an instance of the class, a structure of identity if you will. Then it automatically calls #initialize on the allocated object, if the initialize method exists (if not it will use the default defined in Object, aka ruby's internals). The allocated and initialized instance is then returned and execution returns to the calling method (wherever you called #new from).

    So technically, you could write a method that aliases #new so you could call it something else, like 'init' or 'create' but ultimately you'd be better of just sticking with the default :)
  6. Fenix, the hash (#) is the standard notation for instance methods, not class methods. The new method is a class method, as it's called directly on the class to create an instance -- therefore, the notation becomes either Class.new or Class::new (although the dot notation has become the community standard for Ruby).


    Interestingly enough (and on-topic), new is a class method while initialize is an instance method (which makes perfect sense, really). Also, you forgot to mention the allocate method in the pipeline -- it occurs after the call to new, but before initialize. Of course, it's also generally unnecessary to define, but still an important part of object creation, as it allows processing to occur during the memory allocation phase.
  7. I mentioned allocation, just not the fact that it's an actual method; tey are usually implemented on the C side, and actually a lot of the allocate() methods for RGSS objects are hidden, thus me not mentioning them.


    From what I remember of my experimentation with pushing rgss' limits with ruby, I couldn't access the allocate methods short of some trickery using a dll. As for the class vs instance method notation, I read a topic (which I will definitely try to find for you!) responded to by Matz himself stating that :: and . aren't actually standard method representation, and in fact he meant # to be the separation notation between object and method, regardless of the type of method it is(class, instance, etc). the period is the actual syntactical notation that we use. :: works simply because of a weird (for lack of better word) flaw due to how ruby's internals were originally written and Matz left alone because it became a thing people used. Matz never intended it to be how you called a class method.


    Remember, classes are instances as well, not separate entities. They just have more functionality written in for them in the default. It's totally plausible to write your own class and module hierarchy not using the originals at all, it is just a pain to do so.


    Community standard is different from the language standard, and at one point :: was the community standard for class methods, until it was brought to light that it was in fact a fluke notation.


    EDIT: I understand why the community uses :: for class methods (to distinguish between the different 'types' of methods) but I thought I'd explain why I wasn't using it in my post above; simply because I follow the language standard that Matz outlined, not for any reason otherwise :p
  8. I don't follow the standards of the single creator of the language over the standards of the thousands of professionals who make use of it -- particularly when the notation of the creator is more ambiguous and less useful than the agreed-upon standards used by the majority of the global community. Not differentiating between class and instance methods in a language such as Ruby just strikes me as totally bizarre and unnecessarily vague. For instance, it's useful to know that you call glob on the Dir class directly rather than on an instance of it; if we're referring to all methods using #, that becomes ambiguous.


    In short, these community standards exist for a reason regardless of the author of the language and their own personal preferences -- creating the language doesn't automatically make them right.


    Still, glad to know you wrote it that way intentionally -- I just assumed that you weren't aware of the (current) notation standards.
  9. Wow, such information! Thanks FenixFyreX and Solistra. I think I have to review my Ruby codes for this and apply the things I've learned here. I was curious, because I saw some coders around here and on another forum that somehow uses the default Plane and Sprite but I also saw some others that are using another way, so I thought if there are other workarounds with it, turns out there are! Thank you so much :)